A broken link that opens fine. A healthy page that Google treats as missing. A count of exactly 100 issues that never goes down. Every one of these can appear in an honest report — and every one usually means something less dramatic than it looks.
All three of the findings in this article turned up when we ran a site checker against our own site — real pages, real links, real data. That is worth saying up front, because none of them appears in a synthetic test. A demo site does not link to third parties with bot protection, does not have expired listings answering 200 OK, and does not have more problems than a result cap can hold. Real data surfaces what synthetic tests never do — and it surfaced that the scariest-looking lines in a site report are frequently the most benign. Here is each one, what it usually means, and the thirty-second check that tells you which case you are in.
Is a 403 on a linked page a broken link?
Often it is not. A 404 means the page is gone, and a link pointing at it is genuinely broken. A 403 means the server refused to answer, and servers routinely refuse automated requests while serving the same page happily to a person. Many sites sit behind bot protection that turns away anything that does not look like a browser, so the crawler behind your report was stopped at the door while the link itself works perfectly. Before you remove a link flagged with a 403, open it yourself.
The distinction is worth keeping precise, because the two status codes tell opposite stories. A 404 is the building saying the flat does not exist. A 403 is a doorman: the flat is there, the resident is home, but this particular caller was not let in. Link checkers are exactly the kind of caller doormen exist to refuse — they arrive without the fingerprint of a real browser and ask quickly and repeatedly, so the protection service in front of the target site answers 403 to all of it. Nobody on either end has done anything wrong.
This matters because the natural response to a "broken link" finding is to delete the link, and deleting a working link is a real cost: your reader loses a reference, the target site loses a visitor, and you lose whatever the link was doing for the page. We have written before about what genuinely broken links cost a business — the point here is the mirror image. The finding deserves attention; the automatic fix does not.
The check takes seconds. Open the flagged URL in an ordinary browser tab. If the page loads, the link is fine and the 403 was the doorman doing its job against a crawler. If you also get refused, or land on a page that no longer says what you linked it for, there is something real to act on. A tool that is honest about this says so in the finding itself: checked as a crawler, may differ in a browser.
What is a soft 404?
A soft 404 is a page that answers 200 OK while its content tells the visitor there is nothing here — an empty search result, an expired listing, a category page showing zero products. A tool that trusts the status code counts it as a healthy page. Google reads the content, concludes the page is effectively not found, and quietly drops it from the index. The check is to read the page the way a visitor would, rather than trusting the number the server sent.
Notice that this is the first finding turned inside out. The 403 was a page that looked broken and was fine; the soft 404 is a page that looks fine and is broken — at least in the sense that matters for search. The status code and the content disagree, and different observers believe different halves. Uptime monitors and simple crawlers believe the code, so the page passes every automated health check you point at it. Google believes the content, because Google's job is to send people to pages that answer them, and a page that says "no results found" answers nobody.
How does a site end up with these? Almost never through negligence. A shop marks a product as discontinued and the page politely says so instead of returning 404. A listings site lets adverts expire but keeps the URL. In each case the site is behaving reasonably towards its visitors; it has just left the server answering "success" for a page whose content now says the opposite.
The consequence is quiet rather than catastrophic: the page falls out of the index without any error appearing anywhere, and whatever traffic it earned goes with it. If a page you care about has gone missing from search results, this is one of the first things to rule out — checking whether a page is actually indexed takes a minute and tells you whether you are looking at a soft 404 or something else entirely. The human check is the same as before, pointed the other way: do not ask what the server said, ask what the page says. If it reads as "nothing here" to you, it reads that way to Google.
Why does my site report say exactly 100 issues?
Because a suspiciously round number is very often the tool's limit, not your total. Many checkers stop collecting at a fixed cap — the first 100 pages, the first 100 results — and then report the cap as if it were the count. The real number may be far larger. Worse, fixing twenty of the listed issues does not move the reported number, because the next twenty simply fill in from beyond the cap. When a figure looks like a ceiling, ask whether it is one.
Caps themselves are sensible engineering — no tool should crawl an unbounded site forever. The problem is purely in the presentation: "100 issues" and "the first 100 of an unknown number of issues" are different claims, and a report that shows the first while meaning the second has told you something false without containing a single false row. Every finding in the list may be accurate; the total is the fiction.
The refilling behaviour is what makes this one genuinely corrosive, because it punishes exactly the person who acts on the report. You spend an afternoon fixing twenty broken references, re-run the check, and the number still says 100 — so honest work looks like it achieved nothing. Some people conclude the tool is broken; others that the site is beyond saving. Both are wrong: the number was never a measurement of the whole, so it could not move until the true total dropped below the cap.
You cannot see a cap from inside a single report, but you can test for one. A number that lands exactly on 100, 500 or 1,000 deserves suspicion on sight. A number that stays identical after real fixes is close to proof. And the tool's own wording settles it: an honest report says "first 100" or "at least 100", keeps a separate count of how much it examined, and tells you when a list was truncated. A report that presents a round number without qualification has either measured everything — or stopped counting and not said so.
Should I act on a site report without checking it?
No — not on the report alone. A finding is a claim, not a verdict: it records what a tool observed under the tool's own conditions, and those are never quite the conditions of your visitors or of Google. Verify as a human before acting, prefer tools that state their own limits, and never bulk-delete or bulk-fix on the strength of a list. The findings that survive a human look are the ones worth your afternoon.
This is the lesson the three findings share, and it cuts in both directions. The 403 shows a tool seeing a problem where a human sees none. The soft 404 shows a tool seeing health where Google sees a gap. The capped list shows a tool telling the truth row by row and still leaving a false impression in total. None of these is the tool lying — it is the tool answering a narrower question than the one you are asking, which is the same reason vulnerability scanners report findings that turn out to be false positives: an automated observer reports what it can see from where it stands, and where it stands is not where you stand.
The practical rules that fall out of this are short. Open the thing before you delete the thing. Read the page, not the status code. Treat round numbers as questions rather than answers. And when choosing tools, favour the ones that narrate their own blind spots — "checked as a crawler; may differ in a browser", "list truncated at 100" — because a tool that admits what it cannot see is the only kind whose findings you can safely act on quickly.
What to do this week
Take whichever site report you last received and re-read it with these three patterns in mind. Separate the 403s from the 404s before touching any links, and open the 403s in a browser. Pick a handful of your quietest pages and read them as a stranger would — if any of them says "nothing found" while answering 200 OK, you have found a soft 404. And look at the totals: if any of them is suspiciously round, fix a few items and see whether the number moves.
TrustCtrl was on both sides of this story — it is our own checker that surfaced all three findings on our own site, and it now reports each of them with the caveats this article argues for: link checks distinguish "gone" from "refused a crawler" and say when a browser may see something different, soft 404s are flagged by reading the content rather than trusting the status code, and every truncated list says it is truncated. A finding should arrive with its evidence and its limits attached, so that the thirty-second human check is easy — and so that the report earns the trust it asks for.