
Field notes / Technical SEO
Ecommerce Crawl Budget: When It Matters and What to Check
Diagnose catalog discovery and crawling issues using URL inventories, Search Console, availability checks, and log data.
The short answer
First determine whether crawling is actually limiting discovery; do not label every indexing problem a crawl-budget issue.
Decide whether this is the right diagnosis
Google frames crawl-budget guidance primarily around large or frequently updated sites. A small catalog with a handful of missing pages should first check quality, accessibility, linking, and directives. A page can be crawled and still not be indexed. These are separate steps, and increasing crawl requests does not guarantee search inclusion.
Compare active canonical product URLs with observed crawl and indexing status. Identify whether new products remain undiscovered, discovered but uncrawled, or crawled but not indexed. That distinction changes the investigation. A broken product link needs a discovery fix; a noindex tag needs a directive correction; a duplicative page may require a content or canonical decision.
Check availability before optimizing requests
Review server errors, timeout patterns, and the reliability of representative templates. Search Console crawl statistics and available infrastructure logs can help reveal failures. Do not assume a store is healthy because its homepage loads during one manual visit. Product and filter requests may behave differently under load.
Google notes that improving availability does not necessarily increase crawl budget. It can still be important for shoppers and crawlers to receive a reliable response. Work with hosting and engineering teams to isolate slow databases, expensive filter queries, or rate-limit problems where evidence supports those causes. Record when maintenance or outages occurred to interpret changes accurately.
Identify unnecessary URL expansion
Look for filter permutations, sort states, tracking parameters, session identifiers, and internal search URLs. Quantify real observed patterns where possible rather than estimating an imaginary number of wasted pages. Stable URL generation and a documented facet policy are usually more useful than repeatedly requesting indexation for individual products.
Prioritize patterns that are both large and unhelpful. A rarely requested duplicate may not justify disruptive changes, while an endlessly expanding filter path can deserve immediate attention. Confirm that any proposed restriction preserves access to important products and intentional landing pages. Review robots, canonical, and noindex behavior as a coordinated policy.
Improve the paths to important products
Provide crawlable links from relevant categories and maintain accurate sitemaps containing preferred, indexable URLs. Use meaningful lastmod dates when the underlying page changes materially, not a daily timestamp applied to every entry. A sitemap can aid discovery but does not force Google to crawl or index every URL.
Check launch procedures for new products. A product left outside navigation until a campaign begins can be difficult to discover through ordinary links. When thousands of products change, coordinate deployment, feed updates, and sitemap maintenance. Avoid unnecessary URL renaming that creates additional redirect and recrawl work without improving the customer experience.
Validate with a realistic observation window
Create a baseline of new-product discovery time, observed error rates, and crawl patterns. Note catalog size and update frequency. Compare similar conditions after fixes, acknowledging promotions or seasonal inventory changes. Do not use a single day of data to claim that a large-catalog crawling issue has disappeared.
Keep the diagnostic process ongoing. If newly added products are discovered but remain unindexed, revisit content differentiation and technical eligibility rather than continuing to tighten crawl controls. Crawling improvements support accessibility; commercial results still depend on relevant products, useful landing pages, and demand.
Sources & further reading
Examples are illustrative, not client case studies. Platform features and search requirements can change; consult the linked primary documentation before implementation.