A continuous SEO audit that admits when crawl budget cannot finish the site

This post describes TrustGrowth's current continuous-audit coverage model as configured on the dates stated below: guaranteed-fresh page ceilings, inspection windows, and disclosed best-effort scanning above the ceiling. It does not measure ranking impact, traffic outcomes, or any customer result, and it does not claim the public pricing page currently prints these numbers.

Terms defined on first use

Crawl budget is the portion of a site's pages a scanning system inspects within a given time window, distinct from the total number of pages that exist. Google documents the same idea for its own crawler in Managing crawl budget for large sites. Guaranteed-fresh coverage is the number of pages a plan commits to re-inspecting within its stated window; it is not a claim about pages beyond that ceiling. Inspection window is the fixed number of days within which the guaranteed-fresh page count is re-scanned. Best-effort scanning is additional inspection of pages above the guaranteed ceiling, run on idle capacity, with no completion guarantee.

The problem a fixed daily budget creates

Here is a labelled historical example of the old configuration, not current product behaviour, and not a measured result from a named customer. Take 17,000 indexable pages and a flat budget of 100 pages scanned per day: 17,000 divided by 100 is 170 days to finish one pass (Google crawl-budget documentation is the external reference for why a bounded budget exists at all). By the time that pass ended, the earliest pages would already sit outside a useful freshness window. That arithmetic is why the coverage model was redesigned. Do not size your own property against those two numbers.

The issue was not the figure 100 on its own. A flat per-day rate applied to a growing property has no defined end state: no ceiling to reach, and no window in which reaching it was promised. Pages could be added faster than the daily rate cleared them, and the audit had no way to say so. It kept scanning, without an end state, without telling you that fact in the output.

Why a louder coverage claim does not solve this

A broader scanning promise does not fix an undisclosed limit; it moves the same gap somewhere less visible. If a tool tells you it scans more pages without stating the ceiling and window that broader scanning operates under, you are left assuming completeness by default, because the report does not say otherwise.

That matters if you have to defend your own audit numbers to a sceptical stakeholder. If someone asks whether the audit checked a particular page and the honest answer is that the report does not say, that gap is hard to defend under questioning. An audit that cannot state what it has not yet inspected cannot be cited as evidence about the pages it has not inspected. The alternative is a bounded claim: state the ceiling, state the window, and label everything outside that boundary as unmeasured rather than implicitly passed.

The current coverage model

The five ceilings below are TrustGrowth's own product catalog configuration, dated 21 August 2026.

Plan Page ceiling Inspection window Date captured Free 5,000 pages 30 days 21 August 2026 Starter 10,000 pages 14 days 21 August 2026 Pro 25,000 pages 7 days 21 August 2026 Growth 50,000 pages 7 days 21 August 2026 (catalog) Admin unlimited n/a 21 August 2026

Each row states two things together, as a freshness entitlement should: how many pages, and how frequently they are re-inspected within your plan.

Separately, the scanner processes pages in cycles governed by a setting called CYCLE_BATCH=250, from TrustGrowth's own product catalog configuration dated 21 August 2026: the number of pages worked through per cycle. This is a per-cycle inspection slice, not a pages-per-day budget, and the two should not be read as equivalent.

What scanning above the ceiling means, and does not mean

Pages beyond your plan's page ceiling are not necessarily left unscanned. They may be picked up through best-effort scanning: inspection run on idle capacity, above the plan entitlement, when capacity allows.

This is disclosed as best-effort, not promised. There is no completion timeline attached, and no commitment that a given page above the ceiling will be scanned within any particular cycle, or at all. Best-effort scanning is additional opportunity, not additional entitlement. It is not a coverage promise, and it says nothing about whether scanning a page changes that page's standing.

What the audit is willing to admit

The audit-scoring FAQ, fetched 25 August 2026, states this.

Does the audit re-crawl my whole site every time?

"No. Autopilot revisits a bounded set of pages on your plan's freshness window, so the entitlement is two things — how many pages, and how fresh — not a single cadence word. The plan rows above this FAQ render the current figures." (audit-scoring FAQ, fetched 25 August 2026)

What happens when a check cannot run?

"It is reported as unmeasured — never as a pass, never as a failure." (audit-scoring FAQ, fetched 25 August 2026)

Is the audit free?

"Paid plans widen the page budget and shorten the freshness window; they do not unlock checks that Free is denied." (audit-scoring FAQ, fetched 25 August 2026)

These three quotes are the public disclosure artifact this post is built around. The first quote's last sentence refers to plan rows on that page; as of the 25 August 2026 fetch those rows render qualitative tier language, not the numeric ceilings in the table above. No in-product coverage meter or live coverage API payload is described here, because none was available to inspect on the fetch day. This disclosure is a statement of what the product will and will not claim about its own coverage.

It is not a ranking or traffic result.

Method

On 25 August 2026 we fetched https://trustgrowth.ai/features/audit-scoring and copied the three FAQ answers quoted above verbatim. The same day we fetched https://trustgrowth.ai/proofs/trustgrowth and opened the public pricing page, which describes the tiers as essential, expanded, advanced, and extensive. The five ceilings in the table above are TrustGrowth catalog configuration dated 21 August 2026. That fetch, that pricing-page check, and that catalog reading are the inspection behind this post. We did not crawl a large customer property for this article, and we did not receive a live coverage-progress API response. None of this is a third-party benchmark.

TrustGrowth also publishes dated measured figures for its own property, for example a proofs-page score of 36 for trustgrowth.ai on 25 August 2026 (public proof page). That score is an example of TrustGrowth's practice of dating and publishing first-party figures for its own property. It is not evidence for the coverage ceilings or FAQ claims described above.

Limits of this measurement

The claims in this post are configuration and disclosure facts, not ranking or traffic claims. They describe what the product commits to scanning and what it says about the rest.

As of 25 August 2026, neither the public pricing page nor the audit-scoring page prints the numeric ceilings in the table above, and the audit-scoring plan rows render qualitative tier language.

A request to GET /api/v1/sites/trustgrowth/audit_progress returned HTTP 404 on 25 August 2026, so this post does not describe a live coverage-progress payload. https://trustgrowth.ai/methodology documents the score formula: how a score is calculated from what has been measured. It does not document which pages were scanned, and it is not the source for the ceilings in the table.

The 17,000-page, 100-pages-per-day example earlier in this post describes an old configuration, not current behaviour (Google crawl-budget documentation). It is included as historical context for why a bounded, disclosed coverage model replaced a flat daily rate.

How to read your own property against the table

Pull your current indexable page count (Search Console's Page indexing report, or your own sitemap URL count if you do not have Search Console). Then look up your plan's row in the table above. Two comparisons matter, and they are independent:

1. Count versus ceiling. If your indexable count is at or under the page ceiling, every page can sit inside the freshness entitlement for that plan. If your count is above the ceiling, the surplus is best-effort territory. The product does not treat that surplus as already covered.
2. Window versus how often you need a page re-checked. A 30-day window and a 7-day window are different commitments even at the same page ceiling. A page inside the Free ceiling is re-inspected on a longer cycle than the same page on Pro.

Worked arithmetic, using only the catalog figures dated 21 August 2026. A 12,000-page property on Starter (10,000 pages / 14 days) has 2,000 pages in best-effort territory. The same property on Pro (25,000 pages / 7 days) sits inside the plan ceiling, and those pages are re-inspected on a shorter window.

That is a configuration comparison, not a ranking or traffic prediction.

If you cannot name which of your URLs sit above the ceiling, you cannot defend the audit as inspected for those URLs. Label them unmeasured until they are inspected. That is the same rule the audit-scoring FAQ already states for a check that cannot run.

Close

Compare your own indexable page count against your current plan's page ceiling and inspection window in the table above, and mark which of your pages sit in best-effort territory rather than assuming they are already covered.