वेब एप्लिकेशन के लिए तकनीकी SEO: रैंकिंग वास्तव में क्या बदलता है

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

इससे शुरू करें कि क्रॉलर को वास्तव में क्या मिलता है

तकनीकी SEO की सबसे उपयोगी आदत है ब्राउज़र में पृष्ठ देखना बंद कर देना। सर्वर जो कच्चा HTML लौटाता है उसे लाइए और वही पढ़िए। वह प्रायः उससे अलग दस्तावेज़ होता है जो आप देखते हैं।

क्लाइंट-रेंडर्ड एप्लिकेशन के लिए यह स्क्रिप्ट टैग वाला ख़ाली ढाँचा हो सकता है। Google JavaScript रेंडर करता तो है, पर रेंडरिंग क्रॉलिंग से अलग क़तार में होती है और उसके तत्काल या पूर्ण होने की गारंटी नहीं — और अन्य क्रॉलर, जिनमें सोशल प्रीव्यू और कई AI सिस्टम के पीछे वाले भी हैं, कहीं कम भरोसे से या बिल्कुल रेंडर नहीं करते।

समाधान यह है कि जिस भी पृष्ठ को रैंक कराना है उसका कंटेंट शुरुआती HTML में परोसा जाए। सर्वर-साइड रेंडरिंग, स्टैटिक जनरेशन या प्रीरेंडरिंग सभी यह हासिल करते हैं; कौन-सा चुनें यह आर्किटेक्चर का निर्णय है, पर यदि सर्च मायने रखती है तो यह आवश्यकता बातचीत योग्य नहीं है।

डुप्लिकेट URL चुपचाप सब बर्बाद करते हैं

एप्लिकेशन बिना मेहनत URL के रूपांतर बनाते रहते हैं: ट्रैकिंग पैरामीटर, सेशन पहचानकर्ता, सॉर्ट और फ़िल्टर संयोजन, ट्रेलिंग-स्लैश रूपांतर, बड़े अक्षरों वाले पथ, और वही पृष्ठ दो रास्तों से पहुँच में। क्रॉलर के लिए हर रूपांतर अलग URL है, और रैंकिंग संकेत उनमें बँट जाते हैं।

तीन चीज़ें इसे सुलझाती हैं। हर पृष्ठ पर स्वयं की ओर संकेत करता कैनोनिकल चाहिए जो उसी संस्करण की ओर हो जिसे आप इंडेक्स कराना चाहते हैं। सर्वर को रूपांतर — ग़ैर-कैनोनिकल होस्ट, ग़लत प्रोटोकॉल, असंगत ट्रेलिंग स्लैश — स्थायी रीडायरेक्ट से भेजना चाहिए, न कि सभी परोसने चाहिए। और जो पैरामीटर कंटेंट नहीं बदलते उन्हें अलग इंडेक्स योग्य URL नहीं बनाना चाहिए।

यहाँ सबसे आम ग़लती है ऐसा कैनोनिकल जो साइटमैप से असहमत हो, या ऐसा कैनोनिकल जो किसी रीडायरेक्ट होने वाले URL की ओर संकेत करे। दोनों को भ्रमित संकेत माना जाता है, और भ्रम का निपटारा आपके विरुद्ध होता है।

फ़िल्टर आते ही क्रॉल बजट असली समस्या बन जाता है

पचास पृष्ठों की साइट के लिए क्रॉल बजट आपकी समस्या नहीं है। फ़ैसेटेड नेविगेशन वाले एप्लिकेशन के लिए यह पहली समस्याओं में है, क्योंकि मुट्ठी भर फ़िल्टर URL का संयोजनात्मक विस्फोट पैदा करते हैं और क्रॉलर उन महत्वपूर्ण पृष्ठों के बजाय हफ़्तों उन पर ख़ुशी-ख़ुशी लगा देगा।

स्पष्ट रूप से तय कीजिए कि कौन-से फ़िल्टर संयोजन इंडेक्स होने योग्य हैं — आमतौर पर वे जिनमें वास्तविक सर्च माँग है, जैसे एक श्रेणी और एक विशेषता — और बाक़ी को इंडेक्स-अयोग्य बना दीजिए। जिन पैरामीटर पैटर्न का कोई मूल्य नहीं उनका क्रॉलिंग robots.txt से रोकिए, और उन पृष्ठों के लिए noindex निर्देश रखिए जिन्हें उनके लिंक के लिए क्रॉल होने योग्य रहना है पर परिणामों में नहीं आना चाहिए।

ये दोनों आपस में बदले नहीं जा सकते, और इन्हें गड्डमड्ड करना आम है: robots.txt में रोका गया पृष्ठ क्रॉल नहीं हो सकता, इसलिए उसका noindex कभी देखा नहीं जाता, और URL केवल बाहरी संकेतों पर परिणामों में फिर भी दिख सकता है। यदि किसी पृष्ठ को इंडेक्स से बाहर रखना है, तो वह क्रॉल होने योग्य होना चाहिए और उस पर noindex होना चाहिए।

Core Web Vitals, वास्तविक उपयोग में मापे गए

परफ़ॉर्मेंस एक रैंकिंग कारक है, और उससे भी अधिक यह एक कन्वर्ज़न कारक है। ग़लती यह है कि तेज़ मशीन पर लैब स्कोर के विरुद्ध अनुकूलन किया जाए, न कि वास्तविक उपयोगकर्ता जो अनुभव करते हैं उसके विरुद्ध।

Largest Contentful Paint के लिए सामान्य दोषी हैं वह छवि जो प्रीलोड नहीं है, वह फ़ॉन्ट जो टेक्स्ट को दिखने से रोकता है, और रेंडर-ब्लॉक करने वाली स्टाइलशीट। जो तत्व सबसे बड़ा होगा उसे प्रीलोड कीजिए, font-display का उपयोग कीजिए ताकि टेक्स्ट फ़ॉलबैक में तुरंत दिखे, और पहली स्क्रीन के लिए ज़रूरी स्टाइल इनलाइन रखिए।

Cumulative Layout Shift लगभग हमेशा बिना आयाम वाली छवियों और एम्बेड से, मौजूदा कंटेंट के ऊपर डाले गए कंटेंट से, और स्वैप पर दोबारा बहने वाले वेब फ़ॉन्ट से आता है। स्पष्ट चौड़ाई-ऊँचाई तय कीजिए, देर से आने वाली हर चीज़ के लिए जगह छोड़िए, और फ़ॉलबैक फ़ॉन्ट के माप मिलाइए।

Interaction to Next Paint वह है जिसमें एप्लिकेशन सबसे अधिक विफल होते हैं, क्योंकि यह भारी JavaScript मेन थ्रेड के नीचे प्रतिक्रियाशीलता मापता है। लंबे कार्यों को तोड़िए, मेन थ्रेड पर कम काम कीजिए, और ईमानदारी से देखिए कि जिस पृष्ठ का काम जानकारी दिखाना है उस पर वाक़ई कितना फ़्रेमवर्क चाहिए।

स्ट्रक्चर्ड डेटा जो आपस में मेल खाए

स्ट्रक्चर्ड डेटा सीधे रैंकिंग नहीं बढ़ाता, पर यह तय करता है कि परिणाम कैसे दिखाया जाए और सर्च इंजन कितने भरोसे से समझे कि आपकी साइट किस बारे में है। आम विफलता अमान्य मार्कअप नहीं है — वह मार्कअप है जो पृष्ठों में स्वयं से विरोध करे, एक ही संगठन को तीन अलग तरीक़ों से बताए।

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

ऐसी समीक्षाएँ मार्कअप मत कीजिए जो आपने ली नहीं, ऐसी रेटिंग जो आपने शून्य से जोड़ी हैं, या ऐसे FAQ जो पृष्ठ पर दिखते ही नहीं। ये मैनुअल एक्शन को न्योता देते हैं, और रिच रिज़ल्ट उस जोखिम के लायक़ नहीं।

इंटरनेशनलाइज़ेशन, जहाँ आमतौर पर गड़बड़ होती है

यदि आप कई भाषाएँ परोसते हैं, तो hreflang सर्च इंजन को बताता है कि कौन-सा संस्करण दिखाना है। यह उन चीज़ों में भी है जिनमें सूक्ष्म ग़लती सबसे आसानी से होती है।

• एनोटेशन परस्पर होने चाहिए। यदि अंग्रेज़ी पृष्ठ जर्मन की ओर संकेत करता है, तो जर्मन पृष्ठ को वापस संकेत करना ही होगा, वरना पूरा सेट अनदेखा कर दिया जाता है।
• सेट का हर URL 200 लौटाना चाहिए। क्लस्टर में एक भी 404 पूरी व्यवस्था कमज़ोर कर देता है।
• हर पृष्ठ का कैनोनिकल स्वयं उसी की ओर संकेत करना चाहिए, अंग्रेज़ी संस्करण की ओर नहीं। दूसरी भाषा की ओर कैनोनिकल उस पृष्ठ को इंडेक्स से हटाने का अनुरोध है।
• जब कोई भाषा मेल न खाए तो फ़ॉलबैक के लिए x-default का उपयोग करें।
• किसी पृष्ठ का मशीनी अनुवाद करके उसे भाषा विकल्प के रूप में चिह्नित मत कीजिए, जब तक वह वाक़ई अच्छा न हो। कमज़ोर या बिगड़ा अनुवाद उस भाषा को बिल्कुल न देने से भी बुरा है।

ऐसा मापन जो प्राइवेसी-प्रधान वेब में टिके

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

सर्वर लॉग और सर्वर-साइड मापन में यह समस्या नहीं है, और वे आपको क्रॉलर का व्यवहार भी दिखाते हैं, जो क्लाइंट-साइड एनालिटिक्स कभी नहीं दिखाएगा। नई साइट के लिए, लॉग में Googlebot को आते देखना किसी भी डैशबोर्ड से अधिक उपयोगी संकेत है — यह बताता है कि आपकी समस्या क्रॉलिंग की है या रैंकिंग की, और दोनों बहुत अलग ढंग से ठीक होती हैं।

Search Console सबसे मूल्यवान स्रोत बना हुआ है, क्योंकि यह वे क्वेरीज़ बताता है जिनके लिए आप पहले से दिखते हैं। वे क्वेरीज़ किसी भी कीवर्ड टूल से बेहतर कंटेंट ब्रीफ़ हैं, क्योंकि वे दिखाती हैं कि आप कहाँ इतने क़रीब हैं कि छोटा-सा सुधार नतीजा बदल देगा।

काम का एक व्यावहारिक क्रम

1. पहले इंडेक्सेबिलिटी जाँचेंSearch Console, कवरेज रिपोर्ट, और अपनी ही साइट का एक क्रॉल। ऐसे पृष्ठ को अनुकूलित करने का कोई अर्थ नहीं जो बाहर ही रखा गया है।
2. रेंडरिंग ठीक करेंसुनिश्चित करें कि जिस कंटेंट को रैंक कराना है वह शुरुआती HTML प्रतिक्रिया में हो।
3. डुप्लिकेट सुलझाएँकैनोनिकल, रीडायरेक्ट और पैरामीटर हैंडलिंग, ताकि संकेत बँटने के बजाय एक जगह जमा हों।
4. क्रॉल नियंत्रित करेंतय करें कि कौन-से जनरेटेड URL इंडेक्सिंग के योग्य हैं और बाक़ी को क्रॉल भत्ता ख़र्च करने से रोकें।
5. फिर परफ़ॉर्मेंसफ़ील्ड डेटा, लैब स्कोर नहीं, और बिल्ड पाइपलाइन में तय किया गया ताकि यह फिर से न बिगड़े।
6. फिर कंटेंटउन क्वेरीज़ के लिए लिखा गया जिन पर Search Console दिखाता है कि आप पहले से क़रीब हैं।

यह क्रम मायने रखता है। ऐसे पृष्ठ के लिए लिखा कंटेंट जिसे क्रॉलर देख ही नहीं सकता, व्यर्थ मेहनत है, और इंडेक्स से बाहर रखे पृष्ठ पर परफ़ॉर्मेंस ट्यूनिंग से कुछ भी नहीं बदलता।