एक क्रॉल रिपोर्ट के करीब 47,000वें पेज के आसपास, मैंने सच में कैरियर बदलने पर विचार किया। यह साइट -- एक बड़ी UK-आधारित ई-कॉमर्स कैटलॉग जिसमें करीब 91,000 इंडेक्सेबल URLs थे -- छह महीने से लगभग 34,000 पेज इंडेक्स्ड पर रुकी हुई थी। बढ़ रही नहीं थी। क्लाइंट को यकीन था कि कुछ "टूटा हुआ" है। मैंने उन्हें बताया कि कुछ नहीं टूटा है। मैं आधा सही था।
मुख्य सीख: 91,000 पृष्ठों की साइट पर Googlebot वही क्रॉल करता है जो आपकी आर्किटेक्चर उसे बताती है: आंतरिक लिंकिंग, sitemap अनुशासन, और व्यर्थ को खत्म करना यह तय करता है कि कौन से पृष्ठ इंडेक्स होते हैं।On a 91,000-page site Googlebot crawls what your architecture tells it to: internal linking, sitemap discipline, and killing waste decide which pages get indexed.
उस प्रोजेक्ट ने मेरी सोच को क्रॉल बजट के बारे में पूरी तरह बदल दिया। थ्योरी नहीं -- मैंने Google डॉक्यूमेंटेशन पढ़ा था, मैंने Search Central वीडियो देखे थे, मुझे पता था कि क्रॉल बजट क्या है। लेकिन यह जानना और इसे स्केल पर मैनेज करना दो बिल्कुल अलग चीजें हैं। जो आगे आता है वह वह सब कुछ है जो मैं अपने आप को बताऊंगा अगर मैं मार्च 2022 की उस मंगलवार की सुबह वापस जा सकूं जब मैंने पहली बार Google Search Console में क्रॉल स्टैट्स निकाले और मेरा पेट गिरा।was. But knowing it and actually managing it at scale are two wildly different things. What follows is everything I'd tell myself if I could go back to that Tuesday morning in March 2022 when I first pulled the crawl stats in Google Search Console and felt my stomach drop.
क्रॉल बजट असल में क्या मायने रखता है (और क्या नहीं)
यहाँ वह चीज है जो लोगों को लगातार confuse करती है: crawl budget का मतलब "Google आपके लिए कितने pages को index करेगा" नहीं है। इसका मतलब है कि Googlebot एक दिए गए crawl window के भीतर कितने URLs को fetch करेगा, जिसे Google स्वयं crawl rate limit और crawl demand के combination के रूप में परिभाषित करता है।fetch within a given crawl window, which Google itself defines as a combination of crawl rate limit and crawl demand.
क्रॉल रेट लिमिट यह है कि Googlebot आपके सर्वर को हैमर किए बिना कितनी तेजी से क्रॉल कर सकता है। क्रॉल डिमांड यह है कि Google कितना क्रॉल करना चाहता है -- यह आपके URLs कितने लोकप्रिय हैं और वे कितनी बार बदलते हैं इससे संचालित होता है। इन दोनों लीवर को एक साथ गुणा करें और आपके पास यह मोटा अंदाजा होता है कि आपकी साइट को कितना क्रॉलिंग ध्यान मिलता है।wants to crawl -- driven by how popular your URLs are and how often they change. Multiply those two levers together and you have a rough sense of how much crawling attention your site gets.
1,000 पेज से कम वाली ज्यादातर साइटों के लिए, यह बेमानी है। Google सब कुछ क्रॉल करेगा। लेकिन एक बार जब आप दसियों हजार में आ जाते हैं -- और बिल्कुल जब आप छह अंकों में जाते हैं -- Googlebot चुनाव करने लगता है। यह प्राथमिकता देगा। यह अनदेखा करेगा। और अगर आपने इसे सही चीजों को प्राथमिकता देने के लिए सेट नहीं किया है, तो यह खुशी-खुशी अपना समय आपके session-ID पैरामीटर URLs और आपके फ़िल्टर किए गए facet पेजों को क्रॉल करने में लगाएगा जबकि आपके नए प्रोडक्ट लॉन्च हफ्तों तक अनदेखे रहते हैं।
यह कोई परिकल्पना नहीं है। यह 91,000-पेज प्रोजेक्ट पर वास्तव में हुआ था।
Faceted Navigation की समस्या जिसकी किसी ने चेतावनी नहीं दी
Faceted navigation बड़ी साइटों पर मेरे द्वारा सामना किया गया सबसे बड़ा crawl budget killer है। लगातार। हर बार।
कैटलॉग साइट के पास एक faceted फ़िल्टर सिस्टम था -- रंग, आकार, सामग्री, ब्रांड -- कहीं भी कोई 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, एक जैसी कंटेंट।/shop?colour=blue&size=medium&material=cotton&brand=brandx. Then someone flipped the order and got/shop?size=medium&colour=blue&brand=brandx&material=cotton. Different URL, identical content.
मैंने Screaming Frog क्रॉल (संस्करण 18, जो पुराने संस्करणों की तुलना में JavaScript रेंडरिंग को बहुत बेहतर तरीके से हैंडल करता है) चलाया और फ़िल्टर सिस्टम के अकेले 200,000 से अधिक URLs पाए। Googlebot इन पर लगातार जा रहा था। जबकि हजारों वैध प्रोडक्ट पेज अनइंडेक्स्ड रहते थे।
Fix जो वास्तव में काम करी
हमने इसे दो स्टेजों में टैकल किया। पहले, मैंने Google Search Console में URL पैरामीटर हैंडलिंग कॉन्फ़िगर किया -- फ़िल्टर पैरामीटर को "Doesn't change page content" के रूप में फ़्लैग करके Googlebot को कंसोलिडेट करने का संकेत दिया। दूसरा, और ज्यादा जरूरी, dev टीम ने एक उचित canonical strategy लागू की, सभी फ़िल्टर कॉम्बिनेशन को base category पेज की ओर इशारा किया। हमने low-value फ़िल्टर किए गए पेजों में भी noindex जोड़ा जिन्हें व्यावहारिक रूप से canonical नहीं किया जा सकता था।noindex to low-value filtered pages that couldn't practically be canonicalised.
करीब आठ हफ्तों में, इंडेक्स्ड पेज काउंट बढ़ने लगा। विस्फोटक रूप से नहीं -- स्थिर गति से। जो वास्तव में वह है जो आप चाहते हैं। इंडेक्स किए गए पेजों में अचानक स्पाइक कभी-कभी Google से एक पुनः-मूल्यांकन ट्रिगर कर सकता है एक साफ जीत की बजाय।
Search Console में Crawl Stats: वह डेटा जिसे अधिकांश लोग नज़रअंदाज़ करते हैं
मैंने पिछले तीन सालों में crawl issues के लिए specifically लगभग 80 sites को audit किया है। शायद 15% लोग जिन्होंने मुझे वह sites दिए, उन्होंने कभी Search Console में Crawl Stats report को देखा था। यह संख्या बहुत अधिक होनी चाहिए।Crawl Stats report in Search Console. That number should be much higher.
क्रॉल स्टैट्स रिपोर्ट आपको प्रति दिन औसत क्रॉल रिक्वेस्ट, औसत 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 करते हैं
- साइटमैप में noindexed पेज शामिल होना (यह Googlebot को भ्रमित करता है -- आप एक ही समय में "इसे क्रॉल करो" और "इसे इंडेक्स मत करो" दोनों कह रहे हैं)
<lastmod>dates जो static हैं या बस गलत हैंdates that are static or just wrong- 50,000+ URLs वाले Sitemaps एक ही फाइल में (सीमा प्रति फाइल 50,000 है, और बड़ी फाइलें processing को धीमा करती हैं)
- कोई sitemap index फाइल नहीं, बस एक monolithic XML blob
बड़े कैटलॉग प्रोजेक्ट पर, साइटमैप में एक ही फ़ाइल में 91,000 URLs थे। यह हर उस फ़िल्टर किए गए URL को भी शामिल कर रहा था जो कभी जेनरेट हुआ था -- जिनमें से 40,000 से अधिक noindexed थे। Googlebot इस विशाल फ़ाइल को प्रोसेस कर रहा था और फिर पाता था कि ज़्यादातर URLs को वैसे भी क्रॉल नहीं करना चाहिए। दोनों तरफ़ से सिग्नल बर्बाद हो रहा था।
हमने 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 नहीं।<lastmod>values dynamically generated from the actual last-modified date in the database. No noindexed pages, no redirects.
Bing Webmaster Tools डेटा (हाँ, चेक करने लायक है -- Bing कभी-कभी आपको क्रॉल व्यवहार पैटर्न दिखाता है जो Google को भी प्रभावित करने वाली संरचनात्मक समस्याओं का संकेत देते हैं) ने साइटमैप प्रोसेसिंग समय में 60% से अधिक की गिरावट दिखाई।
Internal Linking: The Lever You Actually Control
यहाँ कुछ ऐसा है जिसकी मुझे सच में सराहना नहीं थी जब तक Seahawk ने 2020 में एक मीडिया क्लाइंट के लिए एक बड़ी कंटेंट साइट -- लगभग 65,000 आर्टिकल -- पर काम नहीं किया। साइट को क्रॉल बजट समस्याएँ थीं भले ही इसका एक अच्छी तरह से बनाया हुआ साइटमैप और स्वच्छ URL संरचना थी। समस्या आंतरिक लिंकिंग गहराई थी। हज़ारों आर्टिकल प्रभावी रूप से अनाथ थे -- किसी भी क्रॉल किए गए पेज से उन्हें कोई आंतरिक लिंक नहीं था।
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 करता है।only follow sitemaps. It follows links. If a page is only discoverable through a sitemap entry and has zero internal links, it gets deprioritised. That's not officially documented in crisp terms, but Google's own guidance on internal linking makes clear that crawlable links from important pages are how Googlebot prioritises discovery.
उस मीडिया क्लाइंट के लिए, हमने Ahrefs के Site Audit टूल का उपयोग करके इंटरनल लिंक्स की जांच की और लगभग 12,000 आर्टिकल्स की पहचान की जिनके पास तीन या उससे कम इंटरनल लिंक्स थे। हमने CMS (WordPress, कस्टम Gutenberg ब्लॉक) में एक ऑटोमेटेड "संबंधित आर्टिकल्स" ब्लॉक बनाया जो संदर्भ से मिलती-जुलती कंटेंट को खींचता था। अगली तिमाही में, उस साइट पर इंडेक्स किए गए पेजेस 41,000 से बढ़कर 58,000 से अधिक हो गए। डोमेन ऑथोरिटी वही रही। कंटेंट प्रोडक्शन की दर वही रही। सिर्फ इंटरनल लिंकिंग बेहतर हुई।WordPress, custom Gutenberg block) that pulled contextually similar content. Over the following quarter, indexed pages on that site climbed from 41,000 to over 58,000. Same domain authority. Same content production rate. Just better internal linking.
यह नंबरड अप्रोच जो मैं अब हर बड़े साइट ऑडिट पर इस्तेमाल करता हूं:
- Screaming Frog का पूरा क्रॉल चलाएं और इंटरनल लिंक डेटा एक्सपोर्ट करें
- हर उस पेज की पहचान करें जिसके पास तीन से कम इनबाउंड इंटरनल लिंक्स हैं
- अच्छी तरह से लिंक किए गए पेजों के विरुद्ध क्रॉस-रेफ़रेंस करें -- विषयगत क्लस्टर खोजेंare well-linked -- find topical clusters
- हाई-ट्रैफिक पेजेस से कंटेक्सचुअल इंटरनल लिंक्स बनाएं और उन्हें पतली-लिंक्ड पेजेस तक ले जाएं
- Search Console के URL Inspection टूल में नए लिंक किए गए पेजों को "Discovered -- currently not indexed" से "Crawled" तक स्थानांतरित होते हुए वेरिफ़ाई करें
वह "Discovered -- currently not indexed" स्थिति Search Console में आपका कैनरी है। इसका मतलब है कि Google को पता है पेज मौजूद है लेकिन उसने इसे फ़ेच करने को प्राथमिकता नहीं दी है। आंतरिक लिंक में सुधार आमतौर पर इसे हल करने का सबसे तेज़ तरीका है।
लॉग फाइल एनालिसिस: असुविधाजनक लेकिन जरूरी
मैं सच कहूँ -- लॉग फ़ाइल विश्लेषण कुछ ऐसा है जिससे मैंने सालों तक बचा। यह बेकार की गहराई जैसा महसूस होता था जब क्रॉल टूल आपको ज़्यादातर सब कुछ दे देते थे। मैं गलत था।
लॉग फ़ाइलें आपको बताती हैं कि Googlebot ने वास्तव में क्या किया, न कि जो आप अपने साइटमैप या क्रॉल टूल से अनुमान लगाते हैं। एक प्रोजेक्ट पर -- एक SaaS कंपनी जिसके पास लगभग 8,000 प्रोडक्ट डॉक्यूमेंटेशन पेज थे -- लॉग विश्लेषण ने पता चला कि Googlebot अपने क्रॉल समय का लगभग 30% /wp-admin/ से सटे URLs और एडमिन-साइड एसेट पर खर्च कर रहा था जिन्हें robots.txt में ब्लॉक किया जाना चाहिए था। किसी ने सही तरीके से वह सेटअप नहीं किया था। डॉक्यूमेंटेशन पेज जिन्हें चार महीने में क्रॉल नहीं किया गया था।actually did, not what you infer it did from your sitemap or crawl tool. On one project -- a SaaS company with about 8,000 product documentation pages -- log analysis revealed Googlebot was spending nearly 30% of its crawl time on/wp-admin/adjacent URLs and admin-side assets that should have been blocked in robots.txt. Nobody had set that up properly. Documentation pages that hadn't been crawled in four months.
Screaming Frog का Log File Analyser वह टूल है जो मैं इस्तेमाल करता हूँ। यह आकर्षक नहीं है लेकिन यह विश्वसनीय है। अपनी सर्वर लॉग को इंपोर्ट करें, Googlebot user agent के आधार पर फ़िल्टर करें, और URL हिट फ्रिक्वेंसी द्वारा सॉर्ट करें। जो पैटर्न उभरते हैं वह लगभग हमेशा प्रकाशमान होते हैं -- और लगभग हमेशा कुछ ऐसा शामिल करते हैं जो क्रॉल हो रहा है जो नहीं होना चाहिए। is the tool I use. It's not glamorous but it's reliable. Import your server logs, filter by Googlebot user agent, and sort by URL hit frequency. The patterns that emerge are almost always illuminating -- and almost always include something crawling that shouldn't be.
कब चिंता करें और कब छोड़ दें
हर बड़ी साइट को 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 दिखाता है
- आप हजारों URLs को "Discovered -- currently not indexed" या "Crawled -- currently not indexed" स्थिति में देखते हैं
वह दूसरी स्थिति -- "Crawled -- currently not indexed" -- अलग है और अलग से ध्यान देने लायक है। इसका मतलब है कि Google ने पेज को फेच किया और उसे इंडेक्स न करने का फैसला किया, आमतौर पर thin content या near-duplicate समस्याओं के कारण। crawl budget optimization से कोई भी गुणवत्ता की समस्या को ठीक नहीं करता।
---
सवाल-जवाब
क्या क्रॉल बजट छोटी साइटों को प्रभावित करता है?
शायद ही कभी किसी सार्थक तरीके से। अगर आपकी साइट के 1,000 से कम पेज हैं और जल्दी लोड होती है, तो Google लगभग निश्चित रूप से सब कुछ crawl करेगा चाहे कुछ भी हो। Crawl budget बड़े पैमाने पर एक वास्तविक चिंता बन जाता है -- आमतौर पर 10,000 से 15,000 पेजों से ऊपर, या उन साइटों पर जहां URLs का एक बड़ा हिस्सा dynamically generate होते हैं।
क्या सीधे साइटमैप सबमिट करने से क्रॉल बजट की समस्या ठीक हो जाएगी?
नहीं। Sitemap discovery में मदद करता है -- यह Google को बताता है कि ये URLs मौजूद हैं। लेकिन अगर आपकी साइट में structural issues हैं (faceted navigation spam, slow server response, shallow internal linking), तो sitemap उन signals को override नहीं करेगा। Sitemap को एक सुझाव के रूप में सोचें, आदेश के रूप में नहीं।
मैं कैसे चेक करूं कि 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 उस पेज पर कोई भी signals नहीं पढ़ सकता। Noindex Google को पेज को fetch करने देता है लेकिन उसे बताता है कि पेज को search results में शामिल न करें। Crawl budget के लिए विशेष रूप से, disallow truly junk URLs (admin paths, internal search results) पर अधिक प्रभावी है। Filtered facet pages के लिए जहां आप Google को content को समझना चाहते हैं लेकिन उसे index न करना चाहते हैं, noindex with a canonical आमतौर पर सही विकल्प है।Disallow in robots.txt prevents Googlebot from fetching the page at all -- saving crawl budget but meaning Google can't read any signals on that page.Noindex allows Google to fetch the page but tells it not to include the page in search results. For crawl budget specifically,disallow is more effective on truly junk URLs (admin paths, internal search results). For filtered facet pages where you want Google to understand the content but not index it,noindex with a canonical is usually the right call.
crawl budget की समस्याओं को ठीक करने के बाद सुधार देखने के लिए एक यथार्थवादी समयसीमा क्या है?
ईमानदारी से, यह आपके crawl rate पर निर्भर करता है। 91,000-पेज प्रोजेक्ट पर, indexed page counts में सार्थक हलचल major fixes deploy होने के बाद लगभग छह से आठ हफ्तों में हुई। रातों-रात परिवर्तन की उम्मीद न करें -- Googlebot को re-crawl, re-evaluate करने की जरूरत है, और indexing pipeline के अपने latency हैं इसके शीर्ष पर।
---
91,000-पेज प्रोजेक्ट अच्छी तरह से समाप्त हुआ। Indexed pages पांच महीनों में 34,000 से बढ़कर 71,000 से अधिक हो गए। परिपूर्ण नहीं -- कुछ genuinely thin product pages थे जो index में न होने के योग्य थे -- लेकिन जो content मायने रखता था वह मिल गया। क्लाइंट ने पूछना बंद कर दिया कि क्या कुछ टूटा हुआ है। और मैंने crawl reports के पेज 47,000 के आसपास career changes पर नजरें डालना बंद कर दीं। ज्यादातर।