Crawl Frequency

How often search engines recrawl a page they already know about — what drives it (popularity, staleness, an honest lastmod), what doesn't (changefreq, priority, publishing daily), and why you can't force it.

First published: Jun 22, 2026 · Last updated: Jul 17, 2026 · Advanced
demand #18 in Crawling#50 in How Search Works#271 in Technical SEO#378 on the site

Crawl frequency is how often a search engine re-fetches a page it already knows about. It's driven mainly by a page's importance (popularity, PageRank, links) and how often it genuinely changes (staleness), though Google names other demand inputs too — Google learns your per-page update pattern and adjusts. You influence it indirectly through importance, real changes, an accurate lastmod, and a healthy server, but you can't set it. changefreq and priority are ignored; bumping lastmod cosmetically backfires; and crawling more often does not improve rankings.

TL;DR — Crawl frequency is the cadence of recrawl for a known URL, set by the scheduler mainly from two inputs: importance (popularity / PageRank / links) and staleness (how often the page genuinely changes) — Google’s documentation names other demand inputs too, such as perceived inventory and site-wide events. Google learns your per-page update pattern and adapts — even backing off on stable pages (3 → 10 → 30 → 100 days). changefreq and priority are ignored; only a verifiable lastmod tied to a significant change is honored. You can’t set frequency directly — you improve the inputs (importance, real change, accurate lastmod, server health) and, for a single URL, request a recrawl. More crawling does not improve rankings. Distinct from crawl rate (speed) and crawl budget (demand + capacity).

What crawl frequency actually is

Crawl frequency is how often a search engine re-fetches a URL it already knows about, to check whether it changed. It’s the cadence of recrawl, decided per URL by the crawl scheduler. The two big inputs are how important the page is and how often it really changes — Google’s documentation calls these popularity and staleness. Evidence for this claim Google's crawl-demand guidance says popular URLs tend to be crawled more often and systems seek to recrawl often enough to detect changes. Scope: Adaptive Google recrawling; no fixed per-page cadence is promised. Confidence: high · Verified: Google: Large site crawl budget guide

This is the piece of the crawling story that’s easiest to blur into its siblings, so let me draw the lines clearly.

Crawl frequency vs. crawl budget vs. crawl rate

These three get used interchangeably and they shouldn’t:

TermWhat it measuresSet by
Crawl frequencyHow often a known URL is re-fetched (cadence)The scheduler — popularity + staleness
Crawl rate (capacity)How fast / how many parallel connectionsYour server’s health (fast = more, errors = less)
Crawl budgetDemand + capacity — “the set of URLs that Google can and wants to crawl”Both of the above, combined

Google’s own definition ties it together: “Google defines a site’s crawl budget as the set of URLs that Google can and wants to crawl.” Frequency is a per-URL cadence that lives inside that budget. Rate is the throttle on the pipe. As I put it in my crawl-budget guide, “Crawl budget is the amount of time and resources a search engine allows for crawling a website. It is made up [of] crawl demand which is how many pages a search engine wants to crawl on your site and crawl rate which is how fast they can crawl.”

Discovery crawls vs. refresh crawls

Frequency is really about refresh crawling. John Mueller laid out the split plainly: “One is a discovery crawl where we try to discover new pages on your website. And the other is a refresh crawl where we update existing pages that we know about.”

Refresh cadence varies enormously by page. Mueller again: “We would refresh crawl the homepage, I don’t know, once a day, or every couple of hours, or something like that.” And on the other end: “If we recognize that individual pages change very rarely, then we realize we don’t have to crawl them all the time.”

The key insight is that Google learns your pattern per page: “If you have a news website and you update it hourly, then we should learn that we need to crawl it hourly. Whereas if it’s a news website that updates once a month, then we should learn that we don’t need to crawl every hour.”

What determines how often Google recrawls a page

In my How Search Works deck I list the crawl-demand factors that drive recrawl: PageRank, how frequently the page changes, time since it was last crawled, and major site changes. That’s the same popularity + staleness model Google documents, just from my own framing — and it’s not an exhaustive list either. Google’s documentation also names perceived inventory (how many URLs it thinks your site has) and site-wide events, such as a domain or URL-structure migration, as things that can move crawl demand up or down. Popularity and staleness are the two you can influence most directly, so they’re the ones worth the most attention. Breaking those down:

“URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems.” More internal and external links to a page → more perceived importance → more frequent recrawls. In my crawl-budget post I say it the same way: “Popular pages, or those with more links and PageRank, will generally receive priority over other pages.”

Staleness — and the backoff

Google’s systems “want to recrawl documents frequently enough to pick up any changes.” The flip side is that pages which don’t change get crawled less and less. From my crawl-budget guide: “If Google sees that a page isn’t changing, they will crawl the page less frequently.” There’s no fixed interval — it’s a backoff: “if they crawl a page and see no changes after a day, they may wait three days before crawling again, ten days the next time, 30 days, 100 days, etc.”

Quality and search demand

Gary Illyes frames the scheduler as something you have to convince: “If you want to increase how much we crawl, then you somehow have to convince search that your stuff is worth fetching, which is basically what the scheduler is listening to.” It’s dynamic: “Scheduling is very dynamic. As soon as we get the signals back from search indexing that the quality of the content has increased across this many URLs, we would just start turning up demand.” It cuts both ways — “If search demand goes down, then that also correlates to the crawl limit going down.”

Worth knowing: Google is actively trying to crawl stable pages less for efficiency reasons. Illyes has publicly described wanting to “crawl even less” and reduce bytes on the wire. So don’t expect the scheduler to err toward over-crawling your unchanging pages.

Server health (rate enables frequency)

Frequency can only go as high as your rate allows. The crawl capacity limit is roughly the maximum number of simultaneous parallel connections Google will use; a fast, error-free server raises that ceiling, while a slow site or one returning 5xx/429 gets crawled less. Server health doesn’t increase frequency — it just stops being a bottleneck.

The role of sitemaps and lastmod

Here’s the biggest myth to bust. People think sitemap settings control cadence. They mostly don’t.

changefreq and priority are ignored

Straight from Google’s sitemap docs: “Google ignores <priority> and <changefreq> values.” Setting <changefreq>hourly</changefreq> does nothing. Evidence for this claim Google ignores sitemap priority and changefreq values and may use accurate lastmod values. Scope: Google sitemap processing. Confidence: high · Verified: Google: Build and submit a sitemap Stop optimizing those fields.

lastmod is the one signal — if it’s honest

The single freshness signal Google honors from a sitemap is lastmod, and only conditionally: “Google uses the <lastmod> value if it’s consistently and verifiably (for example by comparing to the last modification of the page) accurate.” If you lie about it, Google notices and stops trusting it.

And it has to reflect a real change: “The <lastmod> value should reflect the date and time of the last significant update to the page. For example, an update to the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not.” Bumping lastmod because you changed the footer year won’t help — and erodes the trust that makes lastmod work at all.

Can you force or speed up crawling?

The honest answer: there’s no dial for frequency. What you actually have:

  • Improve the inputs — importance (links, internal linking), genuine content changes, an accurate lastmod, and a fast, healthy server.
  • Request a single URL — Google Search Console’s URL Inspection has a “Request indexing” action for one page at a time. It’s a request, not a guarantee, and it doesn’t change ongoing cadence. Google is explicit that mashing the button doesn’t help either: requesting the same URL repeatedly will not get it crawled faster.
  • Push a change (on Bing and others) — see below.
Evidence for this claim Requesting a recrawl repeatedly for the same URL does not make Google crawl it faster. Scope: owned URLs Confidence: high · Verified: Ask Google to recrawl your URLs

What you can’t do: set a frequency, force daily crawls by publishing daily, or use the old GSC crawl-rate slider (it was retired). Bing has a Crawl Control grid, but that controls rate, not frequency.

Bing: adaptive crawling and IndexNow

Bing thinks of crawl frequency as a cost problem. From their crawl-frequency post, the cadence “depends on the frequency of which the content is edited and updated,” and “Defining when to fetch the web page next is the hard problem we are looking to optimize.” Their adaptive answer: “What we learned was that we could optimize our system to avoid fetching the same content over and over, and instead check periodically for major changes” — which in one case yielded “about 40% crawl saving on this site!”

Bing’s “you can nudge it” mechanism is IndexNow: instead of waiting for the scheduler, you signal a change. “Whether you’re adding, updating, or deleting content, IndexNow notifies multiple search engines of your content changes as soon as they happen,” which is about “limiting the need for costly exploratory crawls.” Note the asymmetry: Google does not use IndexNow for general recrawling.

How to check your crawl frequency

  • GSC → Crawl Stats — total requests over time, broken down by response code, file type, and Googlebot type. This is how you observe cadence at the site level; it’s not a per-URL last-crawl report.
  • GSC → URL Inspection — the “last crawl” date for a single URL. This, not Crawl Stats, is where you check when a specific page was last fetched.
  • Bing Webmaster Tools — Crawl Control (rate) and IndexNow Insights.
  • Server log analysis — the ground truth: exactly which URLs bots hit and how often.

Common myths about crawl frequency

  • “Publishing daily forces faster crawling.” No — Google learns your pattern and crawls more for importance and genuine change, not publishing volume.
  • changefreq/priority control cadence.” No — both are ignored.
  • “Just bump lastmod to get recrawled.” Only works if it’s verifiable and tied to a significant change; gaming it makes Google distrust it.
  • “More crawling means better rankings.” No. As I’ve written in my crawl budget guide, “The rate of crawling isn’t going to impact your rankings.” Crawling is a prerequisite, not a boost — “More crawling doesn’t mean you’ll rank better, but if your pages aren’t crawled and indexed they aren’t going to rank at all.”
  • “There’s a fixed schedule.” No — it’s dynamic, per-URL, and adaptive.
  • “I can set crawl frequency in Search Console.” No — the rate slider is gone, and there’s no frequency control.

Add an expert note

Pin an expert quote

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