इच्छित पृष्ठों और पुन:उपयोगी प्रमाण के साथ शुरू करें
उन सार्वजनिक पृष्ठों की सूची बनाएं जिन्हें आप चाहते हैं कि खोजकर्ता ढूंढें: प्रमुख उत्पाद, लेख, श्रेणियाँ, और स्थानांतरित किए गए URLs। प्रत्येक के लिए पसंदीदा URL, अपेक्षित प्रतिक्रिया, इंडेक्सेबिलिटी, टेम्पलेट, मालिक, और प्राथमिकता रिकॉर्ड करें। वैध बहिष्करणों को अलग रखें।
प्रतिनिधि URLs के लिए बिना ऑथेंटिकेशन के प्रतिक्रिया, हेडर, रीडायरेक्ट पथ, पृष्ठ स्रोत, रेंडर किया गया दृश्य, आंतरिक-लिंक स्थिति, और साइटमैप स्थिति कैप्चर करें। हर टेम्पलेट और URL पैटर्न का नमूना लें। प्रमाण डेटेड होते हैं: CDN सेटिंग, डिप्लॉयमेंट, कंसेंट लेयर, या पर्सनलाइज़ेशन बाद में बदल सकते हैं।
होमपेज का सही आना यह साबित नहीं करता कि लिस्टिंग, उत्पाद वेरिएंट, या स्थानीय रूट काम कर रहे हैं।
दिनांकित हेडर और रेंडर प्रमाण रखें ताकि फिक्स और बाद की regressions की तुलना की जा सके।
इंडेक्सेबिलिटी को जानबूझकर निर्णय बनाएं
इंडेक्सेबिलिटी का अर्थ है कि किसी पृष्ठ को खोज सूचकांक में शामिल किया जा सकता है; यह क्रॉलिंग या रैंकिंग के समान नहीं है। HTML में meta robots निर्देशों और X-Robots-Tag रिस्पांस हेडर्स की जाँच करें। noindex निर्देश सर्च इंजनों को बताता है कि पृष्ठ दिखाया न जाए; X-Robots-Tag गैर-HTML फ़ाइलों जैसे PDF पर भी लागू होता है।
robots.txt को अलग से रिव्यू करें। एक क्रॉलर को किसी पृष्ठ तक पहुँचकर उसका noindex निर्देश देखना पड़ता है, इसलिए उस URL को ब्लॉक करने से निर्देश दिखाई ही नहीं देगा। तैनात, सार्वजनिक प्रतिक्रिया की जाँच करें क्योंकि CMS सेटिंग्स और एनवायरनमेंट फ्लैग नियम जोड़ सकते हैं। Noindex एक्सेस कंट्रोल नहीं है: संवेदनशील सामग्री को ऑथेंटिकेशन और उचित सुरक्षा समीक्षा से सुरक्षित करें।
इरादतन-इंडेक्स किए जाने वाले पृष्ठों पर noindex, लॉगिन प्रतिक्रियाएँ, स्टेजिंग संदर्भ, और आवश्यक अस्सेट ब्लॉकिंग को फ़्लैग करें।
HTTP रिस्पांस हेडर में निर्देश हो सकता है भले ही HTML हेड मौजूद न हो।
एक पसंदीदा URL को सुसंगत बनाएं
कैनोनिकलाइज़ेशन डुप्लिकेट या बहुत मिलते-जुलते संस्करणों में पसंदीदा URL पहचानता है, जैसे HTTP और HTTPS, होस्ट, ट्रैकिंग पैरामीटर, फिल्टर्स, या प्रिंट पेज। canonical एलिमेंट, आंतरिक लिंक, साइटमैप URL, और रीडायरेक्ट गंतव्य की तुलना करें। एक इंडेक्सेबल पृष्ठ के लिए, ये सामान्यतः एक ही पूर्ण पसंदीदा URL को संकेत करने चाहिए।
डुप्लिकेट से सेवानिवृत्त होने पर सर्वर-साइड स्थायी रीडायरेक्ट का उपयोग करें। Google स्थायी रीडायरेक्ट और rel=canonical को मजबूत संकेत बताता है, जबकि साइटमैप समावेशन कमजोर होता है; संरेखित संकेत प्राथमिकता को मजबूत करते हैं। canonical के लिए robots.txt का उपयोग या competing canonicals देना ज़रूरी नहीं। सेल्फ-रेफरेंसिंग canonical पसंदीदा संस्करण बताने में मदद करता है, पर सर्च-इंजन का अंतिम चयन आपकी नियंत्रित सीमा के बाहर रहता है।
वेरिएंट्स, पसंदीदा लक्ष्य, आवश्यक नियंत्रण, और एक मालिक दस्तावेज़ित करें।
माइग्रेशन से पहले पुराने-से-नए मैपिंग्स टेस्ट करें और एक उलटने योग्य रीडायरेक्ट परिवर्तन तैयार रखें।
स्टेटस कोड और रीडायरेक्ट व्यवहार जाँचें
स्टेटस कोड ब्राउज़र और क्रॉलर को बताते हैं कि क्या हुआ। महत्वपूर्ण लाइव पृष्ठों को मंशित कंटेंट के साथ अर्थपूर्ण 2xx प्रतिक्रिया देनी चाहिए। जिसका कोई प्रासंगिक प्रतिस्थापन नहीं है उसे असली 404 या 410 लौटाना चाहिए; स्थानांतरित कंटेंट को उसके निकटतम प्रासंगिक प्रतिस्थापन पर पहुँचना चाहिए। केवल त्रुटि दिखाने वाला 200 पृष्ठ सॉफ्ट 404 माना जा सकता है।
हर रीडायरेक्ट हॉप को रिकॉर्ड करें। Google सामान्य वेब क्रॉलिंग के लिए सामान्यतः 10 हॉप तक फॉलो करता है, पर चेन देर और भंगुरता जोड़ते हैं। Google बताता है कि 5xx और 429 प्रतिक्रियाएँ अस्थायी रूप से क्रॉलिंग धीमी कर सकती हैं और लगातार सर्वर त्रुटियाँ अंततः इंडेक्स किए गए URLs को हटा सकती हैं। आवर्ती विफलताओं की जाँच इंजीनियरिंग मालिक के साथ एप्लिकेशन, CDN, ओरिजिन, कैश, डिपेंडेंसी, और डिप्लॉयमेंट परतों के पार करें।
मूल URL, हॉप्स, कोड्स, अंतिम URL और अपेक्षित स्थिति सहेजें।
एक और हॉप जोड़ने के बजाय ओवरलैपिंग CMS, CDN, होस्ट, लोकेल, या स्लैश नियमों को हटाएँ।
JavaScript रेंडरिंग और रूट्स मान्य करें
मुख्य टेम्पलेट्स के लिए प्रारम्भिक HTML और एक रेंडर किया हुआ दृश्यमान दोनों निरिक्षण करें। रेंडर के बाद मुख्य कंटेंट, हेडिंग्स, लिंक, canonical, robots निर्देश, और स्थिति मौजूद हैं यह पुष्टि करें। Google अलग क्रॉल, रेंडर, और इंडेक्स फ़ेज़ का वर्णन करता है और कहता है कि रेंडर किए गए HTML में दिखाई न देने वाला कंटेंट इंडेक्स किया नहीं जा सकता।
नेविगेशन के लिए href मान वाले anchor एलिमेंट्स का उपयोग करें। केवल फ्रैगमेंट-आधारित रूट्स जो अलग कंटेंट लोड करते हैं, खोज के लिए भरोसेमंद नहीं हैं। गैर-मौजूद उत्पादों, लेखों, और फ़िल्टर किए गए URLs को सीधे रिक्वेस्ट करें। क्लाइंट-साइड एप्लिकेशन को वास्तविक त्रुटि स्थिति की ज़रूरत होती है; Google सर्वर 404 पर रूट करने या सॉफ्ट 404 से बचने के लिए noindex जोड़ने का दस्तावेजीकरण करता है। सर्वर रेंडरिंग या प्रीरेंडरिंग मदद कर सकती है, पर तैनात प्रतिक्रिया की सत्यापन करें।
स्रोत HTML, रेंडर किया हुआ HTML, और मानव ब्राउज़र दृश्य के बीच सामग्री अंतर जाँचें।
स्रोत HTML को प्राथमिकता दें; यदि JavaScript इसे सेट करता है तो सुनिश्चित करें कि कोई विरोधाभासी canonical न हो।
साइटमैप और आंतरिक लिंक साफ रखें
साइटमैप एक डिस्कवरी मैप है, इंडेक्सिंग कमांड नहीं। सफल, इच्छित, पसंदीदा canonical URLs शामिल करें; रीडायरेक्ट, त्रुटियाँ, noindex पृष्ठ, पैरामीटर डुप्लिकेट, और सुरक्षित URLs को बाहर रखें। Google पूर्णतः योग्य absolute URLs की सिफारिश करता है और साइटमैप समावेशन को canonical संकेत के रूप में देखता है, गारंटी के रूप में नहीं।
साइटमैप को वैरिफाई करें और इसे इच्छित-इंडेक्स सूची और नेविगेशन से तुलना करें। Google UTF-8 एन्कोडिंग और प्रत्येक साइटमैप पर 50 MB अनकंप्रेस्ड या 50,000 URLs की सीमा का उल्लेख करता है। बड़े साइट्स के लिए उपयोगी समूहों में विभाजित करें और एक इंडेक्स का उपयोग करें। lastmod केवल महत्वपूर्ण, सत्यापनीय पृष्ठ परिवर्तनों के लिए अपडेट करें।
इरादतन URLs, साइटमैप एंट्रीज़, और आंतरिक लिंक में सार्थक अंतर की जाँच करें।
रूटिंग या CMS परिवर्तन के बाद निर्मित साइटमैप और सूचीबद्ध URLs के नमूने की जाँच करें।
प्रदर्शन मापें और ऑडिट को संस्थागत बनाएं
जहाँ उपलब्ध हो फ़ील्ड डेटा का उपयोग करें और Core Web Vitals (कोर वेब विटल्स) की जाँच के लिए नियंत्रित लैब टेस्टिंग से जांचें: लोडिंग के लिए Largest Contentful Paint, रिस्पॉन्सिवनेस के लिए Interaction to Next Paint, और दृश्य स्थिरता के लिए Cumulative Layout Shift। पृष्ठ प्रकार और डिवाइस द्वारा सेगमेंट करें क्योंकि औसत टूटे हुए उच्च-मूल्य टेम्पलेट को छुपा सकता है।
इमेजेज़, CSS और JavaScript, थर्ड-पार्टी टैग्स, फोंट्स, एम्बेड्स, और कैशिंग के माध्यम से धीमी या अस्थिर डिलीवरी का पता लगाएँ। एक मापनीय परिवर्तन करें, फिर रेंडरिंग और यूजर फ़्लोज़ को फिर से जाँचें। फ़ील्ड डेटा वास्तविक उपयोगकर्ताओं को दर्शाता है; लैब डेटा रि-प्रोड्यूस करने में मदद करता है। कोई भी विधि हर भविष्य के क्रॉलर या विज़िटर की भविष्यवाणी नहीं करती। रिस्की रिलीज़ के बाद एक केंद्रित regression चेक दोहराएँ और माइग्रेशन या प्लेटफ़ॉर्म परिवर्तन के बाद एक पूर्ण ऑडिट चलाएँ।
छोटे स्कोर लाभों की तुलना में राजस्व-समूहीकृत या भारी प्रयुक्त टेम्पलेट्स पर विफलताओं की मरम्मत पहले करें।
बंद करने से पहले प्रतिक्रिया, canonical, रेंडर किया हुआ कंटेंट, साइटमैप स्थिति, और प्रासंगिक प्रदर्शन प्रमाण फिर से जाँचें।