टेक्निकल SEO ऑडिट चेकलिस्ट: ज़्यादा कंटेंट से पहले रिपोर्ट में क्या साबित होना चाहिए

जांच की छह परतें और एक प्राथमिकता वाली बैकलॉग

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

यह क्रम इसलिए मायने रखता है क्योंकि हर परत पिछली पर निर्भर करती है; गलत स्टेटस कोड लौटाने वाले पेज को बेहतर टाइटल से फ़ायदा नहीं मिलता। इसीलिए यह ऑडिट कंटेंट के बड़े बजट से पहले होना चाहिए: टूटी डिस्कवरी वाली वेबसाइट पर नए आर्टिकल भी वही खामियां विरासत में पाते हैं।

क्रॉल एक्सेस और इंडेक्स योग्यता सबसे पहले आती है

पहला चरण देखता है कि जिन URL को रैंक करना है, क्या उन तक पहुंचा और उन्हें बनाए रखा जा सकता है। ऑडिटर स्टेटस कोड, रीडायरेक्ट चेन, रोबोट्स फ़ाइल के नियम, साइटमैप और इंटरनल लिंक जांचता है, साथ ही यह भी कि ज़रूरी पेज कितने गहरे दबे हैं और किन्हें इंटरनल लिंक नहीं मिलता।

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

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

जावास्क्रिप्ट से बने पेजों की रेंडरिंग जांच

गूगल जावास्क्रिप्ट पेजों को तीन चरणों में प्रोसेस करता है: क्रॉलिंग, रेंडरिंग और इंडेक्सिंग। सफल कोड लौटाने वाले पेज रेंडरिंग की कतार में इंतज़ार करते हैं, और यह इंतज़ार सेकंडों से कहीं लंबा भी हो सकता है। इसलिए ऑडिट हर टेम्प्लेट का सर्वर एचटीएमएल स्क्रिप्ट के बाद वाले एचटीएमएल से मिलाकर रेंडरिंग के बाद दिखने वाली चीज़ें चिह्नित करता है।

कई जांच गूगल के जावास्क्रिप्ट SEO बेसिक्स से आती हैं। गूगल सिर्फ़ href वाले एंकर को लिंक मानता है, इसलिए क्लिक हैंडलर वाले मेन्यू सेक्शन छिपा सकते हैं। मूल एचटीएमएल में नोइंडेक्स हो तो गूगल रेंडरिंग छोड़ सकता है, बाद में टैग हटाने का फ़र्क़ नहीं पड़ता। स्क्रिप्ट कैनोनिकल दोबारा न लिखे, और सिंगल-पेज ऐप्स सॉफ्ट 404 से बचने को सही एरर हैंडलिंग रखें।

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

पेज सिग्नल और असली विज़िट से मिले कोर वेब वाइटल्स

पेज सिग्नल एचटीएमएल के वे हिस्से हैं जो पेज बताते हैं: टाइटल, मेटा डिस्क्रिप्शन, हेडिंग, लिंक एंकर और स्ट्रक्चर्ड डेटा। टेस्ट मात्रा का नहीं, स्थिरता का है। प्रोडक्ट मार्कअप की कीमत-उपलब्धता पेज से मेल खाए, और टेम्प्लेट-बने टाइटल हर पेज पर अलग रहें। मार्कअप पेज से न मिले तो नया स्कीमा टाइप जोड़ना प्राथमिकता नहीं बनती।

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

ठोस परफ़ॉर्मेंस फाइंडिंग एक जैसे पेजों के समूह के फील्ड डेटा से शुरू होती है, बताती है कि मोबाइल या डेस्कटॉप पर कौन-सा मीट्रिक फेल हो रहा है, और फिर कारण खोजने को लैब रन इस्तेमाल करती है, जैसे सबसे बड़े कंटेंट एलिमेंट के पीछे की वजह।

डुप्लीकेट URL, कैनोनिकल स्वामित्व और भाषा वर्ज़न

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

कैनोनिकल स्वामित्व यानी हर डुप्लीकेट क्लस्टर के लिए दो फ़ैसले: कौन-सा URL इसे रिप्रेज़ेंट करे, और सिस्टम का कौन-सा हिस्सा सिग्नल भेज रहा है — CMS फ़ील्ड, टेम्प्लेट हेल्पर, रीडायरेक्ट नियम या साइटमैप जनरेटर। URL इंस्पेक्शन घोषित कैनोनिकल को गूगल-चयनित के साथ दिखाता है; अलग हों तो जीतने वाला सिग्नल बताएं।

भाषा वर्ज़न की अपनी जांच होनी चाहिए: हर वर्ज़न अपनी भाषा में कैनोनिकल घोषित करे, और एचरेफ़लैंग सेट हर दिशा में पूरे हों। कल्पना करें पांच भाषाओं वाली वेबसाइट, जहां एक साझा हेल्पर हर लोकेल पर अंग्रेज़ी कैनोनिकल छाप देता है। हर पेज गिनाने के बजाय रिपोर्ट में उस हेल्पर का नाम बताना काफी है।

टेम्प्लेट की गलतियां बनाम अकेले पेज की गलतियां

ज़्यादातर टेक्निकल गलतियां टेम्प्लेट में जन्म लेती हैं। कैनोनिकल-रहित प्रोडक्ट लेआउट या हर फ़िल्टर को लिंक दिखाता कैटेगरी पेज अपनी हर URL पर वही गलती दोहराता है। अकेला रीडायरेक्ट लूप या हाथ से लगा नोइंडेक्स जैसी एकल गलतियां भी होती हैं, पर वे शायद ही पूरी वेबसाइट का पैटर्न समझा पाती हैं।

इससे सैंपलिंग बदल जाती है। चेतावनियों को गिनती से छांटने के बजाय, ऑडिटर टेम्प्लेट सूची बनाता है, हर टेम्प्लेट से पुराना, हालिया और असामान्य URL चुनकर गहराई से जांचता है। कोर वेब वाइटल्स रिपोर्ट पहले से एक जैसे पेजों को इसी तरह समूहों में बांटती है; पूरा क्रॉल फिर टेम्प्लेट-गलती का फैलाव नापता है।

इससे रिपोर्ट पढ़ने का तरीका भी बदलता है। मान लीजिए किसी क्लीनिक के एक टेम्प्लेट पर चालीस सर्विस पेज हैं, और टूल दो सौ टाइटल चेतावनियां दिखाता है जो दो टेम्प्लेट फ़ील्ड तक जाती हैं। मूल कारण की तरह लिखने पर यह एक डेवलपर-कार्य बनता है; दो सौ पंक्तियों की तरह लिखने पर महीनों का काम लगता है।

हर फाइंडिंग के लिए ज़रूरी बैकलॉग पंक्ति

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

प्राथमिकता तय करते समय गलती के असर को पेजों की अहमियत से जोड़ें और मेहनत के मुक़ाबले तौलें। फ़िल्टर की लिस्टिंग पर गायब कैनोनिकल और मुख्य कैटेगरी टेम्प्लेट पर गायब कैनोनिकल की प्राथमिकता अलग है, भले ही टूल दोनों को एक गंभीरता दे।

साइन-ऑफ से पहले ऑडिट के पूरा होने का सबूत

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

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

सुधार लागू होने के बाद सर्च कंसोल तारीख़ वाला सबूत देता है। पेज इंडेक्सिंग रिपोर्ट में वैलिडेट फिक्स समस्या वाले URL दोबारा जांचता है, और इसमें कई दिन या ज़्यादा लग सकते हैं। यह ज़रूरी नहीं, क्योंकि गूगल सामान्य क्रॉलिंग में भी सुधार पहचान लेता है, पर इससे रिकॉर्ड बनता है। दोबारा क्रॉल यह काम पूरा करता है।

जब एक छोटी जांच काफी है, और किस एक्सेस की ज़रूरत होगी

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

दोनों स्थितियों में ऑडिटर को एक्सेस चाहिए, वरना फाइंडिंग बाहर से लगाए अंदाज़े बन जाती हैं। URL इंस्पेक्शन और एक्सपोर्ट के लिए सर्च कंसोल अधिकार दें, एनालिटिक्स, सर्वर लॉग जहां हों, साइटमैप पते, स्टेजिंग एक्सेस, टेम्प्लेट सूची, रेवेन्यू लाने वाले URL समूह और हाल की रिलीज़ तारीख़ें। हर छूटी चीज़ क्षमता घटाती है।