2021 में मुझे एक WooCommerce साइट विरासत में मिली जिसमें 140,000 प्रोडक्ट URLs थे, एक साइटमैप.xml जो बिल्कुल 50,000 एंट्रीज पर रुक गई, और एक क्लाइंट जो यह समझ नहीं पा रहा था कि Google Search Console केवल उनके पेजों का एक अंश इंडेक्स कर रहा क्यों है। साइटमैप फाइल बस... रुक गई। कोई त्रुटि नहीं। कोई चेतावनी नहीं। बस चुप्पी से ट्रंकेट हुआ। यह वह तरह की चीज है जो आपकी रैंकिंग को नुकसान पहुंचाती है बिना कभी कोई दृश्यमान संकेत भेजे कि कुछ गलत है।
अगर आपकी साइट 50,000 URLs के आगे बढ़ रही है, तो यह वह पोस्ट है जो आपको इस दीवार से टकराने से पहले पढ़नी चाहिए।
50,000 URL सीमा क्यों मौजूद है
साइटमैप प्रोटोकॉल, जिसे Google, Bing और अन्य द्वारा संयुक्त रूप से बनाए रखा जाता है, एक साइटमैप फाइल पर दो कठोर प्रतिबंध सेट करता है: 50,000 URLs से अधिक नहीं, और 50MB अनकंप्रेस्ड से अधिक नहीं। ये सुझाव नहीं हैं। Googlebot जो सीमा पहले हिट करता है उसपर फाइल को पार्स करना बंद कर देगा।Sitemaps protocol, maintained jointly by Google, Bing, and others, sets two hard constraints on a single sitemap file: no more than 50,000 URLs, and no larger than 50MB uncompressed. These aren't suggestions. Googlebot will stop parsing the file at whichever limit it hits first.
ईमानदारी से, 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 (स्टेटिक पेज) `` sitemap_index.xml ├── sitemap-posts-1.xml (up to 50,000 blog posts) ├── sitemap-posts-2.xml (overflow posts) ├── sitemap-products-1.xml (up to 50,000 products) ├── sitemap-products-2.xml (overflow products) └── sitemap-pages.xml (static pages) ``
Index file root element के रूप में <sitemapindex> का उपयोग करती है, <urlset> की जगह। हर child को एक <sitemap> tag में रखा जाता है जिसमें एक <loc> होता है जो child file की ओर इशारा करता है, और वैकल्पिक रूप से एक <lastmod> timestamp।<sitemapindex> as the root element instead of <urlset>. Each child is wrapped in a <sitemap> tag with a <loc> pointing to the child file, and optionally a <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)
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 के साथ रहें।sitemap-{type}-{page}.xml . Don't use dates in the filename. I made that mistake on a news site in 2019 and ended up with filenames like sitemap-articles-2019-march.xml that became completely meaningless the moment we needed to regenerate historical content. Stick to 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 है।<lastmod> element in your child sitemaps should reflect when the content was actually last modified, not when you regenerated the sitemap. I've seen setups where every regeneration stamps every URL with today's date. That trains Googlebot to ignore your lastmod entirely because the signal is noise. Use your CMS's actual modified timestamp. In WordPress, that's post_modified_gmt from the wp_posts table.
Tooling: What Actually Works at Scale
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 करता हूँ। handles sitemap indexes automatically once you have more than 1,000 URLs per post type. It generates clean, segmented files. But the default batch size is 1,000 URLs per child sitemap, which is conservative. You can filter that up with
wpseo_sitemap_entries_per_page. I usually push it to 5,000 on well-hosted servers. - Rank Math भी यही करता है, लेकिन इसमें थोड़ा ज्यादा granular control है कि कौन से post types और taxonomies को अपना child sitemap मिले। एक हाल की client साइट पर 80,000 WooCommerce products के साथ, Rank Math का segmentation box से ही Yoast से ज्यादा clean था। does the same, with slightly more granular control over which post types and taxonomies get their own child sitemaps. On a recent client site with 80,000 WooCommerce products, Rank Math's segmentation out of the box was cleaner than Yoast's.
- 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 न मिले। is what I reach for when the site has unusual content types or the plugin-generated sitemaps are too slow to generate. I've written scripts that query the database directly, paginate results in chunks of 10,000, write the XML to disk, and then write the index file last. Runs in under 30 seconds for 200,000 URLs. The key is writing to a temp file and atomically moving it into place so Googlebot never hits a 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 करते हैं।Screaming Frog SEO Spider can crawl your site and generate a sitemap index for you, though it's better as a validation tool than a production sitemap generator. For production, generate sitemaps from your data source, not from a crawler. Crawlers miss things.
Search Console में Submit और Validate करना
Google Search Console खोलो, Sitemaps report खोलो, और अपनी index file URL submit करो। एक ही URL। बस यह।Google Search Console, open the Sitemaps report, and submit your index file URL. One URL. That's it.
Submission के बाद, 24-48 घंटे दो और फिर दो चीजें check करो:
- Submitted vs Discovered। "Discovered URLs" count को आपके actual URL count की तरफ बढ़ना चाहिए। अगर यह weird तरीके से जल्दी plateau हो जाए, तो संभवत: आपको crawl budget issue या malformed child sitemap है। The "Discovered URLs" count should be climbing toward your actual URL count. If it plateaus weirdly early, you likely have a crawl budget issue or a malformed child sitemap.
- व्यक्तिगत चाइल्ड साइटमैप स्थिति। Search Console आपको प्रत्येक चाइल्ड साइटमैप और उसकी स्थिति दिखाएगा। अगर एक चाइल्ड एरर रिटर्न कर रहा है, तो आप इसे दूसरों को छुए बिना अलग कर सकते हैं। यह इंडेक्स स्ट्रक्चर का अंडररेटेड फायदा है। Search Console will show you each child sitemap and its status. If one child is returning an error, you can isolate it without touching the others. This is the underrated advantage of the index structure.
Bing Webmaster Tools भी वही तरीके से काम करता है। इंडेक्स फाइल सबमिट करें, चाइल्ड नहीं। दो मिनट का काम है।
आम गलतियां जो मुझे लगातार दिखती हैं
Seahawk नियमित रूप से एजेंसियों के लिए साइटों का ऑडिट करता है। वही साइटमैप एरर बार-बार आते हैं।
Noindexed URLs साइटमैप में। अगर किसी URL के पास noindex मेटा टैग है या X-Robots हेडर है, तो वह आपके साइटमैप में नहीं होना चाहिए। बस। साइटमैप क्रॉल और इंडेक्स करने की सिफारिश है। Noindexed URLs शामिल करने से क्रॉल बजट बर्बाद होता है और सिग्नल भ्रमित होता है। मैं साइटमैप URLs के विरुद्ध एक त्वरित Screaming Frog क्रॉल चलाता हूं और किसी भी प्रमुख साइट लॉन्च से पहले noindex रेसपांस के लिए फिल्टर करता हूं। If a URL has a noindex meta tag or X-Robots header, it should not be in your sitemap. Full stop. A sitemap is a recommendation to crawl and index. Including noindexed URLs wastes crawl budget and confuses the signal. I run a quick Screaming Frog crawl against the sitemap URLs and filter for noindex responses before any major site launch.
साइटमैप में ब्लॉक किए गए URLs। Noindex से भी बदतर: URLs जो robots.txt में डिसअलाऊ हैं लेकिन फिर भी साइटमैप में सूचीबद्ध हैं। Googlebot विरोधाभास देख सकता है। यह आपको पेनल्टी नहीं देगा, लेकिन यह लापरवाही है और समय बर्बाद करता है। Even worse than noindex: URLs that are disallowed in robots.txt but still listed in the sitemap. Googlebot can see the contradiction. It won't penalise you for it, but it's sloppy and it wastes time.
नए चाइल्ड को जोड़ने के बाद इंडेक्स फाइल को अपडेट न करना। यह स्पष्ट लगता है लेकिन कस्टम इमप्लीमेंटेशन को भ्रमित करता है। आप एक नया कंटेंट टाइप जोड़ते हैं, एक नई चाइल्ड साइटमैप फाइल जेनरेट करते हैं, और इंडेक्स में <sitemap> एंट्री जोड़ना भूल जाते हैं। चाइल्ड फाइल डिस्क पर मौजूद है लेकिन कुछ भी इसकी ओर इशारा नहीं करता। मैंने इसे महीनों तक नज़रअंदाज़ देखा है। This sounds obvious but it trips up custom implementations. You add a new content type, generate a new child sitemap file, and forget to add the <sitemap> entry to the index. The child file exists on disk but nothing points to it. I've seen this sit unnoticed for months.
चाइल्ड साइटमैप को व्यक्तिगत रूप से सबमिट करना इंडेक्स की जगह। अगर आपके पास 12 चाइल्ड साइटमैप हैं और आप सभी 12 को Search Console में अलग-अलग सबमिट करते हैं, तो आप संगठनात्मक लाभ खो चुके हैं। इंडेक्स सबमिट करें। इसे कैस्केड होने दें। If you have 12 child sitemaps and you submit all 12 to Search Console separately, you've lost the organisational benefit. Submit the index. Let it cascade.
क्रॉल बजट: बड़ी तस्वीर
साइटमैप इंडेक्स फाइलें क्रॉल बजट प्रबंधन से सीधे जुड़ी होती हैं। क्रॉल बजट पर Google का डॉक्यूमेंटेशन पढ़ने के लायक है अगर आप इस स्केल पर काम कर रहे हैं। संक्षिप्त संस्करण: Googlebot के पास आपकी साइट पर प्रति दिन समय का एक सीमित हिस्सा है, और एक अच्छी तरह से संरचित साइटमैप इंडेक्स इसे पहले आपकी सर्वोच्च-प्राथमिकता वाली कंटेंट पर वह समय खर्च करने में मदद करता है।Google's documentation on crawl budget is worth reading if you're operating at this scale. The short version: Googlebot has a finite amount of time it'll spend on your site per day, and a well-structured sitemap index helps it spend that time on your highest-priority content first.
मैं बड़ी साइटों पर ताज़ा अपडेट की गई कंटेंट को अपनी खुद की child sitemap में डालता हूँ। कुछ implementations जो मैंने किए हैं वे sitemap-recent.xml का उपयोग करते हैं जिसमें केवल पिछले 30 दिनों में संशोधित URLs हैं, हर घंटे refresh होते हैं। Googlebot उसे aggressively recrawl करता है। पुरानी historical sitemap files को कम बार crawl किया जाता है, जो ठीक है क्योंकि वह कंटेंट बदल नहीं रहा है।sitemap-recent.xml that only contains URLs modified in the last 30 days, refreshed hourly. Googlebot recrawls that one aggressively. The older historical sitemap files get crawled less frequently, which is fine because that content isn't changing.
यह कोई ट्रिक नहीं है। यह सिर्फ 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 करता हूँ।need to, but it's worth doing for large files. A 50MB sitemap compresses down to roughly 3-5MB with gzip. Googlebot accepts .xml.gz files without any configuration. Most modern web servers will handle this transparently if you enable gzip compression at the server level. For static-file sitemaps generated to disk, I pre-compress with gzip and serve the .xml.gz directly.
क्या मुझे 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 के लिए यह लायक है।