बड़ी साइटों पर क्रॉल बजट: मैंने क्या सीखा

एक क्रॉल रिपोर्ट के करीब पेज 47,000 पर, मैंने सच में अपना करियर बदलने पर विचार किया। यह साइट, यूके में स्थित एक बड़ी ई-कॉमर्स कैटलॉग थी जिसमें करीब 91,000 इंडेक्सेबल URLs थे, और छह महीने से लगभग 34,000 पेज इंडेक्स किए हुए स्थिर थे। बढ़ नहीं रहा था। क्लाइंट को यकीन था कि कुछ "टूटा हुआ" था। मैंने उन्हें कहा कि कुछ भी टूटा नहीं है। मैं आधा सही था।

मुख्य सीख: 91,000 पृष्ठों की साइट पर Googlebot वही क्रॉल करता है जो आपकी आर्किटेक्चर उसे बताती है: आंतरिक लिंकिंग, sitemap अनुशासन, और व्यर्थ को खत्म करना यह तय करता है कि कौन से पृष्ठ इंडेक्स होते हैं।

उस प्रोजेक्ट ने मेरे क्रॉल बजट के बारे में सोचने का तरीका पूरी तरह बदल दिया। सिद्धांत नहीं — मैंने Google का डॉक्यूमेंटेशन पढ़ा था, मैंने Search Central के वीडियो देखे थे, मुझे पता था कि क्रॉल बजट क्या है। लेकिन इसे जानना और वास्तव में इसे बड़े पैमाने पर मैनेज करना दो बिल्कुल अलग चीजें हैं। आगे जो आता है वह सब कुछ है जो मैं अपने आप को बताता अगर मैं मार्च 2022 की उस मंगलवार की सुबह वापस जा सकता जब मैंने पहली बार Google Search Console में क्रॉल स्टेट्स को देखा और मेरा पेट डूब गया।

क्रॉल बजट असल में क्या मायने रखता है (और क्या नहीं)

यहाँ वह चीज है जो लोगों को लगातार confuse करती है: crawl budget का मतलब "Google आपके लिए कितने pages को index करेगा" नहीं है। इसका मतलब है कि Googlebot एक दिए गए crawl window के भीतर कितने URLs को fetch करेगा, जिसे Google स्वयं crawl rate limit और crawl demand के combination के रूप में परिभाषित करता है।

क्रॉल रेट लिमिट वह गति है जिस पर Googlebot आपके सर्वर को हैमर किए बिना क्रॉल कर सकता है। क्रॉल डिमांड वह है कि Google कितना क्रॉल करना चाहता है, जो इस बात से चलित होता है कि आपके URLs कितने लोकप्रिय हैं और वे कितनी बार बदलते हैं। इन दोनों लीवर को एक साथ गुणा करें और आपको अपनी साइट को कितना क्रॉलिंग ध्यान मिलता है इसका एक मोटा अंदाजा हो जाता है।

1,000 पेज से कम वाली अधिकतर साइटों के लिए, यह प्रासंगिक नहीं है। Google सब कुछ क्रॉल करेगा। लेकिन जब आप दसियों हजार तक पहुंचते हो, और बिल्कुल जब आप छह अंकों को तोड़ते हो, तो Googlebot चुनाव करने लगता है। यह प्राथमिकता देगा। यह नजरअंदाज करेगा। और अगर आपने इसे सही चीजों को प्राथमिकता देने के लिए सेट नहीं किया है, तो यह खुशी से अपना समय आपके session-ID पैरामीटर URLs को क्रॉल करने और आपके फिल्टर किए गए फेसेट पेजों को क्रॉल करने में लगाएगा जबकि आपके नए प्रोडक्ट लॉन्च हफ्तों तक नजरअंदाज रहेंगे।

यह कोई परिकल्पना नहीं है। यह 91,000-पेज प्रोजेक्ट पर वास्तव में हुआ था।

Faceted navigation बड़ी साइटों पर मेरे द्वारा सामना किया गया सबसे बड़ा crawl budget killer है। लगातार। हर बार।

कैटलॉग साइट के पास एक फेसेटेड फिल्टर सिस्टम था — रंग, आकार, सामग्री, ब्रांड — कहीं भी कोई URL पैरामीटर हैंडलिंग कॉन्फ़िगर नहीं थी। प्रत्येक फिल्टर कॉम्बिनेशन एक अलग URL जेनरेट करता था। आप "blue," "medium," "cotton," और "BrandX" चुन सकते थे और /shop?colour=blue&size=medium&material=cotton&brand=brandx पा सकते थे। फिर किसी ने ऑर्डर फ्लिप कर दिया और /shop?size=medium&colour=blue&brand=brandx&material=cotton पा गया। अलग URL, समान कंटेंट।

मैंने Screaming Frog क्रॉल (संस्करण 18, जो पुराने संस्करणों की तुलना में JavaScript रेंडरिंग को बहुत बेहतर तरीके से हैंडल करता है) चलाया और फ़िल्टर सिस्टम के अकेले 200,000 से अधिक URLs पाए। Googlebot इन पर लगातार जा रहा था। जबकि हजारों वैध प्रोडक्ट पेज अनइंडेक्स्ड रहते थे।

Fix जो वास्तव में काम करी

हमने इसे दो चरणों में किया। पहला, मैंने Google Search Console में URL पैरामीटर हैंडलिंग कॉन्फ़िगर किया, फिल्टर पैरामीटर को "Doesn't change page content" के रूप में फ्लैग किया ताकि Googlebot को कंसोलिडेट करने का संकेत मिले। दूसरा, और ज्यादा महत्वपूर्ण, डेव टीम ने एक उचित canonical स्ट्रैटेजी लागू की, जो सभी फिल्टर कॉम्बिनेशन को बेस कैटेगरी पेज पर वापस पॉइंट करती थी। हमने उन low-value फिल्टर पेजों में noindex भी जोड़ा जिन्हें व्यावहारिक रूप से canonicalised नहीं किया जा सकता था।

करीब आठ हफ्तों में, इंडेक्स किए गए पेज की संख्या बढ़ने लगी। विस्फोटक नहीं, लगातार। जो असल में वह है जो आप चाहते हैं। इंडेक्स किए गए पेजों में अचानक वृद्धि कभी-कभी Google से एक re-evaluation ट्रिगर कर सकती है बजाय एक स्वच्छ जीत के।

Search Console में Crawl Stats: वह डेटा जिसे अधिकांश लोग नज़रअंदाज़ करते हैं

मैंने पिछले तीन सालों में crawl issues के लिए specifically लगभग 80 sites को audit किया है। शायद 15% लोग जिन्होंने मुझे वह sites दिए, उन्होंने कभी Search Console में Crawl Stats report को देखा था। यह संख्या बहुत अधिक होनी चाहिए।

Crawl Stats रिपोर्ट आपको औसत क्रॉल रिक्वेस्ट प्रति दिन, औसत response time, और महत्वपूर्ण रूप से, Googlebot वास्तव में क्या क्रॉल कर रहा है यह दिखाती है जो उद्देश्य के अनुसार टूटा हुआ है (discovery बनाम refresh)। अगर आपके "refresh" क्रॉल हावी हो रहे हैं और discovery क्रॉल न्यूनतम हैं, तो Google अपना समय उन पेजों को फिर से चेक करने में लगा रहा है जिन्हें यह पहले से जानता है। नए को नहीं ढूंढ रहा। यह एक संकेत है कि आपकी internal linking संभवतः उथली है या आपका XML sitemap कोई उपयोगी काम नहीं कर रहा है।

91,000-पेज प्रोजेक्ट पर, हम करीब 2,400 क्रॉल रिक्वेस्ट प्रति दिन पर बैठे थे। उस आकार की साइट के लिए, यह मतलब है कि Google को सिद्धांत में सब कुछ को एक बार क्रॉल करने में करीब 38 दिन लगेंगे, मान लें कि हर रिक्वेस्ट एक अलग, उपयोगी पेज से हिट हुई। यह नहीं था। क्रॉल रिक्वेस्ट का करीब 40% redirect chains या parameter-inflated duplicates से हिट हो रहा था।

Average Response Time आपके सोचने से ज्यादा महत्वपूर्ण है

एक बात जिसे मैंने अपने करियर की शुरुआत में कम आंका: Googlebot genuinely server speed के प्रति sensitive है। Ranking के तरीके से नहीं (खैर, सीधे तरीके से नहीं), लेकिन crawl willingness के तरीके से। धीमे सर्वर Googlebot को back off करने का कारण बनते हैं। Google अपनी crawl rate को कम करेगा ताकि एक struggling server को stress न दे।

Catalogue site के पास peak traffic के दौरान category pages पर Time to First Byte लगभग 1.8 seconds था। क्लाइंट के shared hosting से dedicated VPS में जाने के बाद proper caching के साथ (page caching के लिए WP Rocket, object caching के लिए Redis), TTFB 400ms से कम गिर गया। अगले छह हफ्तों में crawl requests प्रति दिन में नोटिस योग्य रूप से चढ़ाई हुई। Correlation, जाहिर है, लेकिन मैंने यह pattern बहुत बार देखा है इसे dismiss करने के लिए।

XML Sitemaps: उन्हें एक Formality की तरह मानना बंद करें

अधिकतर sitemaps जो मैं इनहेरिट करता हूं, वे गलत हैं। नाटकीय रूप से गलत नहीं, बस चुपचाप, बेकार तरीके से गलत।

Common issues जो मैं देखता हूं:

Sitemap में ऐसे pages जो 404s या 301 redirects return करते हैं
Sitemap में noindexed pages शामिल हैं (यह Googlebot को confuse करता है, आप एक साथ कह रहे हैं "इसे crawl करो" और "इसे index मत करो")
<lastmod>dates जो static हैं या बस गलत हैं
50,000+ URLs वाले Sitemaps एक ही फाइल में (सीमा प्रति फाइल 50,000 है, और बड़ी फाइलें processing को धीमा करती हैं)
कोई sitemap index फाइल नहीं, बस एक monolithic XML blob

बड़ी catalogue project पर, sitemap में एक single file में 91,000 URLs थे। यह हर filtered URL को भी include कर रहा था जो कभी generate हुआ था, जिसमें से 40,000 से अधिक noindexed थे। Googlebot इस massive file को process कर रहा था और फिर discover कर रहा था कि ज़्यादातर URLs को crawl किया ही नहीं जाना चाहिए। दोनों तरफ से wasted signal।

हमने sitemap architecture को एक proper sitemap index के रूप में rebuild किया जो segmented child sitemaps की ओर इशारा करता है: एक core category pages के लिए, एक product pages के लिए (volume के कारण दो फाइलों में विभाजित), एक editorial content के लिए। हर फाइल 40,000 URLs से कम है। <lastmod>values database में actual last-modified date से dynamically generate होते हैं। कोई noindexed pages नहीं, कोई redirects नहीं।

Bing Webmaster Tools का data (हाँ, check करने के लायक है, Bing कभी-कभी आपको crawl behaviour patterns दिखाता है जो structural issues की ओर इशारा करते हैं जो Google को भी झेल रहे हैं) ने sitemap processing time में 60% से ज़्यादा की drop दिखाई।

Internal Linking: The Lever You Actually Control

यहाँ कुछ ऐसा है जिसकी मुझे genuinely सराहना तब तक नहीं हुई जब तक Seahawk ने 2020 में एक media client के लिए एक बड़ी content site, लगभग 65,000 articles, नहीं ली। Site को crawl budget issues थे, भले ही इसके पास well-formed sitemap और clean URL structure था। Problem internal linking depth था। हज़ारों articles effectively orphaned थे, किसी भी crawled page से उनकी ओर कोई internal link नहीं।

Googlebot सिर्फ sitemaps को follow नहीं करता। यह links को follow करता है। अगर एक page सिर्फ एक sitemap entry के through discoverable है और zero internal links हैं, तो इसे deprioritise किया जाता है। यह officially crisp terms में documented नहीं है, लेकिन internal linking पर Google की अपनी guidance स्पष्ट करती है कि important pages से crawlable links वह तरीका है जिससे Googlebot discovery को prioritise करता है।

उस मीडिया क्लाइंट के लिए, हमने Ahrefs के Site Audit टूल का उपयोग करके इंटरनल लिंक्स की जांच की और लगभग 12,000 आर्टिकल्स की पहचान की जिनके पास तीन या उससे कम इंटरनल लिंक्स थे। हमने CMS (WordPress, कस्टम Gutenberg ब्लॉक) में एक ऑटोमेटेड "संबंधित आर्टिकल्स" ब्लॉक बनाया जो संदर्भ से मिलती-जुलती कंटेंट को खींचता था। अगली तिमाही में, उस साइट पर इंडेक्स किए गए पेजेस 41,000 से बढ़कर 58,000 से अधिक हो गए। डोमेन ऑथोरिटी वही रही। कंटेंट प्रोडक्शन की दर वही रही। सिर्फ इंटरनल लिंकिंग बेहतर हुई।

यह नंबरड अप्रोच जो मैं अब हर बड़े साइट ऑडिट पर इस्तेमाल करता हूं:

Screaming Frog का पूरा क्रॉल चलाएं और इंटरनल लिंक डेटा एक्सपोर्ट करें
हर उस पेज की पहचान करें जिसके पास तीन से कम इनबाउंड इंटरनल लिंक्स हैं
Well-linked pages के विरुद्ध cross-reference करो, topical clusters खोजो
हाई-ट्रैफिक पेजेस से कंटेक्सचुअल इंटरनल लिंक्स बनाएं और उन्हें पतली-लिंक्ड पेजेस तक ले जाएं
Search Console के URL Inspection tool में validate करो कि newly linked pages "Discovered, currently not indexed" से "Crawled" पर move हो रहे हैं

वह "Discovered, currently not indexed" status Search Console में आपका canary है। इसका मतलब है कि Google को page का पता है लेकिन उसने fetching को prioritise नहीं किया है। Internal links को improve करना आमतौर पर इसे resolve करने का fastest तरीका है।

लॉग फाइल एनालिसिस: असुविधाजनक लेकिन जरूरी

मैं सच कहूँ तो, log file analysis कुछ ऐसा है जिससे मैंने सालों तक बचा। यह unnecessary depth लगता था जब crawl tools आपको ज़्यादातर चीज़ें दे देते थे। मैं गलत था।

Log files आपको बताती हैं कि Googlebot ने actually क्या किया, न कि आप अपने sitemap या crawl tool से क्या infer करते हैं। एक project पर, एक SaaS company जिसके पास लगभग 8,000 product documentation pages थे, log analysis ने reveal किया कि Googlebot अपने crawl time का लगभग 30% /wp-admin/adjacent URLs और admin-side assets पर spend कर रहा था जिन्हें robots.txt में block किया जाना चाहिए था। किसी ने यह properly set up नहीं किया था। Documentation pages जो चार महीने से crawl नहीं हुए थे।

Screaming Frog का Log File Analyser वह tool है जो मैं use करता हूँ। यह glamorous नहीं है लेकिन यह reliable है। अपनी server logs को import करो, Googlebot user agent के आधार पर filter करो, और URL hit frequency के आधार पर sort करो। Patterns जो emerge होते हैं, वे लगभग हमेशा illuminating होते हैं, और लगभग हमेशा कुछ ऐसा include करते हैं जो crawl हो रहा है जो नहीं होना चाहिए।

कब चिंता करें और कब छोड़ दें

हर बड़ी साइट को aggressive crawl budget management की जरूरत नहीं है। अगर आप 10,000 pages पर हैं और 9,800 indexed हैं, तो levers को खींचना शुरू न करें। आप उन समस्याओं को create करेंगे जहाँ कोई नहीं है।

Crawl budget management वास्तव में आपके समय के लायक बन जाता है जब:

आपके पास ~15,000 से अधिक indexable pages हैं
आपकी indexed count plateaued हो गई है हालाँकि नई content add की जा रही है
Crawl Stats आपके page volume के लिए आप जो उम्मीद करते हैं उससे well below average crawl requests दिखाता है
आप "Discovered, currently not indexed" या "Crawled, currently not indexed" स्थिति में हज़ारों URLs देखते हैं

वह दूसरी स्थिति, "Crawled, currently not indexed", अलग है और अलग से ध्यान देने लायक है। इसका मतलब है कि Google ने पेज को fetch किया और उसे index नहीं करने का फैसला किया, आमतौर पर कमज़ोर content या near-duplicate समस्याओं के कारण। Crawl budget optimization से कोई भी quality की समस्या ठीक नहीं होती।

---

सवाल-जवाब

क्या क्रॉल बजट छोटी साइटों को प्रभावित करता है?

शायद ही कभी किसी सार्थक तरीके से। अगर आपकी साइट में 1,000 से कम पेज हैं और जल्दी लोड होते हैं, तो Google लगभग निश्चित रूप से सब कुछ crawl करेगा चाहे जो भी हो। Crawl budget एक वास्तविक चिंता का विषय बनता है scale पर, आमतौर पर 10,000 से 15,000 पेज से ऊपर, या उन साइट्स पर जहाँ URLs का एक बड़ा हिस्सा dynamically generate होता है।

क्या सीधे साइटमैप सबमिट करने से क्रॉल बजट की समस्या ठीक हो जाएगी?

नहीं। एक sitemap discovery में मदद करता है, यह Google को बताता है कि ये URLs मौजूद हैं। लेकिन अगर आपकी साइट में structural समस्याएं हैं (faceted navigation spam, slow server response, shallow internal linking), तो एक sitemap उन signals को override नहीं करेगा। Sitemap को एक सुझाव समझें, command नहीं।

मैं कैसे चेक करूं कि Googlebot कचरा URLs पर क्रॉल बर्बाद कर रहा है?

Google Search Console में Crawl Stats रिपोर्ट से शुरू करें और देखें कि किस URL टाइप को सबसे ज्यादा अनुरोध मिल रहे हैं। फिर Screaming Frog क्रॉल के साथ क्रॉस-रेफरेंस करें ताकि उन URL पैटर्न की पहचान की जा सके जो डुप्लिकेट हैं, noindexed हैं, या कम मूल्य के हैं। लॉग फाइल विश्लेषण आपको सबसे सटीक तस्वीर देगा अगर आपके पास सर्वर लॉग तक पहुंच है।

क्रॉल बजट बचाने के लिए क्या मुझे `noindex` या `robots.txt disallow` का उपयोग करना चाहिए?

अलग-अलग काम के लिए अलग-अलग tools। robots.txt में Disallow Googlebot को पेज को fetch करने से रोकता है, जिससे crawl budget बचता है लेकिन Google उस पेज पर कोई भी signal नहीं पढ़ सकता। Noindex Google को पेज को fetch करने देता है लेकिन उसे सर्च परिणामों में शामिल न करने के लिए कहता है। Crawl budget विशेष रूप से, disallow सच में junk URLs (admin paths, internal search results) पर ज़्यादा प्रभावी है। Filtered facet pages के लिए जहाँ आप Google को content को समझने देना चाहते हैं लेकिन उसे index न करना चाहते हैं, noindex with a canonical आमतौर पर सही call होता है।

crawl budget की समस्याओं को ठीक करने के बाद सुधार देखने के लिए एक यथार्थवादी समयसीमा क्या है?

ईमानदारी से कहूँ तो, यह आपकी crawl rate पर निर्भर करता है। 91,000-page project पर, indexed page count में सार्थक movement मुख्य fixes deploy होने के बाद लगभग छह से आठ हफ़्ते लगे। रातोंरात परिवर्तन की उम्मीद न करें, Googlebot को re-crawl, re-evaluate करना होता है, और indexing pipeline के अपने latency भी होते हैं उसके ऊपर।

---

91,000-page project अच्छी तरह समाप्त हुया। Indexed pages 34,000 से पाँच महीनों में 71,000 से ऊपर चढ़े। Perfect नहीं था, ऐसे genuinely thin product pages थे जिन्हें index न किया जाना चाहिए था, लेकिन जो content मायने रखता था वह मिल गया। Client ने सवाल पूछना बंद कर दिया कि क्या कुछ टूट गया है। और मैंने crawl reports के page 47,000 के आसपास career changes को देखना बंद कर दिया। ज़्यादातर।

संबंधित पठन: 2026 में AI सर्च कीवर्ड रिसर्च: यह क्या है, परंपरागत क्यों, 301 बनाम 302 रीडायरेक्ट्स: SEO के लिए कौन सा वास्तव में महत्वपूर्ण है, और 2026 में LSI कीवर्ड्स: ये क्या हैं, ये क्या नहीं हैं, क्या।

बड़ी साइटों पर क्रॉल बजट: 91,000 पेजों को इंडेक्स करना