Crawl budget is the amount of attention Googlebot gives your site: how many URLs it will fetch in a given period. WordPress sites waste it generating tag archives, date archives, feeds, and parameter URLs that soak up crawls while the pages that earn money wait in line.
Crawl budget is the most misunderstood concept in technical SEO: half the advice treats it as irrelevant for small sites, the other half sells it as a magic lever. The truth is specific: it matters when your site generates far more URLs than you think it has, and WordPress does exactly that, silently, by design. Here's how the budget works, the multiplication math your site is probably doing behind your back, and the cleanup sequence that redirects Googlebot's attention to the pages that matter.
What is crawl budget?
Crawl budget is Google's working limit on how much of your site it will fetch, shaped by two forces. Crawl capacity: how fast your server can be crawled without strain, so slow or erroring servers get crawled more gently. Crawl demand: how much Google wants your content, based on popularity, freshness, and how useful past crawls proved. Multiply the two and you get the practical reality: a finite number of fetches per day, spent on whichever of your URLs Googlebot deems worthwhile.
The strategic point hiding in that definition: crawl budget is spent on URLs, not pages. If one blog post exists at six crawlable addresses, it costs six fetches to keep current. Your site's real crawl surface is every URL it exposes, and that's where WordPress surprises people.
Does crawl budget matter for small sites?
Honestly: for a genuinely small crawl surface, under roughly ten thousand URLs, Google itself says budget is rarely the bottleneck, and most "crawl budget optimization" pitched at 30-page sites is theater. So why does this guide anchor my indexing cluster? Because almost no WordPress site is as small as its owner believes. Here's the multiplication for an ordinary business site with 25 pages, 50 posts, and a modest WooCommerce shop:
- 75 real content pages
- +50 tag archives, +12 category archives, +60 date archives (monthly, over five years)
- +135 attachment pages (WordPress historically created one per uploaded image)
- +75 feed URLs (one per post and category in many themes)
- +comment pagination, +author archives
- +WooCommerce: every filter and sort combination on every category, easily 1,000+ parameter URLs
That "75-page site" exposes several thousand crawlable URLs, and Googlebot has to spend fetches learning that most of them are worthless. Meanwhile the new service page waits days for its first crawl. That's the small-site version of a crawl budget problem, and it's the norm, not the exception. It's also why pages end up stuck as discovered but never crawled.
Where does WordPress waste crawl budget?
The repeat offenders, roughly in order of waste on the sites I audit:
- Parameter URLs. WooCommerce filters, sorting options, and search strings mint unlimited variants: ?orderby=, ?filter_color=, ?s=. The single largest source of waste on store sites.
- Tag and date archives. Every tag is a page; a site with 400 tags has 400 mostly-thin archives competing for fetches.
- Attachment pages. A near-empty page per uploaded image on older setups. Hundreds of fetches for zero value.
- Feeds. RSS endpoints multiply per category and post; crawlers dutifully check them all.
- Redirect chains. Each old redesign layered another hop. Every hop is a spent fetch before any content appears.
- Paginated series. Deep archives and comment pages create long crawl paths through near-identical content.
- Orphan and leftover URLs. Staging copies, old landing pages, and unlinked strays Googlebot keeps revisiting out of habit.
How do you check where your crawl budget goes?
Search Console holds the receipts. In Settings, open the Crawl Stats report:
- Total crawl requests and trend. Your actual daily budget, made visible.
- By response. A healthy site is dominated by 200s. Heavy 301, 404, or 5xx shares mean fetches burning on non-content.
- By file type and purpose. Discovery vs refresh tells you whether Google is exploring new URLs or babysitting old ones.
- Sample URLs. The list that ends arguments: read what Googlebot actually fetched this week. Finding tag archives and filter parameters dominating that sample is the moment most owners understand this page.
- Average response time. Sustained slowness suppresses crawl capacity directly, which makes server speed a crawl issue, not just a user-experience one. That layer belongs with my dedicated speed practice: the Core Web Vitals optimization service.
How do you optimize crawl budget on WordPress?
The cleanup sequence, in the order that produces the least collateral damage:
- Block the infinite spaces in robots.txt. Internal search results and filter or sort parameters should never be crawlable. Full syntax and a starter file are in the WordPress robots.txt guide.
- Noindex the thin archives you keep, remove the ones you don't. Tags you actually curate can stay noindexed; hundreds of drive-by tags should be deleted. Attachment pages should redirect to their file or parent (one plugin setting).
- Flatten redirect chains. Point every internal link and old redirect directly at the final URL, one hop maximum.
- Fix the sitemap to list only canonical, indexable URLs. The sitemap is your statement of what deserves crawling; make it truthful.
- Tighten internal linking toward money pages. Googlebot follows links; the pages you link most get crawled most. Bring your services and best content within three clicks of home.
- Speed up server responses if Crawl Stats shows strain. Faster responses literally raise the ceiling on how much Google will crawl.
- Re-check Crawl Stats after two to four weeks. The win condition is visible: fetch distribution shifting from junk to content, and new pages getting discovered in days instead of weeks.
What's the link between crawl budget and indexing?
Crawling is the audition; indexing is the callback. Budget problems starve pages of the crawls they need to be evaluated at all, which surfaces as discovered, currently not indexed. Quality problems get pages crawled and then declined, which surfaces as crawled, currently not indexed. The two failures look similar in a dashboard and need opposite treatments, which is exactly why the diagnosis order matters: budget first, quality second.
When do you need professional help?
When the Crawl Stats sample is dominated by URLs you don't recognize, when a store's parameter space has grown beyond hand-editing robots.txt, or when fixes here haven't moved the coverage report in a month. My crawlability and indexing service maps where your budget actually goes, applies this entire sequence on your WordPress site, and tracks the coverage report until it clears, $149 flat.
Want to see where your crawl budget is going first? The $49 health check includes the crawl-surface scan, delivered in 48 hours with the waste ranked by size.