एक क्लाइंट ने मुझे पिछली बसंत में मंगलवार की सुबह कॉल किया -- उसकी आवाज़ में सही घबराहट थी। उसके पास एक प्रॉपर्टी लिस्टिंग साइट थी, लगभग 42,000 पेज़, और Google Search Console ने उसे बताया कि उनमें से सिर्फ 5,800 इंडेक्स किए गए थे। उसने रातोंरात अपने इंडेक्स योग्य पेज़ का लगभग 86% खो दिया। कोई एल्गोरिदम अपडेट नहीं। कोई मैनुअल ऐक्शन नहीं। कोई हाल का डिप्लॉयमेंट जो वह याद रख सकता था। बस... चला गया।
मुख्य निष्कर्ष: जब एक 40,000-पेज WordPress साइट में 6,000 पेज इंडेक्स हैं, तो कारण लगभग हमेशा आर्किटेक्चर होता है: फेसेटेड URLs, थिन टेम्पलेट्स, और crawl waste — Google पेनल्टी नहीं।When a 40,000-page WordPress site has 6,000 pages indexed, the cause is almost always architecture: faceted URLs, thin templates, and crawl waste, not a Google penalty.
मैंने Seahawk की 12,000+ WordPress साइटों पर यह सटीक परिस्थिति कितनी बार देखी है, इससे ज्यादा बार। और मार्मिक बात यह है कि बड़ी साइटों पर इंडेक्सेशन का नुकसान शायद ही कभी एक कारण होता है। यह आमतौर पर तीन या चार छोटी विफलताएं हैं जो चुपचाप एक साथ जमा होती हैं जब तक कि कुछ ढह न जाए।WordPress builds. And the maddening thing is that indexation loss on large sites rarely has one cause. It's usually three or four small failures that compound quietly until something collapses.
यहाँ बताया गया है कि मैं वास्तव में इसका निदान कैसे करता हूँ।
---
Google Search Console से शुरुआत करें -- लेकिन वहीं रुकें नहीं
मैं जो पहली चीज़ करता हूँ वह Google Search Console में Pages रिपोर्ट खोलना है। पुरानी Coverage रिपोर्ट नहीं -- Google ने इसे 2023 में अपडेट किया, और नए Pages व्यू ने इंडेक्स किए गए बनाम गैर-इंडेक्स किए गए को सही कारण कोड के साथ तोड़ा है। पहले दिन एक स्क्रीनशॉट लें। आपको एक बेसलाइन की जरूरत है।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.
कारण कोड बहुत महत्वपूर्ण हैं। "Crawled -- currently not indexed" एक पूरी तरह अलग समस्या है "Excluded by 'noindex' tag" से। एक क्वालिटी सिग्नल का मुद्दा है; दूसरा एक कॉन्फ़िगरेशन आपदा है। मैंने डेवलपर्स को दोनों को समान रूप से व्यवहार करते हुए देखा है और हफ्तों गलत चीज़ का पीछा करते हुए बर्बाद किया है।
बड़ी साइट्स पर मुझे सबसे अक्सर दिखने वाले Reasons
- Crawled -- currently not indexed: Google ने पेज़ पर विज़िट किया लेकिन फैसला किया कि यह इंडेक्स करने लायक नहीं है। आमतौर पर पतली कंटेंट, करीब-डुप्लिकेट, या ऐसे पेज़ जो बैकलिंक या इंटरनल लिंक नहीं कमाते।: 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 में) लेकिन उसे क्रॉल करने की परवाह नहीं की। यह कंटेंट समस्या नहीं, क्रॉल बजट समस्या है।: 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: किसी ने -- संभवतः आप, संभवतः एक प्लगइन -- एक noindex निर्देश जोड़ा। इसके बारे में नीचे और जानकारी।: 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 पेज़ क्यों क्रॉल कर रहा था। साइट तेज़ थी। sitemap साफ़ था। सब कुछ सतह पर ठीक दिख रहा था।
पता चला कि साइट हज़ारों फेसेटेड नेविगेशन URLs जेनरेट कर रही थी -- ?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.
क्रॉल बजट मूलतः URLs की संख्या है जो Googlebot आपकी साइट पर किसी दिए गए समय में क्रॉल करने को तैयार है। Google का अपना क्रॉल बजट पर दस्तावेज़ वाकई पढ़ने लायक है -- वे ईमानदारी से बताते हैं कि यह कैसे काम करता है। संक्षिप्त संस्करण: अगर आप इसे कचरा URLs पर बर्बाद कर रहे हैं, तो महत्वपूर्ण पेजों को क्रॉल नहीं किया जाएगा।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 -- के पास पोस्ट टाइप स्तर पर, टैक्सोनॉमी स्तर पर, और व्यक्तिगत पेज स्तर पर अपने noindex टॉगल हैं। इनमें से कोई भी आपकी साइट के विशाल हिस्सों को ख़ामोशी से noindex कर सकता है।
Scale पर noindex की जांच कैसे करें
पूरी साइट पर Screaming Frog चलाएँ और noindex निर्देश लौटाने वाले पेजों के लिए फिल्टर करें। सूची निर्यात करें। फिर अपने महत्वपूर्ण URL ग्रुप्स के साथ क्रॉस-रेफ़रेंस करें -- प्रोडक्ट पेज, सेवा पेज, ब्लॉग पोस्ट, जो कुछ भी व्यवसाय के लिए मायने रखता है।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 पर। अत्यधिक व्यापक Disallow: नियमों को देखें। मैंने Disallow: /wp-content/ जैसे नियम देखे हैं जो CSS और JS को ब्लॉक करते हैं जो Google को पेजों को सही तरीके से रेंडर करने के लिए चाहिए -- जिससे रेंडरिंग विफलताएँ हो सकती हैं जो इंडेक्सेशन समस्याएँ दिखती हैं, लेकिन वास्तव में Googlebot को एक टूटा हुआ पेज दिख रहा है।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 पाथ्स से सुलभ हैं -- /product/red-shoes/, /product-category/footwear/red-shoes/, और कभी-कभी /shop/red-shoes/। प्रत्येक का एक कैनोनिकल टैग है, लेकिन अगर वे कैनोनिकल्स थोड़े अलग URLs की ओर इशारा करते हैं (HTTP बनाम HTTPS, ट्रेलिंग स्लैश बनाम कोई ट्रेलिंग स्लैश नहीं, www बनाम non-www), तो Google उन्हें विभिन्न पेजों की ओर इशारा करने वाले सिग्नल के रूप में मानता है और समेकन करने से इनकार करता है।/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 प्लगइन स्वचालित रूप से साइटमैप्स जेनरेट करते हैं। अधिकांश उन URLs को भी शामिल करते हैं जो आप अपने साइटमैप में नहीं चाहते -- पेजिनेटेड पेजेस (/page/2/, /page/3/), लेखक अभिलेख, दो पोस्टों वाले टैग पेजेस, अटैचमेंट पेजेस।/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.
इस पोस्ट की शुरुआत से संपत्ति सूची साइट पर, साइटमैप में हर टैग अभिलेख, हर पेजिनेशन पेज, और -- यह कहना अभी भी मुझे चोट पहुँचाता है -- WordPress लॉगिन पेज सहित 41,000 URLs थे। इसे पहले साफ़ करें। हमेशा।
---
आंतरिक लिंकिंग एक इंडेक्सेशन समस्या है
लोग आंतरिक लिंकिंग को इंडेक्सेशन टूल के रूप में नहीं सोचते। उन्हें सोचना चाहिए।
यदि किसी पेज पर कोई इंटरनल लिंक नहीं है, तो Googlebot को पहले स्थान पर ही उसे खोजने में कठिनाई हो सकती है -- भले ही वह आपके sitemap में हो। Sitemaps को Google को बताते हैं कि URL मौजूद है। इंटरनल लिंक्स को Google को बताते हैं कि URL महत्वपूर्ण है। ये अलग-अलग संकेत हैं।matters. Those are different signals.
बड़ी content sites पर, orphaned pages बहुत आम हैं। तीन साल पहले publish किया गया एक blog post, जो post archives से linked है लेकिन किसी और post से कभी नहीं जुड़ा है, समय के साथ अपनी crawl frequency लगभग शून्य तक गिरा देखेगा।
मैं Screaming Frog की "Orphan Pages" रिपोर्ट (Site Structure के अंतर्गत) का उपयोग करता हूँ sitemap में उन पेजों को खोजने के लिए जिनपर शून्य इंटरनल लिंक्स हैं। फिर मैं कंटेंट के माध्यम से वापस जाता हूँ ताकि लिंक्स जोड़ने के लिए तार्किक जगहें खोज सकूँ। जबरदस्ती वाले लिंक्स नहीं -- वास्तविक प्रासंगिक लिंक्स। समय लगता है लेकिन indexation पर प्रभाव वास्तविक होता है।
---
एक 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 करें।
- Canonical tags की जाँच करें -- प्लगइन सेटिंग्स नहीं, rendered output की।
- सर्वर लॉग्स निकालें और Googlebot के क्रॉल डिस्ट्रिब्यूशन को URL टाइप्स के आर पार चेक करें।
- XML साइटमैप ऑडिट करें — जंक URLs (पेजिनेशन, खाली आर्काइव्स, गैर-कैनोनिकल वेरिएंट्स) के लिए।
- Orphan Pages रिपोर्ट चलाएं और आंतरिक रूप से अनलिंक्ड पेजेस को पहचानें।
- फेसेटेड नेविगेशन या पैरामीटर-आधारित URLs के लिए चेक करें जो डुप्लिकेट क्रॉलेबल पाथ्स जेनरेट कर रहे हैं।
- पेज स्पीड की पुष्टि करें -- जो पेजेज लगातार time out होते हैं, Googlebot उन्हें कम प्राथमिकता देता है।
सब कुछ एक साथ ठीक करने की कोशिश मत करो। समस्याओं की एक कैटेगरी को ठीक करो, Google के फिर से क्रॉल करने के लिए तीन से चार सप्ताह इंतज़ार करो, माप लो, फिर अगली कैटेगरी पर जाओ। अगर तुम सब कुछ एक साथ बदलते हो तो कभी नहीं पता चल पाएगा कि असल में क्या काम किया।
---
FAQ
पेजेस एक हफ्ते इंडेक्स हो जाते हैं और फिर अगले हफ्ते ड्रॉप हो जाते हैं?
Google का इंडेक्स स्थिर नहीं है। वह लगातार पेजेज को quality signals, freshness, और crawl efficiency के आधार पर दोबारा मूल्यांकन करता है। एक पेज जो छह महीने पहले indexed था, drop किया जा सकता है यदि उसे कोई लिंक्स नहीं मिले, उसे internally link नहीं किया गया, या यदि आपके डोमेन के Google के quality assessment में बदलाव हुआ है। यह site migration या significant content overhaul के बाद विशेष रूप से आम है -- Google फिर से crawl करता है, फिर से मूल्यांकन करता है, और कभी-कभी तय करता है कि पहले indexed किए गए पेजेज अब स्तर पर नहीं हैं।
क्या साइट स्पीड इंडेक्सेशन को प्रभावित करता है?
हाँ, ज्यादातर लोगों को एहसास से अधिक सीधे। यदि पेजेज धीरे-धीरे respond करते हैं -- initial server response के लिए लगातार 2-3 सेकंड से अधिक -- Googlebot उनको crawl करने को कम प्राथमिकता देगा। बड़े पैमाने पर, इसका मतलब है कि slow pages को indexed रहने के लिए काफी बार crawl नहीं किया जाता है। अपने Time to First Byte (TTFB) को ठीक करें इससे पहले कि आप गति से संबंधित किसी अन्य चीज़ की चिंता करें। WP Rocket जैसा सस्ता caching प्लगइन एक मापने योग्य अंतर बनाता है। Core Web Vitals rankings के लिए महत्वपूर्ण हैं, लेकिन TTFB crawling के लिए महत्वपूर्ण है।Core Web Vitals matter for rankings, but TTFB matters for crawling.
क्या साइटमैप में बहुत सारे पेज इंडेक्सेशन को नुकसान पहुंचा सकते हैं?
सीधे नहीं -- लेकिन low-quality URLs के साथ एक bloated sitemap उस संकेत को कमजोर करता है जो आप Google को भेज रहे हैं कि क्या महत्वपूर्ण है। यदि आपका sitemap 40,000 URLs रखता है और उनमें से 30,000 thin archive pages हैं, तो Google सीखता है कि आपके sitemap को शोर के रूप में कैसे माना जाए। Sitemaps को tight और high-quality रखें। इसे URL inventory नहीं, editorial curation के रूप में सोचें।
क्या मुझे Google के URL Inspection टूल का उपयोग करके मैन्युअल रूप से इंडेक्सिंग के लिए रिक्वेस्ट करनी चाहिए?
individual महत्वपूर्ण पेजेज के लिए -- हाँ, बिल्कुल। लेकिन हजारों URLs के लिए manually indexing request करने का प्रयास न करें। यह scale नहीं करता है और Google ने कहा है कि वह manually-requested URLs को long run में special treatment नहीं देता है। underlying crawl और quality issues को ठीक करें और Google के natural crawling को काम करने दें। Manual inspection का उपयोग यह verify करने के लिए करें कि specific pages को index किया जा सकता है, सबकुछ force करने के लिए नहीं।can be indexed, not to force index everything.
---
ईमानदार सच यह है कि indexation diagnosis glamorous काम नहीं है। यह spreadsheets, log files, और बहुत सारी प्रतीक्षा है। लेकिन एक बड़ी साइट पर, अपने lost indexed pages के 20% को भी recover करना organic traffic में एक meaningful jump का मतलब हो सकता है -- और एक 40,000-page property listings site पर, वह real money है। किसी भी exotic चीज़ का पीछा करने से पहले basics को ठीक करें। यह लगभग कभी exotic नहीं होता है।