2021 में मुझे एक WooCommerce साइट विरासत में मिली जिसमें 140,000 प्रोडक्ट URLs थे, एक साइटमैप.xml जो बिल्कुल 50,000 एंट्रीज पर रुक गई, और एक क्लाइंट जो यह समझ नहीं पा रहा था कि Google Search Console केवल उनके पेजों का एक अंश इंडेक्स कर रहा क्यों है। साइटमैप फाइल बस... रुक गई। कोई त्रुटि नहीं। कोई चेतावनी नहीं। बस चुप्पी से ट्रंकेट हुआ। यह वह तरह की चीज है जो आपकी रैंकिंग को नुकसान पहुंचाती है बिना कभी कोई दृश्यमान संकेत भेजे कि कुछ गलत है।
अगर आपकी साइट 50,000 URLs के आगे बढ़ रही है, तो यह वह पोस्ट है जो आपको इस दीवार से टकराने से पहले पढ़नी चाहिए।
50,000 URL सीमा क्यों मौजूद है
साइटमैप प्रोटोकॉल, जिसे Google, Bing और अन्य द्वारा संयुक्त रूप से बनाए रखा जाता है, एक साइटमैप फाइल पर दो कठोर प्रतिबंध सेट करता है: 50,000 URLs से अधिक नहीं, और 50MB अनकंप्रेस्ड से अधिक नहीं। ये सुझाव नहीं हैं। Googlebot जो सीमा पहले हिट करता है उसपर फाइल को पार्स करना बंद कर देगा।
ईमानदारी से, 50MB की सीमा शायद ही कभी समस्या होती है। अधिकतर URLs इतने छोटे होते हैं कि आपको URL काउंट सीमा से पहले फाइल साइज सीमा तक पहुंचने के लिए हास्य रूप से लंबे पाथ की जरूरत होगी। 50,000 URL की सीमा वह है जो लोगों को काटती है।
तो जब आपकी कैटलॉग, आपका ब्लॉग आर्काइव, आपका यूजर-जेनरेटेड कंटेंट सेक्शन उस सीमा को पार कर जाता है, तो आप क्या करते हैं? आप एक sitemap index file का उपयोग करते हैं।
Sitemap Index File असल में क्या होती है
सरल अवधारणा। एक sitemap की जगह जिसमें URLs हों, आप एक parent XML file बनाते हैं जो कई child sitemaps की ओर इशारा करती है। हर child sitemap में 50,000 URLs तक हो सकते हैं। Index file खुद 50,000 child sitemaps तक को reference कर सकती है। तो सैद्धांतिक सीमा 2.5 बिलियन URLs है। आप इस तक नहीं पहुँचेंगे।
संरचना इस तरह दिखती है:
`` sitemap_index.xml ├── sitemap-posts-1.xml (50,000 तक ब्लॉग पोस्ट) ├── sitemap-posts-2.xml (अतिरिक्त पोस्ट) ├── sitemap-products-1.xml (50,000 तक प्रोडक्ट) ├── sitemap-products-2.xml (अतिरिक्त प्रोडक्ट) └── sitemap-pages.xml (स्टेटिक पेज) ``
Index file root element के रूप में <sitemapindex> का उपयोग करती है, <urlset> की जगह। हर child को एक <sitemap> tag में रखा जाता है जिसमें एक <loc> होता है जो child file की ओर इशारा करता है, और वैकल्पिक रूप से एक <lastmod> timestamp।
आप Google Search Console को जो submit करते हैं वह index file का URL है, न कि हर एक child का। एक submission, एक source of truth।
अपने URLs को बुद्धिमानी से कैसे विभाजित करें
यहीं जहाँ ज्यादातर tutorials गलत जाते हैं। वे कहते हैं "बस अपने URLs को 50,000 के ग्रुप में बाँट दो" और वहीं छोड़ देते हैं। लेकिन chunk boundaries maintainability के लिए और Googlebot के crawl logic के लिए मायने रखती हैं।
मैं content type से विभाजित करता हूँ, मनमानी संख्या से नहीं। हमेशा। हर बार।
सबसे पहले कंटेंट टाइप के हिसाब से विभाजित करें
- प्रोडक्ट्स को अपनी sitemap सीरीज़ में रखें (sitemap-products-1.xml,
sitemap-products-2.xml) - ब्लॉग पोस्ट्स को अपनी सीरीज़ में
- कैटेगरी और टैग पेजेस को एक साथ रखें (ये नेविगेशनल हैं, इन्हें एक ग्रुप मानें)
- स्टैटिक पेजेस (About, Contact, landing pages) को एक ही फ़ाइल में, आमतौर पर 1,000 URLs से कम
यह क्यों मायने रखता है? क्योंकि जब प्रोडक्ट डेटाबेस को bulk update मिलता है, तो सिर्फ प्रोडक्ट sitemaps को फिर से जेनरेट करने की ज़रूरत होती है। आप एक बड़ी monolithic फ़ाइल को invalidate और regenerate नहीं करते जो प्रोडक्ट्स और ब्लॉग पोस्ट्स को मिलाती हो। Googlebot आमतौर पर sitemaps को क्रम में crawl करता है, इसलिए टाइप के हिसाब से ग्रुप करने से उसे साफ़ सिग्नल मिलता है कि उसे किस तरह का कंटेंट मिलने वाला है।
फिर हर टाइप के अंदर pagination करें
एक बार जब कंटेंट टाइप 50,000 URLs को exceed कर जाए, तो pagination करें। शुरुआत से ही एक consistent naming convention का इस्तेमाल करें। मैं sitemap-{type}-{page}.xml का इस्तेमाल करता हूँ। फ़ाइल के नाम में dates मत डालें। मैंने 2019 में एक news site पर यह गलती की थी और sitemap-articles-2019-march.xml जैसी filenames के साथ ख़त्म हुआ जो उसी moment meaningless हो गईं जब हमें historical content को regenerate करने की ज़रूरत पड़ी। numbered pages के साथ रहें।
lastmod को ईमानदारी से रखें
आपकी child sitemaps में <lastmod> element को उस समय को reflect करना चाहिए जब कंटेंट को actually last modified किया गया था, न कि जब आपने sitemap को regenerate किया था। मैंने ऐसे setups देखे हैं जहाँ हर regeneration हर URL को आज की date के साथ stamp करता है। यह Googlebot को सिखाता है कि आपके lastmod को ignore कर दे क्योंकि सिग्नल noise है। अपने CMS का actual modified timestamp इस्तेमाल करें। WordPress में, वह wp_posts table से post_modified_gmt है।
टूलिंग: वास्तव में बड़े पैमाने पर क्या काम करता है
WordPress साइट्स के लिए (जो हम Seahawk पर ज्यादातर बनाते हैं), जो विकल्प मैं असल में इस्तेमाल करता हूँ:
- Yoast SEO sitemap indexes को automatically संभालता है जब आपके पास एक post type के लिए 1,000 से ज्यादा URLs हों। यह clean, segmented files generate करता है। लेकिन default batch size प्रति child sitemap 1,000 URLs है, जो conservative है। आप इसे
wpseo_sitemap_entries_per_pageसे filter कर सकते हैं। मैं आमतौर पर इसे well-hosted servers पर 5,000 तक push करता हूँ। - Rank Math भी यही करता है, लेकिन इसमें थोड़ा ज्यादा granular control है कि कौन से post types और taxonomies को अपना child sitemap मिले। एक हाल की client साइट पर 80,000 WooCommerce products के साथ, Rank Math का segmentation box से ही Yoast से ज्यादा clean था।
- WP-CLI के साथ custom generation वह है जिसका मैं उपयोग करता हूँ जब साइट के पास unusual content types हों या plugin-generated sitemaps बनाने में बहुत slow हों। मैंने scripts लिखे हैं जो database को directly query करते हैं, 10,000 के chunks में results को paginate करते हैं, XML को disk पर write करते हैं, और फिर index file को last में write करते हैं। 200,000 URLs के लिए 30 seconds से भी कम में चलता है। Key यह है कि temp file में write करो और फिर atomically इसे place में move करो ताकि Googlebot को कभी half-written file न मिले।
Non-WordPress stacks के लिए, Screaming Frog SEO Spider आपकी site को crawl कर सकता है और आपके लिए एक sitemap index generate कर सकता है, लेकिन यह production sitemap generator से ज्यादा एक validation tool है। Production के लिए, sitemaps को crawler से नहीं, अपने data source से generate करो। Crawlers चीजों को miss करते हैं।
Search Console में Submit और Validate करना
Google Search Console खोलो, Sitemaps report खोलो, और अपनी index file URL submit करो। एक ही URL। बस यह।
Submission के बाद, 24-48 घंटे दो और फिर दो चीजें check करो:
- Submitted vs Discovered। "Discovered URLs" count को आपके actual URL count की तरफ बढ़ना चाहिए। अगर यह weird तरीके से जल्दी plateau हो जाए, तो संभवत: आपको crawl budget issue या malformed child sitemap है।
- व्यक्तिगत चाइल्ड साइटमैप स्थिति। Search Console आपको प्रत्येक चाइल्ड साइटमैप और उसकी स्थिति दिखाएगा। अगर एक चाइल्ड एरर रिटर्न कर रहा है, तो आप इसे दूसरों को छुए बिना अलग कर सकते हैं। यह इंडेक्स स्ट्रक्चर का अंडररेटेड फायदा है।
Bing Webmaster Tools भी वही तरीके से काम करता है। इंडेक्स फाइल सबमिट करें, चाइल्ड नहीं। दो मिनट का काम है।
आम गलतियां जो मुझे लगातार दिखती हैं
Seahawk नियमित रूप से एजेंसियों के लिए साइटों का ऑडिट करता है। वही साइटमैप एरर बार-बार आते हैं।
Noindexed URLs साइटमैप में। अगर किसी URL के पास noindex मेटा टैग है या X-Robots हेडर है, तो वह आपके साइटमैप में नहीं होना चाहिए। बस। साइटमैप क्रॉल और इंडेक्स करने की सिफारिश है। Noindexed URLs शामिल करने से क्रॉल बजट बर्बाद होता है और सिग्नल भ्रमित होता है। मैं साइटमैप URLs के विरुद्ध एक त्वरित Screaming Frog क्रॉल चलाता हूं और किसी भी प्रमुख साइट लॉन्च से पहले noindex रेसपांस के लिए फिल्टर करता हूं।
साइटमैप में ब्लॉक किए गए URLs। Noindex से भी बदतर: URLs जो robots.txt में डिसअलाऊ हैं लेकिन फिर भी साइटमैप में सूचीबद्ध हैं। Googlebot विरोधाभास देख सकता है। यह आपको पेनल्टी नहीं देगा, लेकिन यह लापरवाही है और समय बर्बाद करता है।
नए चाइल्ड को जोड़ने के बाद इंडेक्स फाइल को अपडेट न करना। यह स्पष्ट लगता है लेकिन कस्टम इमप्लीमेंटेशन को भ्रमित करता है। आप एक नया कंटेंट टाइप जोड़ते हैं, एक नई चाइल्ड साइटमैप फाइल जेनरेट करते हैं, और इंडेक्स में <sitemap> एंट्री जोड़ना भूल जाते हैं। चाइल्ड फाइल डिस्क पर मौजूद है लेकिन कुछ भी इसकी ओर इशारा नहीं करता। मैंने इसे महीनों तक नज़रअंदाज़ देखा है।
चाइल्ड साइटमैप को व्यक्तिगत रूप से सबमिट करना इंडेक्स की जगह। अगर आपके पास 12 चाइल्ड साइटमैप हैं और आप सभी 12 को Search Console में अलग-अलग सबमिट करते हैं, तो आप संगठनात्मक लाभ खो चुके हैं। इंडेक्स सबमिट करें। इसे कैस्केड होने दें।
क्रॉल बजट: बड़ी तस्वीर
साइटमैप इंडेक्स फाइलें क्रॉल बजट प्रबंधन से सीधे जुड़ी होती हैं। क्रॉल बजट पर Google का डॉक्यूमेंटेशन पढ़ने के लायक है अगर आप इस स्केल पर काम कर रहे हैं। संक्षिप्त संस्करण: Googlebot के पास आपकी साइट पर प्रति दिन समय का एक सीमित हिस्सा है, और एक अच्छी तरह से संरचित साइटमैप इंडेक्स इसे पहले आपकी सर्वोच्च-प्राथमिकता वाली कंटेंट पर वह समय खर्च करने में मदद करता है।
मैं बड़ी साइटों पर ताज़ा अपडेट की गई कंटेंट को अपनी खुद की child sitemap में डालता हूँ। कुछ implementations जो मैंने किए हैं वे sitemap-recent.xml का उपयोग करते हैं जिसमें केवल पिछले 30 दिनों में संशोधित URLs हैं, हर घंटे refresh होते हैं। Googlebot उसे aggressively recrawl करता है। पुरानी historical sitemap files को कम बार crawl किया जाता है, जो ठीक है क्योंकि वह कंटेंट बदल नहीं रहा है।
यह कोई ट्रिक नहीं है। यह सिर्फ crawl signal को कंटेंट की वास्तविकता के साथ match करना है।
FAQ
एक sitemap index file में कितनी child sitemaps हो सकती हैं?
Protocol एक ही index file में 50,000 child sitemaps तक allow करता है। व्यावहारिक रूप से, अगर आप उस संख्या के करीब पहुँच रहे हैं तो आपके पास सैकड़ों लाख URLs हैं और आप ऐसी समस्याओं का सामना कर रहे हैं जो अधिकांश साइटें कभी नहीं करतीं। बहुत सारी बड़ी साइटों के लिए, आपके पास कहीं 5 से 50 child sitemaps होंगी।
क्या मुझे अपनी sitemap files को gzip से compress करना चाहिए?
आपको करना आवश्यक नहीं है, लेकिन बड़ी files के लिए यह करने लायक है। 50MB की sitemap gzip से लगभग 3-5MB तक compress हो जाती है। Googlebot बिना किसी configuration के .xml.gz files को accept करता है। अधिकांश आधुनिक web servers इसे transparently handle करेंगे यदि आप server level पर gzip compression enable करते हैं। Static-file sitemaps के लिए जो disk में generate होती हैं, मैं gzip से pre-compress करता हूँ और .xml.gz को directly serve करता हूँ।
क्या मुझे image या video sitemaps को index में शामिल करना चाहिए?
हाँ। अगर आप image sitemap extensions या video sitemaps का उपयोग कर रहे हैं, तो उन्हें same index file में child sitemaps के रूप में शामिल किया जा सकता है। उन्हें अपनी खुद की child files में रखें बजाय image data को अपनी standard URL sitemaps में मिलाने के। यह files को छोटा रखता है और जब आपकी media library update हो तो सिर्फ image sitemap को regenerate करना आसान बनाता है।
अगर कोई child sitemap 404 return करता है तो क्या होता है?
Search Console सितemap रिपोर्ट में उस child को errored के रूप में flag करेगा। Googlebot फिर भी index में अन्य child sitemaps को process करेगा। यह पूरे index को invalidate नहीं करेगा, लेकिन वे URLs जो केवल उस 404'd child में listed हैं, sitemap के through discover नहीं होंगे। इसे तुरंत ठीक करें। Error को ठीक करने के बाद भी यह Search Console की रिपोर्ट में हफ्तों तक रहता है, जो annoying है लेकिन harmless है।
क्या मैं एक छोटी site पर sitemap index का उपयोग कर सकता हूँ?
तकनीकी रूप से हाँ, लेकिन इसका कोई कारण नहीं है। 10,000 URLs से कम पर added complexity लायक नहीं है। एक single sitemap.xml maintain करना simpler है, debug करना simpler है, और बिल्कुल वही काम करता है। जब आपको इसकी जरूरत हो तो index file का उपयोग करें, पहले नहीं।
---
50,000 URL limit हर बार लोगों को surprise करती है, आमतौर पर सबसे गलत समय पर, जैसे product launch से ठीक पहले। Index structure को एक बार सही तरीके से set करने का मतलब है कि जैसे-जैसे site बढ़ता है आपको इसके बारे में दोबारा सोचना नहीं पड़ता। एक घंटे के setup के लिए यह लायक है।
संबंधित पाठ: 2026 में AI खोज कीवर्ड रिसर्च: यह क्या है, पारंपरिक क्यों, AI खोज, और बहुभाषी SEO।