Demanda de rastreamento

«> TL;DR — Crawl budget has two sides: how fast a search engine can fetch your

pages (crawl rate) and how much it wants to (crawl demand). Crawl demand is the “want” side. Google wants to crawl a page more when it’s popular (lots of links), when it changes often, and when Google thinks the site is worth its time. You can’t push a button to raise demand — you earn it with links, genuine freshness, and by not burying your good pages under a pile of junk URLs. » (Tradução) (Síntese localizada do trecho três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## What crawl demand is » (Tradução) (Síntese localizada do trecho quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«When people say “crawl budget,” they’re really talking about two separate things squished together. One is your server’s ability to handle being crawled — how fast, how many pages at once. That’s crawl rate, and it’s covered on its own page. The other is how much the search engine actually wants to crawl you in the first place. That’s crawl demand — the topic here. » (Tradução) (Síntese localizada do trecho cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Think of it as supply and demand. Crawl rate is supply: how much crawling your site can support. Crawl demand is demand: how much Google feels like doing. Evidência desta afirmação Google describes crawl demand as one of the two main elements of crawl budget, alongside crawl capacity limit. Escopo: Google Search crawling. Confiança: alta · Verificado: 2026-07-14 Google: Large site crawl budget guide » (Tradução) (Síntese localizada do trecho seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## What makes Google want to crawl a page » (Tradução) (Síntese localizada do trecho sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Google points to a handful of significant factors, not one exhaustive checklist. The three it explains in the most depth: » (Tradução) (Síntese localizada do trecho oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- Popularity. Pages with more links pointing at them get crawled more often, so Google keeps its copy fresh.

• Staleness / freshness. If a page changes a lot, Google wants to check it more often. If it never changes, Google learns to check it less.
• How many URLs Google thinks you have. If your site is full of junk, duplicate, or low-value URLs, Google wastes its crawling on those instead of your real pages. This is the one you control the most. Evidência desta afirmação Google's crawl-demand guidance discusses perceived inventory, popularity, and staleness. Escopo: These inputs influence crawling but do not provide a user-controlled demand setting. Confiança: alta · Verificado: 2026-07-14 Google: Large site crawl budget guide » (Tradução) (Síntese localizada do trecho nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Google also names a few site-level factors that shape demand alongside those three: how big your site is, how often you update it, page quality, and how your site compares to others covering similar ground. Don’t treat “popularity, staleness, perceived inventory” as a complete formula — it’s the biggest, most actionable levers, not the whole list. » (Tradução) (Síntese localizada do trecho dez, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«There’s also a temporary one: if you move your site to a new domain, Google has to re-crawl everything to process it under the new URLs, so demand spikes for a while. » (Tradução) (Síntese localizada do trecho onze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Why you can’t just “increase crawl demand” » (Tradução) (Síntese localizada do trecho doze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«There’s no dial for it — no more than there’s a button to make Google crawl faster. Publishing ten posts a day won’t do it if nobody links to them and they’re not genuinely useful. The things that actually work are slow and real: earn links, keep content genuinely fresh, and clean out the junk URLs so Google’s crawling lands on the pages that matter. » (Tradução) (Síntese localizada do trecho treze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«And here’s the surprise: more crawling isn’t even the goal. Getting crawled a lot doesn’t make you rank higher. What you want isn’t more demand — it’s the demand you have pointed at the right pages. » (Tradução) (Síntese localizada do trecho catorze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Want the deeper version — how demand and your server’s capacity interact, how site quality feeds back into the crawl scheduler, and how to tell a demand problem from a capacity problem? Switch to the Avançado tab. » (Tradução) (Síntese localizada do trecho quinze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«> TL;DR — Crawl demand is the want side of crawl budget; crawl rate/capacity

is the can side. Google names popularity (links / PageRank), staleness (how often a page changes), and perceived inventory (how many URLs Google thinks exist, junk included — “the factor you can positively control the most”) as significant general demand factors — not a closed formula; site size, update frequency, page quality, and comparative relevance also factor in. Site moves spike demand temporarily. My synthesis for tying it together: demand sets the priority order of URLs; host-load capacity decides how far down that queue Googlebot gets — Google doesn’t document this as a literal algorithm, but it’s the model that fits the evidence. A healthy server doesn’t manufacture demand, and high demand can still be capacity-throttled. You can’t set demand directly — the only levers are its inputs, and the scheduler turns demand up when quality signals from indexing improve. Meanwhile Google is actively trying to crawl less while routing demand more precisely, so the real goal was never volume — it’s correct prioritization. Most sites never need to manage any of this.

» (Tradução) (Síntese localizada do trecho dezoito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Crawl demand is the “want,” crawl rate is the “can” » (Tradução) (Síntese localizada do trecho dezenove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Google is explicit that crawl budget has two halves: the amount of time and resources Google devotes to crawling a site “is determined by two main elements: crawl capacity limit and crawl demand.” The way I frame it in my Ahrefs crawl-budget guide: crawl budget is “made up 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.” Demand is the want; rate is the can. Evidência desta afirmação Google describes crawl demand as one of the two main elements of crawl budget, alongside crawl capacity limit. Escopo: Google Search crawling. Confiança: alta · Verificado: 2026-07-14 Google: Large site crawl budget guide » (Tradução) (Síntese localizada do trecho vinte, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«This page is only about the want. The can side — the crawl capacity limit, the GSC rate slider that was removed in January 2024, how 5xx/429 responses slow Googlebot, and Bing’s manual Crawl Control grid — all lives on the crawl rate page. I’m not going to re-derive it here; when the two interact I’ll link across. » (Tradução) (Síntese localizada do trecho vinte e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## The three demand inputs » (Tradução) (Síntese localizada do trecho vinte e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Google’s current guidance calls perceived inventory, popularity, and staleness significant general factors that drive how much it wants to crawl — it doesn’t present them as an exhaustive, closed formula. The same guidance also names site size, how often it’s updated, page quality, and how it compares to similar sites as factors Googlebot weighs. The three below are the ones Google explains in the most depth and the ones you can act on directly. Evidência desta afirmação Google's crawl-demand guidance discusses perceived inventory, popularity, and staleness. Escopo: These inputs influence crawling but do not provide a user-controlled demand setting. Confiança: alta · Verificado: 2026-07-14 Google: Large site crawl budget guide » (Tradução) (Síntese localizada do trecho vinte e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### Popularity » (Tradução) (Síntese localizada do trecho vinte e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«“URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems.” More links and more PageRank pointing at a URL is a demand signal — it’s why your homepage gets crawled constantly and a deep, unlinked page barely at all. As I put it in my crawl-budget guide, “Popular pages, or those with more links and PageRank, will generally receive priority over other pages.” Internal links count here too: a page nothing links to (an orphan) has almost no demand working for it. » (Tradução) (Síntese localizada do trecho vinte e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### Staleness » (Tradução) (Síntese localizada do trecho vinte e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«“Our systems want to recrawl documents frequently enough to pick up any changes.” Google learns each page’s rhythm. A page that changes constantly earns frequent recrawls; a page that never changes gets checked less and less. In my crawl-budget guide I describe the backoff Google applies to a static page: “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.” That per-URL recrawl cadence is really a crawl frequency question — I cover the mechanics there — but the underlying force is demand, and specifically staleness. » (Tradução) (Síntese localizada do trecho vinte e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### Perceived inventory (the one you control most) » (Tradução) (Síntese localizada do trecho vinte e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«This is the headline lever. Google: “Without guidance from you, Google tries to crawl all or most of the URLs that it knows about on your site. If many of these URLs are duplicates, or you don’t want them crawled for some other reason (removed, unimportant, and so on), this wastes a lot of Google crawling time on your site. This is the factor that you can positively control the most.”

» (Tradução) (Síntese localizada do trecho trinta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«The subtle part is what it does to demand, not just capacity. It’s easy to think of junk URLs as “wasting crawl budget” — spending fetches on copies instead of new content. True. But there’s a demand-side effect too: a site whose knowable inventory is mostly low-value duplicates and parameter sprawl looks, to Google, like a lower-value site to crawl. Cutting perceived inventory doesn’t just free capacity; over time it concentrates demand on the URLs that deserve it. Faceted navigation, session IDs, infinite calendar spaces, and other spider traps are the classic inventory inflators — and the classic demand suppressors. » (Tradução) (Síntese localizada do trecho trinta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Site moves and other demand spikes » (Tradução) (Síntese localizada do trecho trinta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«One demand driver isn’t about any single URL: “Additionally, site-wide events like site moves may trigger an increase in crawl demand in order to reprocess the content under the new URLs.” If you do a domain migration or a big replatform and notice Googlebot hitting you far harder than usual for a few weeks, that’s expected — Google has to re-fetch and reprocess everything under the new addresses. It’s a temporary spike, not a new baseline, and it’s a demand event competitor guides almost never mention despite it being verbatim in Google’s own documentation.

» (Tradução) (Síntese localizada do trecho trinta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## How demand and host load interact: queue order vs. capacity gate » (Tradução) (Síntese localizada do trecho trinta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Here’s a mental model that makes the whole topic click — and I want to be upfront that it’s my synthesis, not something Google documents as a literal algorithm. It’s built on a Gary Illyes Q&A, quoted here through Search Engine Roundtable’s coverage: host load “sets a bucket of URLs in importance order and GoogleBot will crawl in that order based on the schedule the host load decided. If Google thinks your server can handle it, it will crawl the whole bucket, if not, it will stop.” Notably, per that same Q&A, host load tracks the importance of your pages — not the raw number of URLs you have or how many you want crawled. That page blocks automated fetching, so I haven’t been able to re-confirm the exact wording directly against the live source this pass — treat it as a well-corroborated paraphrase, not a verbatim primary-source quote. » (Tradução) (Síntese localizada do trecho trinta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Read that carefully and a relationship falls out — again, this is how I connect the pieces, not a mechanism Google has spelled out end to end: » (Tradução) (Síntese localizada do trecho trinta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- Demand sets the order. The “bucket of URLs in importance order” is crawl demand — popularity and staleness deciding which URLs sit at the top of the queue.

• Capacity sets how far Google gets. Host load / crawl rate decides how deep into that ordered bucket Googlebot actually crawls on a given day. “If your server can handle it, it crawls the whole bucket; if not, it stops.” » (Tradução) (Síntese localizada do trecho trinta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«So the two aren’t just multiplied together — they play different roles. A healthy, fast server doesn’t manufacture demand (it only raises the ceiling on how much of your existing demand gets realized), and high demand can still be capacity-throttled (a slow or error-prone server stops Googlebot part-way down the queue no matter how much it wants to crawl). This is why “I bought a faster server and Google still isn’t crawling my new pages” is such a common, frustrating result: capacity was never the constraint — demand was. » (Tradução) (Síntese localizada do trecho trinta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## You can’t set demand directly — but the scheduler listens » (Tradução) (Síntese localizada do trecho trinta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Short answer: you don’t set demand directly. You earn it, indirectly, through real links and real quality improvements that show up in indexing signals — nothing else moves it. » (Tradução) (Síntese localizada do trecho quarenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«There is no “crawl more” request for demand any more than there is for rate. But demand is dynamic, and Google has been unusually candid about how it moves. Gary Illyes: “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.” And the feedback loop is real-time-ish: “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.” The flip side too: “If search demand goes down, then that also correlates to the crawl limit going down.” (I re-checked these three lines against Search Engine Journal’s coverage this pass and they match verbatim; I still haven’t tracked down Google’s own podcast audio/transcript to confirm them as a primary source, so treat them as well-corroborated secondary quotes.) » (Tradução) (Síntese localizada do trecho quarenta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«That reframes “how do I increase crawl demand” away from tricks. Fake lastmod timestamps, sitemap pings, and publishing volume don’t convince the scheduler. The two things that do are the two hard things: real popularity (links) and real quality improvements that show up in indexing signals and feed back into the scheduler. Everything else is theater. » (Tradução) (Síntese localizada do trecho quarenta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Google is trying to crawl less, not more » (Tradução) (Síntese localizada do trecho quarenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«The single freshest angle here, and one older guides miss entirely: Google’s own stated goal is to reduce total crawl volume, not grow it. In an April 2024 LinkedIn post, Illyes wrote: “My mission this year is to figure out how to crawl even less, and have fewer bytes on wire.” He pushed back on the idea that Google had slashed crawling — “we’re crawling roughly as much as before, however scheduling got more intelligent” — and framed the goal as a shared win: “Decreasing crawling without sacrificing crawl-quality would benefit everyone.” The mechanisms he pointed at were better caching, cache sharing across user-agents, and fewer bytes transferred — not “crawl my site more.” » (Tradução) (Síntese localizada do trecho quarenta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«The takeaway: crawl demand was never something to maximize. Google is actively optimizing for less total crawling with equal or better crawl quality, routing the demand it does have toward URLs more likely to deserve it. Your goal isn’t more demand — it’s correct prioritization of the demand you’ve earned. » (Tradução) (Síntese localizada do trecho quarenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Do you even have a demand problem? » (Tradução) (Síntese localizada do trecho quarenta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Most sites don’t, and shouldn’t spend a minute on this. Google’s own de-escalation applies squarely to demand: “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” John Mueller has been similarly blunt about scale — per Search Engine Roundtable’s coverage of his tweet, 100k URLs is usually not enough to affect crawl budget, since that works out to well under one crawl per minute over three months. » (Tradução) (Síntese localizada do trecho quarenta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«If you are big enough to care, here’s the diagnostic that separates a demand problem from a capacity one — with a caveat up front: it produces a hypothesis to test, not a diagnosis. Pull up GSC’s Crawl Stats report and your server logs. If host status is healthy and average response time is fine but a set of URLs is barely getting crawled — and they’re stuck in “Discovered – currently not indexed” — that pattern is evidence pointing toward demand, not proof of it. Crawl Stats shows crawl activity (a capacity-side view), not a demand score — there is no public per-site “crawl demand score” anywhere, so you’re always inferring demand from activity plus indexing status, never reading it off a dashboard. » (Tradução) (Síntese localizada do trecho quarenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Before you act on “it’s a demand problem,” rule out the other things that produce the same healthy-server-but-not-crawled symptom: Google may not have discovered the URLs yet (no path in, no sitemap entry), rendering may be hiding the content Googlebot needs to see, canonicalization may point Google somewhere else entirely, real quality issues (thin, duplicate, low-value) can get a page crawled but deliberately left out of the index, and Google’s own indexing selection can sit a page out even when crawling and quality are both fine. Only after those are checked and don’t explain it does “low demand” become the working explanation — and even then, treat it as the best-supported hypothesis, not a confirmed cause. Faster hardware won’t fix a genuine demand problem; the fix is on the demand inputs: links to those pages, genuine reasons to recrawl them, and less junk inventory drowning them out. » (Tradução) (Síntese localizada do trecho quarenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«For ground-truth, per-URL crawl data, log analysis is the answer. I’ll flag one current tool I can speak to firsthand in the Tools tab. » (Tradução) (Síntese localizada do trecho cinquenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Crawl demand vs. rate vs. budget vs. frequency » (Tradução) (Síntese localizada do trecho cinquenta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Keep the family straight: » (Tradução) (Síntese localizada do trecho cinquenta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- Crawl demand — how much Google wants to crawl (popularity + staleness + perceived inventory). This page.

• Crawl rate — how fast it can (capacity / host load). Its own page.
• Crawl budget — the two together: “the number of URLs Googlebot can and wants to crawl.”
• Crawl frequency — how often a given URL gets recrawled, which is a demand output (mostly staleness).

» (Tradução) (Síntese localizada do trecho cinquenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Bing doesn’t use the term “crawl demand” — it reframes the whole thing as crawl efficiency: Fabrice Canel defines it as “how often we crawl and discover new and fresh content per page crawled,” and Bing’s philosophy is inventory-reduction-first, the demand-side equivalent of perceived inventory. IndexNow is Bing’s way of signaling demand-relevant change events instead of waiting for the scheduler to infer staleness — but note Google does not use IndexNow, so it won’t move Google’s demand.

» (Tradução) (Síntese localizada do trecho cinquenta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## AI summary » (Tradução) (Síntese localizada do trecho cinquenta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«A condensed take on the Advanced version: » (Tradução) (Síntese localizada do trecho cinquenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- Crawl demand = the “want” side of crawl budget; crawl rate/capacity is the “can” side. Budget is “the number of URLs Googlebot can and wants to crawl.”

• Significant demand factors — not a closed formula: popularity (links / PageRank), staleness (how often a page changes), and perceived inventory (how many URLs Google thinks exist — junk included; “the factor you can positively control the most”), plus site size, update frequency, page quality, and comparative relevance.
• Site moves spike demand temporarily while Google reprocesses content under new URLs.
• Demand vs. capacity model (my synthesis, not a documented Google algorithm): demand sets the priority order of URLs; host-load capacity decides how far down that queue Googlebot gets. A fast server doesn’t create demand; high demand can still be capacity-throttled.
• You can’t set demand directly. The scheduler “turns up demand” when quality signals from indexing improve — so the only real levers are earning links and making genuine quality/freshness improvements. Fake lastmod, sitemap pings, and publishing volume don’t move it.
• Google is trying to crawl less, not more (Illyes: “crawl even less… fewer bytes on wire”), routing demand more precisely. The goal is correct prioritization, not volume.
• Diagnose demand vs. capacity: healthy host status + low crawl volume + stuck in “Discovered – currently not indexed” is a demand hypothesis, not proof — rule out » (Tradução) (Síntese localizada do trecho cinquenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.) « discovery, rendering, canonicalization, and indexing-selection causes first. No public “crawl demand score” exists.
• Bing reframes it as crawl efficiency; IndexNow signals change to Bing (not Google). Most sites never need to manage this. » (Tradução) (Síntese localizada do trecho cinquenta e nove, parte dois: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Official documentation » (Tradução) (Síntese localizada do trecho sessenta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Primary-source documentation from the search engines. » (Tradução) (Síntese localizada do trecho sessenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Google

• Optimize your crawl budget — the source that defines crawl demand, its three inputs (popularity, staleness, perceived inventory), and site-move demand spikes.
• Crawl Budget Management — the capacity/demand split, with the crawl-capacity mechanics that demand runs into.
• What crawl budget means for Googlebot (2017) — Gary Illyes’ original post defining crawl budget as what Googlebot “can and wants to crawl,” and the low-value-URL categories that suppress effective demand.
• Myths and facts about crawling — confirms crawl rate isn’t a ranking signal and that server health, not desire, sets the capacity ceiling.
• Crawling December series (2024) — Googlebot, HTTP caching, faceted nav, and the efficiency thinking behind crawling less. » (Tradução) (Síntese localizada do trecho sessenta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Bing / Microsoft

• bingbot Series: Maximizing Crawl Efficiency — Bing’s “crawl efficiency” framing, its demand-side analogue.
• bingbot Series: Optimizing Crawl Frequency — Bing’s take on recrawl cadence driven by how often content changes (its “staleness” analogue).
• IndexNow / indexnow.org — signal changed URLs to Bing and others (not Google) instead of waiting on inferred staleness. » (Tradução) (Síntese localizada do trecho sessenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Quotes from the source » (Tradução) (Síntese localizada do trecho sessenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«On-the-record statements from Google and Bing. Each link is a deep link that jumps to the quoted passage on the source page. » (Tradução) (Síntese localizada do trecho sessenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Google — the demand definition and its inputs » (Tradução) (Síntese localizada do trecho setenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- “The amount of time and resources that Google devotes to crawling a site is commonly called the site’s crawl budget and it’s determined by two main elements: crawl capacity limit and crawl demand.” — Large Site Owner’s Guide to Managing Crawl Budget. Jump to quote

• “Each crawler has its own ‘demand’ when it comes to crawling the web.” Jump to quote
• “URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems.” (popularity) Jump to quote
• “Our systems want to recrawl documents frequently enough to pick up any changes.” (staleness) Jump to quote » (Tradução) (Síntese localizada do trecho setenta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Google — perceived inventory and site moves » (Tradução) (Síntese localizada do trecho setenta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- “If many of these URLs are duplicates, or you don’t want them crawled for some other reason (removed, unimportant, and so on), this wastes a lot of Google crawling time on your site. This is the factor that you can positively control the most.” Jump to quote

• “Additionally, site-wide events like site moves may trigger an increase in crawl demand in order to reprocess the content under the new URLs.” Jump to quote
• “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” Jump to quote » (Tradução) (Síntese localizada do trecho setenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Gary Illyes, Google — how demand actually moves (via Search Engine Journal’s coverage of his podcast appearance) » (Tradução) (Síntese localizada do trecho setenta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- “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.” Read the coverage

• “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.” Read the coverage
• “If search demand goes down, then that also correlates to the crawl limit going down.” Read the coverage » (Tradução) (Síntese localizada do trecho setenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Gary Illyes, Google — the “crawl even less” mission (LinkedIn, April 2024 — primary source, verified verbatim) » (Tradução) (Síntese localizada do trecho setenta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- “My mission this year is to figure out how to crawl even less, and have fewer bytes on wire.” Read the post

• “we’re crawling roughly as much as before, however scheduling got more intelligent” and “Decreasing crawling without sacrificing crawl-quality would benefit everyone.” Read the post » (Tradução) (Síntese localizada do trecho setenta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Bing / Microsoft — crawl efficiency (the demand-side analogue) » (Tradução) (Síntese localizada do trecho setenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- “The crawl efficiency is how often we crawl and discover new and fresh content per page crawled.” — Fabrice Canel. Jump to quote » (Tradução) (Síntese localizada do trecho setenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Note: the three Illyes “how demand moves” lines are quoted through Search Engine Journal’s contemporaneous coverage of his podcast appearance, not a direct transcript, so confirm them against the original before treating as final. The 2017 Illyes crawl-budget blog post (linked in Official Docs) is JavaScript-rendered and resists automated checking — its “can and wants to crawl” definition and low-value-URL list are corroborated through secondary coverage; confirm against the live page. The Illyes “host load… bucket of URLs in importance order” quote and John Mueller’s “100k URLs” line, paraphrased in the Advanced tab, come from Search Engine Roundtable pages that block automated fetch; they’re paraphrased rather than quoted here and should be confirmed against the live pages. » (Tradução) (Síntese localizada do trecho oitenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Is it a crawl-demand problem — and should you care? » (Tradução) (Síntese localizada do trecho oitenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Work top-down. Most sites exit early with “leave it alone.” » (Tradução) (Síntese localizada do trecho oitenta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Crawl demand myths and mistakes » (Tradução) (Síntese localizada do trecho oitenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«The conflations that send people down the wrong path. » (Tradução) (Síntese localizada do trecho oitenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«“Crawl demand and crawl budget are the same thing.” Why it’s wrong: demand is one of two components; budget is capacity × demand together — “the number of URLs Googlebot can and wants to crawl.” Do instead: keep the vocabulary straight. Budget is the outcome; demand and capacity are its two inputs. A budget problem is always really a demand problem, a capacity problem, or both. » (Tradução) (Síntese localizada do trecho noventa, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«“A faster server increases crawl demand.” Why it’s wrong: server speed raises the capacity ceiling only. It lets Google realize more of the demand you already have; it doesn’t make Google want to crawl more. Demand is set by popularity, staleness, and perceived inventory — none of which your hardware touches. Do instead: if a healthy server still isn’t getting your pages crawled, stop buying hardware and work the demand inputs (links, freshness, less junk inventory). » (Tradução) (Síntese localizada do trecho noventa e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«“Publishing more often increases demand.” Why it’s wrong: publishing volume without genuine importance or change doesn’t convince the scheduler. Ten thin posts a day that nobody links to move nothing. Do instead: publish things that earn links and genuinely change/improve — that’s what feeds the quality signals the scheduler listens to. (This is a crawl frequency point too; more detail lives there.) » (Tradução) (Síntese localizada do trecho noventa e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«“Blocking junk URLs in robots.txt instantly redirects that demand to my good pages.” Why it’s wrong: cutting perceived inventory helps demand concentrate over time as Google reassesses the site — but it isn’t an instant reallocation. Google won’t automatically pour freed-up crawling onto your good pages the moment you disallow the junk. Do instead: reduce junk inventory for the long-term concentration benefit, and be patient. It’s a trend, not a switch. » (Tradução) (Síntese localizada do trecho noventa e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«“There’s a crawl-demand score I can check in Search Console.” Why it’s wrong: no public per-site demand score exists. Crawl Stats shows crawl activity — a capacity-side report — not a demand metric. Do instead: infer demand from activity plus indexing status (e.g., healthy host + low crawl volume + “Discovered – currently not indexed” = a demand signal). Use log data for per-URL ground truth. » (Tradução) (Síntese localizada do trecho noventa e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«“IndexNow or sitemap pings raise Google’s crawl demand.” Why it’s wrong: Google doesn’t use IndexNow, and it ignores changefreq/priority in sitemaps. Pinging Google doesn’t make it want to crawl you more. Do instead: use IndexNow for Bing and other participating engines. For Google, an accurate lastmod helps it schedule, but the demand levers remain links, freshness, and inventory. » (Tradução) (Síntese localizada do trecho noventa e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«“More crawling is always better — for me and for Google.” Why it’s wrong: getting crawled more doesn’t raise rankings, and Google itself is trying to crawl less (“My mission this year is to figure out how to crawl even less, and have fewer bytes on wire”) while routing demand more precisely. Do instead: aim for correct prioritization, not raw volume. The goal is the demand you have landing on the right URLs. » (Tradução) (Síntese localizada do trecho noventa e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Runbook: “Google isn’t crawling my important pages, and my server is fine” » (Tradução) (Síntese localizada do trecho noventa e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«A linear path for a large-site owner who suspects a demand problem. Stop as soon as a step resolves it. » (Tradução) (Síntese localizada do trecho cem, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«1. Confirm you’re big enough to care. If pages are usually crawled the day they’re published, or the site is normal-sized, stop — you don’t have a crawl-demand problem. This runbook is for 1M+-page or fast-changing sites, or sites with a large “Discovered – currently not indexed” pile. » (Tradução) (Síntese localizada do trecho cento e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«2. Rule out capacity first. Open GSC Crawl Stats. Check host status and average response time over the last 90 days. If you see 5xx/timeout spikes or climbing response times, this is a capacity problem — fix server health (see the crawl rate page) and re-run this runbook afterward. If the server looks healthy, continue. » (Tradução) (Síntese localizada do trecho cento e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«3. Pull per-URL ground truth from logs. Get server logs (or a bot-analytics feed) for the affected URL set. Confirm the pattern: real Googlebot hits are sparse or absent on pages you care about, while junk/parameter URLs are eating hits. Sparse hits on healthy-server pages is a demand hypothesis, not a confirmed cause yet — before you commit to “demand,” rule out the look-alikes: Google not having discovered the URL, a rendering failure hiding the content, canonicalization pointing away from the page, real quality/duplication issues, and Google’s own indexing-selection choices. Check Search Console’s URL Inspection and rendered-HTML view for each. » (Tradução) (Síntese localizada do trecho cento e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«4. Check for perceived-inventory inflation. Count how many low-value URLs Google could be discovering: faceted-navigation combinations, session IDs, sort/filter parameters, calendar/infinite spaces, on-site duplicates. If these dwarf your real pages, demand is likely being spread across junk. » (Tradução) (Síntese localizada do trecho cento e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«5. Cut the junk inventory. Reduce the low-value URL space at the source (parameter handling, robots.txt disallow of infinite spaces, fixing spider traps, consolidating duplicates via canonicalization). Expect concentration over time, not an instant reallocation. » (Tradução) (Síntese localizada do trecho cento e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«6. Work the popularity input. Add internal links from strong pages to the under-crawled ones (kill orphans), and pursue external links. Popularity is a primary demand driver. » (Tradução) (Síntese localizada do trecho cento e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«7. Work the quality/freshness input. Genuinely improve and update the pages so the signals that come back from indexing tell the scheduler to “turn up demand.” Accurate lastmod helps Google schedule; fake freshness does not. » (Tradução) (Síntese localizada do trecho cento e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«8. Give it time, then re-measure. Re-check Crawl Stats and logs after Google has had time to reassess. Demand shifts are gradual. If the pages are now crawling and indexing, done. If not, revisit whether the pages are genuinely worth crawling — sometimes the honest answer is that they aren’t, and thin pages shouldn’t be forced into the index. » (Tradução) (Síntese localizada do trecho cento e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Crawl-demand checklist » (Tradução) (Síntese localizada do trecho cento e onze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Diagnose: is it demand or capacity? » (Tradução) (Síntese localizada do trecho cento e doze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- [ ] Confirmed the site is actually large/fast-changing enough to care (else stop).

• GSC Crawl Stats: host status healthy, average response time stable, no 5xx/timeout spikes.
• Server logs (or bot analytics) reviewed for real per-URL Googlebot hits.
• Pattern identified: healthy server + low crawl volume on good pages + “Discovered – currently not indexed” = a demand hypothesis, not proof — and not a capacity issue.
• Ruled out the look-alikes before blaming demand: discovery, rendering, canonicalization, quality/duplication, and indexing-selection issues. » (Tradução) (Síntese localizada do trecho cento e treze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Work the demand inputs (there’s no direct dial) » (Tradução) (Síntese localizada do trecho cento e catorze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- [ ] Popularity: important pages have internal links pointing at them (no orphans); external link-building underway where it matters.

• Staleness/freshness: pages that should be recrawled often are genuinely updated; lastmod is accurate (not faked).
• Perceived inventory: faceted-nav, parameter, session-ID, and infinite URL spaces are controlled; spider traps fixed; duplicates consolidated. » (Tradução) (Síntese localizada do trecho cento e quinze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Reality checks » (Tradução) (Síntese localizada do trecho cento e dezesseis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- [ ] Not expecting a faster server to raise demand (it only raises the capacity ceiling).

• Not expecting robots.txt disallow of junk to instantly reroute demand to good pages (it concentrates over time).
• Not relying on IndexNow/sitemap pings to move Google’s demand (Google ignores IndexNow and changefreq/priority).
• After a site move, treating the temporary crawl spike as expected, not a problem.
• Remembering more crawling isn’t the goal — correct prioritization is; crawl volume isn’t a ranking factor. » (Tradução) (Síntese localizada do trecho cento e dezessete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Crawl demand — cheat sheet » (Tradução) (Síntese localizada do trecho cento e vinte, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«The two sides of crawl budget » (Tradução) (Síntese localizada do trecho cento e vinte e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«| | Crawl demand (this page) | Crawl rate / capacity | | --- | --- | --- | | What it is | How much Google wants to crawl | How fast it can | | Drivers | Popularity, staleness, perceived inventory (+ site moves) | Server health / host load | | Role in the queue | Sets the order of URLs (importance) | Sets how far down Google gets | | Your lever | Links, real freshness, cut junk inventory | Faster/healthier server | | Direct dial? | No | No | » (Tradução) (Síntese localizada do trecho cento e vinte e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«The three most-actionable demand inputs (Google names these plus site size, update frequency, page quality, and comparative relevance as significant general factors — not a closed formula) » (Tradução) (Síntese localizada do trecho cento e vinte e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«| Input | What raises it | What it isn’t | | --- | --- | --- | | Popularity | More links / PageRank (internal + external) | Not publishing volume | | Staleness | Genuine, frequent content change | Not fake lastmod | | Perceived inventory | Fewer junk/duplicate URLs (cutting it helps) | Not a faster server | » (Tradução) (Síntese localizada do trecho cento e vinte e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Fast facts » (Tradução) (Síntese localizada do trecho cento e vinte e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- Crawl budget = “the number of URLs Googlebot can and wants to crawl.”

• Perceived inventory is “the factor you can positively control the most.”
• Site moves temporarily spike demand (reprocessing under new URLs).
• Demand sets the priority order; host-load capacity decides how deep Google crawls — a healthy server doesn’t create demand.
• The scheduler “turns up demand” when indexing quality signals improve — that’s the only real lever besides links.
• Google’s goal is to crawl less overall, not more (Illyes, 2024). Crawl volume is not a ranking factor.
• No public “crawl demand score” — Crawl Stats shows activity (capacity side).
• Bing has no “crawl demand” term — it’s crawl efficiency; IndexNow signals change to Bing, not Google. » (Tradução) (Síntese localizada do trecho cento e vinte e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Tools for diagnosing crawl demand » (Tradução) (Síntese localizada do trecho cento e vinte e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«There’s no “demand meter,” so diagnosing demand means reading crawl activity and comparing it against what you know about the pages. » (Tradução) (Síntese localizada do trecho cento e trinta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- Google Search Console — Crawl Stats report — total crawl requests over time, host status, average response time, and breakdowns by response code, file type, purpose, and Googlebot type. Read it as a capacity view: healthy host status + low crawl volume on good pages is your demand tell.

• GSC — Page indexing report — the “Discovered – currently not indexed” bucket is the classic footprint of a demand shortfall (Google knows the URLs, doesn’t care enough to crawl them yet).
• URL Inspection (GSC) — check when a specific URL was last crawled and whether it’s indexed; useful to confirm a single page’s demand story.
• Server log file analysis — the ground truth for real, per-URL Googlebot hits: which URLs bots actually fetch, how often, and where crawling is being wasted on junk inventory. (See log file analysis.)
• Ahrefs Bot Analytics — a tool I can speak to firsthand. As I described it when we launched it, “Have y’all checked out Bot Analytics in Ahrefs yet? We released a new tool that shows how bots crawl your website. Bot Analytics collects data server-side via Cloudflare integration.” It shows every bot crawling your site and the pages they hit across 12 categories — exactly the per-URL, per-bot ground truth you need to check Google’s “perceived inventory” and “popularity” story against reality. Ahrefs’ own framing of the problem it solves: “uncontrolled bot traffic wastes crawl budget — bots crawling 404 pages or low-value URLs aren’t crawling the » (Tradução) (Síntese localizada do trecho cento e trinta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.) « pages you need indexed,” and it cites the estimate that over half of all crawler traffic is wasted effort.
• Ahrefs Site Audit / Screaming Frog SEO Spider — simulate a crawl to surface the parameter sprawl, duplicates, and trap-like patterns that inflate perceived inventory and suppress demand. » (Tradução) (Síntese localizada do trecho cento e trinta e um, parte dois: o texto-fonte foi preservado para conferência na revisão nativa.)

«## The importance × change × inventory framework » (Tradução) (Síntese localizada do trecho cento e trinta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Use three questions to explain changes in crawl demand: » (Tradução) (Síntese localizada do trecho cento e trinta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«1. Importance: did internal or external signals make the URL more or less important? 2. Change: did the page change meaningfully, and did truthful sitemap signals communicate that? 3. Inventory: did the crawler’s known set of duplicates, parameters, or low-value URLs expand? » (Tradução) (Síntese localizada do trecho cento e trinta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Host health is the ceiling, not a fourth demand input. If logs show errors or timeouts, diagnose crawl capacity separately. If the server is healthy but valuable URLs lose crawl share, work through importance, change, and inventory in that order. » (Tradução) (Síntese localizada do trecho cento e trinta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Compare crawl share by directory » (Tradução) (Síntese localizada do trecho cento e quarenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«This shell pipeline summarizes verified crawler requests by the first URL-path directory in a common access log: » (Tradução) (Síntese localizada do trecho cento e quarenta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

awk 'BEGIN{IGNORECASE=1} /Googlebot/ {split($7,p,"/"); print "/" p[2] "/"}' access.log | sort | uniq -c | sort -nr

«On PowerShell: » (Tradução) (Síntese localizada do trecho cento e quarenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Select-String .\access.log -Pattern 'Googlebot' | ForEach-Object { if ($_.Line -match '"(?:GET|HEAD)\s+https?://[^/]+/([^/?\s]*)|"(?:GET|HEAD)\s+/([^/?\s]*)') { '/' + (($Matches[1],$Matches[2] | Where-Object { $_ })[0]) + '/' } } | Group-Object | Sort-Object Count -Descending

«Compare the same-length windows before and after a change. A directory gaining share is a clue about scheduler allocation, not proof of higher quality or rankings. » (Tradução) (Síntese localizada do trecho cento e quarenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Metrics for crawl demand » (Tradução) (Síntese localizada do trecho cento e quarenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### Valuable-template crawl share » (Tradução) (Síntese localizada do trecho cento e quarenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Metric: crawler requests to important templates divided by verified crawler requests. What it tells you: whether demand is reaching the inventory you care about. How to pull it: classify access-log URLs by template. Benchmark / realistic range: define the desired mix from your own valuable inventory and update cadence; there is no universal percentage. Cadence: weekly for large changing sites, monthly otherwise. » (Tradução) (Síntese localizada do trecho cento e cinquenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### Recrawl lag after meaningful changes » (Tradução) (Síntese localizada do trecho cento e cinquenta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Metric: time from a real page update to the next verified crawler fetch. What it tells you: whether the scheduler recognizes the page’s importance and change pattern. How to pull it: join deployment or content timestamps to access logs. Benchmark / realistic range: baseline by template; news and stable reference pages should not share a target. Cadence: monthly. » (Tradução) (Síntese localizada do trecho cento e cinquenta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### Low-value inventory share » (Tradução) (Síntese localizada do trecho cento e cinquenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Metric: known and crawled parameter, duplicate, empty, or soft-404 URLs relative to useful URLs. What it tells you: whether perceived inventory is diluting attention. How to pull it: combine crawl exports, sitemaps, indexability rules, and logs. Benchmark / realistic range: trend downward from the site’s baseline without blocking required resources. Cadence: monthly and after faceted-navigation or platform changes. » (Tradução) (Síntese localizada do trecho cento e cinquenta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Resources worth your time » (Tradução) (Síntese localizada do trecho cento e cinquenta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«My related writing

• When Should You Worry About Crawl Budget? — where I frame crawl budget as demand (“how many pages a search engine wants to crawl”) plus rate, and cover popularity, the staleness backoff, and who actually needs to care.
• What Is Googlebot & How Does It Work? — how Googlebot decides what and how much to crawl.
• The Beginner’s Guide to Technical SEO — where crawling and crawl budget fit in the bigger picture. » (Tradução) (Síntese localizada do trecho cento e cinquenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«My speaking

• How Search Works (SlideShare) — my walkthrough of crawling, including the demand factors (PageRank, freshness, time since last crawl, major site changes) and the separate capacity/host-load slide. (Standing disclaimer: “This is my understanding of systems… not going to be 100% complete or accurate.”) » (Tradução) (Síntese localizada do trecho cento e cinquenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«From around the industry

• Google’s Crawling Priorities: Insights From Gary Illyes (Search Engine Journal) — the “convince search your stuff is worth fetching,” “turning up demand,” and “search demand goes down” quotes on how demand actually moves.
• Gary Illyes on crawling even less (LinkedIn, April 2024) — the primary source for “crawl even less… fewer bytes on wire” and “scheduling got more intelligent.”
• Google Has Two Types Of Crawling: Discovery & Refresh (Search Engine Journal) — John Mueller on discovery vs. refresh crawls; refresh cadence is a pure demand output.
• Google’s Gary Illyes On Crawl Budget, Scheduling & Host Load (Search Engine Roundtable) — the “bucket of URLs in importance order” host-load framing (paraphrased in this article; the page blocks automated fetch — confirm against the live page).
• Google: 100k URLs Won’t Impact Crawl Budget (Search Engine Roundtable) — John Mueller’s scale gut-check (paraphrased here; confirm against the live page). » (Tradução) (Síntese localizada do trecho cento e sessenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.) «- What Is Crawl Budget? How It Works + Optimization Tips (Search Engine Land) — a solid crawl-budget mega-guide; useful background on the three demand factors.
• Ahrefs Bot Analytics — the product page with the “uncontrolled bot traffic wastes crawl budget” and “over half… wasted effort” framing for diagnosing demand vs. capacity from real bot data. » (Tradução) (Síntese localizada do trecho cento e sessenta, parte dois: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Test yourself: Crawl Demand » (Tradução) (Síntese localizada do trecho cento e sessenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Five quick questions on the “want” side of crawl budget. Pick an answer for each, then check. » (Tradução) (Síntese localizada do trecho cento e sessenta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Registro de alterações