एक-पेज ऐप में, गलत URL (404 त्रुटियों) से निपटने का सही तरीका क्या है?

Question

मैं वर्तमान में कोणीय का उपयोग कर एक वेब अनुप्रयोग लिख रहा हूं, लेकिन मुझे लगता है कि यह प्रश्न क्लाइंट साइड (as angular does) पर रूटिंग करने वाले क्लाइंट-साइड जावास्क्रिप्ट फ्रेमवर्क पर लागू होता है।

एकल पृष्ठ ऐप में, गलत URL से निपटने का सही तरीका क्या है?

कुछ प्रमुख साइटों को देखते हुए, मुझे लगता है कि यदि आप https://mail.google.com/mail/ से नीचे कोई यादृच्छिक URL टाइप करते हैं तो जीमेल इनबॉक्स पर रीडायरेक्ट करेगा। यह सर्वर-साइड (http 300 कोड के साथ) या क्लाइंट-साइड होता है, इस पर निर्भर करता है कि गलत पथ # वर्ण से पहले या उसके बाद है या नहीं। दूसरी तरफ, ट्विटर किसी भी अवैध यूआरएल के लिए वास्तविक HTTP 404 दिखाता है। एक तीसरा विकल्प एक "मुलायम" 404, एक पूरी तरह से क्लाइंट-साइड त्रुटि पृष्ठ दिखाने के लिए होगा।

ये समाधान विभिन्न स्थितियों के लिए उपयुक्त प्रतीत होते हैं। ट्विटर ट्विटर उपयोगकर्ताओं और ट्वीट्स के लिंक वास्तविक लिंक होने के लिए चाहता है, इसलिए लोग उन्हें साझा कर सकते हैं, उन्हें समाचार लेखों आदि में पोस्ट कर सकते हैं, इसलिए यह महत्वपूर्ण है कि अमान्य लिंक इस तरह से पहचाने जाएं (यदि मेरे पास एक ट्वीट के टूटे हुए लिंक हैं मेरी वेबसाइट, एक साधारण क्रॉल मुझे बताएगा)। दूसरी तरफ, जीमेल में, आपको अपने इनबॉक्स में लिंक साझा करने की उम्मीद नहीं है, और मुझे यह भी यकीन नहीं है कि लिंक वास्तव में स्थायी/लगातार हैं: ऐसा लगता है कि यूआरएल अपडेटिंग ज्यादातर ब्राउज़र इतिहास नेविगेशन के उद्देश्य से कार्य करता है एकल पृष्ठ ऐप। नरम त्रुटियों को देने का तीसरा दृष्टिकोण जीमेल के समान स्थितियों के लिए उपयुक्त हो सकता है, लेकिन जहां कोई उचित "डिफ़ॉल्ट" पृष्ठ नहीं है।

इस लंबी शुरूआत के बाद, यहाँ कुछ विशिष्ट प्रश्न हैं:

• यह कभी स्वीकार्य एक 404 त्रुटि के बजाय एक "सॉफ्ट" त्रुटि पृष्ठ देने के लिए है, या एक एकल पृष्ठ एप्लिकेशन को हमेशा की ओर ही रीडायरेक्ट असली 404 अगर यूआरएल अमान्य है?
• जीमेल का कोड पूरी तरह से बगफ्री हो सकता है, लेकिन अगर इसमें एक बग है जो अमान्य लिंक की ओर जाता है जो इनबॉक्स पर वापस रीडायरेक्ट करना समाप्त करता है, तो यह किसी त्रुटि पृष्ठ से उपयोगकर्ताओं के लिए और भी भ्रमित हो सकता है। वहां अधिकांश वेब ऐप्स के लिए, जिन्हें जीमेल के रूप में भी परीक्षण नहीं किया गया है, क्या एक त्रुटि पृष्ठ दिखाना बेहतर होगा?
• सिंगल-पेज ऐप्स के लिए वास्तविक 404 को लागू करने के लिए, सर्वर-साइड पर रूटिंग तर्क को डुप्लिकेट करना आवश्यक लगता है। क्या इसके आसपास कोई रास्ता है?
• 404 पर रीडायरेक्ट करते समय, मुझे लगता है कि उपयोगकर्ता उस यूआरएल को देखने में सक्षम होना चाहिए जिसने त्रुटि को संभवतः यूआरएल बार में देखा है। एचटीएमएल 5 इतिहास एपीआई के साथ, मुझे लगता है कि यह उपरोक्त वर्णित सर्वर-साइड रूटिंग के साथ संयुक्त वर्तमान पृष्ठ (गलत यूआरएल के साथ) को फिर से लोड करके पूरा किया जा सकता है। ऐसे ब्राउज़र के लिए जो इसका समर्थन नहीं करते हैं या हैशबैंग नोटेशन का उपयोग करते समय, यह संभव नहीं लगता है। सभी ब्राउज़रों का समर्थन करने का सबसे अच्छा तरीका क्या है?

Answer 1

tl; डॉ: ड्रॉप hashbang समर्थन और PJAX व्यवहार की तरह के लिए चुनते हैं, तो आप एसईओ के बारे में परवाह।

क्या आप कोई ऐप या वेबसाइट बना रहे हैं? यदि वेबसाइट आपको 404 वापस करने की आवश्यकता है ताकि आप Google को भ्रमित न करें। यह वास्तविक 404 होना चाहिए न केवल पृष्ठ का एक संदेश दिखाएं (यानी 200 संदेश "पृष्ठ नहीं मिला" बहुत बुरा है)। इसके अलावा आप किस ब्राउजर का समर्थन करने की देखभाल करते हैं?

मेरी राय यह है कि पूरे हैशबैंग सर्वर साइड प्रतिपादन से बचा जाना चाहिए (यानी बुरा Google एसईओ #! हैक)। या तो असली पुशस्टेट का उपयोग करें या पूरे पृष्ठ को पुनः प्रस्तुत करें यदि यूआरएल उन ब्राउज़रों के लिए बदलता है जो पुशस्टेट का समर्थन नहीं करते हैं (हैश चेंज नहीं)।

अब कारण यह मायने रखता है कि एक #! एक 404 वापस कभी नहीं करना चाहिए क्योंकि यह भावना और इसकी असंभव नहीं है क्योंकि सर्वर कभी नहीं चल रहा है बाहर जावास्क्रिप्ट के साथ #! के बाद क्या हो जाता है सर्वर साइड नकल करने के लिए है।

इस प्रकार यदि आप वास्तव में एसईओ की परवाह करते हैं तो मैं पीजेएक्स की तरह कुछ करता हूं और रूटिंग के लिए केवल सही पुशस्टेट का उपयोग करता हूं और फिर पुराने वेब 1.0 में विफल रहता हूं। नतीजतन मैं आपको सलाह देता हूं कि आप वास्तव में 404 पर #! (परंपरागत # ठीक नहीं होने चाहिए, क्योंकि पेज की सामग्री बहुत अधिक नहीं बदलती है)।

अंत में 404 ज्यादातर समस्या नहीं है बल्कि 30X यानी प्रतिक्रियाओं को पुनर्निर्देशित करता है। Thats क्योंकि ब्राउज़र स्वचालित रूप से रीडायरेक्ट को संभाल लेगा ताकि आपकी जावास्क्रिप्ट AJAX कॉल कभी भी 30X नहीं देख पाएंगे (उन्हें इसके बजाय रीडायरेक्ट प्रतिक्रिया मिलेगी ... यानी 200)। 30X प्रतिक्रियाओं को संभालने के लिए आपको प्रत्येक अनुरोध के लिए हेडर वापस भेजना होगा ताकि यह संकेत दिया जा सके कि पुनर्निर्देशित यूआरएल क्या था (यानी आपको क्या रीडायरेक्ट किया गया था) ताकि आप पुशस्टेट इतिहास को गड़बड़ न करें।

बेशक यदि आपको ट्विटर जैसे हैशबैंग का समर्थन करने की आवश्यकता है तो भी (and they are the ones that even killed hashbang), आप खराब एसईओ को कम करने की कोशिश करने के लिए Google Sitemaps और rel=nofollow का लाभ उठा सकते हैं।