Crawling

How search engines discover and download the web — Googlebot and Bingbot, URL discovery, the crawl scheduler, rendering, and how crawling differs from indexing and ranking. The hub for everything crawl-related.

First published: Jun 22, 2026 · Last updated: Jul 17, 2026 · Advanced
demand #2 in How Search Works#17 in Technical SEO#23 on the site
1 evidence signal on this page

Crawling is stage one of search (crawl → index → serve): bots like Googlebot and Bingbot discover URLs and download pages so they can be rendered, indexed, and ranked. It's necessary to appear in search but it isn't a ranking factor — and it's distinct from both indexing and rendering. Most sites never need to manage crawl budget; when crawling does break, server logs are the ground truth. This hub explains the whole pipeline and points you to the deep dives.

TL;DR — Crawling is the first of search’s three stages (crawl → index → serve). Bots discover URLs by pull (links + sitemaps) and push (IndexNow, Indexing API), then fetch them on an algorithmic schedule that throttles to your server’s health. Rendering JavaScript is a separate step. Crawling is required to rank but is not itself a ranking signal, and it’s distinct from indexing — a robots-blocked page can still be indexed. Most sites don’t need to manage crawl budget; logs are how you see what actually happened.

Crawling is stage one of three

Crawling is stage one of three. A page must clear each stage before it can rank. Source: /technical-seo/how-search-works/crawling/

Three stages run left to right. Crawl: a bot discovers a URL and downloads the page. Index: the engine processes the page and stores eligible information. Serve or rank: the best indexed matches are ordered for a query. The Crawl stage is highlighted, and a note says not every page advances through every stage.

© Patrick Stox LLC · CC BY 4.0 ·

Google is blunt about the pipeline: “Google Search works in three stages, and not all pages make it through each stage” — crawling, indexing, and serving. Evidence for this claim Google describes Search as three stages: crawling, indexing, and serving results. Scope: Google Search's documented processing model; it does not guarantee that a page reaches every stage. Confidence: high · Verified: Google Search Central: In-depth guide to how Google Search works The “not all pages make it” part is the whole game in technical SEO. A page can be crawled but not indexed, or indexed but never served for a query. Keeping the stages separate in your head is the single most useful mental model here.

Who actually does the crawling

“Googlebot” sounds like one program. It isn’t. In my How Search Works deck I describe it as 1,000+ systems running a family of specialized crawlers — desktop, mobile, image, news, video, ads — with the requests mostly originating out of Mountain View. They all draw from the same crawl budget pool, which is why a runaway image or parameter crawl can starve the crawling of your actual content.

And it’s not just search engines anymore. 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 in the next couple of years. If you’re reading your logs, the cast of characters has changed.

How crawlers discover URLs

Discovery is both pull and push — Google calls the whole thing “URL discovery.” Source: /technical-seo/how-search-works/crawling/

Two discovery routes feed one crawl queue. Pull discovery includes following links and sitemaps. Push discovery includes IndexNow for Bing, Yandex, and other participating engines but not Google for general pages; the Google Indexing API for JobPosting and BroadcastEvent pages; and change notifications through sitemap lastmod, RSS, and WebSub.

© Patrick Stox LLC · CC BY 4.0 ·

Discovery is both pull and push:

  • Pull — links. Google: “Other pages are discovered when Google extracts a link from a known page to a new page.” This is why orphan pages (nothing links to them) struggle to get found.
  • Pull — sitemaps. “Still other pages are discovered when you submit a list of pages (a sitemap) for Google to crawl.”
  • Push — change notifications. Instead of waiting to be re-crawled, you tell the engine something changed: IndexNow (Bing, Yandex, and others — Google does not use it for general pages) and Google’s Indexing API (officially only for JobPosting and BroadcastEvent pages). Sitemaps’ lastmod, RSS, and WebSub round out the push options.

Google calls the whole thing “URL discovery.”

How crawlers fetch pages

  • The schedule is algorithmic. “Googlebot uses an algorithmic process to determine which sites to crawl, how often, and how many pages to fetch from each site.” You influence it; you don’t set it.
  • Crawling is polite. Bots throttle themselves so they don’t knock your site over: “they try not to crawl the site too fast to avoid overloading it… HTTP 500 errors mean ‘slow down.’” This is the lever behind temporarily slowing a crawl — return 503/429 and Googlebot eases off (for a day or two, not forever).
  • There’s a byte limit. As of Google’s March 2026 Inside Googlebot update, Googlebot fetches up to roughly 2 MB per URL (down from the old 15 MB figure), with PDFs allowed up to 64 MB. Go over and the fetch is truncated, not rejected — only the downloaded portion is passed on for indexing. If your critical content sits below 2 MB of bloat, that matters.
  • Caching cuts re-crawl cost. Google’s crawlers use conditional requests and caching so unchanged resources aren’t re-fetched every time. Google doesn’t publish an exact cache duration for rendering resources, so don’t assume a fixed refresh window for a code change — expect some lag, not an instant reflect.
Evidence for this claim Googlebot algorithmically determines which sites to crawl, how often to crawl them, and how many pages to fetch. Scope: web Confidence: high · Verified: In-Depth Guide to How Google Search Works

Rendering is not crawling

This trips people up constantly. “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome.” Rendering is a distinct step from fetching the HTML. The renderer (the Web Rendering Service) is stateless — storage and cookies are cleared between loads, it denies permission prompts, and it rejects service workers. If your content only appears after a click or a JS-driven navigation that isn’t a real <a href> link, expect discovery and rendering problems. (Full treatment in JavaScript SEO.)

Crawling vs indexing vs ranking

The most important distinctions on this page:

  • Crawling ≠ ranking. Crawling is necessary to be in results, but it is not a ranking signal. A higher crawl rate won’t lift your positions. Crawl budget is an efficiency concern, full stop.
  • Crawling ≠ indexing. A page you block in robots.txt can still be indexed if other pages link to it — Google just can’t see the content, or any noindex tag you put there. As I put it in Indexed, though blocked by robots.txt: “crawling and indexing are two different things.” To actually remove a page, allow crawling and add noindex — don’t block it.

I tested the blocking side directly. In The Story of Blocking 2 High-Ranking Pages With Robots.txt I blocked two of our ranking pages. The result: “We lost a position here or there and all of the featured snippets for the pages… I expected a lot more impact, but the world didn’t end.” My takeaway stands: “Don’t block pages you want indexed. It hurts. Not as bad as you might think it does — but it still hurts.”

How to control crawling

  • robots.txt controls crawling, not indexing. “A robots.txt file tells search engine crawlers which URLs the crawler can access on your site.” Evidence for this claim robots.txt controls crawler access and is not a reliable way to keep a URL out of Google. Scope: Google Search behavior for URLs blocked by robots.txt; blocked URLs may still be indexed when discovered elsewhere. Confidence: high · Verified: Google Search Central: Introduction to robots.txt Use it to keep bots out of low-value spaces — not as a deindexing tool.
  • Site architecture & internal links govern how deep pages sit and whether they’re discovered at all (see crawl depth).
  • Crawl-rate controls. Google retired its manual crawl-rate slider in Search Console (early 2024) — it now leans on your server’s responses and a lower automatic minimum. Bing still gives you a manual Crawl Control grid in Bing Webmaster Tools (see crawl rate).

Crawl efficiency and crawl budget

Both engines think about crawling as efficiency. Gary Illyes frames Google’s side as crawl rate limit + crawl demand (popularity and staleness). Bing’s Fabrice Canel calls it their “crawl efficiency north star … to crawl a URL only when the content has been added … updated.”

The reassuring part: most sites don’t need to worry about it. Google says it plainly — if your site doesn’t have a large number of rapidly changing pages, or your pages are crawled the same day they’re published, “you don’t need to read this guide.” It starts to matter around 1M+ pages changing weekly or 10k+ changing daily (see crawl budget and crawl frequency).

Evidence for this claim Sites without many rapidly changing pages, or whose new pages are crawled the day they are published, generally do not need crawl-budget management. Scope: large websites Confidence: high · Verified: Optimize your crawl budget

When crawling goes wrong — how to see it

Before you reach for a fix, figure out which stage is actually broken — the symptoms and the remedies are different at each one:

  • Not discovered at all? Nothing links to the page and it’s missing from your sitemap. Fix internal linking and sitemap coverage — see crawl depth and crawl frequency.

  • Discovered but never fetched? Server errors, timeouts, or a robots.txt block are turning bots away. Check GSC Crawl Stats and your logs — see crawl budget and crawl rate.

  • Fetched but rendering wrong? Content depends on a click or JS-only navigation Googlebot won’t perform, or WRS times out. See JavaScript SEO for the render-specific failure modes.

  • Fetched and rendered but still not indexed? That’s a separate decision the index makes — see the Indexing hub rather than treating it as a crawl problem.

  • Log file analysis is the ground truth. Your server logs show exactly which URLs bots actually hit, how often, and what status codes they got — the best way to spot wasted crawling and find pages bots never reach (see log file analysis).

  • Spider traps — infinite URL spaces from calendars, faceted navigation, session IDs, or relative-link explosions — quietly burn your crawl budget on junk URLs (see spider traps).

Where to go next: the crawling cluster

This hub is the map. Each topic below is its own deep dive:

Crawl efficiency — how much and how often

  • Crawl budget — what it is (capacity + demand), what wastes it, and who actually needs to care.
  • Crawl rate — how fast bots fetch, why the GSC rate slider went away, and how to speed up or slow down a crawl today.
  • Crawl frequency — what makes Google re-crawl a page sooner (popularity, staleness, accurate lastmod) and what doesn’t.
  • Crawl depth — click depth vs. crawl traversal depth, and why important pages belong close to the homepage.

Meet the crawlers — who’s actually fetching your pages

  • Crawler — what a web crawler (bot, spider) is and the fetch → parse → follow loop they all run.
  • User agent — the user-agent string and robots.txt token a bot identifies itself with, and why you can’t trust the string alone.
  • Googlebot — Google’s crawler: Smartphone vs. Desktop, rendering, and how to verify it.
  • Bingbot — Microsoft’s crawler, how it differs, and the surfaces beyond Bing it feeds.
  • AI crawlers — the bots from AI companies (training vs. AI-search vs. user-triggered fetchers) and how to control them.

Diagnosing crawl problems

  • Log file analysis — verifying real bots and reading what they crawled.
  • Spider traps (crawler traps) — the patterns that generate infinite URLs, and how to fix them.

Every topic above is its own deep dive nested under this hub — they’re in the sidebar too.

Qualifying your outbound links is a related on-page control that overlaps with crawling — these tell Google how to treat a link rather than whether to crawl it: nofollow (the original catch-all, now a hint), plus rel=sponsored and rel=ugc for paid/advertising and user-generated links. All three live in the on-page meta tags cluster.

Getting found in the first place is a related but separate stage. How search engines discover your URLs — internal links, sitemaps (XML, sitemap index, image, and video), and the push protocols IndexNow and the Google Indexing API (what each is actually for, and why Google doesn’t use IndexNow) — now lives in its own Discovery hub. For the broader topic, see How Search Works.

Add an expert note

Pin an expert quote

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