एक ग्राहक ने पिछली वसंत एक मंगलवार की सुबह मुझे फोन किया — उसकी आवाज में सही घबराहट थी। वह एक संपत्ति सूचीकरण साइट चलाता था, लगभग 42,000 पेज, और Google Search Console ने उसे बताया था कि उनमें से केवल 5,800 इंडेक्स किए गए थे। वह अपने इंडेक्स किए जाने योग्य पेजों का लगभग 86% खो गया था, जाहिर है रातोंरात। कोई एल्गोरिदम अपडेट नहीं। कोई मैनुअल कार्रवाई नहीं। कोई हालिया डिप्लॉयमेंट जिसे वह याद कर सकता था। बस… चला गया।
मैंने Seahawk की 12,000+ WordPress साइटों पर यह सटीक परिस्थिति कितनी बार देखी है, इससे ज्यादा बार। और मार्मिक बात यह है कि बड़ी साइटों पर इंडेक्सेशन का नुकसान शायद ही कभी एक कारण होता है। यह आमतौर पर तीन या चार छोटी विफलताएं हैं जो चुपचाप एक साथ जमा होती हैं जब तक कि कुछ ढह न जाए।
यहाँ बताया गया है कि मैं वास्तव में इसका निदान कैसे करता हूँ।
---
Google Search Console से शुरू करें — लेकिन वहीं न रुकें
पहली चीज़ जो मैं हमेशा करता हूँ वह है Google Search Console में Pages रिपोर्ट खोलना। पुरानी Coverage रिपोर्ट नहीं — Google ने इसे 2023 में अपडेट किया, और नया Pages व्यू indexed बनाम non-indexed को सही reason codes के साथ तोड़ देता है। पहले दिन एक स्क्रीनशॉट लें। आपको एक baseline चाहिए।Pages report in Google Search Console. Not the old Coverage report — Google updated this in 2023, and the new Pages view breaks down indexed vs. non-indexed with proper reason codes. Take a screenshot on day one. You need a baseline.
Reason codes बेहद महत्वपूर्ण हैं। "Crawled — currently not indexed" बिल्कुल अलग समस्या है "Excluded by 'noindex' tag" से। एक quality signal issue है; दूसरा एक configuration disaster है। मैंने developers को दोनों को समान रूप से मानते हुए देखा है और हफ़्तों गलत चीज़ का पीछा करते हुए बर्बाद किया है।
बड़ी साइट्स पर मुझे सबसे अक्सर दिखने वाले Reasons
- Crawled — currently not indexed: Google ने पेज को visit किया लेकिन यह तय किया कि इसे index करने योग्य नहीं है। आमतौर पर thin content, near-duplicates, या ऐसे पेज जो backlinks या internal links नहीं अर्जित करते हैं।: Google visited the page but decided it wasn't worth indexing. Usually thin content, near-duplicates, or pages that don't earn backlinks or internal links.
- Discovered — currently not indexed: Google को URL मिला (संभवतः आपके sitemap में) लेकिन इसे crawl करने की परवाह नहीं की। यह crawl budget समस्या है, content समस्या नहीं।: Google found the URL (likely in your sitemap) but hasn't bothered to crawl it yet. This is a crawl budget problem, not a content problem.
- Excluded by 'noindex' tag: किसी ने — संभवतः आप, संभवतः एक plugin — एक noindex directive जोड़ा। इसके बारे में नीचे अधिक।: Someone — possibly you, possibly a plugin — added a noindex directive. More on this below.
- Duplicate, Google chose different canonical: आपके canonical tags कहीं अप्रत्याशित की ओर इशारा कर रहे हैं, या Google उन्हें override कर रहा है।: Your canonical tags are pointing somewhere unexpected, or Google is overriding them.
- Page with redirect: एक पेज जो index किए जाने योग्य होना चाहिए, कहीं redirect हो रहा है, या तो सही तरीके से या गलत तरीके से।: A page that should be indexable is redirecting somewhere, either correctly or incorrectly.
केवल totals को न देखें। प्रत्येक reason code के लिए पूरी सूची को CSV के रूप में डाउनलोड करें। 40,000-पेज वाली साइट पर, आपको sort और filter करने में सक्षम होना चाहिए।
---
क्रॉल बजट असली है और यह बड़ी साइट्स को नष्ट कर देगा
2019 में वापस, Seahawk एक बड़े ई-कॉमर्स क्लाइंट पर काम कर रहा था — लगभग 28,000 प्रोडक्ट पेज — और हम यह नहीं समझ सके कि Google प्रतिदिन केवल लगभग 3,000 पेज ही क्यों क्रॉल कर रहा था। साइट तेज़ थी। साइटमैप साफ था। सतह पर सब कुछ ठीक दिख रहा था।
पता चला कि साइट हज़ारों फेसेटेड नेविगेशन URL्स जेनरेट कर रही थी — ?colour=red&size=large&sort=price — जो क्रॉल करने योग्य थे, ठीक से कैनोनिकलाइज़ नहीं किए गए थे, और Googlebot के क्रॉल अनुमान को असली प्रोडक्ट पेज तक पहुँचने से पहले ही खत्म कर रहे थे।?colour=red&size=large&sort=price — that were crawlable, not canonicalised properly, and eating through Googlebot's crawl allowance before it ever reached the real product pages.
क्रॉल बजट मूलतः URL्स की संख्या है जो Googlebot किसी दिए गए समय सीमा में आपकी साइट पर क्रॉल करने को तैयार है। क्रॉल बजट पर Google का स्वयं का डॉक्यूमेंटेशन वास्तव में पढ़ने योग्य है — वे यह बताते हैं कि यह कैसे काम करता है। संक्षिप्त संस्करण: अगर आप इसे बेकार URL्स पर बर्बाद कर रहे हैं, तो महत्वपूर्ण पेज क्रॉल नहीं होते।Google's own documentation on crawl budget is genuinely worth reading — they're honest about how it works. The short version: if you're wasting it on garbage URLs, the important pages don't get crawled.
क्रॉल बजट का ऑडिट वास्तव में कैसे करें
- अपने सर्वर लॉग्स खींचें। Google के क्रॉल स्टैट्स नहीं — असली सर्वर लॉग्स। Screaming Frog Log File Analyser जैसे टूल्स आपको केवल Googlebot हिट्स के लिए फ़िल्टर करने देते हैं।Screaming Frog Log File Analyser let you filter purely for Googlebot hits.
- देखें कि Googlebot की विज़िट्स का कितना प्रतिशत उन URL्स पर लैंड हो रहा है जिनकी आप वास्तव में परवाह करते हैं। अगर यह 60% से नीचे है, तो आपको बजट की समस्या है।
- URL पैटर्न खोजें जो सबसे ज्यादा क्रॉल्स खा रहे हैं। फ़्रीक्वेंसी के हिसाब से सॉर्ट करें। शीर्ष अपराधी लगभग हमेशा ये होते हैं: फेसेटेड नेव, पेजीनेटेड आर्काइव्स पर पेजिनेशन, सेशन ID पैरामीटर्स, और खाली कैटेगरी/टैग आर्काइव पेज।
- लक्षण को नहीं, स्रोत को ठीक करें। उन पैरामीटर्स के लिए robots.txt में Disallow करें जिन्हें कभी क्रॉल नहीं किया जाना चाहिए। बाकी सब के लिए Canonical टैग्स।
robots.txtfor parameters that should never be crawled. Canonical tags for everything else.
उस ई-कॉमर्स प्रोजेक्ट पर, हमने फेसेटेड URL्स को robots.txt के माध्यम से ब्लॉक किया और सभी फ़िल्टर्ड व्यूज़ में rel="canonical" जोड़ा। छह हफ्तों के भीतर, इंडेक्स किए गए पेज 8,000 से 24,000 तक पहुँच गए। वही कंटेंट। बस Googlebot अंत में इसे पा सका।robots.txt and added rel="canonical" to all filtered views. Within six weeks, indexed pages went from 8,000 to 24,000. Same content. Just Googlebot finally reaching it.
---
noindex आपदा (यह आपके विचार से ज्यादा बार होता है)
मुझे इस बारे में बात करनी है क्योंकि मैंने इसे खुद किया है। मेरा सर्वश्रेष्ठ पल नहीं। 2021 में एक समाचार साइट के लिए staging-से-live माइग्रेशन के दौरान, हमने WordPress Settings → Reading में "Discourage search engines from indexing this site" को अनचेक करना भूल गए। साइट site-wide noindex के साथ live हो गई। ग्राहक को ध्यान देने में ग्यारह दिन लगे कि organic traffic में भारी गिरावट आई है।
WordPress उस चेकबॉक्स को एक ऐसी जगह छिपाता है जहाँ कोई उम्मीद नहीं करता। और कुछ SEO प्लगइन — Yoast, Rank Math, यहाँ तक कि AIOSEO — के पास post type स्तर पर, taxonomy स्तर पर, और individual page स्तर पर अपने noindex toggles हैं। इनमें से कोई भी आपकी साइट के बड़े हिस्सों को चुप-चाप noindex कर सकता है।
Scale पर noindex की जांच कैसे करें
पूरी साइट पर Screaming Frog चलाएँ और noindex directive लौटाने वाले पेजों के लिए फ़िल्टर करें। सूची को export करें। फिर अपने महत्वपूर्ण URL समूहों के विरुद्ध cross-reference करें — product pages, service pages, blog posts, जो कुछ भी व्यवसाय के लिए महत्वपूर्ण है।noindex directive. Export the list. Then cross-reference against your important URL groups — product pages, service pages, blog posts, whatever matters to the business.
अपने robots.txt को yourdomain.com/robots.txt पर भी जाँचें। अत्यधिक broad Disallow: rules को देखें। मैंने Disallow: /wp-content/ जैसे rules देखे हैं जो CSS और JS को block करते हैं जिनकी Google को पेजों को सही तरीके से render करने के लिए जरूरत है — जो rendering failures का कारण बन सकते हैं जो indexation समस्याओं जैसे दिखते हैं लेकिन दरअसल Googlebot को एक broken page दिख रहा है।robots.txt at yourdomain.com/robots.txt. Look for overly broad Disallow: rules. I've seen rules like Disallow: /wp-content/ blocking CSS and JS that Google needs to render pages properly — which can cause rendering failures that look like indexation problems but are actually Googlebot seeing a broken page.
---
Canonical Tags जो चुप-चाप गलत काम कर रहे हैं
Canonicals बड़ी WordPress साइटों पर सबसे चालाक indexation killer हैं। क्योंकि वे अलग-अलग देखने में सही लगते हैं और scale पर केवल अपनुकूल प्रभाव को reveal करते हैं।
मुझे लगातार एक पैटर्न दिखता है: WooCommerce वाली एक साइट के पास प्रोडक्ट्स कई URL पाथ के जरिए accessible होते हैं — /product/red-shoes/, /product-category/footwear/red-shoes/, और कभी-कभी /shop/red-shoes/। हर एक का canonical tag है, लेकिन अगर वे canonicals थोड़े-से अलग URLs की ओर इशारा करते हैं (HTTP बनाम HTTPS, trailing slash बनाम बिना trailing slash के, www बनाम non-www), तो Google उन्हें अलग-अलग पेजों की ओर इशारा करने वाले सिग्नल के तौर पर treat करता है और consolidate करने से इनकार कर देता है।/product/red-shoes/, /product-category/footwear/red-shoes/, and sometimes /shop/red-shoes/. Each one has a canonical tag, but if those canonicals point to slightly different URLs (HTTP vs HTTPS, trailing slash vs no trailing slash, www vs non-www), Google treats them as signals pointing to different pages and refuses to 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 करें।.htaccess redirects or your CDN's URL normalisation. You have to verify the rendered canonical, not just what the plugin thinks it's outputting. Fetch the page with a tool like httpstatus.io and inspect the actual response headers and HTML.
---
बड़ी साइट्स पर XML Sitemaps अक्सर गलत होते हैं
ज्यादातर WordPress SEO plugins automatically sitemaps generate करते हैं। ज्यादातर में ऐसे URLs भी शामिल होते हैं जो आप अपनी sitemap में नहीं चाहते — paginated pages (/page/2/, /page/3/), author archives, tag pages जिनपर दो posts हों, attachment pages।/page/2/, /page/3/), author archives, tag pages with two posts on them, attachment pages.
एक sitemap आपके best, सबसे canonical पेजों की एक shortlist होनी चाहिए। WordPress ने कभी भी जो URL generate किया हो उसके सभी का dump नहीं।
साइटमैप स्वच्छता के नियम जिनका मैं वास्तव में पालन करता हूँ
- पृष्ठांकित आर्काइव पेजों को बाहर रखें। हमेशा।
- लेखक आर्काइव पेजों को बाहर रखें, जब तक कि यह एक बहु-लेखक साइट न हो जहाँ लेखक पेजों का वास्तविक सामग्री मूल्य हो।
- टैग आर्काइवों को बाहर रखें जब तक कि टैग संपादकीय रूप से प्रबंधित न हों और सार्थक सामग्री न हों।
- एक पोस्ट गणना थ्रेशोल्ड सेट करें — मैं आमतौर पर पाँच से कम पोस्ट वाले किसी भी आर्काइव पेज को बाहर रखता हूँ।
- बड़े साइटमैप को साइटमैप इंडेक्स में विभाजित करें। व्यक्तिगत साइटमैप फ़ाइलों को 10MB और 50,000 URLs के अंतर्गत रखें। Google ने यहाँ प्रलेखित सीमाएँ दी हैं।documented limits here.
इस पोस्ट की शुरुआत से संपत्ति सूची साइट पर, साइटमैप में 41,000 URLs थे जिसमें हर टैग आर्काइव, हर पृष्ठांकन पेज, और — यह कहना मुझे अभी भी दर्दनाक है — WordPress लॉगिन पेज शामिल था। पहले इसे साफ़ करें। हमेशा।
---
आंतरिक लिंकिंग एक इंडेक्सेशन समस्या है
लोग आंतरिक लिंकिंग को इंडेक्सेशन टूल के रूप में नहीं सोचते। उन्हें सोचना चाहिए।
अगर किसी पेज के लिए कोई internal link नहीं है, तो Googlebot उसे खोज ही नहीं सकता — भले ही वह आपके sitemap में हो। Sitemaps Google को बताते हैं कि एक URL मौजूद है। Internal links Google को बताते हैं कि एक URL महत्वपूर्ण है। ये दोनों अलग-अलग signals हैं।matters. Those are different signals.
बड़ी content sites पर, orphaned pages बहुत आम हैं। तीन साल पहले publish किया गया एक blog post, जो post archives से linked है लेकिन किसी और post से कभी नहीं जुड़ा है, समय के साथ अपनी crawl frequency लगभग शून्य तक गिरा देखेगा।
मैं Screaming Frog की "Orphan Pages" report (Site Structure के अंदर) का उपयोग करता हूँ sitemap में उन pages को identify करने के लिए जिनके पास zero internal links हैं। फिर मैं content के माध्यम से वापस काम करता हूँ links जोड़ने के लिए logical जगहें खोजने के लिए। Forced links नहीं — वास्तव में relevant वाले। समय लगता है लेकिन 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 करें।
robots.txtfor accidental broad disallows. - WordPress के "Discourage search engines" checkbox को verify करें कि वह off है।
- Screaming Frog चलाएँ और page level पर noindex directives के लिए filter करें।
- कैनोनिकल टैग्स चेक करें — रेंडर किया गया आउटपुट, प्लगइन सेटिंग्स नहीं।
- सर्वर लॉग्स निकालें और Googlebot के क्रॉल डिस्ट्रिब्यूशन को URL टाइप्स के आर पार चेक करें।
- XML साइटमैप ऑडिट करें — जंक URLs (पेजिनेशन, खाली आर्काइव्स, गैर-कैनोनिकल वेरिएंट्स) के लिए।
- Orphan Pages रिपोर्ट चलाएं और आंतरिक रूप से अनलिंक्ड पेजेस को पहचानें।
- फेसेटेड नेविगेशन या पैरामीटर-आधारित URLs के लिए चेक करें जो डुप्लिकेट क्रॉलेबल पाथ्स जेनरेट कर रहे हैं।
- पेज स्पीड वेरिफाई करें — जो पेजेस लगातार टाइम आउट होते हैं, Googlebot उन्हें कम प्राथमिकता देता है।
सब कुछ एक साथ ठीक करने की कोशिश मत करो। समस्याओं की एक कैटेगरी को ठीक करो, Google के फिर से क्रॉल करने के लिए तीन से चार सप्ताह इंतज़ार करो, माप लो, फिर अगली कैटेगरी पर जाओ। अगर तुम सब कुछ एक साथ बदलते हो तो कभी नहीं पता चल पाएगा कि असल में क्या काम किया।
---
FAQ
पेजेस एक हफ्ते इंडेक्स हो जाते हैं और फिर अगले हफ्ते ड्रॉप हो जाते हैं?
Google का इंडेक्स स्थिर नहीं है। यह क्वालिटी सिग्नल, फ्रेशनेस और क्रॉल एफिशिएंसी के आधार पर पेजों का लगातार दोबारा मूल्यांकन करता है। एक पेज जिसे छह महीने पहले इंडेक्स किया गया था, वह ड्रॉप हो सकता है अगर उसे कोई लिंक नहीं मिला, उसे इंटरनल लिंक नहीं दिया जा रहा, या आपके डोमेन की Google की क्वालिटी असेसमेंट बदल गई हो। यह साइट माइग्रेशन के बाद या किसी महत्वपूर्ण कंटेंट ओवरहॉल के बाद खासकर आम है — Google दोबारा क्रॉल करता है, दोबारा मूल्यांकन करता है, और कभी-कभी फैसला करता है कि पहले इंडेक्स किए गए पेज अब स्टैंडर्ड नहीं रखते।
क्या साइट स्पीड इंडेक्सेशन को प्रभावित करता है?
हां, ज्यादातर लोग जितना समझते हैं उससे कहीं ज्यादा सीधे तरीके से। अगर पेज सर्वर रिस्पांस के लिए धीमे हैं — लगातार 2-3 सेकंड से ज्यादा — तो Googlebot उन्हें क्रॉल करने को प्रायोरिटी नहीं देगा। बड़े पैमाने पर, इसका मतलब है कि धीमे पेज इंडेक्स में बने रहने के लिए काफी बार क्रॉल ही नहीं होते। अपना Time to First Byte (TTFB) ठीक करो स्पीड से जुड़ी किसी और चीज़ को लेकर सोचने से पहले। WP Rocket जैसा सस्ता कैशिंग प्लगइन मापने लायक फर्क लाता है। Core Web Vitals रैंकिंग के लिए मायने रखते हैं, लेकिन TTFB क्रॉलिंग के लिए मायने रखता है।
क्या साइटमैप में बहुत सारे पेज इंडेक्सेशन को नुकसान पहुंचा सकते हैं?
सीधे तौर पर नहीं — लेकिन कम-क्वालिटी URLs वाला एक फूला हुआ साइटमैप उस सिग्नल को कमजोर कर देता है जो तुम Google को भेज रहे हो कि क्या मायने रखता है। अगर तुम्हारे साइटमैप में 40,000 URLs हैं और उनमें से 30,000 थिन आर्काइव पेज हैं, तो Google सीखता है कि तुम्हारे साइटमैप को शोर मानना है। साइटमैप को टाइट और हाई-क्वालिटी रखो। इसे URL इन्वेंटरी नहीं, एडिटोरियल क्यूरेशन की तरह सोचो।
क्या मुझे Google के URL Inspection टूल का उपयोग करके मैन्युअल रूप से इंडेक्सिंग के लिए रिक्वेस्ट करनी चाहिए?
अलग-अलग महत्वपूर्ण पेजों के लिए — हां, बिल्कुल। लेकिन हजारों URLs के लिए मैन्युअल रूप से इंडेक्सिंग रिक्वेस्ट करने की कोशिश मत करो। यह स्केल नहीं करता और Google ने कहा है कि यह मैन्युअल रूप से रिक्वेस्ट किए गए URLs को लंबे समय में विशेष ट्रीटमेंट नहीं देता। अंतर्निहित क्रॉल और क्वालिटी मुद्दों को ठीक करो और Google की नेचुरल क्रॉलिंग को काम करने दो। मैन्युअल इंस्पेक्शन का उपयोग यह वेरिफाई करने के लिए करो कि खास पेज इंडेक्स किए जा सकते हैं, सब कुछ इंडेक्स करने के लिए नहीं।can be indexed, not to force index everything.
---
सच्चाई यह है कि इंडेक्सेशन डायग्नोसिस ग्लैमरस काम नहीं है। यह स्प्रेडशीट, लॉग फाइलें और बहुत सारी प्रतीक्षा है। लेकिन एक बड़ी साइट पर, अपने इंडेक्स किए गए खोए हुए पेजों के 20% को रिकवर करना भी ऑर्गेनिक ट्रैफिक में मतलब का जंप दे सकता है — और एक 40,000-पेज प्रॉपर्टी लिस्टिंग साइट पर, वह असली पैसा है। किसी एक्सोटिक चीज़ का पीछा करने से पहले बेसिक्स को सही करो। यह लगभग कभी एक्सोटिक नहीं होता।