Noindex Gets Traffic

No Comments
Noindex gets traffic
TL;DR: A page you told Google not to index is still pulling organic clicks. That means one of two things is true: the noindex was added recently and Google has not recrawled yet, or your noindex signal is being contradicted somewhere else. Either way it is a conflict worth resolving, because you are getting traffic to a page you decided should not be in the index.
Signal type
Crawl / index
Severity
Medium
Usual cause
Recrawl lag or conflict
Best tool
GSC URL Inspection
Fix time
Minutes, then wait

This check fires when a URL carries a noindex directive but Search Console still reports impressions and clicks for it. On the surface that reads like a bug in Google. It usually is not. Noindex is a request that only takes effect once Google recrawls the page and sees the tag, so there is always a window where a page is marked noindex in your code but still sitting in the index from its last successful crawl. The interesting question is whether you are looking at normal lag or a genuine conflict that will keep the page indexed indefinitely.

What "noindex gets traffic" actually means

A noindex directive tells search engines to drop a page from their index. You deliver it one of two ways: a meta robots tag in the HTML head, <meta name="robots" content="noindex">, or an HTTP response header, X-Robots-Tag: noindex. Both are equally valid. The key detail people forget is that the directive is processed at crawl time. Google has to fetch the page, render it, and read the tag before it will act. Until that happens, the old indexed version stays live and can keep ranking.

So a page that gets traffic despite a noindex is Google telling you: "I have this URL in my index from an earlier crawl, and I have not yet processed your removal request." If you added the tag last week, that is expected. If the tag has been there for two months and the page is still ranking, something is stopping Google from seeing or trusting it.

Why it matters

Two reasons, pulling in opposite directions. First, if you genuinely want this page gone, the traffic is a symptom that your removal is not sticking, and you need to fix the underlying block. Second, and this trips people up more often, the traffic is a hint that maybe you noindexed something you should not have. I have seen a category page, a high-converting comparison page, and an entire paginated archive get noindexed by a careless plugin setting or a staging config that shipped to production. The page kept ranking for a while, revenue looked fine, and then the recrawl landed and the traffic fell off a cliff. If a noindexed URL is bringing in real clicks, confirm that killing it is actually what you want before you help Google along.

The recrawl lag versus real conflict decision

Noindexed URL still ranks When did you add the tag? Recently (under ~4 weeks) Likely recrawl lag. Wait, or request removal. Long ago (weeks or months) Real conflict. Google cannot see the tag. Check: robots.txt block, conflicting tags, cache

How to detect and diagnose it

Start with the one tool that gives you Google's own view: the URL Inspection tool in Search Console. Paste the URL, look at the indexing status, and use "Test live URL" to see what Googlebot fetches right now. This tells you whether Google currently sees the noindex tag and when it last crawled the page. If the live test shows the noindex but the indexed version does not reflect it yet, you are in lag territory.

  • Screaming Frog: crawl the URL and check the Directives tab. Confirm the meta robots value and the X-Robots-Tag header. Run "Render" mode if the tag is injected by JavaScript, because a raw fetch will miss it.
  • Server logs: confirm Googlebot is actually reaching the URL and getting a 200. If the page returns a 200 but is blocked in robots.txt, Google cannot read the noindex at all.
  • curl: curl -sI https://example.com/page shows response headers so you can catch an X-Robots-Tag that contradicts the meta tag, or vice versa.
  • Sitebulb: flags indexability conflicts across the whole site so you can see if this is one page or a pattern.

The classic conflicts that keep a noindex from working

ConflictWhat happensFix
Blocked in robots.txtGoogle never crawls the page, so it never reads the noindex, so the URL stays indexedUnblock in robots.txt so Google can crawl and see the tag
Tag injected by JavaScript onlyRaw HTML has no noindex; only the rendered DOM does. Slower to be picked up, sometimes missedServe noindex in the raw HTML or the HTTP header
Contradictory directivesMeta tag says noindex, header says index (or two meta tags disagree). Google may pick the wrong oneMake every signal say the same thing
Stale CDN or page cacheGooglebot is served an old cached copy without the tagPurge the cache, confirm the live fetch shows the tag
Just added, not recrawledNothing is wrong. Google has not returned since you added the tagWait, or use Removals for something urgent

How to fix it, step by step

  1. Decide if you actually want it gone. If the traffic is valuable, the right fix might be to remove the noindex, not enforce it. Do this first.
  2. Confirm the tag is really there. Use URL Inspection "Test live URL" and a raw curl -sI. Check both the meta robots tag and the X-Robots-Tag header.
  3. Rule out a robots.txt block. This is the single most common reason a noindex fails. A blocked page cannot be crawled, so the tag is never read. Allow crawling.
  4. Kill any conflicting signals. One page, one clear directive. Remove contradictory tags and headers.
  5. Purge caches. Make sure Googlebot gets the current version, not a stale CDN copy.
  6. Speed it up if urgent. Use the Removals tool in Search Console for a temporary block while the recrawl catches up. It is not permanent, but it hides the page fast.
  7. Wait and recheck. After Google recrawls, the impressions should decay to zero. Recheck in URL Inspection after a couple of weeks.

What good looks like

A clean noindexed page returns a 200, is crawlable (not blocked in robots.txt), and serves a single unambiguous noindex directive that Googlebot can read on fetch. Within a few weeks of the last crawl, its impressions in Search Console trend to zero and it drops out of the index. There is no contradicting X-Robots-Tag, no JavaScript-only tag, and no stale cache in the way.

DO
  • Confirm you truly want the page out before enforcing noindex
  • Keep noindexed pages crawlable so Google can read the tag
  • Serve one consistent directive in HTML or the HTTP header
  • Use URL Inspection to see Google's live fetch
  • Give it a few weeks after the last crawl before you worry
DON'T
  • Block a noindexed page in robots.txt and expect it to deindex
  • Rely on a JavaScript-only noindex tag
  • Ship contradictory meta and header directives
  • Panic on day three and assume Google is broken
  • Deindex a revenue page just because a check flagged it

FAQ

How long until a noindexed page drops out of the index?
It depends entirely on how often Google recrawls the URL. Popular, frequently crawled pages can drop within days. Deep, rarely crawled pages can take weeks. There is no fixed number, which is why the last-crawl date in URL Inspection is the value to watch.
Should I add noindex and a robots.txt block together?
No. That is the classic mistake. If you block the page in robots.txt, Google cannot crawl it, cannot read the noindex, and the URL can linger in the index indefinitely. Pick one: to deindex, allow crawling and use noindex.
Can I force removal faster?
Yes, use the Removals tool in Search Console for a temporary hide, roughly six months, while the recrawl catches up and makes the noindex permanent. It is a stopgap, not a replacement for the tag.
Is meta robots or X-Robots-Tag better?
Both work. Use the HTTP header when you cannot edit the HTML, for example on PDFs and non-HTML files, or when you want to noindex a whole pattern at the server level. For a single HTML page, the meta tag is simplest. Just do not have them contradict each other.
Getting mixed signals from your index?

Conflicting noindex directives, stale caches, and robots.txt blocks are exactly the kind of thing a proper crawl surfaces before they cost you traffic. Our audit maps every indexability conflict on your site and tells you which ones to fix first.

Get an Advanced SEO Audit

Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.

About SEO ProCheck

Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.

Work With Me

Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.

Subscribe to our newsletter!

More from our blog