Start here if a page won't appear in Google
A URL has to clear three gates before Google will index it. It must return a 200, it must not carry a noindex directive, and its canonical tag must point at itself rather than somewhere else. Fail any one of them and the page will not rank, however good the content is.
Paste the URL above and the scan reports all three at once, so you can tell in a few seconds which gate is closed — and rule out the other two.
What the scan actually reads
The scanner requests your URL the way a search engine would — logged out, following each redirect manually so every hop stays visible. It then reports exactly four things. All of it is read from the live response; nothing is inferred.
| Signal | Where it comes from | Why it blocks indexing |
|---|---|---|
| HTTP status | The response line, plus every redirect hop and the final URL | Only a 200 is indexable. A 301 moves the signal elsewhere; 404, 410, and 5xx remove the page entirely. |
| Robots meta tag | <meta name="robots"> in the rendered <head> |
A noindex value tells Google to drop the URL on its next crawl. |
| X-Robots-Tag | The HTTP response header | Same effect as the meta tag, but invisible in "View Source" — the reason this bug survives so long. |
| Canonical link | <link rel="canonical"> in the rendered HTML |
If it names a different URL, Google indexes that one and treats this page as a duplicate. |
The scan also follows internal links and repeats the same four checks on up to 10 pages — which is how you catch a directive applied to an entire post type rather than a single URL.
The four causes, in the order they actually occur
1. "Discourage search engines" was never unticked
WordPress ships a checkbox at Settings → Reading that adds noindex across the entire site. It exists for sites under construction, and it is the single most common reason a freshly launched site gets no traffic — the launch checklist misses it and nobody notices for weeks.
How it shows up here: a noindex finding on every scanned URL, not just one. If the whole crawl comes back noindex, check this box before anything else.
Fix: untick it, then request indexing for your key URLs in Search Console rather than waiting for the natural recrawl.
2. An SEO plugin is noindexing a whole post type
Yoast, Rank Math, and SEOPress all expose per-post-type and per-taxonomy indexing switches. The defaults noindex some archives deliberately, which is often correct — but the same screens make it easy to noindex a custom post type you actually want ranking, and one toggle silently affects hundreds of URLs.
How it shows up here: noindex on one section of the site while the homepage stays clean.
Fix: in Yoast, Search Appearance → Content Types; in Rank Math, Titles & Meta. Change the setting, then re-run this scan against the live URL to confirm the tag actually changed in the served HTML.
3. An X-Robots-Tag header set at the server
This is the one that wastes days. A noindex can be sent as an HTTP header from .htaccess, an Nginx block, or a CDN rule — and because it never appears in the page source, developers check the HTML, see a clean robots meta tag, and conclude indexing is fine. Staging environments are the usual origin: the rule gets added to keep staging out of Google, then travels to production during a migration.
How it shows up here: a noindex finding whose evidence is a header value rather than a meta tag.
Fix: grep your server config for X-Robots-Tag, and check the CDN's header rules separately — a header injected at the edge will not appear in any file on the origin server.
4. A canonical tag pointing at the wrong URL
This one does not block crawling, so the page looks healthy in every other respect — it simply never accumulates its own ranking signals. It usually happens when two systems both write a canonical: an SEO plugin plus a page builder, or a second SEO plugin whose settings survived an incomplete uninstall. A migration that leaves canonicals hardcoded to the old domain produces the same result.
How it shows up here: a canonical finding whose value is not the URL you submitted, or a missing-canonical warning.
Fix: identify which plugin emits it before changing anything — overriding one canonical while a second system still writes its own leaves you with two, which is worse than one wrong tag.
Reading the result
- Every URL noindexed → a site-wide switch. Settings → Reading, or a server header. Check those two before touching plugin settings.
- One section noindexed → a post-type or taxonomy rule in your SEO plugin.
- Clean robots, wrong canonical → the page is crawlable but is handing its ranking to another URL. Find the duplicate before editing the tag.
- Redirect hops before a 200 → indexable, but the signal belongs to the final URL. Make sure that is the URL in your sitemap and internal links.
- Nothing flagged, still not indexed → indexability is not your problem. Look at robots.txt blocking the crawl, thin or duplicated content, or a URL that simply is not linked from anywhere.
What this scan cannot tell you
- It reads the public response only. It cannot see which plugin or setting produced a directive — it tells you what Google sees, not who wrote it.
- It does not evaluate
robots.txt. A page can pass every check here and still never be crawled because a disallow rule blocks it. - It reports what Google can index, not what Google will index. Thin, duplicated, or unlinked pages are often skipped despite being perfectly indexable.
- It sees the page as an anonymous visitor. If a cache serves different HTML to logged-out traffic, the scan reflects that version — which is the version that matters, but may not match your browser.
- It does not execute JavaScript. A canonical or robots tag injected client-side will not be detected here, though Google may still process it.
Before you change anything
- Re-test in a private browser window. If the page looks fine to you but not to the scan, a cache is serving two versions and that is the first thing to resolve.
- Purge the cache layer in front of the page — plugin cache, then host cache, then CDN — and re-run the scan. Confirm the directive is genuinely present before hunting for its source.
- Change one thing at a time. Untick a setting, re-scan, confirm the served HTML changed. Two simultaneous changes make it impossible to tell which one worked.
- Once the page returns clean, use Search Console's URL Inspection and request indexing. Google's own view is the only authoritative confirmation.
Related workflow
- Redirect Chain Checker
Use when the scan shows redirect hops and you need every status code in the chain.
- HTTP Status Code Checker
Check a whole list of URLs at once rather than one page and its internal links.
- Robots.txt Generator
Use when the page is indexable but a disallow rule is preventing the crawl.
- XML Sitemap Health Checker
Confirm the fixed URL is the one your sitemap submits to Google.
Frequently asked questions
Why is my WordPress page not being indexed by Google?
Four causes account for nearly all cases, in this order: Settings → Reading still has "Discourage search engines" ticked, which noindexes the whole site and is frequently left on after launch; an SEO plugin noindexes the post type or taxonomy; a canonical tag points at a different URL, so Google indexes that one instead; or the URL returns something other than a 200. This tool reports all four signals for the URL you submit.
What is the difference between a robots meta tag and an X-Robots-Tag header?
They do the same job through different channels. The robots meta tag is HTML in the page's <head>, usually written by an SEO plugin. X-Robots-Tag is an HTTP response header, typically set in .htaccess, an Nginx config, or by a CDN — so it never appears in the page source. Because "View Source" cannot show it, a noindex set there is one of the hardest indexing bugs to find. This scan reads both.
Does a noindex tag remove pages already in Google's index?
Yes, once Google recrawls the URL and sees the directive. That gradual decay is what makes an accidental site-wide noindex so damaging — pages drop out over successive crawls rather than all at once, so the traffic loss looks like a slow slump rather than a single event. One caveat: a URL blocked in robots.txt cannot be recrawled, so Google may never see the noindex and the page can linger in the index indefinitely.
Why does my canonical tag point to the wrong URL?
Usually because two systems are both writing one — an SEO plugin plus a theme or page builder, or a second SEO plugin that was never fully removed. WordPress core also emits its own canonical via rel_canonical(). When several appear in one page, Google may disregard all of them. Always check the rendered HTML rather than the plugin's settings screen: the settings screen shows intent, the HTML shows what was actually served.
Can this tool see settings inside my WordPress admin?
No, and that limit is deliberate. It requests the URL the way a search engine would and reports only what is publicly served: response status, robots meta tag, X-Robots-Tag header, and canonical link. That is enough to tell you what Google can see — which is what determines indexing — but confirming which plugin or setting produced it still needs admin or WP-CLI access.
Why does the result differ from what I see in my browser?
Almost always caching. A page cache, CDN, or optimisation plugin can serve different HTML to a logged-out crawler than to a logged-in administrator. Test in a private window, purge the relevant cache layer, then re-run. If the two still disagree, whatever sits between WordPress and the visitor is introducing the difference — and the crawler's version is the one Google acts on.
Maintained and reviewed
Last reviewed 2026-07-21. This page absorbed the separate canonical-conflict and noindex/nofollow checkers, which ran the same scan against the same signals. One page now covers all three, so you get a single indexability verdict instead of three partial ones.