Page loaded
Convertos

Most crawler activity was repeat work. That was the real crawl-budget problem.

2026-06-26·13 min·By Ethan

An anonymized marketplace analysis found 82% recrawls, 39% parameter waste, and heavy duplicate-mobile leakage. Here is how to turn those signals into fixes.

High crawl volume did not mean the site was being explored well. In this case, the better signal was where crawler effort actually landed: URLs that were already known, duplicated, parameterized, paginated, or otherwise unlikely to improve discovery of canonical, indexable, commercially important pages. That is also the practical reading of Google’s guidance on crawl budget: not “more hits is better,” but whether crawling is spent on URLs worth fetching at scale (official documentation, managing crawl budget for large sites).

The crawler was busy, but much of the work had little value

Within the sampled snapshots, about 82% of crawler activity revisited known URLs, more than 39% reached parameterized URLs, duplicate mobile URLs consumed more than 50% of product-detail crawl activity, and pagination absorbed about 40% of category and listing crawl activity. Taken together, the crawler was active, but much of that activity went to low-yield paths.
Waste signal from sampled snapshotsWhat it means operationallyWhy it lowers crawl value
82% of crawler activity revisited known URLsMost requests returned to URLs already discoveredDiscovery capacity for new or corrected canonicals was limited
More than 39% of requests hit parameterized URLsFilters, sorts, tracking, or session-like variants were being fetchedCrawl was diluted across alternate URL states
More than 50% of product-detail crawl hit duplicate mobile URLsProduct attention split across duplicate representationsCanonical product URLs received less concentrated crawl
About 40% of category/listing crawl went to paginationDeep listing sequences absorbed bot timeHigher-value category hubs and key products competed for fetches
The key question is simple: what share of crawl was clearly aligned with the pages that matter most? If about 82% was repeat work, only about 18% was not repeat work in that sample. And inside major templates, that remainder was still diluted. More than 50% of product-detail crawling went to duplicate mobile URLs, while about 40% of category and listing crawling went to pagination. So before anyone celebrates crawl growth, they need to check where those requests landed and whether those URLs were canonical, indexable, and commercially meaningful.
Most crawler activity was repeat work. That was the real crawl-budget problem. editorial visualization
Where crawl budget goes to waste — Convertos.ai original workflow poster.
Where crawl budget goes to waste — Convertos.ai original explainer.
This original 34-second narrated explainer reduces the article to three checks: Inventory URLs, Verify in logs, Tighten discovery. It summarizes the article and does not carry essential claims that are absent from the text. Captions and a transcript are included for accessibility.
Video transcriptEcommerce sites waste crawl budget when bots spend time on filters, sorting pages, internal search, tracking parameters, and duplicate paths. The problem is not simply having many URLs. It is making low-value URLs easier to discover than products and categories that matter. Inventory the URL patterns first. Use server logs to confirm what Googlebot actually fetches. Then tighten internal links, parameter handling, canonicals, and sitemap rules. Measure the share of crawl activity reaching valuable pages again after two to four weeks.
Anonymous crawl allocation chart showing 82% revisits, over 39% parameterized URLs, over 50% duplicate mobile product crawl, and about 40% listing pagination
These shares have different denominators, but each identifies a large source of low-value crawl.

Four URL patterns consumed the crawl opportunity

The waste was not random. In the sampled snapshots, four URL patterns repeatedly pulled crawler time away from canonical, indexable pages that could actually rank: known-URL recrawls, parameterized URLs, duplicate mobile paths, and pagination. These figures come from limited observation windows, so they show concentration of activity, not controlled causation. They are still useful because each pattern points to a different generator and a different fix. First, the crawler kept returning to URLs it already knew. About 82% of crawler activity in the sample revisited known URLs instead of discovering net-new ones. That is only healthy when the revisits land on pages worth refreshing. If they land on duplicates, thin variants, or dead listings, crawl volume rises while useful coverage stalls. Google’s guidance for managing crawl budget for large sites makes the same point: the issue is not raw bot traffic, but whether crawling is focused on URLs that matter. Parameters were the clearest multiplier. More than 39% of crawler hits reached parameterized URLs. That suggests sort, filter, tracking, or session-like variants were being emitted into crawlable paths faster than canonical targets could absorb demand. On large catalogs, this is how one product or category becomes dozens of fetchable addresses. Google’s documentation on faceted navigation URLs exists for exactly this problem. Duplicate mobile paths created a second copy of product-detail demand. More than 50% of product-detail crawl activity went to duplicate mobile URLs rather than the preferred product URLs. That is not a mobile strategy. It is a crawl split. If half of product-detail fetching goes to alternates, the canonical set gets only the remainder before any other duplication is counted. Pagination did the same thing to category and listing pages. About 40% of category and listing crawl activity was absorbed by paginated URLs. In a later snapshot, non-200 category/listing URLs consumed 14% of crawl budget, up from about 9%, while the number of 4xx URLs found in the site structure grew 3.5 times. That combination is a warning sign because it shows the crawler spending more time on broken or low-value paths.
PatternShare seen in sampleWhat it displaced
Known-URL recrawlsAbout 82% of crawler activityDiscovery and refresh of priority canonicals
Parameterized URLsMore than 39% of crawler activityClean category and product URLs
Duplicate mobile product pathsMore than 50% of product-detail crawlPreferred product-detail canonicals
PaginationAbout 40% of category/listing crawlCore listing pages and valid deeper inventory

A rising crawl count can be a warning, not a win

A higher crawl count can look like progress in a dashboard. It can also mean URL hygiene is getting worse. In the later snapshot here, non-200 category and listing URLs took 14% of crawl activity, up from about 9% in the earlier snapshot. That is a 5 percentage point increase in crawler effort spent on pages that did not return a successful page load. Over the same comparison window, discovered 4xx URLs in the site structure increased 3.5x. These are snapshot comparisons, not a controlled experiment, so they show association rather than proof of cause. But they are strong warning signals because they show where the crawler actually went. The issue is not that crawlers ever touch error URLs. Some non-200 activity is normal on large sites. The problem starts when that share rises while commercially useful coverage does not. If a crawler is spending more requests on broken category paths, expired listings, or malformed variants, then a bigger total crawl number can hide a smaller share reaching canonical, indexable pages. That is why Google frames crawl budget as a question of whether Googlebot can spend time on the URLs that matter, not whether raw request volume is high in isolation. See Google’s official documentation and Crawl Stats.
SnapshotNon-200 share on category/listing crawlChange vs earlierDiscovered 4xx URLs in site structure
Earlier sampleAbout 9%BaselineBaseline
Later sample14%+5 percentage points3.5x
A practical rule helps: treat rising crawl volume as a risk when error discovery grows faster than useful URL coverage. On a large site, that can delay recrawl of pages that actually drive revenue.

Start with logs, then prove the URL rule

If crawl waste is suspected, start with raw request logs, not aggregate crawl charts. The job is to classify each bot hit by URL pattern and page intent, then test whether a generator rule is creating low-value demand. Pull a representative log sample, isolate verified Googlebot requests, and join each requested URL to six fields: status code, canonical target, indexability, page type, template or route, and business value tier. Google’s guidance on managing crawl budget for large sites is useful here because it treats crawl budget as a routing problem, not a vanity metric. A practical schema looks like this:
FieldExample valueWhy it matters
BotGooglebot SmartphoneSeparates search crawl from other automation
URL rule?sort=, /m/, ?page=Lets you test generator-level causes
Status200, 301, 404Quantifies wasted fetches and broken paths
Canonical stateself, other URL, noneShows whether crawl lands on the preferred URL
Indexabilityindexable, noindex, blocked, duplicateDistinguishes useful discovery from dead ends
Page typeproduct, category, pagination, searchConnects waste to templates
Value tierhigh, medium, lowPrevents equal treatment of unequal pages
Once that join exists, compare crawl share against page value. In one later snapshot from this case, more than 39% of crawler activity reached parameterized URLs, duplicate mobile URLs consumed more than 50% of product-detail crawl activity, and pagination absorbed about 40% of category and listing crawl activity. Those figures come from snapshots, not a controlled experiment, so they show concentration, not causation. But they are enough to test a generator hypothesis: if a route pattern repeatedly attracts Googlebot while resolving to duplicate, non-canonical, or low-value states, the template is manufacturing crawl demand. Use a simple decision rule: prioritize a URL rule when it takes a visible share of Googlebot requests and those requests often end on duplicate, non-canonical, blocked, or otherwise low-value pages. For faceted and parameterized paths, Google’s documentation on faceted navigation URLs gives the implementation guardrails, but the proof should come from your own logs. Logs show what Googlebot actually requested. The URL rule shows what the site kept generating.

Fix the generator before cleaning individual URLs

When repeat crawl dominates, deleting URLs one by one is usually the slowest fix. The better move is to stop producing low-value paths in the first place. In this case, the pattern-level waste was clear within the sampled snapshots: more than 39% of crawler activity hit parameterized URLs, duplicate mobile URLs took more than 50% of product-detail crawl activity, and pagination absorbed about 40% of category and listing crawl activity. Those shares do not prove causation across all periods, but they are enough to set engineering priority. If a template, link module, or routing rule keeps generating these paths, manual cleanup will be overwritten by the next deploy. Start where the site creates discoverability. Internal links matter more than isolated URL removals because they teach crawlers what exists and what deserves revisits. If filters, sort orders, session-like parameters, or alternate mobile paths are linked from navigation, cards, breadcrumbs, or faceted controls, the crawler will keep finding them. Google’s guidance on faceted navigation URLs and consolidate duplicate URLs points in the same direction: reduce crawlable combinations, consolidate duplicates, and make the preferred URL the easiest one to discover. Rank generators by recoverable crawl share, not by how messy the URLs look.
Generator to fixEvidence from sampled snapshotsWhy it goes firstTypical rule change
Mobile duplicate product URLsMore than 50% of product-detail crawlHigh-value template, direct collision with canonical product crawlRemove crawlable alternate mobile paths; unify internal links to one canonical product URL
Parameterized URLsMore than 39% of total crawler activitySitewide waste across many templatesBlock unnecessary parameter generation in links and forms; keep only required crawlable states
PaginationAbout 40% of category/listing crawlLarge recurring drain in listing templatesLimit deep crawlable pagination and reduce linked page combinations
Error-producing category/listing templatesNon-200 share rose from about 9% to 14%; 4xx URLs in structure grew 3.5xWaste is increasing, so the generator is still activeFix broken link logic, retired nodes, and error templates exposing dead paths
SitemapsFast way to stop re-advertising low-value URLsInclude only canonical, indexable 200 URLs
The decision rule is straightforward: fix generators that control a meaningful share of crawl in commercially important templates before touching individual URLs. The later snapshot makes the case stronger because non-200 category and listing URLs rose from about 9% to 14%, while 4xx URLs exposed in the site structure grew 3.5 times. That is not just cleanup debt. It points to a production source still emitting bad paths.

Measure where crawl moved after the release

The release is not validated by a lower crawl count. It is validated when crawl shifts toward canonical, indexable, commercially important URLs. Keep the scorecard small enough to review weekly from logs, Search Console, and sitemap exports. Four measures usually tell the story: useful-crawl share, discovery latency for new priority URLs, indexable coverage of priority templates, and ranked or clicked outcomes on the same URL set. Google’s guidance on managing crawl budget for large sites supports that framing: the goal is not more fetching, but better fetching.
MetricHow to calculateWhy it mattersRecording field
Useful-crawl shareGooglebot hits to canonical, indexable priority URLs ÷ all Googlebot hitsShows whether crawl moved away from wastePre-release: ___ / Post-release: ___
Discovery latencyTime from first internal link or sitemap inclusion to first Googlebot hit on new priority URLsTests whether important new pages are found fasterPre-release: ___ / Post-release: ___
Indexable coveragePriority URLs returning 200, self-canonical, not blocked, and eligible for indexation ÷ all priority URLsSeparates crawl improvement from template or status-code defectsPre-release: ___ / Post-release: ___
Search outcome ratePriority URLs with impressions, rankings, or clicks ÷ crawled priority URLsChecks whether better crawl reached pages that can performPre-release: ___ / Post-release: ___
The worked example is the one that matters. In the observed snapshots, about 82% of crawler activity revisited known URLs, more than 39% reached parameterized URLs, duplicate mobile URLs took more than 50% of product-detail crawl activity, and pagination absorbed about 40% of category crawl activity. Those figures come from limited snapshots, not a controlled test, so treat them as directional. If a release reduces those waste patterns, useful-crawl share should rise even if total hits stay flat. Do not stop at logs. Pair the shift with coverage and outcome checks. If non-200 category and listing URLs still consume 14% of crawl in a later snapshot, up from about 9%, or if 4xx URLs in the site structure have grown 3.5 times between snapshots, the generator is still leaking crawl opportunity. Use Crawl Stats to confirm host-level changes, but judge success on the priority URL set. The concrete decision is this: if useful-crawl share does not rise while non-200 share and discovered 4xx exposure stay elevated, keep work focused on generator-level fixes rather than individual URL cleanup. Keep the retest on the same cohort in the SEO audit workflow; the Convertos SEO guides can then guide the page-level follow-up without changing the baseline.

Disclosure

The case data comes from a private 2026 operating review of a large cross-border marketplace. It is reproduced with permission after company, vendor, domain, system, and personnel identifiers were removed. The figures show association, not controlled causation.

Need practical guidance?

Talk to me about your SEO / GEO bottlenecks

Reach me by email, WeChat, or LinkedIn. I can help you prioritize issues and suggest a practical first step.

Email: Send emailWeChat: 15765565449LinkedIn