WordPress इंडेक्सेशन समस्याएं: एक निदान गाइड

एक क्लाइंट ने मुझे एक मंगलवार की सुबह आखिरी वसंत में फोन किया था, बिल्कुल घबराहट वाली आवाज में। उसके पास एक प्रॉपर्टी लिस्टिंग साइट थी, करीब 42,000 पेज, और Google Search Console ने अभी-अभी उसे बताया था कि उनमें से सिर्फ 5,800 इंडेक्स किए गए हैं। उसने लगभग 86% इंडेक्स किए जा सकने वाले पेज खो दिए हैं, जैसे रातोंरात। कोई एल्गोरिदम अपडेट नहीं। कोई मैनुअल एक्शन नहीं। कोई हाल की डिप्लॉयमेंट नहीं जो वह याद रख सके। बस... चले गए।

मुख्य निष्कर्ष: जब एक 40,000-पेज WordPress साइट में 6,000 पेज इंडेक्स हैं, तो कारण लगभग हमेशा आर्किटेक्चर होता है: फेसेटेड URLs, थिन टेम्पलेट्स, और crawl waste — Google पेनल्टी नहीं।

मैंने Seahawk की 12,000+ WordPress साइटों पर यह सटीक परिस्थिति कितनी बार देखी है, इससे ज्यादा बार। और मार्मिक बात यह है कि बड़ी साइटों पर इंडेक्सेशन का नुकसान शायद ही कभी एक कारण होता है। यह आमतौर पर तीन या चार छोटी विफलताएं हैं जो चुपचाप एक साथ जमा होती हैं जब तक कि कुछ ढह न जाए।

यहाँ बताया गया है कि मैं वास्तव में इसका निदान कैसे करता हूँ।

---

Google Search Console से शुरुआत करें, पर वहीं रुकें नहीं

मैं हमेशा सबसे पहले Google Search Console में Pages रिपोर्ट खोलता हूँ। पुरानी Coverage रिपोर्ट नहीं — Google ने 2023 में इसे अपडेट किया है, और नया Pages व्यू इंडेक्स किए गए बनाम गैर-इंडेक्स किए गए पेजों को सही कारण कोड के साथ तोड़ता है। पहले दिन एक स्क्रीनशॉट लें। आपको बेसलाइन चाहिए।

कारण कोड अत्यंत महत्वपूर्ण हैं। "Crawled, currently not indexed" पूरी तरह से "Excluded by 'noindex' tag" से अलग समस्या है। एक गुणवत्ता सिग्नल का मुद्दा है; दूसरा कॉन्फ़िगरेशन का आपदा है। मैंने डेवलपर्स को दोनों को समान मानते हुए गलत चीज़ का पीछा करते हुए सप्ताहों बर्बाद करते देखा है।

बड़ी साइट्स पर मुझे सबसे अक्सर दिखने वाले Reasons

Crawled, currently not indexed: Google ने पेज पर जाया पर सोच-समझकर फैसला किया कि इसे इंडेक्स करने लायक नहीं है। आमतौर पर पतली कंटेंट, लगभग-डुप्लिकेट, या ऐसे पेज जिन्हें बैकलिंक या आंतरिक लिंक नहीं मिलते।
Discovered, currently not indexed: Google को URL मिल गया (शायद आपके साइटमैप में) पर अभी तक इसे क्रॉल करने की चिंता नहीं की है। यह कंटेंट समस्या नहीं है, क्रॉल बजट समस्या है।
Excluded by 'noindex' tag: किसी ने, संभवतः आप, संभवतः कोई प्लगइन, noindex निर्देश जोड़ा है। इस बारे में और नीचे।
Duplicate, Google chose different canonical: आपके canonical tags कहीं अप्रत्याशित की ओर इशारा कर रहे हैं, या Google उन्हें override कर रहा है।
Page with redirect: एक पेज जो index किए जाने योग्य होना चाहिए, कहीं redirect हो रहा है, या तो सही तरीके से या गलत तरीके से।

केवल totals को न देखें। प्रत्येक reason code के लिए पूरी सूची को CSV के रूप में डाउनलोड करें। 40,000-पेज वाली साइट पर, आपको sort और filter करने में सक्षम होना चाहिए।

---

क्रॉल बजट असली है और यह बड़ी साइट्स को नष्ट कर देगा

2019 में, Seahawk एक बड़े ई-कॉमर्स क्लाइंट पर काम कर रहा था, करीब 28,000 प्रोडक्ट पेज, और हम यह पता नहीं लगा सके कि Google प्रतिदिन केवल 3,000 पेज क्रॉल क्यों कर रहा था। साइट तेज़ थी। साइटमैप साफ-सुथरा था। सतह पर सब कुछ ठीक लग रहा था।

पता चला कि वह साइट हज़ारों faceted navigation URLs जनरेट कर रही थी, ?colour=red&size=large&sort=price, जो crawlable तो थे, लेकिन properly canonicalised नहीं थे, और Googlebot के crawl allowance को ख़त्म कर रही थी उससे पहले कि वह असली product pages तक पहुँचता।

Crawl budget अनिवार्य रूप से उन URLs की संख्या है जो Googlebot किसी दिए गए timeframe में आपकी साइट पर crawl करने को तैयार है। Google का अपना documentation on crawl budget सच में पढ़ने लायक है, वे ईमानदार हैं कि यह कैसे काम करता है। संक्षिप्त संस्करण: अगर आप इसे garbage URLs पर बर्बाद कर रहे हैं, तो महत्वपूर्ण pages को crawl नहीं किया जाता।

क्रॉल बजट का ऑडिट वास्तव में कैसे करें

अपने server logs खींचें। Google के crawl stats नहीं, असली server logs। Tools जैसे Screaming Frog Log File Analyser आपको purely Googlebot hits के लिए filter करने देते हैं।
देखें कि Googlebot की विज़िट्स का कितना प्रतिशत उन URL्स पर लैंड हो रहा है जिनकी आप वास्तव में परवाह करते हैं। अगर यह 60% से नीचे है, तो आपको बजट की समस्या है।
URL पैटर्न खोजें जो सबसे ज्यादा क्रॉल्स खा रहे हैं। फ़्रीक्वेंसी के हिसाब से सॉर्ट करें। शीर्ष अपराधी लगभग हमेशा ये होते हैं: फेसेटेड नेव, पेजीनेटेड आर्काइव्स पर पेजिनेशन, सेशन ID पैरामीटर्स, और खाली कैटेगरी/टैग आर्काइव पेज।
लक्षण को नहीं, स्रोत को ठीक करें। उन पैरामीटर्स के लिए robots.txt में Disallow करें जिन्हें कभी क्रॉल नहीं किया जाना चाहिए। बाकी सब के लिए Canonical टैग्स।

उस ई-कॉमर्स प्रोजेक्ट पर, हमने फेसेटेड URL्स को robots.txt के माध्यम से ब्लॉक किया और सभी फ़िल्टर्ड व्यूज़ में rel="canonical" जोड़ा। छह हफ्तों के भीतर, इंडेक्स किए गए पेज 8,000 से 24,000 तक पहुँच गए। वही कंटेंट। बस Googlebot अंत में इसे पा सका।

---

noindex आपदा (यह आपके विचार से ज्यादा बार होता है)

मुझे इस बारे में बात करनी है क्योंकि मैंने इसे खुद किया है। मेरा सर्वश्रेष्ठ पल नहीं। 2021 में एक समाचार साइट के लिए staging-से-live माइग्रेशन के दौरान, हमने WordPress Settings → Reading में "Discourage search engines from indexing this site" को अनचेक करना भूल गए। साइट site-wide noindex के साथ live हो गई। ग्राहक को ध्यान देने में ग्यारह दिन लगे कि organic traffic में भारी गिरावट आई है।

WordPress उस checkbox को एक जगह दबाता है जहाँ कोई expect नहीं करता। और कुछ SEO plugins, Yoast, Rank Math, यहाँ तक कि AIOSEO, के अपने noindex toggles हैं post type level पर, taxonomy level पर, और individual page level पर। इनमें से कोई भी आपकी साइट के बड़े हिस्से को silently noindex कर सकता है।

Scale पर noindex की जांच कैसे करें

पूरी साइट पर Screaming Frog चलाएँ और उन pages को filter करें जो noindex directive return कर रहे हैं। List को export करें। फिर अपने महत्वपूर्ण URL groups के विरुद्ध cross-reference करें, product pages, service pages, blog posts, जो भी business के लिए मायने रखता है।

अपने robots.txt को भी yourdomain.com/robots.txt पर check करें। Overly broad Disallow: rules को देखें। मैंने ऐसे rules देखे हैं जैसे Disallow: /wp-content/ जो CSS और JS को block कर रहे हैं जिन्हें Google को pages को properly render करने के लिए चाहिए, जो rendering failures का कारण बन सकता है जो indexation problems की तरह दिखते हैं लेकिन वास्तव में Googlebot को एक broken page दिख रहा है।

---

Canonical Tags जो चुप-चाप गलत काम कर रहे हैं

Canonicals बड़ी WordPress साइटों पर सबसे चालाक indexation killer हैं। क्योंकि वे अलग-अलग देखने में सही लगते हैं और scale पर केवल अपनुकूल प्रभाव को reveal करते हैं।

यहाँ एक pattern है जो मैं लगातार देखता हूँ: WooCommerce वाली साइट के products multiple URL paths के through accessible हैं, /product/red-shoes/, /product-category/footwear/red-shoes/, और कभी-कभी /shop/red-shoes/। हर एक के पास एक canonical tag है, लेकिन अगर वे canonicals slightly different URLs को point कर रहे हैं (HTTP vs HTTPS, trailing slash vs no trailing slash, www vs non-www), तो Google उन्हें signals मानता है जो different pages को point कर रहे हैं और consolidate करने से इनकार करता है।

फिक्स बोरिंग है लेकिन जरूरी है:

अपनी WordPress install से generate होने वाली हर URL structure को audit करें। Screaming Frog के site crawl का उपयोग करें → "Canonical" के लिए filter करें → export करें।
mismatched protocols, trailing slashes, और subdomain variations की जांच करें।
सुनिश्चित करें कि आपका canonical हमेशा आपने preferred URL से perfectly match करे, character दर character।

Rank Math और Yoast दोनों automatically canonical tags generate करते हैं, लेकिन कोई भी plugin आपकी .htaccess redirects या आपने CDN की URL normalisation के बारे में नहीं जानता। आपको plugin को जो लगता है वह output कर रहा है उसकी जगह rendered canonical को verify करना होगा। httpstatus.io जैसे tool से page को fetch करें और actual response headers और HTML को inspect करें।

---

बड़ी साइट्स पर XML Sitemaps अक्सर गलत होते हैं

अधिकांश WordPress SEO plugins automatically sitemaps जनरेट करते हैं। इनमें से अधिकांश आपके sitemap में URLs भी include करते हैं जिन्हें आप नहीं चाहते, paginated pages (/page/2/, /page/3/), author archives, tag pages जिनमें दो posts हैं, attachment pages।

एक sitemap आपके best, सबसे canonical पेजों की एक shortlist होनी चाहिए। WordPress ने कभी भी जो URL generate किया हो उसके सभी का dump नहीं।

साइटमैप स्वच्छता के नियम जिनका मैं वास्तव में पालन करता हूँ

पृष्ठांकित आर्काइव पेजों को बाहर रखें। हमेशा।
लेखक आर्काइव पेजों को बाहर रखें, जब तक कि यह एक बहु-लेखक साइट न हो जहाँ लेखक पेजों का वास्तविक सामग्री मूल्य हो।
टैग आर्काइवों को बाहर रखें जब तक कि टैग संपादकीय रूप से प्रबंधित न हों और सार्थक सामग्री न हों।
एक post count threshold set करें, मैं आमतौर पर किसी भी archive page को exclude करता हूँ जिसमें पाँच से कम posts हों।
बड़े साइटमैप को साइटमैप इंडेक्स में विभाजित करें। व्यक्तिगत साइटमैप फ़ाइलों को 10MB और 50,000 URLs के अंतर्गत रखें। Google ने यहाँ प्रलेखित सीमाएँ दी हैं।

इस post की शुरुआत की property listings site पर, sitemap में 41,000 URLs थे जिनमें हर tag archive, हर pagination page, और, यह कहना अभी भी मेरे लिए दर्दनाक है, WordPress login page शामिल था। इसे पहले clean up करें। हमेशा।

---

आंतरिक लिंकिंग एक इंडेक्सेशन समस्या है

लोग आंतरिक लिंकिंग को इंडेक्सेशन टूल के रूप में नहीं सोचते। उन्हें सोचना चाहिए।

अगर किसी पेज की ओर कोई इंटरनल लिंक नहीं है, तो Googlebot उसे पहली जगह ही नहीं खोज पाएगा, भले ही वह आपके sitemap में हो। Sitemaps को Google बताते हैं कि एक URL मौजूद है। Internal links को Google बताते हैं कि एक URL महत्वपूर्ण है। ये अलग-अलग सिग्नल हैं।

बड़ी content sites पर, orphaned pages बहुत आम हैं। तीन साल पहले publish किया गया एक blog post, जो post archives से linked है लेकिन किसी और post से कभी नहीं जुड़ा है, समय के साथ अपनी crawl frequency लगभग शून्य तक गिरा देखेगा।

मैं Screaming Frog की "Orphan Pages" रिपोर्ट (Site Structure के अंदर) का इस्तेमाल करता हूँ sitemap में उन पेजों को पहचानने के लिए जिनकी ओर शून्य इंटरनल लिंक हैं। फिर मैं content में वापस जाता हूँ लिंक जोड़ने के लिए logic places ढूंढने के लिए। Forced links नहीं, असली में relevant ones। समय लगता है लेकिन indexation impact असली है।

---

एक Systematic Diagnosis Checklist

अगर मैं यह Seahawk के किसी junior developer को देता, तो यह order है जिसमें मैं उन्हें इसके through काम करने के लिए कहता:

Google Search Console → Pages report खींचें → सभी non-indexed URLs को reasons codes के साथ download करें।
robots.txt को accidental broad disallows के लिए check करें।
WordPress के "Discourage search engines" checkbox को verify करें कि वह off है।
Screaming Frog चलाएँ और page level पर noindex directives के लिए filter करें।
Canonical tags देखें, rendered output देखें, plugin settings नहीं।
सर्वर लॉग्स निकालें और Googlebot के क्रॉल डिस्ट्रिब्यूशन को URL टाइप्स के आर पार चेक करें।
XML साइटमैप ऑडिट करें — जंक URLs (पेजिनेशन, खाली आर्काइव्स, गैर-कैनोनिकल वेरिएंट्स) के लिए।
Orphan Pages रिपोर्ट चलाएं और आंतरिक रूप से अनलिंक्ड पेजेस को पहचानें।
फेसेटेड नेविगेशन या पैरामीटर-आधारित URLs के लिए चेक करें जो डुप्लिकेट क्रॉलेबल पाथ्स जेनरेट कर रहे हैं।
Page speed verify करें, जो पेज consistently timeout होते हैं उन्हें Googlebot deprioritise करता है।

सब कुछ एक साथ ठीक करने की कोशिश मत करो। समस्याओं की एक कैटेगरी को ठीक करो, Google के फिर से क्रॉल करने के लिए तीन से चार सप्ताह इंतज़ार करो, माप लो, फिर अगली कैटेगरी पर जाओ। अगर तुम सब कुछ एक साथ बदलते हो तो कभी नहीं पता चल पाएगा कि असल में क्या काम किया।

---

FAQ

पेजेस एक हफ्ते इंडेक्स हो जाते हैं और फिर अगले हफ्ते ड्रॉप हो जाते हैं?

Google का index static नहीं है। वह continuously पेजों को quality signals, freshness, और crawl efficiency के आधार पर फिर से evaluate करता है। एक पेज जो छह महीने पहले indexed था, उसे drop किया जा सकता है अगर उसे कोई links नहीं मिले हैं, internally link नहीं किया जा रहा है, या अगर Google के quality assessment में आपके domain के लिए बदलाव हुआ है। ये खासकर site migration के बाद या बड़े content overhaul के बाद आम है — Google फिर से crawl करता है, फिर से evaluate करता है, और कभी-कभी decide करता है कि पहले indexed पेज अब bar में नहीं आते।

क्या साइट स्पीड इंडेक्सेशन को प्रभावित करता है?

हाँ, ज़्यादातर लोग सोचते हैं उससे ज़्यादा directly। अगर पेज slow respond करते हैं, consistently 2-3 सेकंड से ज़्यादा initial server response के लिए, तो Googlebot उन्हें crawl करना deprioritise कर देगा। Scale पर, इसका मतलब है कि slow pages simply frequently enough crawl नहीं होते indexed रहने के लिए। पहले अपना Time to First Byte (TTFB) ठीक करें, फिर कुछ और speed से जुड़ी चीज़ों के बारे में सोचें। WP Rocket जैसा सस्ता caching plugin measurable difference बनाता है। Core Web Vitals rankings के लिए महत्वपूर्ण हैं, लेकिन TTFB crawling के लिए महत्वपूर्ण है।

क्या साइटमैप में बहुत सारे पेज इंडेक्सेशन को नुकसान पहुंचा सकते हैं?

Directly नहीं, लेकिन low-quality URLs के साथ एक bloated sitemap उस signal को dilute कर देता है जो आप Google को भेज रहे हैं कि क्या महत्वपूर्ण है। अगर आपके sitemap में 40,000 URLs हैं और उनमें से 30,000 thin archive pages हैं, तो Google सीखता है कि आपके sitemap को noise के रूप में treat करें। Sitemaps को tight और high-quality रखें। इसे एक URL inventory नहीं, editorial curation के रूप में सोचें।

क्या मुझे Google के URL Inspection टूल का उपयोग करके मैन्युअल रूप से इंडेक्सिंग के लिए रिक्वेस्ट करनी चाहिए?

Individual important pages के लिए, हाँ, बिल्कुल। लेकिन हज़ारों URLs के लिए manually indexing request करने की कोशिश न करें। ये scale नहीं करता और Google ने कहा है कि manually-requested URLs को long run में special treatment नहीं मिलती। Underlying crawl और quality issues को ठीक करें और Google के natural crawling को काम करने दें। Manual inspection का इस्तेमाल करें specific pages verify करने के लिए कि वे indexed हो सकते हैं, सब कुछ force index करने के लिए नहीं।

---

ईमानदारी से कहूँ तो indexation diagnosis glamorous काम नहीं है। ये spreadsheets हैं, log files हैं, और बहुत सारी waiting है। लेकिन एक बड़ी site पर, अपने lost indexed pages का भी 20% recover करने का मतलब organic traffic में meaningful jump हो सकता है, और एक 40,000-page property listings site पर, वह असली पैसा है। Basics को पहले ठीक करें कुछ भी exotic chase करने से पहले। ये almost never exotic है।