Free Noindex Checker: Meta Robots and X-Robots-Tag Test

What does this noindex checker look at?

Six things, in the order a crawler meets them. First robots.txt, because a crawler reads that before it touches the page, and a Disallow there decides whether Google ever sees the rest. Then the page itself through every redirect: the X-Robots-Tag header on each hop, the X-Robots-Tag header on the final response, the meta robots tag in the HTML, a second meta tag named googlebot that applies to Google only, and the rel=canonical link. The result names the one place that is responsible, quotes the exact line, and says what to change. One address at a time, or up to ten in one table.

Where a noindex hides	Set by	Shows in page source?	Seen by
<meta name="robots" content="noindex">	CMS setting, SEO plugin, theme template	Yes	Every search engine
<meta name="googlebot" content="noindex">	SEO plugin, template	Yes	Google only
X-Robots-Tag: noindex on the final response	Server config, hosting staging rules, a CDN rule	No	Every search engine
X-Robots-Tag: noindex on a redirect hop	The redirecting hostname or path	No	Every search engine that follows the redirect
robots.txt Disallow	robots.txt, a CDN-managed section	No (a separate file)	Hides the page, and any noindex on it
rel=canonical pointing elsewhere	CMS, SEO plugin, template	Yes	Google may index the other address instead

Meta tag, header or robots.txt: which one is it?

The three are often confused, and the confusion is what keeps pages out of Google for weeks. A meta robots tag sits in the HTML head and is written by the CMS, a plugin or the theme. You can see it in view-source. An X-Robots-Tag header is part of the HTTP response, not the page, so view-source never shows it; the server, the host's staging rules or a CDN rule add it, which is why an SEO plugin with every setting right can still ship a noindexed page. Both mean the same thing to Google: drop this page from the index. Google documents the two forms side by side in its robots meta tag and X-Robots-Tag specifications.

A robots.txt Disallow is different. It does not say "do not index". It says "do not fetch". Google's introduction to robots.txt is explicit that a disallowed page can still be indexed if other pages link to it, and that to keep a page out of Google you should use noindex, not robots.txt. The trap is the combination: if robots.txt blocks a page that also carries a noindex, Google cannot fetch the page, so it never reads the noindex, and the page can stay in the index as a bare URL with no title or snippet. That is why this checker reads robots.txt first and warns when a Disallow would hide the noindex you are trying to apply. The Search Console report for that state is "Indexed, though blocked by robots.txt", and we have a post on exactly that message.

How do I remove a noindex in my CMS?

Find the source first with the checker above, because the fix lives wherever the directive comes from. The usual places by platform:

WordPress. Settings → Reading → untick "Discourage search engines from indexing this site". That one box writes a meta robots noindex on every page and is the single most common cause after a launch; our post on "Excluded by 'noindex' tag" covers the recovery in Search Console. Then check the SEO plugin: in Yoast, the page's Advanced tab ("Allow search engines to show this Page") and Search Appearance for whole post types; in Rank Math, the page's Advanced tab and Titles & Meta per post type. If the tag is still there, the theme's header.php or a snippet plugin is printing it. A header noindex on WordPress almost always comes from the host: managed hosts add X-Robots-Tag on staging copies and sometimes keep it after a push to live.
Webflow. Project settings → SEO → "Disable Webflow subdomain indexing" only affects the webflow.io copy, which is right. On the custom domain, open the page settings and check the "Exclude this page from search results" switch, and the Collection template settings for CMS pages. Webflow adds the directive as a meta tag.
Shopify. There is no noindex switch in the admin; a noindex comes from the theme code (theme.liquid, usually inside a condition on the template or the handle), from an app, or from the password page while the store is unpublished. Search theme.liquid and the layout files for "noindex". Shopify's own robots.txt disallows checkout, cart and account paths by design, and the checker reads that file too.
Wix. Page settings → SEO basics → "Let search engines index this page", and the site-wide switch under Site settings → SEO. Wix writes a meta tag; a header noindex on Wix is rare and worth a support ticket.
Squarespace. Page settings → SEO → "Hide this page from search results", and Settings → SEO → "Hide site from search engines" for the whole site. Both write a meta tag.
Next.js and other frameworks. The directive is in code: the metadata export (robots: { index: false }) in the App Router, a next/head tag in the Pages Router, or a middleware that sets the X-Robots-Tag header for preview deployments. Vercel and Netlify add X-Robots-Tag: noindex to preview URLs on purpose; the production domain should not carry it. If it does, a header rule or an environment variable meant for previews is running in production.

After the fix, confirm with the checker, then open the page in Search Console's URL Inspection, run "Test live URL" and press "Request indexing". Google reports what it saw at its last crawl, so the report lags the page until it is recrawled.

What do the Search Console messages mean?

"Excluded by 'noindex' tag" means Google fetched the page and found a noindex in the meta tag or the X-Robots-Tag header. The word "tag" is misleading: a header counts. If view-source shows nothing, the header is the answer, and this checker shows it. The full walk-through is in our post on "Excluded by 'noindex' tag".

"Indexed, though blocked by robots.txt" means the opposite problem: Google could not fetch the page because of a Disallow, but kept it in the index because something links to it. Any noindex on that page is invisible to Google until the Disallow goes. Fix the order: allow the page in robots.txt, leave the noindex in place, wait for the recrawl, and only then block it again if you must.

"Submitted URL marked 'noindex'" is the same as the first message for a URL that is also in your sitemap. A sitemap should list only pages you want indexed, so either remove the noindex or remove the URL from the sitemap. Google's Page indexing report help lists every state and what Google did with the page.

A redirect-hop example: the page is clean, the redirect is not

A site moves from http to https and from old-domain.example to new-domain.example. The new page is perfect: no meta robots, no header, a self-referencing canonical. Yet it drops out of Google. The reason is on the way there. The old hostname still runs on the previous host, whose staging rule sends X-Robots-Tag: noindex on every response, including the 301. Google reads headers on every hop of a redirect chain, so the chain looks like this:

HTTP 301 http://old-domain.example/pricing      X-Robots-Tag: noindex
HTTP 301 https://old-domain.example/pricing     X-Robots-Tag: noindex
HTTP 200 https://new-domain.example/pricing     (clean)

Nothing in the new CMS, nothing in view-source, and the SEO plugin reports all green. This checker lists each hop with its headers and marks the hop that sent the directive, which is the line to take to whoever runs the old host. The fix is on the redirecting hostname, not on the final page.

A real case, anonymised

One of the sites run through quietwatch's checks, with the details changed enough that it cannot be identified: a law firm's site, several years old and ranking for its practice areas, was rebuilt by an agency and relaunched on a Friday. The new theme printed <meta name="robots" content="noindex, nofollow"> on every page because the developer's local setting had been committed with the template. Nobody noticed: the site looked fine, the forms worked, the agency had moved on. Google recrawled the pages over the following three weeks and dropped them one by one, and the first sign was a partner asking why the phone had stopped ringing. The site was out of Google for roughly a month before the tag was found. We do not name the sites we check, and this one is anonymised, but the shape of it repeats: the launch works, the noindex rides along, and the damage shows up in traffic weeks later. A daily check of each page's indexability, the thing quietwatch watches every day, turns that month into an email on day one.

What about a noindex added by JavaScript?

This checker reads the HTML the server sends and the response headers, which is also what Google's first pass reads. A noindex that a script injects after load is only seen when Google renders the page. Google's JavaScript SEO basics say that a noindex in the raw HTML can stop Google from rendering the page at all, and that removing a noindex with JavaScript may not work as expected, so the raw HTML and the headers are the places that decide. A rendered check is on our list; until then, if your framework sets robots directives in client-side code, read the rendered DOM in Search Console's URL Inspection ("View crawled page", then "More info").

Why it matters

A noindex left on after a launch or a migration takes pages out of Google one by one as they are recrawled, and the drop shows up in traffic weeks later. Recovery is not instant either: after the fix, every page needs another crawl, and pages that lost their rankings do not always get them straight back. Catching the directive on the day it appears is cheaper than any recovery.

How to use it

Paste the address of the page you care about and press Check this site.
Read the verdict at the top of the result, then the evidence under each answer: the exact line, tag, header or date.
Follow the fix under any failing answer, run the check again, then keep the result link; it works for 30 days.

Questions

What does noindex do?

It tells search engines to drop the page from their index. Google honours it in the meta robots tag and in the X-Robots-Tag HTTP header; the page can still be crawled, it just never appears in results.

Is my page noindexed? How do I check in 30 seconds?

Paste the address above. The result says indexable or noindexed and names the place responsible: the meta robots tag, a googlebot meta tag, the X-Robots-Tag header or a redirect hop, with the exact line. To check by hand, view the page source for a meta robots tag, then run curl -I on the address and read the X-Robots-Tag header.

Why can't I find the noindex in my CMS?

Because it is probably in the X-Robots-Tag header, which the server, the host's staging rules or a CDN add to the response. It never shows in page source or in an SEO plugin. This tool reads the headers, so it finds it.

What is the difference between noindex and a robots.txt Disallow?

noindex says do not index; Disallow says do not fetch. A disallowed page can stay in Google as a bare URL if other pages link to it, and Google cannot read a noindex on a page it is not allowed to fetch. To keep a page out of Google, allow it in robots.txt and use noindex.

Does a noindex on a redirect matter?

Yes. Google reads the headers of every hop. A redirect from the old domain or from http to https that carries X-Robots-Tag: noindex can keep the final page out even though the page itself is clean.

What is the googlebot meta tag?

A second robots tag, <meta name="googlebot">, that applies to Google only. SEO plugins and templates set it; it overrides nothing but adds its own directives, so noindex there is enough to drop the page from Google.

How do I check a noindex in Chrome without a tool?

View-source shows a meta robots tag but never a header. For the header, open DevTools, the Network tab, reload, click the page's own request and read Response Headers for X-Robots-Tag. Redirect hops need the "Preserve log" box ticked, which is the step most people miss and the reason this checker lists every hop.

The page is clean but Search Console still says "Excluded by noindex tag". Why?

Google reports what it saw at its last crawl. Fix the page, run "Test live URL" in URL Inspection, then "Request indexing". The blog post linked below walks through it.

Can I check more than one page at once?

Yes, up to ten addresses in one go, one per line, under the single-URL form. They are fetched one after another, never two at once to the same host, and shown in one table with where any noindex comes from.

Does the checker see a noindex added by JavaScript?

No. It reads the HTML the server sends and the response headers, like Google's first pass. A noindex that a script injects after load is only seen when Google renders the page, and Google says a noindex in the raw HTML can stop rendering altogether, so the raw check is the one that matters most. A rendered check is on our list.

How often should I check this?

Every time a site is deployed, migrated or moved to a new host, and otherwise once a day, because the directive arrives silently. quietwatch runs this check on every page you add each day and emails you the day a noindex appears.

How is this different from the free checker on the home page?

The home page runs all twelve checks. This page runs only the indexability ones, on one URL or ten, and says which of the places is responsible.

Free noindex checker: is this page set to noindex?