Log File Analysis

How to read your server's raw access logs to see exactly what Googlebot, Bingbot, and AI crawlers actually fetched — verifying real bots, finding crawl waste and orphans, and why logs are the ground truth that crawl tools and Search Console only approximate.

First published: Jun 22, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #10 in Crawling#19 in How Search Works#114 in Technical SEO#151 on the site
1 evidence signal on this page

Log file analysis is reading your server's raw access logs — the unsampled, ground-truth record of every request the server got — to see exactly which URLs Googlebot, Bingbot, and AI crawlers actually fetched, how often, and with what status code. The non-negotiable first step is verifying the bots are real (reverse + forward DNS, or Google's published IP ranges), because user agents are spoofed all the time. Then you look for crawl waste, most/least-crawled URLs, status codes by frequency, orphan pages, and the mobile-vs-desktop split. Logs complement GSC Crawl Stats; they don't replace it. Most small sites don't need this — it's a large-site, ecommerce, and migration tool.

TL;DR — Logs are the unsampled ground truth for crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor.: every request, every botA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index., every status code. The non-negotiable first step is verifying GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer./BingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share. via reverse + forward DNS (or Google’s published IP-range JSON) — user agentsA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. are spoofed constantly, and you do all crawl math on the verified set only. Then read the logs for most/least-crawled URLs and sections, crawl frequencyCrawl frequency is how often a search engine comes back to re-fetch a page it already knows about. Popular pages that change often get refreshed many times a day; stable pages can go weeks or months between crawls — and you influence it indirectly, not by setting a dial. over time, status codes prioritized by frequency, crawl waste (params, facets, internal search, infinite paginationPagination splits a large set of content — product listings, blog archives, search results — across multiple sequentially numbered URLs. For SEO, each paginated page should be crawlable, indexable, and self-canonical; Google no longer uses rel=prev/next, but Bing still does.), orphan and uncrawled pages (cross-referenced against a crawl), and the mobile-vs-desktop GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. split. Bing publishes no official IP ranges, so DNS to *.search.msn.com is the method there. Logs complement GSC Crawl StatsA Google Search Console report (under Settings) that shows how Google has crawled your site over the last 90 days — total requests, download size, and average response time, broken down by response code, file type, Googlebot type, and purpose. It's only available for root-level properties (a Domain property or a URL-prefix property verified at the site's root). — they don’t replace it. And in 2026, AI bots are now a huge share of what shows up.

Evidence for this claim Web-server access logs record HTTP requests and commonly include request, response-status, user-agent, and timing fields depending on configuration. Scope: Apache HTTP Server access-log behavior; other servers vary by configuration. Confidence: high · Verified: Apache HTTP Server: Log Files Evidence for this claim User-agent text alone does not authenticate Googlebot; Google recommends DNS verification or matching published IP ranges. Scope: Google crawler verification, applicable when classifying log traffic. Confidence: high · Verified: Google Search Central: Verify Googlebot

Why logs are the ground truth

There are three ways to “see” how search engines crawl you, and they are not equal:

  • A crawl tool (Screaming Frog SEO Spider, Ahrefs Site Audit) simulates a crawl. It tells you what a bot could find, not what Google did fetch.
  • GSC Crawl Stats summarizes the real thing, but it’s sampled, aggregated, and capped (roughly 1,000 rows, ~90 days, no per-URL export).
  • Server logs record the real thing — every request, for every bot, with the exact URL, timestamp, and status code.

The Ahrefs log-file guide I reviewed puts it plainly: server logs are “the most trustworthy source of information to understand the URLs that search engines have crawled.” That’s the whole reason this technique exists. When I want to know what Googlebot actually did — not what it might do, not a rounded summary — I go to the logs.

A typical log line carries the IP address, user agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target., URL path, timestamp, request method (GET/POST), and HTTP status codeAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index.. Everything below is just slicing those fields intelligently.

When you actually need it (and when you don’t)

Be honest with yourself here. Log file analysisLog file analysis is reading a web server's raw access logs to see exactly which URLs search engine crawlers actually requested, when, how often, and what status code they got. Unlike crawl tools or Search Console, logs are the unsampled, ground-truth record of what really happened. is a large-site tool. It earns its keep on sites with tens of thousands of URLs, ecommerce and faceted navigationFaceted navigation (faceted search, product filtering) lets visitors refine a list of products or content by attribute — price, color, size, brand, rating. The SEO problem: each filter combination can spawn a distinct crawlable URL, turning a small catalog into millions of near-duplicate pages that waste crawl budget and dilute ranking signals., sites mid-migration, and sites stuck in Discovered – currently not indexed. As I wrote in my crawl budget guide, “Most sites don’t need to worry about crawl budget, but there are few cases where you may want to take a look.” Daniel Waisberg of Google has made a similar point about Crawl Stats — per Search Engine Journal’s coverage, the report isn’t much of a concern for sites under ~1,000 pages.

If your few-hundred-page site is being crawled fine, skip this and go fix something with more leverage.

How to get your logs (the hardest part is access)

Logs live wherever the request actually terminated:

  • Apache & Nginx → the Apache “combined” log format (the most common).
  • Microsoft IIS → W3C format.
  • AWS ELB/ALB → ELB format.
  • CDNs (Cloudflare, Fastly, Akamai) → their own log exports. This matters: at a CDN-fronted site, an origin-only log misses edge-cached hits, so pull logs at the layer the bot actually reached.

Aim for 30 days minimum, 90 ideal, to capture crawl-frequency variation. And plan for friction — getting access to server logs is often the genuinely hard part (DevOps gatekeeping). Even Googlers, in a migration episode of Search Off the Record, flagged how hard log files can be to obtain in practice. Budget time for the request.

Logs aren’t just bot traffic — they capture every request, including real visitors, and can carry query-string values, session identifiers, or other sensitive data alongside the URL path. OWASP’s logging guidance is blunt about this: authentication credentials, access tokens, and personally identifiable information generally shouldn’t land directly in a log; they should be removed, masked, or hashed first. Build that into your access controls and export process before you hand a log file to anyone for analysis, not after.

Step 1 — Verify the bots are real (do this before anything else)

This is the step most guides wave at in one line. Do not. Many bots pretend to be Googlebot to get past firewalls (Ahrefs). The user agent is unauthenticated text; treat every “Googlebot” line as a claim to be proven.

Googlebot — two valid methods:

  1. Reverse + forward DNS (the bidirectional check). Google’s own steps: run a reverse DNS lookup on the IP from your logs with the host command; verify the domain is googlebot.com, google.com, or googleusercontent.com; then run a forward DNS lookup on that hostname and verify it resolves back to the original IP. The forward step is what makes this trustworthy — a spoofer can point reverse DNS at a *.googlebot.com name, but only the round-trip back to the same IP proves it. (Commands for macOS/Linux and Windows are in the Scripts tab.)
  2. Match against Google’s published IP ranges. Google publishes JSON files of its crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. IPs in CIDR format — common-crawlers.json for Googlebot and friends, plus special-crawlers.json, the user-triggered-fetcher files, and an all-Google goog.json. As I noted in my Googlebot guide, Google “provided a list of public IPs you can use to verify the requests are from Google… You can compare this to the data in your server logs.”

BingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share. — DNS only. This is the key contrast: Bing does not officially publish IP ranges. Bing’s own wording is that “…like other search engines, Bing does not publish a list of IP addresses or ranges from which we crawl the Internet,” because “the IP addresses or ranges we use can change any time.” So for Bingbot you do reverse + forward DNS to a hostname ending in *.search.msn.com (e.g. msnbot-157-55-33-18.search.msn.com), or use the Verify Bingbot tool. (Microsoft has since released a bingbot IP JSON, but its official verification guidance still centers on DNS precisely because IPs change.)

Then throw out the fakes. Do all of your crawl math on the verified set only. Unverified “Googlebot” is almost always a scraper or a spoofed bot and belongs in a security review, not your crawl-waste analysis.

TIP Verify identities before calculating crawl totals

This result keeps identity, crawler purpose, and response waste as separate findings instead of one blended bot score.

Upload a representative access-log sample and inspect the exact requests behind each finding with my free Log File Analyzer Free

  1. Include IP, user-agent, path, status, and timestamp fields.
  2. Resolve crawler range mismatches before aggregating traffic under a famous bot name.
  3. Use the status and path tables for crawl decisions; logs do not prove indexing or citations.
Verify the actor first, then analyze what the verified requests fetched and received.

The sample reports 30 requests claiming a known crawler from an IP outside the operator's published ranges, a separate training-crawler traffic share, and a separate non-200 response finding. Each result has its own evidence and remedy.

Step 2 — What to look for

Once you’re working with verified hits, here’s the read:

  • Most & least crawled URLs and sections. Rank requests by URL and by directory. This is where your crawl budgetThe number of URLs an engine will crawl in a timeframe. is actually going — and it’s usually surprising.
  • Crawl frequencyCrawl frequency is how often a search engine comes back to re-fetch a page it already knows about. Popular pages that change often get refreshed many times a day; stable pages can go weeks or months between crawls — and you influence it indirectly, not by setting a dial. over time. Trend crawls by URL/section to catch drops (a migration broke something) or spikes (a new section, or a spider trapA spider trap (also called a crawler trap) is a site structure that generates an effectively infinite number of URLs — from faceted filters, calendars, session IDs, or redirect loops — so crawlers waste their budget on low-value, near-duplicate pages instead of your real content. spinning up infinite URLs).
  • Status codes bots hit, prioritized by frequency. Quantify 200 vs. 301/302 (and chains), 404, and 5xx. A 404 hit 5,000×/week is a different problem than a 404 hit once — fix by crawl frequency, not by mere existence.
  • Crawl waste. Faceted nav, URL parametersThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO., internal search results, and infinite calendars/paginationPagination splits a large set of content — product listings, blog archives, search results — across multiple sequentially numbered URLs. For SEO, each paginated page should be crawlable, indexable, and self-canonical; Google no longer uses rel=prev/next, but Bing still does. can eat a large share of crawl budget on bad offenders. Logs show exactly which junk patterns the bots are burning time on.
  • Orphan & uncrawled pages. This needs both datasets. Cross-reference logs against a site crawl: URLs in the logs but not in the crawl = orphans, old redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., or externally-linked pages; URLs in the crawl but not in the logs = pages Google has never fetched.
  • Mobile vs. desktop Googlebot. Split by user agent. Post mobile-first, it should be majority Googlebot Smartphone — a desktop-heavy split is worth a look.
  • Response time & crawl health. Rising average response time correlates with reduced crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor.. Per SEJ’s write-up of Waisberg’s guidance: “Watch out for a consistent increase in average response time. Google says it might not affect crawl rateCrawl rate is how fast a search engine crawler fetches pages from your site — the number of simultaneous requests it makes and the delay between them. Google sets it automatically based on your server's health; it's the supply side of crawl budget, not a ranking factor. immediately, but it’s a good indicator that your servers might not be handling all the load.”

What logs do NOT tell you

Keep these straight or you’ll over-read the data:

  • Crawl ≠ index. A URL Googlebot fetches daily can stay unindexed indefinitely. Logs prove fetching, not index status — pair them with GSC’s Page IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. / URL Inspection to learn the index side.
  • Crawl ≠ rank, and more crawling doesn’t help. As I’ve said repeatedly, “The rate of crawling isn’t going to impact your rankings.” Don’t chase crawl volume as if it were a ranking lever.
  • noindex doesn’t reduce crawling. noindex controls indexation, not crawling — to actually stop the crawl you use robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. or a status code.
  • Crawl ≠ model training or citation. A verified hit from GPTBot, ClaudeBot, or PerplexityBot proves that request happened — a fetch at that layer. It doesn’t prove the page was used to train a model, retained anywhere downstream, or cited in a chat answer. Those are separate, unobserved outcomes; don’t stretch a verified log line further than it goes.

The 2026 wrinkle: AI bots are all over your logs now

The cast of characters in a modern log file has changed. In my analysis of Cloudflare Radar data (Meet the New Web Crawlers), search-engine bots still crawl the most — but AI bots are firmly in second place and on track to overtake them within a couple of years. GPTBot, ClaudeBot, PerplexityBot, and friends now show up heavily. When you segment your verified hits by user agent, don’t be surprised to find AI crawlersAI crawlers are bots from AI companies that fetch web pages to train language models, build AI-search indexes, or answer live user questions. They come in three categories, each with its own user-agent tokens and its own robots.txt controls. rivaling the search engines for share of requests. (Screaming Frog’s Log File Analyser has added a dedicated AI-bot tutorial for exactly this.)

How this fits with the rest of crawling

Logs are the diagnostic layer under the whole crawling cluster. They’re how you actually measure the crawl budget spend that engines describe in the abstract (Gary Illyes defines it as “the number of URLs Googlebot can and is willing or is instructed to crawl”). They’re also how you catch spider traps red-handed — an infinite URL space from a calendar or facet shows up as a flood of near-identical requests — and how you confirm whether your crawl frequency work (accurate lastmod, internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them. to important pages) actually changed bot behavior. And remember they complement, not replace, GSC Crawl Stats: Crawl Stats is the sampled on-ramp; logs are the unsampled, multi-bot, per-URL detail.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.