Free tool
Noindex Checker
Check a whole list of URLs at once and see exactly what is keeping each one out of Google: the meta robots tag, the X-Robots-Tag header, robots.txt, or a canonical pointing somewhere else. No signup required.
0 URLs entered · free check covers the first 10
Checks the meta robots tag, the X-Robots-Tag header, robots.txt and rel=canonical on every URL. No signup, no credit card.
The four places a noindex hides
A noindex directive can live in four different places, and a page only needs one of them to disappear from search results. Most free noindex checkers read the meta tag and stop, which is why a page can pass their test and still be excluded. This checker reads all four, in the order Google applies them.
1. robots.txt
Checked first, because it decides whether Google is allowed to fetch the page at all. A Disallow rule here stops everything below it from ever being read.
2. X-Robots-Tag header
An HTTP response header set by your server or CDN, applied before the HTML is even parsed. It never appears in view-source, which makes it the single most commonly missed cause of a missing page.
3. Robots meta tag
The familiar <meta name="robots" content="noindex"> in the head. A googlebot-specific tag overrides it for Google, and none is shorthand for noindex plus nofollow.
4. rel=canonical
Not a noindex, but a frequent reason a page is missing anyway. A canonical pointing at a different URL asks Google to index that one instead of this one.
The conflict that keeps noindexed pages in Google
If a page is blocked in robots.txt and carries a noindex, the noindex does nothing. Google is not allowed to crawl the page, so it never fetches the HTML, never reads the directive, and the URL can stay in the index indefinitely. This is the most common reason someone adds a noindex, waits a month, and finds the page still ranking.
How to fix it
Remove the Disallow rule from robots.txt and leave the noindex in place. Google will recrawl the page, finally read the noindex, and drop it from the index. Once the page is gone, you can add the robots.txt rule back if you want to save crawl budget. Using both at the same time from the start is the mistake.
The checker above labels this combination as a conflict rather than reporting a clean noindex, so you can tell the difference between a directive that is working and one that is stranded.
How to remove a noindex
Fix the source the checker actually found. Removing a meta tag will not help if the noindex is coming from a header.
| Where it came from | What to change |
|---|---|
| WordPress | Settings › Reading, untick “Discourage search engines”. Then check your SEO plugin (Yoast, Rank Math) for a per-page indexing toggle, which overrides the global setting. |
| Shopify | Edit theme.liquid and remove the conditional noindex block. Note that Shopify noindexes some system pages by default. |
| Raw HTML in the page head | Delete the robots meta tag, or set it to index, follow. Check for a separate googlebot meta tag, which wins over the generic one. |
| X-Robots-Tag header | Look in your Nginx or Apache config, your CDN header rules (Cloudflare, Vercel, Netlify), and any staging or password-protection middleware that blankets the environment in noindex. |
| robots.txt | Remove the matching Disallow line. The checker shows you which rule matched, so you know exactly which line to edit. |
After the fix, confirm with Google Search Console URL Inspection and request reindexing. Then check whether Google has actually put the page back with the Google index checker, which answers a different question: not “can it be indexed” but “is it indexed right now”.
A noindex almost never arrives on purpose
Nobody sits down and decides to exclude their own money page. The noindex arrives with a staging flag that shipped to production, a plugin setting someone toggled, a CDN rule added for an unrelated reason, or a theme update. All of these land silently, weeks after the last time anyone thought to check.
That is the gap a one-off checker cannot close. It tells you the truth about this moment and then forgets. If nothing is watching afterwards, an excluded page can sit invisible for a month before the traffic drop is big enough to notice.
Keep watching after you close this tab
SearchOptimo re-checks your URLs on a schedule, keeps an index history timeline per URL, and alerts you the day a page drops out of Google. You find out when it happens, not when you next remember to look.
Frequently asked questions
- What is a noindex checker?
- A noindex checker is a tool that fetches a URL and reports whether anything on it tells search engines not to index the page. A complete check covers four separate places a noindex can live: the robots meta tag in the HTML head, the X-Robots-Tag HTTP response header, a robots.txt rule that blocks crawling entirely, and a rel=canonical pointing at a different URL. Most free checkers only read the meta tag, which is why a page can pass their test and still be excluded from Google.
- How do I check if a page has a noindex tag?
- Paste the URL into the checker above and it reports all four signals at once. To check by hand, open the page source and look in the head for <meta name="robots" content="noindex">, then inspect the HTTP response headers for X-Robots-Tag: noindex. The header is the one people miss, because it is set by the server or CDN and never appears in view-source. For your own site, Google Search Console URL Inspection gives the authoritative answer.
- Why is my page still in Google after I added a noindex?
- The usual cause is that the page is also blocked in robots.txt. A noindex only works if Google is allowed to crawl the page and read it. If robots.txt disallows the URL, Googlebot never fetches it, never sees the noindex, and the page can stay indexed indefinitely. Remove the robots.txt Disallow rule, leave the noindex in place, and let Google recrawl. The checker above flags this combination as a conflict.
- What is the difference between noindex and robots.txt?
- Robots.txt controls crawling and noindex controls indexing. A robots.txt Disallow tells Googlebot not to fetch the page at all, but Google can still index the URL from links pointing at it, usually with no snippet. A noindex tells Google it may fetch the page but must keep it out of search results. To reliably remove a page from Google, use noindex and allow crawling.
- Where does the X-Robots-Tag header come from?
- It is set by your web server, application or CDN rather than by the page HTML. Common sources are an Nginx or Apache config block, a Cloudflare or Vercel header rule, a staging environment that adds noindex to everything, and frameworks that apply it to non-HTML files like PDFs. Because it is a header, it never shows up when you view page source, so it is the most common cause of a page that looks perfectly indexable but is not.
- Does a noindex tag outside the head work?
- Usually not. Google stops reading head-level directives at the first body element, so a robots meta tag injected further down the document is typically ignored. If you added a noindex and nothing changed, check that the tag is actually inside <head> in the served HTML. The checker above reports it when a noindex is found outside the head.
- How often should I check for noindex tags?
- Checking once tells you about today. Unintended noindex tags are almost always introduced later by something routine: a staging flag shipped to production, a CMS or SEO plugin setting toggled, a new CDN header rule, or a theme update. Because nothing alerts you when it happens, a money page can sit excluded for weeks. For any page that matters to revenue, re-check on a schedule so you find out the day it changes.
Find it once. Then never miss the next one.
Checking by hand catches today’s noindex. Monitoring catches the one that has not happened yet. Free forever plan, no credit card, cancel anytime.