Noindex checker, canonical checker, server header checker and cache checker, the four readings that say whether a page can be indexed at all

Four free checkers answer one question between them, and the question is whether a given page is allowed into a search index at all. A server header checker tells you what status code the page returns and what rules travel in the response. A noindex checker tells you whether the page carries an instruction not to be indexed. A canonical checker tells you which address the page nominates as the real one. A cache checker tells you what a search engine last held. Run them in that order, because each one can make the next irrelevant.

Google reports 70 searches a month in the United Kingdom alone for "noindex checker" and 70 for "url link checker", with 30 each for "canonical url checker" and "server header checker", harvested on 22 October 2026 against the United Kingdom target on its own.

The one rule that decides the order

Google's documentation on blocking indexing, read at developers.google.com on 22 October 2026, carries the sentence that explains why these four tools have to be run in sequence: "for the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler."

Read that twice, because it is counterintuitive and it costs people weeks. A page blocked in robots.txt cannot be crawled, so the instruction inside it is never read. If you want a page out of the index, it has to be reachable in order to be told to leave. If you block and noindex at once, you have given an instruction to a crawler you have also refused entry to. For the cases a parser has to get right before you trust any robots file, including your own, see four robots.txt cases a parser has to get right.

The four readings, in the order to take them

Reading	What the tool reports	What a bad answer means
Server header	The status code, any redirect chain, the content type, and rule carrying headers	A 404, a 500 or a chain of redirects. Nothing below this matters until it returns 200
Robots rule	Whether robots.txt allows the path	Blocked, in which case no instruction on the page is ever read
Noindex	Whether a robots meta tag or an X-Robots-Tag header says noindex	Noindex present on a page you want indexed, which is usually left over from staging
Canonical	Which address the page nominates	A canonical pointing at the home page or at a different page entirely

The third row has a trap in it that catches experienced people. The noindex rule can be set in the page markup or in the HTTP response headers, and only one of those is visible in your browser's view source. A page that looks perfectly clean in the markup can be carrying a noindex in its headers, put there by a server rule or a content delivery network, and the only tool that finds it is a server header checker. That is why the header reading comes first.

The canonical faults worth knowing by shape

A canonical checker gives you one address. What makes it useful is recognising which of five shapes you are looking at.

• Self referencing. The page names itself. This is the normal, healthy answer for a standalone page.
• Pointing at the home page. Almost always a template or plugin default that nobody changed, and it is the one that quietly empties a whole section out of search. If one page on a site has this, check the template rather than the page.
• Pointing at a parameter stripped version. Correct and deliberate on filtered or sorted listings, where you want the clean address to be the one that counts.
• Pointing at a page that redirects. A chain, and it weakens the signal. Point at the final destination.
• Missing entirely. Not a fault by itself. Google will pick an address. It becomes a fault the moment the same content is reachable at two addresses, which on a real site happens sooner than anybody expects.

How Google chooses between candidates when the signals conflict is a separate subject and it is set out in canonical tags and duplicate content.

What a cache checker is still good for

Google retired the public cache link from its results, so the old habit of clicking through to see the stored copy has gone. What remains useful is the underlying question, which is what a search engine currently holds for your address rather than what you published. The first party answer now comes from the URL inspection tool inside Search Console for a property you own, and that tool reports the crawl date, the page's indexing status and the canonical Google actually selected, which is often the single most useful line on the screen because it can differ from the one you declared.

Third party cache checkers mostly query whatever index they can reach, so treat the result as evidence about that index. For a site you do not own, the Internet Archive is the more honest answer to the same question, because it tells you the date of the copy it is showing you.

Where the link checkers fit

A url link checker and a broken link finder are the same job at two scales. One address, or a whole site. Both crawl the links they find and report the status code each one returns, and the outputs worth acting on sort into three groups.

• Internal links to pages returning 404. Fix these first, every time. They are entirely within your control, they waste crawl effort, and each one is a reader who hit a dead end on your own site.
• Internal links through a redirect. Not urgent, but worth a pass before a migration. Point the link at the destination and the chain disappears.
• Outbound links to pages that have gone. A page citing six sources where two are dead reads as unmaintained to a human and offers nothing to a machine reading the page for its references.

One caution on the reports. Plenty of sites return 403 or 405 to an unfamiliar crawler while serving a browser perfectly, so a link flagged dead by a tool deserves a click before you remove it. If you want checkers whose logic you can read rather than infer, the projects and what each one actually inspects are listed in open source SEO audit tools, what each project checks.

Questions about indexability checkers

My page has noindex and is still in Google, why

Either the page is blocked in robots.txt, so the instruction was never read, or the crawler has not returned since you added it. Google's documentation states the rule only works if the page is not blocked and is otherwise accessible. Unblock the path, confirm the page returns 200, then request a recrawl.

Where else can a noindex rule hide

In the HTTP response headers, as an X-Robots-Tag. That one is invisible in view source and is often set by a server configuration or a content delivery network rather than by anything in your site's code. A server header checker is the tool that finds it.

Should every page have a canonical tag

A self referencing canonical on every page is a reasonable default and costs nothing. It matters most where the same content is reachable at more than one address, which on any site with filters, search results, tracking parameters or a print view is already true.

Can I still see Google's cached version of a page

The public cache link has been retired. For a site you own, the URL inspection tool in Search Console reports the crawl date, the indexing status and the canonical Google selected. For a site you do not own, the Internet Archive answers the same question and tells you the date of the copy.

How often should I run a broken link check

Monthly on a site that publishes regularly, and always before and after a migration. The before run gives you the list to redirect. The after run tells you which redirects you missed, and that comparison is the whole value of running it twice.

Does a 403 from a checker mean the link is broken

No. Many servers refuse unfamiliar crawlers while serving browsers normally. Treat 403 and 405 as unknown rather than dead, and open the link yourself before you edit the page.

A fifth reading, on a surface with no status code

These four tools all answer versions of one question, which is what a crawler is permitted to see. There is now a reader with no crawler and no status code to report. When somebody asks an assistant about the thing your page covers, it writes a short answer and names a company or two, built out of whatever it has read about the subject. A page can return 200, carry a clean canonical, pass every check on this list and still take no part in that answer, because being crawlable and being chosen are two separate outcomes. The reading that matters there is which companies the assistants name for your category when your own name is kept out of the question. AI Knows Us puts those buying questions to the main assistants and records who gets named and the sources each answer was assembled from.