50,000 पेज वाली साइटों पर क्रॉल बजट के लिए लॉग फाइल विश्लेषण

2021 में वापस जाएं, मैंने एक क्लाइंट को संभाला -- Birmingham में एक e-commerce खुदरा विक्रेता जिसके पास लगभग 52,000 indexed URLs थे -- जो यह समझ नहीं पा रहे थे कि उनके लगभग 18,000 प्रोडक्ट पेजों को तीन महीने से ज्यादा समय में क्रॉल नहीं किया गया था। उनकी dev टीम अनुमान लगा रही थी। XML sitemaps जोड़ रहे थे। Google Search Console को ping कर रहे थे। कुछ भी काम नहीं किया। फिर मैंने उनके raw server logs को खींचा और लगभग चालीस मिनट में जवाब बिल्कुल स्पष्ट था: Googlebot अपने दैनिक crawl allowance को paginated filter URLs, session parameters, और एक broken internal search facet पर बर्बाद कर रहा था जो हर सप्ताह 4,000 जैसे unique लेकिन बेकार URLs जेनरेट कर रहा था। पूरी बर्बादी। बिल्कुल बकवास।

मुख्य निष्कर्ष: सर्वर लॉग दिखाते हैं कि Googlebot वास्तव में 50,000-पृष्ठ वाली साइट पर कौन से पृष्ठ पढ़ता है; लॉग विश्लेषण crawl-budget निर्णयों के लिए एकमात्र निर्भरयोग्य स्रोत है।Server logs show exactly which pages Googlebot actually reads on a 50,000-page site; log analysis is the only ground truth for crawl-budget decisions.

यही है जो log file analysis वास्तव में करने के लिए है -- vanity metrics के लिए नहीं, boardroom slides के लिए नहीं, बल्कि यह जानने के लिए कि crawler आपकी साइट पर किसी भी दिन क्या कर रहा है और निर्दयी से अनावश्यक चीजों को काट देना है।

क्यों क्रॉल बजट बड़े स्तर पर वास्तव में मायने रखता है

बात यह है जो ज्यादातर लोग गलत समझते हैं। Crawl budget एक 200-पेज की brochure साइट के लिए चिंता का विषय नहीं है। Googlebot इसे मिनटों में निपटा देगा। लेकिन जब आप 20,000 URLs से आगे जाते हैं -- और निश्चित रूप से जब आप 50,000 या उससे अधिक पर हैं -- Google का crawler यह स्पष्ट निर्णय लेता है कि किसे प्राथमिकता दी जाए। Google के अपने डॉक्यूमेंटेशन को इसे "crawl budget" कहते हैं और इसे दो घटकों में विभाजित करते हैं: crawl rate limit (Googlebot कितनी तेजी से crawl करता है बिना आपके सर्वर को overload किए) और crawl demand (Google वास्तव में कितना crawl करना चाहता है यह इस पर आधारित है कि popularity और freshness signals)।Google's own documentation calls this "crawl budget" and breaks it down into two components: crawl rate limit (how fast Googlebot crawls without hammering your server) and crawl demand (how much Google actually wants to crawl based on popularity and freshness signals).

दोनों को manipulate किया जा सकता है। लेकिन आप जो measure नहीं कर सकते उसे manipulate नहीं कर सकते। और बिना लॉग्स के आप इसे सही तरीके से measure नहीं कर सकते।

Google Search Console जैसे Analytics tools आपको एक crawl stats रिपोर्ट देते हैं। शुरुआत के लिए यह ठीक है। लेकिन यह aggregated है, delayed है, और यह आपको नहीं बताता कि कौन से specific URLs budget को खा रहे हैं। Server logs बताते हैं। वे आपको हर single request दिखाते हैं जो Googlebot ने की, किस URL को, किस समय पर, और कौन सा HTTP status code वापस मिला। यह raw material है।which specific URLs are eating the budget. Server logs do. They show you every single request Googlebot made, to which URL, at what time, and what HTTP status code it received back. That's the raw material.

Logs तक पहुँचना

यह obvious लगता है लेकिन यहीं ज्यादातर लोग अटक जाते हैं। आपके hosting setup के आधार पर, logs अलग-अलग जगहों पर होते हैं।

WP Engine या Kinsta जैसे managed WordPress host पर, आप dashboard से या SFTP के माध्यम से raw access logs खींच सकते हैं -- /logs/ डायरेक्टरी में देखें। Nginx चलाने वाले VPS पर, आपका access log आमतौर पर /var/log/nginx/access.log पर होता है। Apache इसे /var/log/apache2/access.log पर डालता है। यदि आप Cloudflare जैसे CDN पर हैं, तो आपको Cloudflare Logpush (enterprise tier) की आवश्यकता होगी या आप केवल CDN-edge requests देख सकेंगे, origin नहीं -- महत्वपूर्ण अंतर।WordPress host like WP Engine or Kinsta, you can pull raw access logs from the dashboard or via SFTP -- look in the/logs/directory. On a VPS running Nginx, your access log is typically at/var/log/nginx/access.log. Apache puts it at/var/log/apache2/access.log. If you're on a CDN like Cloudflare, you'll need Cloudflare Logpush (enterprise tier) or you'll only see CDN-edge requests, not origin -- important distinction.

उस Birmingham client के लिए, वे Kinsta managed server पर थे। मैंने 30 दिनों के logs pull किए, जो लगभग 4.2GB compressed .gz files में आए। यह एक busy 50K-page साइट के लिए normal size है।.gz files. That's a normal size for a busy 50K-page site.

Raw Logs को Parse करना बिना अपना दिमाग खोए

यहाँ आपके दो real options हैं:

1. Screaming Frog Log File Analyser -- यह वह है जो मैं 90% समय उपयोग करता हूं। आप log files को सीधे import करते हैं, Googlebot user agent द्वारा filter करते हैं, और यह आपको crawled URLs, crawl frequency, status codes, और response times का एक sortable breakdown देता है। ईमानदारी से, ज्यादातर agency काम के लिए यह सही tool है। Screaming Frog का log analyser कई GB तक के files को बिना crash किए handle करता है, जो मायने रखता है। -- This is what I use 90% of the time. You import the log files directly, filter by Googlebot user agent, and it gives you a sortable breakdown of crawled URLs, crawl frequency, status codes, and response times. Honestly, for most agency work it's the right tool.Screaming Frog's log analyser handles files up to several GB without falling over, which matters.
2. ELK Stack (Elasticsearch, Logstash, Kibana) -- अधिक सेटअप, significantly अधिक शक्ति। यदि आपके पास किसी बड़े क्लाइंट के लिए या enterprise contract के लिए चल रही monitoring needs हैं, तो यह निवेश के लायक है। Seahawk के पास कुछ क्लाइंट हैं जहाँ हम logs को सीधे एक Kibana dashboard में pipe करते हैं। Real-time, सुंदर, और आप alerts सेट कर सकते हैं जब Googlebot crawl frequency अचानक गिरता है। -- More setup, significantly more power. If you've got ongoing monitoring needs for a large client or an enterprise contract, this is worth the investment. Seahawk has a couple of clients where we pipe logs directly into a Kibana dashboard. Real-time, beautiful, and you can set alerts when Googlebot crawl frequency drops suddenly.

एक one-off audit के लिए, Screaming Frog Log File Analyser ठीक है। कुछ भी चल रहे के लिए, ELK stack बनाएं या कम से कम GoAccess पर विचार करें -- यह open source है, terminal में चलता है, और large log files को लगभग किसी और चीज से ज्यादा तेजी से process करता है जो मैंने test किया है।GoAccess -- it's open source, runs in the terminal, and processes large log files faster than almost anything else I've tested.

असल में क्या देखना चाहिए

एक बार डेटा लोड हो जाने के बाद, ज्यादातर लोग उसे घूरते रहते हैं और नहीं पता चलता कि किस बारे में सवाल पूछें। यहाँ मैं लॉग ऑडिट में असल में क्या देखता हूँ:

क्रॉल फ्रीक्वेंसी डिस्ट्रीब्यूशन

अपने URLs को crawl frequency द्वारा sort करें -- 30-दिन की window में Googlebot ने प्रत्येक URL को कितनी बार हिट किया। आप लगभग हमेशा एक bimodal distribution पाएंगे। महत्वपूर्ण URLs का एक cluster बार-बार crawl किया जा रहा है (अच्छा) और junk URLs की एक लंबी tail भी बार-बार crawl की जा रही है (बहुत बुरा)। यह junk tail आपकी समस्या है।

उस Birmingham साइट पर, top 500 crawled URLs में 340 filter/facet combinations शामिल थे। उनमें से कोई भी indexed नहीं था। उनमें कोई search volume नहीं था। Googlebot actual category pages की तुलना में ?colour=red&size=M&sort=price_asc को अधिक बार visit कर रहा था। शानदार।?colour=red&size=M&sort=price_asc more often than it was visiting the actual category pages. Wild.

स्टेटस कोड ब्रेकडाउन

उस सब कुछ के लिए फ़िल्टर करें जो 200 नहीं है। खास तौर पर:

• 404s बार-बार crawl की जा रहीं -- ये एक crawl budget haemorrhage हैं। उन्हें 301 redirects से ठीक करें या internal links को patch करें जो उन पर pointing हैं। -- These are a crawl budget haemorrhage. Fix them with 301 redirects or patch the internal links that point to them.
• 301 chains -- एक रिडायरेक्ट जो A → B → C जाता है, वह दो व्यर्थ हॉप्स हैं। Googlebot उन्हें फॉलो करता है लेकिन इससे बजट की कीमत होती है और हर जंप पर PageRank लीक होता है। -- A redirect that goes A → B → C is two wasted hops. Googlebot follows them but it costs budget and PageRank leaks at each jump.
• 500 errors -- अगर Googlebot ऐसे पेजों को हिट कर रहा है जो 500s रिटर्न करते हैं और फिर उन्हें दोबारा ट्राई करते हैं, तो आप बजट बर्बाद कर रहे हैं और समय के साथ Google के साथ अपनी crawlability score को नुकसान पहुंचा रहे हैं। -- If Googlebot is hitting pages that return 500s and then retrying them, you're wasting budget AND damaging your crawlability score with Google over time.
• 304 Not Modified -- असल में ठीक है। इसका मतलब है कि Google ताजगी की जांच कर रहा है और आपके कैशिंग हेडर सही तरीके से काम कर रहे हैं। -- Actually fine. Means Google is checking freshness and your caching headers are working correctly.

Response Time Spikes

Google ने सार्वजनिक रूप से कहा है कि धीमे सर्वर रेस्पांस टाइम Googlebot को कम आक्रामक तरीके से क्रॉल करने का कारण बनते हैं। अगर आपके लॉग में क्रॉल किए गए URLs के लिए 500ms से अधिक का औसत रेस्पांस टाइम दिखता है -- खासकर कैटेगरी या प्रोडक्ट पेजों के लिए -- तो यह एक सिग्नल है कि आपको किसी और चीज से पहले अपनी सर्वर-साइड कैशिंग को ठीक करना चाहिए। that slow server response times cause Googlebot to crawl less aggressively. If your logs show average response times above 500ms for crawled URLs -- particularly category or product pages -- that's a signal to fix your server-side caching before anything else.

Budget Killers की पहचान

मैं आपको बड़ी साइट्स पर crawl budget खाने वाली चीज़ों की एक लिस्ट दे रहा हूँ, जो मुझे कितनी बार मिलती हैं इसके क्रम में:

1. Faceted navigation बिना noindex या disallow के -- फिल्टर, कलर पिकर, साइज सिलेक्टर, सॉर्ट ऑर्डर। ये आपके URL काउंट को ज्यामितीय रूप से गुणा करते हैं। 10 फिल्टर ऑप्शन और 5 सॉर्ट ऑर्डर वाली एक प्रोडक्ट कैटेगरी 50+ डुप्लिकेट URL वेरिएंट्स जनरेट करती है। 50K-पेज साइट के आर-पार, यह संभावित रूप से सैकड़ों हजारों URLs हैं। -- Filters, colour pickers, size selectors, sort orders. These multiply your URL count geometrically. A product category with 10 filter options and 5 sort orders generates 50+ duplicate URL variants. Across a 50K-page site, that's potentially hundreds of thousands of URLs.
2. Paginated archives को अनंत तक क्रॉल किया जाना -- /page/2, /page/3.../page/847। अगर आपके ब्लॉग आर्काइव के पेज 200 की कंटेंट के पास जीरो ऑर्गेनिक सर्च वैल्यू है, तो आपको या तो इसे noindex करना चाहिए या पेजिनेशन पाथ को robots.txt में disallow करना चाहिए। -- /page/2,/page/3.../page/847. If the content on page 200 of your blog archive has zero organic search value, you need to either noindex it or disallow the pagination path in robots.txt.
3. URLs में Session IDs -- पुराने CMS प्लेटफॉर्म्स (और कुछ लीगेसी WooCommerce सेटअप्स) ?sessionid=abc123def456 जैसे सेशन टोकन को URLs में जोड़ते हैं। हर सेशन एक यूनिक URL जनरेट करता है। Googlebot उन सभी को क्रॉल करता है। यह पुरानी साइट्स पर एक विनाशकारी बजट लीक है। -- Old CMS platforms (and some legacy WooCommerce setups) append session tokens like?sessionid=abc123def456 to URLs. Every session generates a unique URL. Googlebot crawls all of them. This is a catastrophic budget leak on older sites.
4. URL parameters के माध्यम से डुप्लिकेट कंटेंट -- इंटरनल लिंक्स में ?utm_source=email, ट्रैकिंग पैरामीटर जो क्रॉलेबल URLs में लीक हो रहे हैं, affiliate plugins द्वारा जोड़े गए ?ref=homepage। Google Search Console के URL parameter tool में ठीक करें और HTML लेवल पर canonicalise करें। -- ?utm_source=email in internal links, tracking parameters leaking into crawlable URLs,?ref=homepage appended by affiliate plugins. Fix in Google Search Console's URL parameter tool and canonicalise at the HTML level.
5. Orphaned pages जिनके पास कोई इंटरनल लिंक नहीं है लेकिन फिर भी sitemap में हैं -- Googlebot उन्हें sitemap के माध्यम से खोजता है, उन्हें क्रॉल करता है, कोई इंटरनल सिग्नल नहीं पाता, समय के साथ उन्हें deprioritise करता है। लेकिन वे अभी भी डिस्कवरी क्रॉल्स पर बजट खाते हैं। -- Googlebot finds them via sitemap, crawls them, finds no internal signal, deprioritises them over time. But they still eat budget on discovery crawls.
6. Soft 404 pages जो 200 status रिटर्न करते हैं -- सर्च रिजल्ट के बिना सर्च पेजेस, खाली कैटेगरी पेजेस, डिलीटेड अकाउंट्स के लिए यूजर प्रोफाइल पेजेस। Google इन्हें क्रॉल करने में समय बर्बाद करता है और कभी-कभी उन्हें इंडेक्स भी करता है। -- Search pages with no results, empty category pages, user profile pages for deleted accounts. Google wastes time crawling these and sometimes indexes them.

जो आप पाएं उसे ठीक करना

ईमानदारी से कहूँ तो, विश्लेषण आसान हिस्सा है। कार्यान्वयन वह जगह है जहाँ प्रोजेक्ट राजनीतिक हो जाता है।

यहाँ मेरा असली वर्कफ़्लो है जब मैंने लॉग ऑडिट पूरा कर लिया है और सिफारिशें प्रस्तुत करनी हैं:

• Robots.txt में उन URL पैटर्न के लिए disallow सेट करें जिन्हें कभी क्रॉल नहीं किया जाना चाहिए -- सेशन पैरामीटर, फ़िल्टर संयोजन, आंतरिक सर्च रिजल्ट URL। मैं Disallow: /*?sessionid=style वाइल्डकार्ड नियम इस्तेमाल करता हूँ। डिप्लॉय करने से पहले Google Search Console के robots.txt टेस्टर में हर नियम की जांच करें। for URL patterns that should never be crawled -- session parameters, filter combinations, internal search result URLs. I use Disallow: /*?sessionid=style wildcard rules. Test every rule in Google Search Console's robots.txt tester before deploying.
• पेज 2 या 3 के बाद पैजिनेटेड पेजों पर noindex + nofollow लगाएँ, यह कंटेंट की ताज़गी पर निर्भर करता है। पैजिनेशन को पूरी तरह अनुमति न दें वरना आप Googlebot की लिंक्ड कंटेंट खोजने की क्षमता को तोड़ देंगे। on paginated pages beyond page 2 or 3, depending on content freshness. Don't disallow pagination entirely or you break Googlebot's ability to discover linked content.
• सभी पैरामीटराइज़्ड URL वेरिएंट्स पर canonical tags लगाएँ जो क्लीन canonical URL की ओर इशारा करते हों। यह robots.txt के साथ-साथ एक सुरक्षा परत है। on all parameterised URL variants pointing to the clean canonical URL. This is belt-and-braces alongside robots.txt.
• 404 एरर को स्रोत पर ठीक करें -- या तो आंतरिक लिंक को अपडेट करें या 301 रीडायरेक्ट लागू करें। मैं Screaming Frog के मुख्य क्रॉलर को लॉग डेटा के साथ इस्तेमाल करता हूँ ताकि यह पता लगा सकूँ कि कौन से पेज डेड URL पर लिंक कर रहे हैं। -- Either update the internal links or implement 301 redirects. I use Screaming Frog's main crawler alongside the log data to find which pages are linking to dead URLs.
• XML साइटमैप की सफाई -- अपने साइटमैप से कोई भी URL हटाएँ जो गैर-200 रिस्पांस देता है, noindexed है, या रीडायरेक्ट है। आपका साइटमैप उन पेजों की एक क्यूरेटेड सूची होनी चाहिए जिन्हें आप इंडेक्स कराना चाहते हैं, और कुछ नहीं। -- Remove any URL from your sitemap that returns a non-200, is noindexed, or is a redirect. Your sitemap should be a curated list of pages you want indexed, nothing else.

Seahawk के पास पिछले साल एक फिनटेक क्लाइंट था -- लगभग 65,000 पेज, ज़्यादातर डायनामिक कॉन्टेंट -- जहाँ सिर्फ robots.txt को ठीक करके आंतरिक सर्च URL पैटर्न को ब्लॉक करने से Googlebot की जंक URL क्रॉलिंग छह हफ्तों में 61% कम हो गई। बाकी 39% क्रॉल बजट प्रोडक्ट और कैटेगरी पेजों की ओर शिफ्ट हो गया। नए कॉन्टेंट का इंडेक्सेशन औसतन 23 दिन से घटकर 6 दिन हो गया। यह असली दुनिया का प्रभाव है।

चल रही निगरानी सेट अप करना

एक लॉग ऑडिट एक स्नैपशॉट है। अच्छी क्रॉल बजट प्रबंधन चल रही है। यह व्यावहारिक रूप से वास्तव में कैसा दिखता है?

न्यूनतम रूप से, मैं 30,000 से अधिक पेज वाली किसी भी साइट के लिए महीने में एक बार लॉग निकालने और पार्स करने की सलाह दूँगा। अपने शीर्ष 100 राजस्व-चालित URL के लिए क्रॉल फ्रीक्वेंसी ट्रेंड देखें। अगर उन पेजों के लिए Googlebot की विजिट फ्रीक्वेंसी घट रही है, तो कुछ बदल गया है -- नए क्रॉल बजट लीक, सर्वर परफॉर्मेंस समस्याएँ, या PageRank सिग्नल में गिरावट।

यदि आप अधिक परिष्कृत तरीका चाहते हैं, तो GoAccess को क्रॉन जॉब के रूप में सेट अप करें ताकि दैनिक लॉग स्नैपशॉट प्रोसेस हो सकें और एक सारांश रिपोर्ट ईमेल की जा सके। कॉन्फ़िगरेशन में लगभग दो घंटे लगते हैं और यह आपको त्रैमासिक ऑडिट के बीच धीमी-गति वाली क्रॉल बजट क्षरण को मिस करने से बचाता है।

FAQ

क्या क्रॉल बजट महत्वपूर्ण है यदि मैं पहले से ही पूरी तरह इंडेक्स किया हुआ हूँ?

किसी हद तक। आज पूरा इंडेक्सेशन इसका मतलब यह नहीं है कि यह वैसे ही रहेगा। अगर आप नियमित रूप से नया कॉन्टेंट पब्लिश कर रहे हैं -- नए प्रोडक्ट, नई ब्लॉग पोस्ट, नई लैंडिंग पेज -- क्रॉल बजट यह निर्धारित करता है कि वह नया कॉन्टेंट कितनी जल्दी मिलता है। क्रॉल बजट में लीक वाली साइट के नए पेज हफ्तों तक बिना जाँच के पड़े रह सकते हैं। अगर आप तेज़-गति वाली निश एक्सेल में हैं तो यह असली प्रतिस्पर्धात्मक नुकसान है।

क्या मुझे robots.txt का उपयोग करके कुछ सबफोल्डर से Googlebot को पूरी तरह ब्लॉक करना चाहिए?

हाँ, विशिष्ट मामलों में। एडमिन एरिया, स्टेजिंग पाथ, आंतरिक सर्च रिजल्ट, और पैरामीटर-भरी फ़िल्टर URL सभी Disallow नियमों के लिए उचित उम्मीदवार हैं। एक चीज़ जिससे मैं सावधान रहूँ वह है JavaScript या CSS फ़ाइलों को ब्लॉक करना -- Googlebot को अपने पेजों को सही तरीके से रेंडर करने के लिए उन्हें चाहिए। बहुत सारी पुरानी SEO सलाह कहती है कि JS को ब्लॉक करें; इसे नज़रअंदाज़ करें।

मुझे कितने लॉग डेटा का विश्लेषण करना चाहिए?

30 दिन अधिकांश साइट्स के लिए सही समय है। इससे कम और आपको low-frequency crawl patterns नहीं दिखेंगे। इससे अधिक और फ़ाइल साइज़ बेकाबू हो जाते हैं जब तक कि आप एक सही ELK stack न चला रहे हों। मौसमी ई-कॉमर्स साइट्स के लिए, मैं कभी-कभी ट्रैफिक लोड के तहत crawl behaviour समझने के लिए peak period को span करते हुए 60 दिन देखता हूँ।

क्या होगा अगर मेरा होस्ट raw access logs प्रदान नहीं करता?

अपने होस्टिंग प्रोवाइडर को दबाव डालें -- अधिकांश मैनेज्ड होस्ट के पास यह उपलब्ध है भले ही डैशबोर्ड में यह साफ तरीके से सामने न आया हो। अगर आप वाकई रॉ लॉग नहीं प्राप्त कर सकते, तो Cloudflare का bot analytics साइट्स के लिए Cloudflare प्रॉक्सी के पीछे एक आंशिक चित्र दे सकता है, हालाँकि यह असली लॉग डेटा के लिए एक कमजोर विकल्प है। अगर यह किसी बड़े क्लाइंट अकाउंट पर बार-बार अवरोधक है तो होस्ट बदलने पर विचार करें।Cloudflare's bot analytics can give you a partial picture for sites behind the Cloudflare proxy, though it's a pale substitute for real log data. Consider switching hosts if this is a recurring blocker on a large client account.

क्या Google Search Console's crawl stats काफी है?

एक छोटी साइट के लिए, कुछ हद तक हाँ। 20K से अधिक पेज के लिए, नहीं। GSC क्रॉल स्टैट दिन दर दिन एकीकृत होते हैं और URL-स्तरीय डेटा सामने नहीं आता। आप देख सकते हैं कि Googlebot ने मंगलवार को 12,000 पेज क्रॉल किए लेकिन कौन से 12,000 पेज नहीं। लॉग फ़ाइलें आपको वह रेजॉल्यूशन देती हैं। दोनों टूल्स एक साथ -- वह पूरी तस्वीर है।which 12,000 pages. Log files give you that resolution. Both tools together -- that's the complete picture.

---

देखो, अधिकांश SEOs log file analysis को छोड़ देते हैं क्योंकि यह DevOps territory जैसा लगता है। यह glamorous नहीं है। आप timestamps और user-agent strings के gigabytes के माध्यम से grep कर रहे हैं। लेकिन बड़ी साइट्स पर, यह अंतर है कि आप अपने crawl budget कहाँ जा रहा है इसका अनुमान लगा रहे हैं और वास्तव में जान रहे हैं। और मेरे अनुभव में, जानना हमेशा उन दो घंटों के लायक है जो डेटा pull करने में लगते हैं।