JavaScript SEO: सुनिश्चित करें कि लिंक्स रिडरिंग के बाद भी बने रहें

Google JavaScript को एक एवरग्रीन Chromium के साथ रिडर करता है। समस्या शायद रिडरिंग की नहीं होती। समस्या उन लिंक्स की होती है जो कभी एंकर नहीं बनते, और उन पेजों की होती है जो एक क्रॉलर के पास न होने वाली स्थिति पर निर्भर करते हैं।

ArchiLinks research team · अद्यतन 2026-10-29

स्टोन फाउंडेशन से ग्लास संरचनाओं को जोड़ने वाला एक पुल जो लिंक सर्फाइवल का प्रतिनिधित्व करता है

एक क्रॉलर क्या देखता है

Googlebot ने मई 2019 से एक एवरग्रीन Chromium का उपयोग किया है। इससे यह सवाल समाप्त हो गया कि क्या यह आधुनिक JavaScript चला सकता है।

व्यावहारिक जोखिम पुराने हैं: रिडरिंग क्रॉलिंग के बाद होती है और इसमें देरी हो सकती है, क्लिक या लॉगिन के पीछे की सामग्री कभी प्रकट नहीं होती, और एक div पर onclick हैंडलर से बना लिंक्स लिंक्स नहीं होता। किसी वेबसाइट के पेजों पर backlinks जाँचने से पहले, जिन्हें हाल ही में React फ्रंटएंड पर ले जाया गया है, पुष्टि करें कि वे पेज अपनी सामग्री रिसपांस में या रिडर किए गए HTML में दिखाते हैं।

SSR, SSG, CSR: लिंक्स के लिए क्या बदलाव आता है

दृष्टिकोण	पहले रिसपांस में सामग्री	एंकर के रूप में आंतरिक लिंक्स	इसके लिए अच्छा
SSR (Next.js, Nuxt)	हाँ	हाँ, यदि आप असली एंकर का उपयोग करते हैं	बदलते डेटा वाले सार्वजनिक पेज
SSG या प्रीरेंडर	हाँ	हाँ	दस्तावेज़, ब्लॉग, मार्केटिंग पेज
CSR सिंगल-पेज एप्लिकेशन	नहीं, खोल खाली है	रिडरिंग के बाद ही	लॉगिन के पीछे डैशबोर्ड
हाइब्रिड (SSR होम, CSR एप)	प्रत्येक रूट के लिए	प्रत्येक रूट के लिए	ज्यादातर उत्पादों में एक सार्वजनिक पक्ष

परीक्षण एक: रॉ HTML बनाम रिडर किया गया HTML

यदि मुख्य लिंक्स पहले रिसपांस में प्रकट होते हैं, तो सवाल समाप्त है। यदि नहीं, तो हेडलेस रिडर के साथ तुलना करें।

bash

# raw response: are the links there?
curl -s https://new-shop.com/guides/ | grep -o '<a [^>]*href="[^"]*"' | head -20

# rendered DOM with headless Chrome
chrome --headless --dump-dom https://new-shop.com/guides/ | grep -c '<a '

एक बगीचे में पेड़ की जड़ों की जाँच कर रहा एक बगीचे का मालिक जो बाहरी बैकलिंक्स हेल्थ चेक का प्रतिनिधित्व करता है

बाहरी लिंक्स कहाँ आते हैं

एक रिडरिंग बग आपकी सामग्री छुपा सकता है। यह उन लिंक्स को मिटा नहीं देता जो अन्य साइट्स ने पहले ही दिए हैं।

Next.js, Vite या एक हेडलेस CMS पर माइग्रेशन के बाद, होस्ट के लिए toppages चलाएँ और 20 सबसे ज्यादा लिंक्स वाले URLs की स्थिति, कैनोनिकल और दृश्यमान सामग्री के लिए परीक्षण करें। इसे पहले करें। यदि एक पेज जिस पर 40 लिंक डोमेन हैं, एक खाली खोल या क्लाइंट-साइड 404 देता है, तो कुछ भी करने से पहले इसे ठीक करें, क्योंकि यहीं आपकी अधिकता आती है। आंतरिक बनाम बाहरी इक्विटी पेज दिखाता है कि उस सूची की तुलना अपने आंतरिक लिंक्स से कैसे करें, और माइग्रेशन चेकलिस्ट परीक्षण को एक लॉन्च योजना में डालता है।

फ्रेमवर्क्स अनुशासन से कम मायने रखते हैं। टेम्पलेट इंजन के साथ Express, एक WordPress थीम और एक Next.js एप रूटर सभी क्रॉल करने योग्य लिंक्स सर्व कर सकते हैं। यदि एक टीम एंकर भेजती है जो केवल क्लिक के बाद मौजूद होते हैं, तो हर एक विफल भी हो सकता है।

लिंक्स और रिडरिंग चेकलिस्ट

नेविगेशन और पेजिनेशन <a href> का उपयोग करती है, अन्य तत्वों पर क्लिक हैंडलर नहीं।
हर रूट एक असली स्टेटस कोड लौटाता है। सॉफ्ट 404 स्क्रीन को 404 लौटना चाहिए।
JavaScript द्वारा इंजेक्ट किया गया noindex या कैनोनिकल सर्वर रिसपांस में वाले से मेल खाता है।
पहले रिसपांस में फॉलबैक सामग्री असली पेज है, न कि एक स्पिनर जिसे Google इंडेक्स कर सकता है।
ऑथ कोड सार्वजनिक रूट्स पर क्रॉलरों को रीडायरेक्ट नहीं करता।
रिडरिंग के लिए आवश्यक CSS और JS फाइलें robots.txt में ब्लॉक नहीं हैं।
लेज़ी लोडिंग IntersectionObserver या नेटिव लोडिंग एट्रिब्यूट्स का उपयोग करती है, स्क्रॉल इवेंट्स नहीं।

सर्च कंसोल के सबूत को पढ़ना

सर्च कंसोल रिडरिंग के ज्यादातर सवालों का जवाब देता है यदि आप सही रिपोर्ट पूछें। URL Inspection का उपयोग करें, फिर View crawled page देखें।

तीन चीजों की तुलना करें: Google द्वारा फेच किया गया HTML, स्क्रीनशॉट, और वे पेज संसाधन जो लोड नहीं हो पाए। एक पेज जो आपके ब्राउज़र में पूर्ण दिखता है लेकिन स्क्रीनशॉट में खाली है, आमतौर पर एक स्क्रिप्ट त्रुटि या एक अनुमत न होने वाले संसाधन द्वारा ब्लॉक होता है, और समाधान आपकी सामग्री में नहीं, बल्कि आपके बिल्ड में है।

देरी को याद रखें। आज आप जो बदलाव भेजते हैं, वह इन्स्पेक्शन टूल में तभी प्रकट होता है जब Google URL को फिर से क्रॉल करता है, जिसमें दिन लग सकते हैं।

जब SSR मायने रखता है

सार्वजनिक पेज जो रैंक करने चाहिए: हाँ। डैशबोर्ड: नहीं।

यदि एक रूट ऑर्गेनिक ट्राफिक आकर्षित करना चाहिए, तो सामग्री को पहले रिसपांस में सर्व करें। यदि यह लॉगिन के पीछे है, तो जटिलता छोड़ दें। प्रोजेक्ट के बजाय रूट के अनुसार चुनें, और निर्णय को दस्तावेजित करें ताकि अगला डेवलपर उसे उल्टा न करे।

रिडर किए गए आउटपुट की तुलना करने के लिए रिच रिजल्ट टेस्ट और URL Inspection का उपयोग करें।
प्रत्येक फ्रेमवर्क अपग्रेड के बाद सर्च कंसोल लाइव टेस्ट से परीक्षण करें।

एक पहाड़ी पर दो घर जो प्रीरेंडरिंग बनाम क्लाइंट-साइड रिडरिंग दिखाते हैं

क्या सर्वर रिडरिंग आवश्यक है, या प्रीरेंडरिंग काफी है?

सर्वर रिडरिंग वैकल्पिक है। यह एक तरीका है ताकि पहला रिसपांस वह ले आए जो एक क्रॉलर को चाहिए। कई सार्वजनिक साइटें प्रीरेंडरिंग, एक स्टैटिक बिल्ड, या उन पेजों के लिए सर्वर रिडर के साथ वहाँ पहुँचती हैं जो मायने रखते हैं, और लॉगिन वाले हिस्सों को अकेला छोड़ देती हैं।

मान लीजिए कि आपके उत्पाद पेज और दस्तावेज़ सार्वजनिक हैं, जबकि डैशबोर्ड लॉगिन के पीछे है। पहले समूह को प्रीरेंडर करें। डैशबोर्ड को क्लाइंट-साइड छोड़ दें। सार्वजनिक पेज फिर अपने लिंक्स पहले रिसपांस में ले जाएँगे, और डैशबोर्ड उतना ही जटिल रह सकता है जितना उसे चाहिए।

केवल होम पेज का प्रीरेंडरिंग

होम पेज का प्रीरेंडरिंग पहले क्रॉल को हल करता है, लेकिन यह हर अन्य रूट को ब्राउज़र की प्रतीक्षा में छोड़ देता है। यदि होम पेज क्लाइंट-रेंडर किए गए कैटेगरी पेजों को लिंक करता है, तो उन पेजों पर लिंक्स अभी भी रिडरिंग पर निर्भर रहते हैं। केवल फ्रंट डोर नहीं, बल्कि हर टेम्पलेट की जाँच करें।

सार्वजनिक रूट्स की एक छोटी सूची उनके रिडर विधि के साथ रखें। सूची क्रॉल रिपोर्ट से तेज़ी से अंतर दिखाएगी।

क्या सर्वर रिडरिंग स्थानीय दृश्यता बदलता है

सर्वर रिडरिंग इस बात को बदल सकता है कि पहली सामग्री कितनी जल्दी प्रकट होती है, और पाठक इसे महसूस करते हैं। यह एक पेज को स्वयं एक स्थानीय क्वेरी के लिए प्रासंगिक नहीं बनाता। वे सिग्नल पेज की सामग्री, व्यवसाय विवरण और उस पर इशारा करने वाले लिंक्स से आते हैं।

रिडरिंग को उस तरीके के रूप में मानें जिससे वे सिग्नल एक क्रॉलर के लिए पठनीय बनते हैं, और API के साथ लिंक्स को अलग से मापें।

Vite और React एप्लिकेशन जो एक खोल सर्व करते हैं

हर पाथ के लिए एक HTML खोल सर्व करने वाला एक Vite बिल्ड सारा काम क्लाइंट पर डालता है। ऐसा एप कुछ क्वेरीज़ के लिए रैंक कर सकता है, लेकिन हर सार्वजनिक रूट की एक योजना चाहिए: इसे प्रीरेंडर करें, सर्वर पर रिडर करें, या हानि को स्वीकार करें और उसे लिख दें।

रीबिल्ड के बाद वेबसाइट रूट्स पर backlinks जाँचने से पहले, तय करें कि हर सार्वजनिक रूट अपनी सामग्री कैसे प्राप्त करता है। अन्यथा लिंक डेटा दिखाएगा कि बाहरी लिंक्स उन पेजों पर जा रहे हैं जिनमें कुछ नहीं है।

परीक्षण कि क्या एक रूट अपने लिंक्स दिखाता है

दो परीक्षण ज्यादातर सवालों का जवाब देते हैं। रॉ रिसपांस दिखाता है कि एक क्रॉलर को स्क्रिप्ट चलने से पहले क्या मिलता है। रिडर किया गया DOM दिखाता है कि एक ब्राउज़र उसके बाद क्या बनाता है। एक लिंक्स जो केवल दूसरे में प्रकट होता है, अभी भी एक लिंक्स है, लेकिन यह इस बात पर निर्भर करता है कि रिडरिंग ठीक से हो रही है या नहीं।

सर्च कंसोल में लाइव टेस्ट पढ़ना

URL Inspection से लाइव टेस्ट को एक बार में एक रूट पर चलाएँ। रिडर किए गए HTML को देखें, फिर उन संसाधनों की सूची को देखें जो लोड नहीं हो पाए। एक ब्लॉक स्क्रिप्ट एक पूरा नेविगेशन ब्लॉक हटा सकता है, और पेज बिना किसी दृश्य त्रुटि दिखाए पतला दिखता है।

फ्रेमवर्क अपग्रेड के बाद परीक्षण को दोहराएँ, क्योंकि एक नया डिफ़ॉल्ट बदल सकता है कि लिंक्स एक स्क्रिप्ट चलने से पहले या बाद में रिडर होते हैं। पेज इंडेक्स नहीं हुए गाइड कवर करती है कि जब एक रिडर किया गया पेज बाहर रहता है तो क्या करना है।

जब एक रूट रिडर करता है लेकिन सामग्री एक स्पिनर है

पहले रिसपांस में फॉलबैक ज्यादातर टीमों की उम्मीद से ज्यादा मायने रखता है। एक स्पिनर या एक खाली कंटेनर का मतलब है कि उस समय पेज क्रॉलर के लिए कोई टेक्स्ट नहीं ले जाता है। शीर्षक, परिचय और मुख्य लिंक्स को पहले रिसपांस में डालें, भले ही एक विस्तृत सूची बाद में लोड हो।

एक फॉलबैक जो असली पेज है, सरल रह सकता है। उसका एकमात्र काम सामग्री को धारण करना है जब तक बाकी आता है।

अपने लिंक्स खोए बिना एक क्लाइंट-साइड साइट ले जाना

बाहरी लिंक्स वाले रूट्स की सूची बनाएँ

होस्ट के लिए toppages चलाएँ और शीर्ष 50 URLs नोट करें। कोड बदलने से पहले उन रूट्स का परीक्षण पहले करें, ताकि आपको पता चले कि रीबिल्ड को क्या रखना है।

रॉ और रिडर किए गए आउटपुट की तुलना करें

प्रत्येक रूट के लिए, पुराने और नए बिल्ड में रॉ HTML और रिडर किया गया DOM जाँचें। किसी भी लिंक को नोट करें जो एक में मौजूद हो और दूसरे में नहीं।

क्लिक हैंडलर को एंकर से बदलें

नेविगेशन को एक उचित पता देकर असली एंकर बनाएं। स्पीड वर्क एक स्प्रिंट के लिए रुक सकता है, जबकि एक मिसिंग एंकर रूट को साइट में अपने रास्ते से वंचित कर देता है।

रिलीज के बाद परीक्षण को दोहराएँ

रिलीज के एक सप्ताह बाद, उसी रूट्स पर लाइव टेस्ट चलाएँ और परिणामों की तुलना पहले वाले से करें। अंतर दिखाएंगे कि रीबिल्ड ने आउटपुट को कहाँ बदला है।

क्लाइंट-साइड एप्लिकेशन में स्टेटस कोड और रीडायरेक्ट्स

एक सिंगल-पेज एप अक्सर एक नॉट-फाउंड स्क्रीन दिखाता है जबकि सर्वर 200 स्टेटस लौटाता है। Google ऐसे पेज को एक सॉफ्ट 404 मान सकता है, और गायब URL की ओर इशारा करने वाले बाहरी लिंक्स आपके लिए कम काम करते हैं। समाधान सर्वर पर है।

अज्ञात रूट्स जो अभी भी 200 लौटाते हैं

किसी भी गैर-मौजूद रूट के लिए सर्वर से एक असली 404 लौटाएँ, और क्लाइंट-साइड रूट से आने वाले विजिटरों के लिए इन-एप नॉट-फाउंड स्क्रीन रखें। जहाँ एक प्रतिस्थापन मौजूद है, वहाँ 301 भेजें।

हर रिलीज के बाद लाइव होस्ट पर कुछ बनाए गए पते जाँचें। रिसपांस कोड वह चीज है जिसे पढ़ना है, न कि वह पेज जिसे आप ब्राउज़र में देखते हैं।

ब्राउज़र में चलने वाले रीडायरेक्ट्स

एक रीडायरेक्ट जो पेज लोड होने के बाद फायर होता है, उदाहरण के लिए एक कंपोनेंट के अंदर एक URL पैरामीटर पढ़कर, एक सर्वर रीडायरेक्ट से अलग चीज है। एक क्रॉलर रीडायरेक्ट चलने से पहले पहले रिसपांस को इंडेक्स कर सकता है। जहाँ एक रूट स्थायी रूप से स्थानांतरित हुआ है, वहाँ सर्वर से 301 लौटाएँ और उन पैरामीटरों को रखें जो सामग्री बदलते हैं। रीडायरेक्ट मैप रेसिपी दिखाता है कि उन नियमों की जाँच कैसे करें।