सिंगल पेज ऐप्लिकेशन SEO: SPA को Google पर इंडेक्स और AI द्वारा पढ़ने योग्य कैसे बनाएँ

संक्षेप में: सिंगल पेज ऐप्लिकेशन (SPA) एक ही HTML ढाँचा लोड करता है और हर व्यू ब्राउज़र में JavaScript से बनाता है। Google JavaScript को रेंडर कर सकता है, पर रेंडरिंग में देरी होती है और वह नाज़ुक होती है, और ChatGPT, Claude और Perplexity के पीछे चलने वाले क्रॉलर उसे बिल्कुल नहीं चलाते। रैंक करने और उद्धृत होने के लिए SPA के हर व्यू का अपना URL होना चाहिए, एक असली लिंक जिसमें href हो, एक अनोखा टाइटल और विवरण, सही स्टेटस कोड, और सबसे ज़रूरी, उसकी मुख्य सामग्री सर्वर के भेजे HTML में मौजूद हो, सर्वर-साइड रेंडरिंग, स्टैटिक जनरेशन या प्रीरेंडरिंग के ज़रिए।

सिंगल पेज ऐप्लिकेशन SEO उन तकनीकों का समूह है जो React, Vue, Angular या Svelte से बने JavaScript ऐप को एक पारंपरिक वेबसाइट जितना ही क्रॉल करने योग्य बनाती हैं। समस्या अच्छी तरह दर्ज है: Google अपनी JavaScript SEO की बुनियादी बातों में समझाता है कि वह JavaScript पेजों को तीन चरणों (क्रॉलिंग, रेंडरिंग, इंडेक्सिंग) में प्रोसेस करता है, और हर SPA की कमज़ोरी इसी पाइपलाइन में कहीं न कहीं होती है। यह गाइड SPA पर केंद्रित है; JavaScript साइटों की सामान्य जानकारी के लिए हमारी JavaScript SEO गाइड पढ़ें।

सिंगल पेज ऐप्लिकेशन क्या है, और SEO के लिए यह कठिन क्यों है?

एक पारंपरिक वेबसाइट हर URL के लिए पूरा HTML दस्तावेज़ लौटाती है। SPA हर URL के लिए लगभग एक ही दस्तावेज़ लौटाता है: एक खाली <div id="root">, कुछ मेटा टैग और एक बड़ा JavaScript बंडल। ब्राउज़र बंडल डाउनलोड करता है, एक API बुलाता है, फिर पेज बनाता है। जब विज़िटर किसी लिंक पर क्लिक करता है, तो JavaScript बिना रीलोड के सामग्री बदल देता है।

तेज़ फ़ोन वाले इंसान के लिए नतीजा तुरंत लगता है। क्रॉलर के लिए पहला जवाब एक खाली ढाँचा होता है: कोई शीर्षक नहीं, कोई टेक्स्ट नहीं, कोई लिंक नहीं। सब कुछ इस पर टिका है कि बॉट JavaScript चलाता है या नहीं, और कब। यही एक तथ्य SPA SEO की ज़्यादातर समस्याएँ समझा देता है:

• देर से या गायब सामग्री: टेक्स्ट केवल रेंडरिंग के बाद मौजूद होता है, जिसे Google बाद में करता है और दूसरे बॉट छोड़ देते हैं।
• कई व्यूज़ के लिए एक URL: पुराने SPA फ़्रैगमेंट (/#/pricing) से रूट करते हैं, और # के बाद का हिस्सा कभी सर्वर को नहीं भेजा जाता, इसलिए सारे व्यू एक URL में सिमट जाते हैं।
• एक-से टाइटल और विवरण: ढाँचे में एक <title> होता है, और अगर राउटर उसे अपडेट नहीं करता, तो हर पेज वही साझा करता है।
• बिना href के लिंक: बटन और onClick हैंडलर उपयोगकर्ताओं के लिए नेविगेट करते हैं, पर क्रॉलर के लिए फ़ॉलो करने को कुछ नहीं देते।
• सॉफ़्ट 404 त्रुटियाँ: सर्वर हर पथ पर 200 लौटाता है, उन पेजों पर भी जो मौजूद नहीं हैं, इसलिए त्रुटि व्यू पतले पेज की तरह इंडेक्स हो जाते हैं।
• भारी JavaScript: बड़े बंडल पहली स्क्रीन और इंटरैक्शन को धीमा करते हैं, जो Core Web Vitals को नुकसान पहुँचाता है।

Google SPA को कैसे क्रॉल और रेंडर करता है?

Googlebot पहले कच्चा HTML लाता है और उसमें मिले लिंक और निर्देश पढ़ता है। 200 स्टेटस लौटाने वाले पेज फिर Web Rendering Service की कतार में जाते हैं, जो एक हेडलेस Chromium है। Google कहता है कि पेज "इस कतार में कुछ सेकंड रह सकता है, पर उससे ज़्यादा समय भी लग सकता है"। रेंडर होने के बाद परिणामी HTML को फिर से सामग्री और लिंक के लिए पार्स किया जाता है, फिर इंडेक्स किया जाता है।

Google के दस्तावेज़ की चार बातें SPA के लिए मायने रखती हैं:

1. केवल href वाले <a> तत्व भरोसेमंद लिंक हैं। JavaScript से डाले गए लिंक ठीक हैं, बशर्ते वे इसी फ़ॉर्मैट में हों।
2. फ़्रैगमेंट अलग पेज नहीं हैं। Google पुराने # रूट की जगह History API (pushState) इस्तेमाल करने को कहता है। उसने अपनी पुरानी AJAX क्रॉलिंग योजना (#! वाले URL) अक्टूबर 2015 में बंद कर दी थी।
3. मूल HTML में noindex जीतता है। noindex देखकर Google रेंडरिंग छोड़ सकता है, इसलिए बाद में JavaScript से उसे हटाने से कुछ नहीं होता।
4. रेंडरिंग कैश्ड फ़ाइलों का इस्तेमाल करती है। Googlebot JavaScript और CSS को आक्रामक रूप से कैश करता है, इसलिए पुराने बंडल से बचने के लिए फ़ाइल नामों में फ़िंगरप्रिंट (नाम में कंटेंट हैश) इस्तेमाल करें।

व्यावहारिक नतीजा: Google क्लाइंट-रेंडर्ड SPA को इंडेक्स कर सकता है, पर हर पेज में एक दूसरा चरण, देरी और विफलता का बिंदु जुड़ जाता है। रेंडरिंग के दौरान टाइमआउट, ब्लॉक हुई API कॉल या JavaScript त्रुटि इंडेक्स हुए संस्करण को खाली छोड़ देती है। Search Console के URL इंस्पेक्शन टूल से जाँचें कि Google क्या देखता है, और अगर पेज इंडेक्स से बाहर रहते हैं तो Google इंडेक्सिंग कैसे काम करती है पर हमारी गाइड पढ़ें।

क्या ChatGPT, Claude और Perplexity JavaScript पढ़ते हैं?

ज़्यादातर नहीं। दिसंबर 2024 में प्रकाशित, अपने नेटवर्क के ट्रैफ़िक पर एक अध्ययन में Vercel और MERJ ने पाया कि "वर्तमान में कोई बड़ा AI क्रॉलर JavaScript रेंडर नहीं करता": GPTBot, OAI-SearchBot और ChatGPT-User (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Meta-ExternalAgent और Bytespider, सब केवल कच्चा HTML पढ़ते हैं। वे JavaScript फ़ाइलें डाउनलोड करते हैं (ChatGPT के अनुरोधों का लगभग 11.5% और Claude के 23.8%), पर उन्हें चलाते नहीं। अपवाद हैं Gemini, जो Google के रेंडरिंग इन्फ़्रास्ट्रक्चर पर निर्भर है, और AppleBot, जो ब्राउज़र-आधारित क्रॉलर इस्तेमाल करता है।

क्लाइंट-रेंडर्ड SPA के लिए इसका मतलब है कि ChatGPT, Claude और Perplexity को चलाने वाले AI क्रॉलर एक खाली पेज देखते हैं। आपका प्रोडक्ट Google पर रैंक कर सकता है और फिर भी AI जवाबों में अदृश्य रह सकता है, क्योंकि सहायक ने उसका एक शब्द नहीं पढ़ा। यही बात सोशल नेटवर्क और मैसेजिंग ऐप के ज़्यादातर लिंक प्रीव्यू बॉट पर लागू होती है, जो कच्चे HTML के Open Graph टैग पढ़ते हैं। एक बार सामग्री HTML में आ जाए, तो यह भी जाँचें कि आपकी robots.txt चाहे गए AI क्रॉलर को अनुमति देती है।

SPA को कौन सी रेंडरिंग रणनीति इस्तेमाल करनी चाहिए?

समाधान है पहले ही जवाब में असली HTML भेजना। Google अपने डायनामिक रेंडरिंग दस्तावेज़ में डायनामिक रेंडरिंग (केवल बॉट को प्रीरेंडर्ड संस्करण देना) को "एक वर्कअराउंड, न कि अनुशंसित समाधान" कहता है, और इसके बजाय सर्वर-साइड रेंडरिंग, स्टैटिक रेंडरिंग या हाइड्रेशन की ओर इशारा करता है। नीचे की परिभाषाएँ web.dev पर Rendering on the Web संदर्भ का पालन करती हैं।

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

फ़्रेमवर्क विकल्प

AI वेबसाइट बिल्डर से बनी साइटों का खास ज़िक्र ज़रूरी है: कई क्लाइंट-रेंडर्ड React ऐप एक्सपोर्ट करते हैं। अगर आपने ऐसे बिल्डर से साइट बनाई है, तो यह मान लेने से पहले कि Google और ChatGPT उसे पढ़ सकते हैं, हमारे Lovable SEO और GEO नोट्स देखें।

SPA SEO चेकलिस्ट: रूट दर रूट क्या ठीक करें

1. हर व्यू को साफ़, क्रॉल योग्य URL दें

History API इस्तेमाल करें (/pricing, कभी /#/pricing नहीं), हर सामग्री का एक URL, और वही URL चाहे विज़िटर सीधे आए या ऐप के भीतर नेविगेशन से। हर URL नए टैब में खोलने पर सही सामग्री लोड करे, यही वह जाँच है जो क्रॉलर करता है।

2. असली लिंक इस्तेमाल करें

हर नेविगेशन तत्व जो इंडेक्स योग्य पेज की ओर ले जाता है, एक <a href="/path"> होना चाहिए। फ़्रेमवर्क के लिंक कंपोनेंट (Link, NuxtLink, routerLink) यही मार्कअप देते हैं; div या button तत्वों पर कस्टम क्लिक हैंडलर नहीं देते। अच्छे लिंक आपके साइट आर्किटेक्चर को भी सहारा देते हैं: अगर कोई पेज लिंक नहीं है, तो क्रॉलर उसे शायद ही खोजते हैं।

3. हर रूट के लिए टाइटल, विवरण और कैनोनिकल अपडेट करें

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

4. ईमानदार स्टेटस कोड लौटाएँ

गायब उत्पाद और हटाए गए लेख 200 के साथ त्रुटि संदेश न लौटाएँ। SSR में सर्वर से असली 404 या 410 लौटाएँ। शुद्ध SPA में Google दो विकल्प मानता है: JavaScript से 404 देने वाले URL पर रीडायरेक्ट, या त्रुटि व्यू पर noindex robots मेटा टैग।

5. मुख्य सामग्री और स्ट्रक्चर्ड डेटा HTML में रखें

शीर्षक, मुख्य टेक्स्ट, कीमतें, FAQ और JSON-LD स्ट्रक्चर्ड डेटा सर्वर के जवाब में होने चाहिए, क्लिक या स्क्रोल के बाद लोड होने वाले नहीं। टैब के पीछे की सामग्री, जो माँग पर रेंडर होती है, या "और लोड करें" बटन के पीछे की सामग्री अक्सर छूट जाती है।

6. JavaScript को हल्का रखें

बंडल को रूट के हिसाब से बाँटें, जो पहले व्यू के लिए ज़रूरी न हो उसे टालें, और हाइड्रेशन के दौरान पूरे पेज को दोबारा रेंडर करने से बचें। ध्यान दें कि Chrome फ़ील्ड डेटा (CrUX) ऐप के भीतर के नेविगेशन के मेट्रिक्स को उस URL पर गिनता है जो विज़िटर ने पहले लोड किया था, इसलिए अपने मुख्य टेम्पलेट अलग-अलग जाँचें।

7. जाँचें कि बॉट क्या पाते हैं

हर मुख्य टेम्पलेट के तीन संस्करणों की तुलना करें: कच्चा HTML (सोर्स देखें या कमांड-लाइन टूल से पेज लाएँ), Google का रेंडर किया HTML (URL इंस्पेक्शन, फिर "क्रॉल किया गया पेज देखें") और JavaScript बंद करके दिखने वाला पेज। अगर मुख्य टेक्स्ट केवल दूसरे संस्करण में दिखता है, तो AI क्रॉलर उसे नहीं देखते। हमारा मुफ़्त AI के लिए क्रॉलेबिलिटी ऑडिट और इंडेक्सेबिलिटी चेकर किसी भी URL पर ये जाँचें चलाते हैं।

कैसे पता चले कि आपके SPA में SEO समस्या है?

SPA SEO और GEO: Google पर मिलना और AI द्वारा उद्धृत होना

सालों तक क्लाइंट-साइड रेंडरिंग एक संभालने योग्य जोखिम थी, क्योंकि Google अंततः JavaScript रेंडर कर देता था। अब खोज का एक हिस्सा ChatGPT, Claude, Gemini और Perplexity में होता है, इसलिए लागत बदल गई है: वह पेज जो केवल JavaScript चलने के बाद मौजूद होता है, उन स्रोतों से गायब है जिन्हें ज़्यादातर सहायक पढ़ सकते हैं। कच्चे HTML में क्रॉलेबिलिटी जेनरेटिव इंजन ऑप्टिमाइज़ेशन की पहली शर्त बन गई है।

एक बार HTML पूरा हो जाए, तो बाकी वही सामान्य नियम लागू होते हैं: जो पेज एक सवाल का साफ़ जवाब देते हैं, स्रोत वाले तथ्यों और स्ट्रक्चर्ड डेटा के साथ, वही सहायकों द्वारा उद्धृत होते हैं। Sorank की GEO ऑप्टिमाइज़ेशन सुविधाएँ ऐसी सामग्री लिखने और प्रकाशित करने में मदद करती हैं, और AI मेंशन ट्रैकिंग रेंडरिंग सुधार के बाद दिखाता है कि ChatGPT, Claude और Gemini आपके ब्रांड को उद्धृत करते हैं या नहीं।

सिंगल पेज ऐप्लिकेशन SEO का मुख्य नियम एक वाक्य में आ जाता है: जो कुछ आप चाहते हैं कि Google रैंक करे और AI उद्धृत करे, वह सर्वर के भेजे HTML में होना चाहिए। लॉगिन वाले अनुभव के लिए SPA रखें, सार्वजनिक पेज सर्वर पर या बिल्ड के समय रेंडर करें, फिर हर रिलीज़ से पहले और बाद में जाँचें कि बॉट क्या पाते हैं।