Reading server logs to find out what crawlers actually do
Search Console tells you what Google concluded. Server logs tell you what it actually requested, when, and what your server returned. When indexing behaviour makes no sense from the reports alone, the logs almost always contain the answer.
Part ofTechnical SEO Engineering
Log analysis has a reputation for being specialist work requiring expensive tooling. It is neither. A few command-line utilities against a week of access logs answers questions no other data source can, and the questions it answers are usually the ones blocking a diagnosis.
What only logs can tell you
Verify the crawler before trusting the data
User-agent strings are trivially spoofed, and a meaningful share of traffic claiming to be Googlebot is not. Analysing unverified logs produces conclusions about scrapers rather than search engines.
Where is crawl budget actually going?
The first genuinely useful output is a ranked list of what crawlers spend their requests on. It is frequently surprising, and it is where crawl waste becomes visible rather than theoretical.
If parameterised URLs account for a large share of crawl on a site whose valuable content lives at clean URLs, you have found a concrete, quantified problem — and the robots.txt or faceting policy that fixes it.
Status codes the crawler received
Search Console reports errors in aggregate and with delay. Logs show exactly which URLs returned what, including intermittent failures that never accumulate enough to surface in a report.
Finding orphaned and never-crawled pages
Two opposite problems, both found by comparing your sitemap against the log: pages crawlers never visit, and pages crawlers visit that are not in your sitemap at all.
The first list tells you which content is not being discovered, usually because nothing links to it prominently. The second frequently reveals entire URL patterns nobody intended to expose.
Crawl frequency as a proxy for perceived value
How often a page is recrawled correlates with how important a search engine currently considers it. Comparing recrawl frequency between templates shows where perceived value sits.
A realistic cadence
Log analysis does not need to be continuous. It needs to happen at the moments when it answers a question.
- After a migration — daily for two weeks, watching for 404s and unmapped URLs receiving crawler traffic.
- When indexing behaviour contradicts the reports — logs resolve the contradiction.
- Quarterly on large sites — to catch crawl waste that has accumulated since the last review.
- After any incident involving 5xx errors — to confirm crawl rate recovered rather than staying suppressed.
Questions
How do I verify a request really came from Googlebot?
Run a reverse DNS lookup on the IP, confirm it resolves to googlebot.com or google.com, then run a forward lookup on that hostname and confirm it returns the original IP. Both directions must agree. Alternatively, match against Google's published crawler IP ranges, which is faster for large log volumes.
How much log data do I need for useful analysis?
A week is enough to see crawl distribution and error patterns on most sites. A month is better for crawl-frequency analysis, since infrequently crawled pages need a longer window to appear at all. For migration monitoring, daily analysis of the previous day matters more than depth.
Do I need a dedicated log analysis tool?
Not to start. awk, sort, uniq and comm answer most questions against raw access logs, and everything in this article is doable that way. Dedicated tools help when log volume is large enough that command-line processing becomes slow, or when you want ongoing dashboards rather than point-in-time answers.
What if my host does not give me access logs?
Check the CDN first — Cloudflare, Fastly and most edge providers expose request logs even when the origin platform does not. Failing that, Search Console's crawl stats report is a much coarser substitute: it gives aggregate request counts, response times and status distribution, but no per-URL detail.