Direct answer
If an SEO audit tool can't load one of my pages, what happens to that page in the report?
In a well-built audit, the failure itself is recorded as evidence — categorized as an HTTP error, timeout, network error, invalid content, or unknown failure — rather than the page being silently skipped or counted as passing. A page that couldn't be inspected is a different finding from a page that was inspected and found clean.
01
A silently dropped page can look identical to a page that passed every check, unless the failure is recorded explicitly.
02
Fetch failures fall into distinct categories, and the category often points directly at the cause.
03
This is the same 'absence of evidence isn't evidence of absence' principle that shows up in AI visibility testing.
Every website crawl hits pages it can't load. The interesting question is what the tool does next.
A server times out. A page returns a 500 error. A network hiccup interrupts the request halfway through. These things happen constantly, at scale, to every crawler that has ever existed. The difference between a trustworthy audit and a misleading one isn't whether these failures occur — it's whether the tool tells you about them.
The silent-drop problem
Imagine an audit crawls 50 pages on your site. Forty-eight load fine. Two time out. If the tool simply excludes those two from the report, you're left looking at a summary of 48 pages, with no indication that two pages exist that were never actually checked. The report might say "no structured-data issues found" when what it really means is "no structured-data issues found on the pages we managed to load."
Those are very different claims. The first sounds like a clean bill of health. The second is an honest description of a partial result — and if the two pages that failed happen to be your pricing page and your main integration doc, the gap matters a lot more than the wording suggests.
Why the type of failure is worth recording, not just the fact of it
Not all fetch failures point at the same problem. An HTTP error usually means the server itself returned something unexpected — a real, fixable issue on your end. A timeout can mean the same page is simply slow, or that something transient interfered with one request. A network error might have nothing to do with your site at all. Invalid content — a response that came back but wasn't parseable as a real page — suggests something different again.
Lumping all of these into one generic "couldn't check this page" bucket throws away information that would otherwise point you toward the cause. Keeping them distinct means a repeated pattern — say, every product page under one URL path returning the same HTTP error — becomes visible as a pattern, instead of getting lost in a pile of unexplained gaps.
The same principle, in a different place
This is the same idea that matters when an AI visibility test fails to return an answer: a check that didn't complete is not the same finding as a check that completed and came back clean. We cover that version of the same problem in Unavailable Isn't the Same as Not Mentioned. Whether it's a page a crawler couldn't load or a prompt an AI assistant couldn't answer, the underlying rule doesn't change: absence of evidence is not evidence of absence, and a report that treats them as the same thing will eventually mislead you.
It also matters for the same reason a single domain-wide score can hide real problems — a report needs to be honest about its own scope, whether that scope is limited by an aggregate average or by pages it simply never managed to reach. More on that in Why One SEO Score for Your Whole Website Doesn't Tell You Much.
A gap should look like a gap
Growthract preserves fetch failures instead of dropping them.
A page that couldn't be inspected is reported as exactly that, categorized by failure type, so it never gets mistaken for a page that passed.
A couple of follow-up questions
Does a fetch failure always mean my page is broken?
No. It could be a one-off timeout unrelated to your site. It's worth re-checking before assuming a real problem, which is easier to do when the failure is recorded clearly the first time.
How would I even notice a page was silently dropped?
You usually wouldn't — that's exactly the risk. The number of pages a report claims to have checked is worth comparing against how many pages your site actually has.
Continue exploring
Related insights
Case study
A public technical audit of growthract.com covering 49 production HTML pages, crawler access, robots.txt, sitemap integrity and legacy routes — with the limits of the evidence stated explicitly.
See the case study →
Insight
A single number for your whole website's SEO health sounds reassuring. It's also usually hiding the one or two pages that actually matter.
Read the insight →
Insight
A missing schema type on a self-serve free tool and the same gap on an enterprise sales page aren't the same problem. Here's why business context changes how evidence should be read.
Read the insight →