क्रॉल बजट अनुकूलन के लिए लॉग फाइल विश्लेषण

2021 में मुझे एक क्लाइंट मिला, बर्मिंघम का एक ई-कॉमर्स रिटेलर जिसके पास करीब 52,000 इंडेक्स किए गए URLs थे, लेकिन वह नहीं समझ पा रहे थे कि उनके लगभग 18,000 प्रोडक्ट पेज तीन महीने से क्रॉल क्यों नहीं हो रहे थे। उनकी डेव टीम अनुमान लगा रही थी। XML सितemap जोड़ रहे थे। Google Search Console को पिंग कर रहे थे। कुछ भी काम नहीं आया। फिर मैंने उनके रॉ सर्वर लॉग निकाले और करीब चालीस मिनट में जवाब बिल्कुल स्पष्ट हो गया: Googlebot अपना दैनिक क्रॉल अलाउंस पेजिनेटेड फिल्टर URLs, सेशन पैरामीटर्स, और एक टूटे हुए इंटरनल सर्च फेसेट पर खर्च कर रहा था जो हर हफ्ते लगभग 4,000 यूनिक लेकिन बेकार URLs जेनरेट कर रहा था। पूरी बर्बादी। बिल्कुल निरर्थक।

मुख्य निष्कर्ष: सर्वर लॉग दिखाते हैं कि Googlebot वास्तव में 50,000-पृष्ठ वाली साइट पर कौन से पृष्ठ पढ़ता है; लॉग विश्लेषण crawl-budget निर्णयों के लिए एकमात्र निर्भरयोग्य स्रोत है।

लॉग फाइल एनालिसिस असल में इसी के लिए है, न कि व्यर्थ मेट्रिक्स के लिए, न ही बोर्डरूम स्लाइड्स के लिए, बल्कि यह पता लगाने के लिए कि किसी दिए गए मंगलवार को क्रॉलर आपकी साइट पर क्या कर रहा है और निर्दयता से अनावश्यक हिस्सों को काटने के लिए।

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

यहाँ वह बात है जो ज्यादातर लोग गलत समझते हैं। Crawl budget 200-पेज वाली ब्रोशर साइट के लिए चिंता का विषय नहीं है। Googlebot उसे मिनटों में साफ कर देगा। लेकिन जब आप 20,000 URLs के बाद जाते हैं, और निश्चित रूप से 50,000 या उससे ज्यादा होने पर, Google का क्रॉलर प्राथमिकता देने के बारे में स्पष्ट निर्णय लेता है। Google का अपना दस्तावेज़ इसे "crawl budget" कहता है और इसे दो घटकों में विभाजित करता है: crawl rate limit (Googlebot कितनी तेजी से क्रॉल करता है बिना आपके सर्वर पर दबाव डाले) और crawl demand (Google वास्तव में लोकप्रियता और ताजगी संकेतों के आधार पर कितना क्रॉल करना चाहता है)।

दोनों को 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 है।

Logs तक पहुँचना

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

WP Engine या Kinsta जैसे managed WordPress होस्ट पर, आप डैशबोर्ड से या SFTP के माध्यम से रॉ एक्सेस लॉग निकाल सकते हैं, /logs/ डायरेक्टरी में देखें। Nginx चलाने वाले VPS पर, आपका एक्सेस लॉग आमतौर पर /var/log/nginx/access.log पर होता है। Apache इसे /var/log/apache2/access.log पर रखता है। अगर आप Cloudflare जैसे CDN पर हैं, तो आपको Cloudflare Logpush (enterprise tier) की जरूरत होगी या आप सिर्फ CDN-edge रिक्वेस्ट देखेंगे, origin नहीं, महत्वपूर्ण अंतर।

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

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

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

Screaming Frog Log File Analyser, यह मैं 90% समय उपयोग करता हूँ। आप लॉग फाइलें सीधे इंपोर्ट करते हैं, Googlebot user agent के आधार पर फिल्टर करते हैं, और यह आपको क्रॉल किए गए URLs, क्रॉल फ्रीक्वेंसी, स्टेटस कोड्स, और रिस्पांस टाइम्स का एक सॉर्टेबल ब्रेकडाउन देता है। सच कहूँ, ज्यादातर एजेंसी काम के लिए यह सही टूल है। Screaming Frog का लॉग एनालाइज़र कई GB तक की फाइलें संभाल सकता है बिना क्रैश किए, जो मायने रखता है।
ELK Stack (Elasticsearch, Logstash, Kibana), ज्यादा सेटअप, काफी ज्यादा शक्ति। अगर आपको किसी बड़े क्लाइंट के लिए चल रहे मॉनिटरिंग की जरूरत है या कोई enterprise contract है, तो यह निवेश करने लायक है। Seahawk के पास कुछ क्लाइंट हैं जहाँ हम लॉग सीधे Kibana डैशबोर्ड में डालते हैं। रियल-टाइम, सुंदर, और आप अलर्ट सेट कर सकते हैं जब Googlebot क्रॉल फ्रीक्वेंसी अचानक गिर जाए।

एक बार की ऑडिट के लिए, Screaming Frog Log File Analyser ठीक है। चल रहे किसी भी काम के लिए, ELK stack बनाएँ या कम से कम GoAccess पर विचार करें, यह ओपन सोर्स है, टर्मिनल में चलता है, और बड़ी लॉग फाइलों को लगभग किसी भी चीज से तेजी से प्रोसेस करता है जिसे मैंने टेस्ट किया है।

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

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

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

अपने URLs को क्रॉल फ्रीक्वेंसी के आधार पर सॉर्ट करें, 30-दिन की विंडो में Googlebot ने प्रत्येक URL को कितनी बार हिट किया। आप लगभग हमेशा एक bimodal distribution देखेंगे। महत्वपूर्ण URLs का एक समूह जो बार-बार क्रॉल हो रहे हैं (अच्छा) और कचरा URLs की एक लंबी पूँछ जो भी बार-बार क्रॉल हो रहे हैं (बहुत बुरा)। वह कचरा पूँछ आपकी समस्या है।

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

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

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

404s जो बार-बार क्रॉल हो रहे हैं, ये crawl budget में खून का रिसाव हैं। उन्हें 301 redirects से ठीक करें या उन इंटरनल लिंक्स को पैच करें जो उन्हें पॉइंट करते हैं।
301 chains, एक रीडायरेक्ट जो A → B → C में जाता है, वह दो बेकार हॉप हैं। Googlebot इन्हें फॉलो करता है लेकिन इससे बजट खर्च होता है और हर jump पर PageRank leak होता है।
500 errors, अगर Googlebot ऐसे पेजों को हिट कर रहा है जो 500s रिटर्न करते हैं और फिर उन्हें दोबारा प्रयास कर रहा है, तो आप बजट बर्बाद कर रहे हैं AND समय के साथ Google के साथ अपनी crawlability score को नुकसान दे रहे हैं।
304 Not Modified, असल में ठीक है। इसका मतलब है कि Google freshness की जांच कर रहा है और आपके caching headers सही तरीके से काम कर रहे हैं।

Response Time Spikes

Google ने सार्वजनिक रूप से कहा है कि slow server response times Googlebot को कम आक्रामक तरीके से crawl करने के लिए प्रेरित करते हैं। अगर आपके logs में crawled URLs के लिए 500ms से ऊपर average response times दिख रहा है, खासकर category या product pages के लिए, तो यह एक संकेत है कि आप अपने server-side caching को किसी और चीज से पहले ठीक करें।

Budget Killers की पहचान

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

Faceted navigation without noindex या disallow, Filters, colour pickers, size selectors, sort orders। ये आपकी URL count को geometrically गुणा करते हैं। 10 filter options और 5 sort orders वाली एक product category 50+ duplicate URL variants generate करती है। 50K-page site के across, यह संभवतः सैकड़ों हजारों URLs हो सकता है।
Paginated archives infinitely crawled, /page/2,/page/3.../page/847। अगर आपके blog archive के page 200 पर content के पास zero organic search value है, तो आपको या तो इसे noindex करना होगा या robots.txt में pagination path को disallow करना होगा।
Session IDs in URLs, पुराने CMS platforms (और कुछ legacy WooCommerce setups) session tokens जैसे?sessionid=abc123def456 को URLs में append करते हैं। हर session एक unique URL generate करता है। Googlebot इन सभी को crawl करता है। यह पुरानी sites पर एक catastrophic budget leak है।
Duplicate content via URL parameters, ?utm_source=email in internal links, tracking parameters crawlable URLs में leak हो रहे हैं,?ref=homepage affiliate plugins द्वारा append किया जा रहा है। Google Search Console के URL parameter tool में fix करें और HTML level पर canonicalise करें।
Orphaned pages with no internal links लेकिन फिर भी sitemap में, Googlebot उन्हें sitemap के via खोजता है, उन्हें crawl करता है, कोई internal signal नहीं पाता है, समय के साथ उन्हें deprioritise करता है। लेकिन वे discovery crawls पर भी बजट खर्च करते हैं।
Soft 404 pages returning 200 status, Search pages with no results, empty category pages, deleted accounts के लिए user profile pages। Google इन्हें crawl करने में समय बर्बाद करता है और कभी-कभी उन्हें index करता है।

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

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

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

Robots.txt में URL पैटर्न के लिए disallow का उपयोग करें जिन्हें कभी क्रॉल नहीं किया जाना चाहिए — सेशन पैरामीटर, फ़िल्टर संयोजन, आंतरिक सर्च रिजल्ट URL। मैं Disallow: /*?sessionid=style वाइल्डकार्ड नियमों का उपयोग करता हूँ। डिप्लॉय करने से पहले Google Search Console के robots.txt टेस्टर में हर नियम का परीक्षण करें।
पेज 2 या 3 के बाद पैजिनेटेड पेजों पर noindex + nofollow लगाएँ, यह कंटेंट की ताज़गी पर निर्भर करता है। पैजिनेशन को पूरी तरह अनुमति न दें वरना आप Googlebot की लिंक्ड कंटेंट खोजने की क्षमता को तोड़ देंगे।
सभी पैरामीटराइज़्ड URL वेरिएंट्स पर canonical tags लगाएँ जो क्लीन canonical URL की ओर इशारा करते हों। यह robots.txt के साथ-साथ एक सुरक्षा परत है।
404s को स्रोत पर ठीक करें — या तो आंतरिक लिंक अपडेट करें या 301 रीडायरेक्ट लागू करें। मैं यह पता लगाने के लिए कि कौन से पृष्ठ मृत URLs को लिंक कर रहे हैं, Screaming Frog के मुख्य क्रॉलर को लॉग डेटा के साथ उपयोग करता हूँ।
XML sitemap स्वच्छता — अपने sitemap से कोई भी URL हटाएं जो non-200 response देता है, noindexed है, या एक रीडायरेक्ट है। आपका sitemap उन पृष्ठों की एक क्यूरेटेड सूची होनी चाहिए जिन्हें आप इंडेक्स किए जाने चाहते हैं, और कुछ नहीं।

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

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

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

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

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

FAQ

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

कुछ हद तक। आज पूर्ण इंडेक्सेशन इसका मतलब नहीं है कि यह वैसे ही रहेगा। यदि आप नियमित रूप से नई कंटेंट — नए प्रोडक्ट, नई ब्लॉग पोस्ट, नई लैंडिंग पेजें — पब्लिश कर रहे हैं, तो क्रॉल बजट यह निर्धारित करता है कि वह नई कंटेंट कितनी जल्दी खोजी जाती है। एक leaky क्रॉल बजट वाली साइट के नए पेज हफ्तों तक जाँच के बिना बैठ सकते हैं। यह एक तेजी से बदलने वाले niche में वास्तविक प्रतिस्पर्धात्मक नुकसान है।

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

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

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

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

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

अपने होस्टिंग प्रदाता पर दबाव डालें — अधिकांश managed होस्ट के पास यह उपलब्ध है भले ही यह डैशबोर्ड में प्रमुखता से सामने न आया हो। यदि आप वास्तव में raw लॉग नहीं प्राप्त कर सकते, तो Cloudflare का bot analytics Cloudflare प्रॉक्सी के पीछे की साइटों के लिए आंशिक तस्वीर दे सकता है, हालाँकि यह वास्तविक लॉग डेटा का कमजोर विकल्प है। यदि यह एक बड़े क्लाइंट अकाउंट पर बार-बार बाधा है तो होस्ट स्विच करने पर विचार करें।

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

एक छोटी साइट के लिए, तर्कसंगत रूप से हाँ। 20K पेजों से ऊपर कुछ भी, नहीं। GSC क्रॉल स्टेट्स दिन के आधार पर एकत्रित किए जाते हैं और URL-स्तरीय डेटा सामने नहीं लाते। आप देख सकते हैं कि Googlebot ने मंगलवार को 12,000 पेजों को क्रॉल किया लेकिन कौन से 12,000 पेज नहीं। लॉग फ़ाइलें आपको वह रेजोल्यूशन देती हैं। दोनों टूल एक साथ, यह पूरी तस्वीर है।

---

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

संबंधित पाठ: 2026 में AI सर्च कीवर्ड रिसर्च: यह क्या है, पारंपरिक क्यों है, AI सर्च, और बहुभाषी SEO।