A caveat is not a gate

By Matt Kerr·Published 18 September 2026

An audit flags a page. You read the finding, and halfway down its own advice is a sentence explaining that your case is probably fine. The tool knew the exception, wrote it down, and reported you anyway — leaving you to filter its list by hand. A caveat is not a gate, and a finding that needs one has not finished being written.

Nearly every flagged page was correct

On an insurer's site, twenty-one of twenty-five crawled pages were reported as blocked from indexing, at the second-highest severity. Every one was a form confirmation sitting under a thank-you path — pages that are supposed to carry noindex, because nobody should arrive at a confirmation from a search result.

The check's fix text already said so, in those words: legitimate noindex targets such as cart, checkout, thank-you and internal search results are fine. So the tool had the rule. It simply did not apply it before deciding what to report.

The cost is not the reading time. Reporting correct pages at high severity teaches somebody to skip the check — and a skipped check costs more than the occasional real noindex it would have caught, because the real one is the whole reason the check exists.

The advice that would have removed working signals

A week earlier, in a different part of the same tool, the same defect. A retailer with many shops publishes a phone number beside each branch address on its store locator. That is correct practice, and it is how a search engine matches each branch to its listing.

The check counted the numbers, called the site inconsistent, and advised using one number site-wide. Following it would have deleted the per-branch numbers that local ranking depends on. And once more, the finding's own text had already conceded the case: separate department or location numbers are fine.

The repair in both places was the same — turn the sentence into a condition. Before reporting a noindex page, check whether its URL is one of the paths where noindex belongs. Before reporting several phone numbers, check whether the site has several sets of premises.

When a caveat is the honest answer

This is the distinction that makes the rule usable, and it is why "never write a caveat" would be wrong advice.

The same check reports a local business with no street address at a lower severity, with its caveat stated plainly — because a service-area business legitimately has no address, and nothing in the markup can tell the two apart. There is no condition to write. Stating the limit and lowering the severity is the honest thing to do.

So the test is not whether an exception exists. It is:

• Can the tool detect the exception? A URL segment, a store locator, a second address, a noindex on a checkout path — all detectable. Then it must be a gate, and a finding that fires anyway is a defect.
• Or is the exception invisible from the outside? Then a stated caveat at a lower severity is correct, and the reader is the one who can resolve it.

A caveat at high severity is the combination that should not exist — it is a tool saying "this is urgent, and it may not apply to you" in one breath.

The detail that makes a gate work or fail

Worth a paragraph because it is where these fixes usually go wrong. The list of paths where noindex belongs is matched against whole URL segments, with any file extension stripped first. Both halves were paid for:

• Substring matching is too greedy. Matching path fragments anywhere in a URL put six local-business findings on a video editing site, because the fragments appeared inside longer words.
• Extensions hide the segment. A path ending in .html is not the word before it until the extension comes off, which only surfaced when a test served a real file rather than a tidy path.

Reading this on your own report

• Read the fix text before the headline. If it contains "are fine", "legitimate", "unless" or "separate … are fine", check whether your case is the one it names. If it is, the finding is wrong and no work is owed.
• Look at what fraction of the flagged pages are exceptions. When nearly all of them are, the finding is describing your site's design rather than a fault in it.
• Do not silence the check — check the residue. In the insurer's case four pages were not confirmations, and those four were the only ones worth a minute.

When the finding is real and urgent

Keep the severity in view. A noindex on a page that should rank is one of the most expensive single defects there is, because the page is invisible while looking perfectly healthy to a visitor. The cases that matter:

• Noindex on a product, service or article page — usually left over from a staging environment.
• Noindex on a whole section, which is a template-level mistake and therefore one edit. For why the count in that finding is not the number of fixes, see when a finding blames the whole site →.

And the opposite problem is real too: utility pages that are missing their noindex and end up competing with your own content — stop indexing site search and cart pages →. Both pages are about the same set of URLs; the question is only which way round yours are wrong.

The fixes that make it worse

• Removing noindex from confirmation pages to clear the finding. You have added a set of thin, duplicate, un-navigable pages to the index to satisfy a false positive.
• Collapsing branch phone numbers to one. The finding was wrong and the fix is subtractive — see also when "regenerate your sitemap" is wrong →.
• Turning the check off. Which is what the tool is training you to do, and the reason this defect is worth naming rather than tolerating.

Where this sits in an audit

The registered checks are index.noindex, which covers pages blocked from indexing, and local.nap, which covers name, address and phone consistency. Both now gate on the exception their own advice describes.

Common questions

My audit flags my thank-you pages as blocked from indexing. Is that a problem?

No. Confirmation, cart, checkout and internal search pages are supposed to carry noindex. A tool that reports them has not applied the exception its own advice describes.

Should a multi-branch business use one phone number everywhere?

No. A number beside each branch address is correct practice and is how each location gets matched to its listing. Collapsing them to one removes a signal rather than tidying it.

Is it ever right for a finding to state a caveat instead of filtering?

Yes, when the exception cannot be detected from the outside — a service-area business with no street address, for example. Then the honest form is a stated limit at a lower severity.

How do I tell a false positive from a real noindex problem?

Look at what kind of page it is. Confirmation and utility paths are correct; a product, service or article page carrying noindex is one of the most expensive defects there is.

Should I turn off a check that keeps flagging correct pages?

No, but do not work through its list either. Read the residue — the flagged pages that are not exceptions — because those are the only ones the check was really for.