जिस Sitemap को Google ने छह महीने तक नहीं पढ़ा, और 14 सेकंड की फिक्स

अगर Google Search Console आपके Sitemap Index को Success दिखा रहा है जबकि Discovered pages शून्य पर है, और Child Sitemaps हर बार दोबारा सबमिट करने के बाद भी "Couldn't fetch" पर रह रहे हैं, तो आप शायद Server की समस्या नहीं देख रहे हैं। आप Google के Sitemap Scheduler के अंदर एक Per-URL Backoff देख रहे हैं। इसे साबित करने का सबसे तेज़ तरीका है कि समान फ़ाइल को थोड़ा भिन्न URL के तहत दोबारा सबमिट करें और देखें क्या होता है।

यह निदान मुझे छह महीने, पाँच अलग-अलग Audits और चार अलग-अलग AI मॉडल्स लगे। आखिरकार जिस परीक्षण ने इसे साबित किया वह 14 सेकंड का था।

मुख्य निष्कर्ष: एक Sitemap Index "Success" दिखा सकता है जबकि इसके अंदर के हर Child Sitemap Google के लिए अदृश्य हों। अगर आपके Edge Logs में "Couldn't fetch" Child के लिए Googlebot का कोई Request नहीं है, तो विफलता आपकी ओर से नहीं है—Google की ओर से है। समान फ़ाइल को एक Versioned URL जैसे /sitemap/0.xml?v=20260815 पर दोबारा सबमिट करने से Backoff को Bypass किया जा सकता है और कुछ सेकंड में प्रोसेस हो जाता है।

"Success" वास्तव में क्या Report कर रहा था

यह साइट Deluxe Astrology है—मेरे माता-पिता का Vedic Astrology Platform और सबसे बड़ी चीज़ जो मैं चलाता हूँ: लगभग 240,000 URLs 30 भाषाओं में, Supabase से प्रकाशित और 63 Child Sitemaps के साथ एक Sitemap Index के रूप में परोसी गई। मैंने इसके Architecture के बारे में Deluxe Astrology Project Page पर लिखा है।

Indexed Pages कई हफ़्तों से गिर रहे थे। Impressions जून के अंत में गायब हो गई। और वह एक System जिसका पूरा काम Google को नए URLs की सूची देना है—यह एक हरी Tick दिखा रहा था।

Sitemap Index को Search Console में खोलिए और यह कहता है "Sitemap Index processed successfully"। इसमें क्लिक करिए और Sitemaps की Table 0-0 of 0 दिखाती है। Google ने Index को तीन बार तीन हफ़्तों में Fetch किया, इसे Index के रूप में सही तरीके से Parse किया, लेकिन इसके किसी भी Child को Register नहीं किया। एक भी Child Sitemap कभी Fetch नहीं हुआ। जब मैंने तीन को सीधे सबमिट किया, वे घंटों "Couldn't fetch" पर रह गए।

यह जाल है। एक Sitemap Index पर Status केवल Index File के बारे में एक बयान है। यह बताता है कि XML Parse हुआ और Child URLs अच्छी तरह से बनाए गए दिखते हैं। यह आपको नहीं बताता कि Google ने कभी जाकर उन्हें पढ़ा या नहीं। यह भेद एक Table में छिपा हुआ है जिसे अधिकांश लोग कभी Scroll तक नहीं करते, और यह पूरा खेल है किसी भी साइट पर जो Sitemap Index की जरूरत है।

Server पर सबकुछ ठीक था, पाँच अलग-अलग बार

अगर आपने "Couldn't fetch" को हिट किया है तो आप जानते हैं कि अगला घंटा कैसे जाता है। आप URL को Curl करते हैं। आप robots.txt Check करते हैं। आप Firewall Check करते हैं। आप CDN Cache Check करते हैं। आप URL Inspection में Live Test चलाते हैं। सबकुछ Clean आता है। तो आप अपने आप को Classic Search Console Lie बताते हैं: इसे समय चाहिए, 24 से 72 घंटे में वापस Check करो।

महीनों में यह एक वास्तव में thorough Investigation बन गया, और केवल मेरी ओर से नहीं। मैंने समस्या को कई Frontier Models के माध्यम से Independent Auditors के रूप में चलाया: Claude, Kimi, GLM और कुछ Custom Agents, प्रत्येक के पास Codebase, Search Console Data और Edge Logs तक पहुंच थी। मैंने पहले लिखा है कि एक बार में कितने AI Models वास्तव में चलाने लायक हैं, और यह वह Case था जिसने इसे सबसे कठोरता से परीक्षण किया।

वे लगभग सब कुछ पर सहमत थे, और वे लगभग सब कुछ के बारे में सही थे:

• Live Sitemap Index ने एक Valid <sitemapindex> सभी 63 Children के साथ, सही Content Type, कोई Byte Order Mark नहीं, कोई Cross-host URLs नहीं परोसा।
• हर Child ने एक Valid <urlset> सही URL Counts के साथ परोसा।
• Googlebot ने URL Inspection के माध्यम से index और child दोनों का अपना live fetch किया, और असली XML मिला। "URL Google के लिए उपलब्ध है।"
• Edge logs ने index के लिए असली Googlebot requests दिखाए जो allowed थे और cache से 200 serve किए गए थे।
• robots.txt, middleware, redirects या CDN config में sitemap paths को कुछ भी touch नहीं किया गया था।

एक पहली गलती असली थी और पहले ही ठीक की जा चुकी थी। WAF पर एक per-IP rate limit, जिसे कई महीने पहले एक bot farm से लड़ने के लिए जोड़ा गया था जो मेरे hosting bill को तबाह कर रहा था, ने crawler traffic को कुछ समय के लिए challenge कर रहा था। वह rule सही किया गया। Correction के बाद, हर audit एक ही निष्कर्ष पर पहुंचा: server side साफ है, Google को समय चाहिए, 24 से 72 घंटे में फिर से check करें।

पांच audits। एक जैसी verdict। एक जैसी recommendation। संख्या कभी नहीं बदली।

संकेत एक error नहीं था, absence था।

असुविधाजनक तथ्य edge logs में छिपा था, उसमें जो नहीं था। तीन child sitemaps submit करने के बाद, किसी भी उनके लिए कोई Googlebot request नहीं था। न एक allowed, न एक challenged, न एक denied। Google children को fetch करने में विफल नहीं हो रहा था। Google कोशिश न करने का चुनाव कर रहा था।

आप इसे server से diagnose नहीं कर सकते, construction से। कुछ भी arrive नहीं होता inspect करने के लिए। Standard kit में हर tool एक request को explain करने के लिए बनाया गया है जो गलत हो गया, और कोई request नहीं था। यह समस्या का एक ही class है जिसे log file analysis omission के बजाय evidence से solve करता है: आप hits के लिए देखते हैं, और जवाब empty result set है।

Search Console का live test यह और भी बदतर बनाता है, क्योंकि यह जो भी scheduler है उसे bypass करता है जो वह चुनाव करता है। यह on demand fetch करता है, एक अलग code path से, और cheerfully report करता है "available" एक URL के लिए जिसे sitemap subsystem कभी queue नहीं करेगा। एक green live test यह proof नहीं है कि sitemap pipeline कभी file को touch करेगा।

API ने सच कहा जो UI नहीं कहेगी

Search Console Sitemaps API ने पहला honest signal दिया। UI कहता है "Couldn't fetch", जो एक cause के साथ एक failure की तरह पढ़ा जाता है। API returns करता है isPending: true with errors: 0 और कोई lastDownloaded timestamp बिल्कुल नहीं।

ये अलग-अलग claims हैं। "Couldn't fetch" एक attempt को imply करता है जो failed हुआ। isPending with zero errors का मतलब कोई attempt कभी नहीं किया गया। छः महीने की debugging एक failure की ओर निर्देशित की गई थी जो exist नहीं करती थी।

अगर आप anything को scale पर run करते हैं, तो API को wire up करें इससे पहले कि आप उसकी जरूरत हों। यह एक OAuth scope और कुछ lines of code है, और यह एक status string के बीच का difference है जो reassurance के लिए designed है और record की actual state। मैं इसे heavily lean करता हूँ मेरे Claude Code SEO audit workflow में इसी कारण के लिए।

Controlled experiment

छठे audit को run करने की बजाय, मैंने एक control run किया।

पहले, एक baseline। मैंने एक sitemap submit किया जिसे Google ने कभी नहीं देखा था, site के एक छोटे section के लिए एक। यह download किया गया और submission के 34 सेकंड बाद process किया गया। तो pipeline healthy थी, host reachable था, और Google इस domain से sitemaps fetch करने के लिए willing था right now।

फिर real test। मैंने stuck children में से एक को resubmit किया, byte for byte identical, same route से same server पर served, बस एक difference के साथ: end पर एक query string। /sitemap/0.xml?v=20260815।

समान फ़ाइल। समान सर्वर। समान बाइट्स। भिन्न स्ट्रिंग। एक ढाई घंटे तक अदृश्य रहा और अभी भी है, दूसरा 14 सेकंड में पढ़ा गया।

यह संपूर्ण निदान है, और यह कारण है कि मैं तर्क देता रहता हूं कि एक नियंत्रित परीक्षा सत्यापन के एक और दौर से बेहतर है। हर ऑडिट ने सर्वर के बारे में तथ्यों की पुष्टि की थी। किसी ने भी एकमात्र इनपुट को नहीं बदला जो महत्वपूर्ण निकला।

वास्तव में क्या हो रहा था

Google का sitemap सिस्टम उन सटीक 63 URLs को प्रति-URL विफलता बैकऑफ़ में रख रहा था।

महीनों पहले, इंडेक्स का हर पढ़ना सेकंड के भीतर एक एकल Google IP से 63 चाइल्ड फ़ेच का विस्फोट ट्रिगर करता था। यह एक इंडेक्स के लिए सामान्य Googlebot व्यवहार है: यह पैरेंट को पढ़ता है, फिर चाइल्ड को अधिक या कम एक साथ प्राप्त करता है। WAF पर प्रति-IP दर सीमा, औसत मानव ट्रैफ़िक के लिए आकार दी गई, एक पते से 63 अनुरोधों का विस्फोट देखी और अपनी कॉन्फ़िगरेशन के अनुसार काम किया। इसने उन्हें चुनौती दी। हर चक्र। हफ्तों के लिए।

एकल इंडेक्स अनुरोध स्वयं हमेशा आगे बढ़ गया, क्योंकि एक अनुरोध विस्फोट नहीं है। यही कारण है कि इंडेक्स "सफलता" पढ़ता रहा जबकि इसके चाइल्ड कभी अस्तित्व में नहीं आए। यह नियम बिल्कुल ठीक उन URLs को तोड़ने के लिए आकार दिया गया था जिन्हें मुझे Google को पढ़ने की आवश्यकता थी, जबकि एक URL को जो उन पर रिपोर्ट करता है अछूता छोड़ दिया।

फ़ायरवॉल को ठीक करने से Google की उन URLs की मेमोरी नहीं हटी जो विफल हुई थीं। इसने केवल नई विफलताओं को बनाना बंद कर दिया। उन 63 विशिष्ट स्ट्रिंग्स पर बैकऑफ़ फ़िक्स को सहन करता था, और प्रतीक्षा के बारे में कुछ भी इसे एक ऐसे समयमान पर समाप्त करने वाला नहीं था जो मैं देख सकूं।

फ़िक्स: 63 सबमिशन, शून्य डिप्लॉय

Search Console API के माध्यम से मैंने सभी 63 चाइल्ड को संस्करण क्वेरी स्ट्रिंग के साथ फिर से सबमिट किया। लगभग दो मिनट के भीतर उनमें से हर एक को फ़ेच और प्रोसेस कर दिया गया: 155,545 URLs Google के साथ पंजीकृत, शून्य त्रुटियां, शून्य चेतावनियां। खोजे गए पृष्ठ, जिन्होंने छह महीने के लिए शून्य पढ़ा था, मेरे देखते हुए आबाद हो गए।

टिकाऊ फ़िक्स अगली रिलीज़ में एक दो-पंक्ति परिवर्तन है: sitemap इंडेक्स को संस्करण वाले चाइल्ड URLs को एमिट करना चाहिए, इसलिए इंडेक्स और robots.txt उन URLs की ओर इशारा करते हैं जिन्हें Google पढ़ने के लिए तैयार है। जब भी जनरेशन लॉजिक बदलता है संस्करण टोकन को बंप करें और आप मुफ्त में एक स्वच्छ कैश-बस्टिंग तंत्र प्राप्त करते हैं।

एक ईमानदार चेतावनी। इंडेक्सिंग खोज नहीं है। Google महीनों की अविश्वास के बाद इस होस्ट को एक ड्रिप पर क्रॉल कर रहा है, और 155,000 URLs एक सप्ताह में नहीं खींचे जाते हैं। खोज फिर से काम करना पूर्वशर्त है, परिणाम नहीं। यदि आपका crawl budget पहले से ही पतला है, तो sitemap को ठीक करना वह जगह है जहां काम शुरू होता है।

पाँच ऑडिट गलत उत्तर पर क्यों आए

यह वह हिस्सा है जिस पर मैं बार-बार लौटता हूँ।

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

एक साझा अंधे स्थान पर अभिसरण बिल्कुल सर्वसम्मति जैसा दिखता है। पाँच ऑडिटर समान साक्ष्य पढ़ते हैं एक ही धारणा के साथ, कि एक फ़ेच विफलता एक फ़ेच प्रयास का तात्पर्य है, पाँच आत्मविश्वासी सहमतियाँ और शून्य प्रगति का उत्पादन करेंगे। यह सहमति पुष्टि जैसी महसूस होती है। यह वास्तव में ऑडिटर के बीच सहसंबंध है, न कि ऑडिटर और वास्तविकता के बीच।

गतिरोध को तोड़ने वाली चीज़ एक और ऑडिट नहीं थी। यह तय करना था कि छह महीने की "72 घंटे प्रतीक्षा करें" एक योजना के बजाय एक परिकल्पना है, और एक ऐसी परीक्षा डिजाइन करना जहाँ एकमात्र चर URL स्ट्रिंग था। यह एक मानवीय कार्य है, और मुझे नहीं लगता कि यह जल्द ही होना बंद होता है।

मैंने जो पाँच नियम सीखे

• Sitemap index पर सफलता index फ़ाइल के बारे में है, बच्चों के बारे में नहीं। "Sitemaps read" तक स्क्रॉल करें। अगर यह शून्य कहता है, तो हरा टिक सिर्फ सजावटी है।
• UI में "Couldn't fetch" का मतलब API में "अभी processed नहीं हुआ" है। API पढ़ें। isPending और lastDownloaded ही वह हैं जो आप वास्तव में जानना चाहते हैं, और UI आपको कोई भी नहीं दिखाता।
• Google आपकी infrastructure की गलतियों को आप से ज़्यादा समय तक याद रखता है। एक rate limit जिसने क्रॉलर को कुछ हफ़्तों तक चुनौती दी, वह नियम के जाने के बाद भी विशिष्ट URLs को backoff में रख सकता है। इंतज़ार इसे साफ़ नहीं करता। URL को version करना करता है।
• Rate limits को औसत ट्रैफ़िक के लिए नहीं, क्रॉलर bursts के लिए आकार दें। एक index read एक IP से सेकंड के भीतर N बच्चों को fetch करता है। N से नीचे कोई भी per-IP limit आपको ठीक उन URLs को चुनौती देगा जिन्हें Google को सबसे ज़्यादा पढ़ने की ज़रूरत है, जबकि index itself pass करता है और सफलता की रिपोर्ट करता है।
• जब कई models सहमत हों कि server clean है और आपको इंतज़ार करना चाहिए, तो वे शायद server के बारे में सही हैं और wait के बारे में गलत। एक छठे audit की जगह एक control चलाएँ।

अगर आपको लगता है कि आपके पास यही समस्या है

इसे इसी क्रम में काम करें। इसमें लगभग पंद्रह मिनट लगते हैं और यह server की समस्या को Google-side backoff से साफ़ तरीके से अलग करता है।

• Search Console में sitemap index खोलें और status नहीं, Sitemaps read count को पढ़ें। एक healthy index पर शून्य बच्चे read होना signature है।
• Search Console API के माध्यम से same sitemaps खींचें। प्रत्येक के लिए isPending, errors और lastDownloaded को नोट करें।
• पिछले 30 दिनों में विशिष्ट बच्चों के paths के लिए अपने edge या CDN logs में Googlebot requests के लिए खोजें। किसी भी status की कोई requests नहीं, इसका मतलब है कि समस्या आपके server पर नहीं है।
• एक बिल्कुल नया sitemap URL जमा करें जो Google ने कभी नहीं देखा है। अगर यह एक मिनट से कम में process होता है, तो आपका host और आपका pipeline ठीक हैं।
• एक stuck बच्चे को version query string के साथ फिर से जमा करें। अगर वह process होता है और plain URL नहीं, तो आपके पास आपका उत्तर है और same step में remedy है।
• अपने WAF rate limits को averages के विरुद्ध नहीं, burst behaviour के विरुद्ध audit करें, ताकि backoff खुद को फिर से build न करे। फिर बड़ी sites पर अपने indexation fundamentals के बाकी हिस्से को check करें।

इस सब के पीछे reference material के लिए, sitemap build और submit करने के लिए Google का अपना guide और sitemaps.org protocol अभी भी एकमात्र दो documents हैं जो मायने रखते हैं। कोई भी per-URL backoff का mention नहीं करता, जो यह है कि इसने इतना समय क्यों लिया।

अगर आप 100,000 URLs से अधिक के साथ एक site चलाते हैं और आप same symptom पर stuck हैं, तो यह वह चीज़ है जो मैं जीविका के लिए करता हूँ: बड़ी sites पर technical SEO, उन programmatic SEO builds सहित जहाँ sitemaps formality होना बंद कर देते हैं और whole distribution channel बन जाते हैं। मेरे पास API scripts, diagnostic sequence और scar tissue है।

FAQ

मेरा sitemap index Success क्यों कहता है लेकिन शून्य discovered pages दिखाता है?

क्योंकि status सिर्फ index file के बारे में है। Google ने आपके <sitemapindex> को parse किया और well-formed बच्चों के URLs को पाया, जो सब कुछ "Success" दावा करता है। चाहे वह फिर से उन बच्चों को fetch करे या नहीं, यह Sitemaps read table में अलग से रिपोर्ट किया जाता है। एक valid index पर शून्य read का मतलब है कि बच्चों को कभी process नहीं किया गया, और हरा टिक आपको कुछ भी उपयोगी नहीं बता रहा है।

Search Console में "Couldn't fetch" का वास्तव में क्या मतलब है?

जितना लगता है उससे कम। Search Console API में same sitemap आमतौर पर isPending: true के साथ errors: 0 और कोई lastDownloaded value नहीं return करता है, जिसका मतलब है कि Google ने fetch का प्रयास नहीं किया बजाय प्रयास करने और असफल होने के। एक failure को debug करने का समय बिताने से पहले API check करें जो कभी नहीं हुई हो।

मुझे sitemap को वास्तव में stuck मानने से पहले कितना समय इंतजार करना चाहिए?

एक sitemap जिसे Google पढ़ने के लिए तैयार है, आमतौर पर सेकंड से मिनट में प्रोसेस होता है, दिनों में नहीं। अगर कोई child sitemap 24 घंटे से अधिक समय से pending है जबकि उसी host पर एक बिल्कुल नया sitemap URL तुरंत प्रोसेस हो जाता है, तो और इंतजार करना कोई रणनीति नहीं है। इसके बजाय versioned resubmission test चलाएं।

क्या sitemap URL में query string जोड़ने से duplicate content या अन्य SEO समस्याएं पैदा होती हैं?

नहीं। एक sitemap एक discovery file है, न कि कोई indexable page, और इसके अंदर के URLs अपरिवर्तित रहते हैं। Google /sitemap/0.xml और /sitemap/0.xml?v=20260815 को दो अलग-अलग sitemap resources के रूप में मानता है, जो बिल्कुल वही property है जिसका आप उपयोग कर रहे हैं। अपने index और robots.txt को versioned URLs की ओर इंगित करें ताकि एक canonical सेट चल रहा हो।

क्या एक WAF rate limit sitemap discovery को बिना किसी और चीज को तोड़े ही break कर सकता है?

हां, और यही है जो इसे खोजना इतना मुश्किल बनाता है। एक sitemap index को पढ़ना एक सेकंड के भीतर एक Google IP से child fetches का burst trigger करता है, इसलिए human traffic के लिए साइज किया गया per-IP limit children को challenge करेगा जबकि single index request pass हो जाएगा। साइट पर बाकी सब कुछ, live URL Inspection tests सहित, पूरी तरह काम करता रहता है।

क्या sitemap को ठीक करने से खोई हुई impressions तुरंत बहाल हो जाएंगी?

नहीं। Discovery और indexing अलग-अलग चरण हैं। 155,000 URLs को पंजीकृत करना pipeline में input को बहाल करता है, लेकिन एक host पर जो महीनों से fail हो रहा है वहां crawl rate धीरे-धीरे ठीक होता है, और indexing decisions crawling के बाद आते हैं। हफ्तों की उम्मीद करें, और यह समय सुनिश्चित करने के लिए लगाएं कि जो pages discover हो रहे हैं वे indexing के लायक हैं।