# Noindex page still getting Google traffic: the 3 causes and how to fix each

> A noindex page keeps clicks when Google hasn't recrawled it, can't see the tag, or your report shows old or reassigned data. How to check and fix each.

Source: https://seofix.ai/blog/noindex-page-still-getting-traffic  
Published: 2026-10-22  
Updated: 2026-10-09  
Author: SEOFix Team  
Category: Technical SEO  
Tags: Technical SEO, Guides  
Length: 1,969 words, 9 min read

If a noindex page is still getting Google traffic, one of three things is going on. Google hasn't recrawled the page since you added `noindex`. Or Google can't see the `noindex` at all, because robots.txt blocks the page, a firewall answers instead of your server, or the tag only exists after JavaScript runs. Or the report you're reading is behind or counts clicks against a different URL than you think. Each has a quick check, and the fix depends on which one it is, so check before you change anything.

Before any of that, decide whether the `noindex` should be there. A page that earns clicks and has `noindex` is either about to lose that traffic on purpose, or carrying a tag left over from staging, a plugin setting or a shared layout. If it's the second, remove the tag and stop reading.

## How Google processes noindex

Three rules from Google's documentation explain almost every case:

- **Google has to crawl the page to see the tag.** "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" ([Block indexing with noindex](https://developers.google.com/search/docs/crawling-indexing/block-indexing)).
- **It only takes effect on the next crawl.** The same page says that "depending on the importance of the page on the internet, it may take months for Googlebot to revisit a page."
- **The meta tag and the HTTP header are equivalent.** `<meta name="robots" content="noindex">` in the HTML and `X-Robots-Tag: noindex` in the response headers do the same job, and the header also works for PDFs and images ([robots meta tag spec](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag)). When rules conflict, "the more restrictive rule applies."

Once Google has processed it, the page shows up in Search Console's Page indexing report under "URL marked 'noindex'": "When Google tried to index the page it encountered a 'noindex' directive and therefore did not index it" ([Page indexing report](https://support.google.com/webmasters/answer/7440203)).

## Cause 1: Google hasn't recrawled the page yet

The most common case and the least worrying. You added `noindex` last week, Googlebot last fetched the page a month ago, and Google is still serving the version it indexed then.

**How to check.** Open URL Inspection in Search Console for the page. The indexed result shows "Last crawl" ("the last time this page was crawled by Google") and "Indexing allowed?" ([URL Inspection tool](https://support.google.com/webmasters/answer/9012289)). If the last crawl is older than your change, this is your cause. **Test live URL** then fetches the page now and should report the `noindex`. If the live test doesn't see it either, skip to cause 2.

**How to fix.**

- Click **Request indexing** in URL Inspection. Google calls this a request, not a guarantee. It usually takes "only a day or so, but can take much longer in some cases", and there's "a daily limit to how many index requests you can submit" ([URL Inspection tool](https://support.google.com/webmasters/answer/9012289)).
- For many URLs, Request indexing doesn't scale. What we do is leave the pages in the XML sitemap until URL Inspection shows a "Last crawl" after the change, and remove them from the sitemap after that. A sitemap that lists noindexed pages is a contradiction you shouldn't keep long, but for a few weeks it's another pointer for Google to revisit them.
- If the page has to disappear from results now (personal data, a leaked price list), use the **Removals** tool. It hides the URL "for about six months" and doesn't stop Google crawling it, so the `noindex` still has to be there when the block expires ([Removals tool](https://support.google.com/webmasters/answer/9689846)).

Then wait. Traffic falls away as Google recrawls, and low-priority pages go last.

## Cause 2: Google can't see the noindex

This one doesn't fix itself. The page keeps its traffic until you change something, however long you wait.

### robots.txt blocks the page

The classic mistake is adding `noindex` and a `Disallow` for the same path, to be thorough. Google's robots meta spec is explicit: "If a page is disallowed from crawling through the robots.txt file, then any information about indexing or serving rules will not be found and will therefore be ignored" ([robots meta tag spec](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag)). Google adds that a blocked page "can still appear in search results, for example if other pages link to it" ([block-indexing docs](https://developers.google.com/search/docs/crawling-indexing/block-indexing)). In the Page indexing report this often shows up as "Indexed, though blocked by robots.txt", and Google's advice for it is to "remove the robots.txt block and use 'noindex'" ([Page indexing report](https://support.google.com/webmasters/answer/7440203)).

Check robots.txt for the path:

```bash
curl -s https://example.com/robots.txt | grep -i -n "disallow"
```

Fix: remove the `Disallow` for pages you want deindexed. Once Google has dropped them (they show as "URL marked 'noindex'"), you can add the `Disallow` back if you need to save crawl budget.

### A firewall or login answers instead of the page

If a bot-management rule, rate limit or geo block sends Googlebot a challenge page or a 403, Google never gets your HTML and never sees the tag. URL Inspection's live test shows what Googlebot received. In SEOFix this shows up as `BLOCKED_BY_FIREWALL` on the affected pages. Our [Cloudflare and Googlebot](https://seofix.ai/blog/cloudflare-blocking-googlebot) post covers how to check for it.

### The noindex is added or removed by JavaScript

Google's JavaScript guidance says that when it "encounters the `noindex` tag, it may skip rendering and JavaScript execution", so using JavaScript to remove a `noindex` from the original HTML "may not work as expected" ([JavaScript SEO basics](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)). Adding `noindex` with JavaScript is allowed, but it only works when Google renders the page, which happens after the crawl and adds delay.

Put the tag in the server HTML. Check what the server actually returns, without a browser:

```bash
# robots meta tag and X-Robots-Tag header, as Googlebot's user agent sees them
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/old-page | grep -i -o '<meta[^>]*robots[^>]*>'
curl -s -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/old-page | grep -i "x-robots-tag"
```

If neither command prints a `noindex`, Google doesn't get one from the first fetch.

In Next.js App Router, set it in the page's metadata so it renders on the server:

```typescript
// app/old-page/page.tsx
import type { Metadata } from 'next'

export const metadata: Metadata = {
  robots: { index: false, follow: true },
}
```

The [Next.js docs](https://nextjs.org/docs/app/api-reference/functions/generate-metadata) show the `robots` field rendering as `<meta name="robots" content="...">` in the head. One caveat for `generateMetadata`: since 15.2, Next.js can stream metadata and append the tags to `<body>` after the initial HTML, for user agents it doesn't classify as "HTML-limited bots". The docs say Googlebot reads streamed metadata correctly. Other crawlers may not, so the curl check above is worth running anyway.

For files, or for a whole directory, send the header from the server. In nginx:

```
location /internal-reports/ {
    add_header X-Robots-Tag "noindex" always;
}
```

### The tag is there, but not on every response

Some setups send `noindex` on some responses and not others. Common ones:

- A CDN caches a version from before the change. Purge the paths.
- One origin server or container still runs the old build.
- The header is set by an app route, but static files bypass it.
- The tag uses `name="googlebot"` on one template and `name="robots"` on another, and someone removed the wrong one while debugging.

Run the curl checks against several URLs from the same template, and a few times each.

## Cause 3: the report isn't saying what you think

Sometimes Google has already dropped the page and the traffic you're looking at is old or belongs to a different URL.

### The date range includes days before the change

Search Console's default views cover the last 28 days or 3 months. Google says collected data "should be available in 2-3 days" ([About Search Console data](https://support.google.com/webmasters/answer/96568)). A page that went `noindex` ten days ago still shows weeks of clicks in a 28-day total. Switch the Performance report to daily data, filter on the page and look at the days after Google recrawled it (the crawl date from URL Inspection).

### Clicks are assigned to Google's canonical

Search Console doesn't always report clicks against the URL the visitor landed on: "Click, impression, and position data for all variations of a page are assigned to the canonical URL that Google selects for each page" ([What URL is my data assigned to?](https://support.google.com/webmasters/answer/7042828)). If your noindexed URL is the one Google picked as canonical for a group of duplicates (say the `http` or trailing-slash variants of the same page), the whole group's clicks appear against it until Google re-evaluates.

The opposite also happens. You noindex `/jobs?page=2` but give it a canonical to `/jobs`, and Google has to reconcile two signals pointing different ways. Google's canonicalization guide says it doesn't recommend "using noindex to prevent selection of a canonical page within a single site" ([consolidate duplicate URLs](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls)). Pick one. Use a canonical if the pages are duplicates and the signals should go to one URL. Use `noindex` (with a self-referencing canonical or none) if the page shouldn't be in Google at all.

URL Inspection shows the "Google-selected canonical" for a URL. If it's a different URL from the one you inspected, the clicks you're seeing belong to that canonical.

## A quick way to tell the three apart

| What you see | Likely cause | Next step |
| --- | --- | --- |
| URL Inspection: last crawl before your change; live test sees `noindex` | 1: not recrawled | Request indexing; wait |
| Live test doesn't see `noindex`, or gets a 403 or challenge | 2: Google can't see it | Fix robots.txt, firewall or server HTML |
| curl shows the tag on some requests only | 2: inconsistent responses | Purge the CDN; check every origin |
| Page shows "URL marked 'noindex'", clicks only on days before the crawl | 3: date range | Nothing to fix |
| Google-selected canonical differs from the inspected URL | 3: canonical attribution | Make canonical and `noindex` agree |

## How SEOFix flags it: NOINDEX\_RECEIVES\_TRAFFIC

SEOFix has a check for exactly this situation. From the [indexability checks reference](https://seofix.ai/help/checks-indexability), `NOINDEX_RECEIVES_TRAFFIC` fires when:

- the page answered `200` in the latest full audit,
- the first `<meta name="robots">` tag in its HTML contains `noindex` (case-insensitive), and
- Search Console shows any clicks or impressions for the page over the last 28 days, matching any `www`, scheme or trailing-slash variant of the URL.

The issue records `clicks_28d`, `impressions_28d` and the `meta_robots` value. It's a warning, it only runs for verified sites with a [Search Console connection](https://seofix.ai/help/connect-google-search-console), and it's re-evaluated at the next full audit rather than by Verify fix. SEOFix's 28-day window ends 3 days ago because of Google's data lag, so a page noindexed yesterday will still match. That's cause 3 in action, and why the check is a warning rather than an error.

It has limits worth knowing. It reads the robots meta tag only. A `noindex` sent in the `X-Robots-Tag` header, or only in a `<meta name="googlebot">` tag, doesn't trigger it. It also can't tell you which of the three causes applies. It surfaces the pages so you can run the checks above. Two related checks help with the rest: `BECAME_NOINDEX` flags pages that gained `noindex` since the previous audit (the usual sign of a staging flag shipped to production), and `NOINDEX_IN_SITEMAP` flags noindexed pages still listed in your sitemap.

## FAQ

**How long does it take for a noindex page to drop out of Google?** Until Googlebot recrawls it. For important pages that can be days. Google says it "may take months" for others. Request indexing speeds up individual URLs.

**Should I block the page in robots.txt as well?** Not until it's gone from the index. A robots.txt block stops Google seeing the `noindex`.

**Is X-Robots-Tag better than the meta tag?** Google treats them the same. Use the header for non-HTML files or when you can't edit the template. Use the meta tag when you want the rule visible in the page source.

**The page shows "URL marked 'noindex'" but still has clicks. Why?** Check the date range first. If the clicks are all from before the recrawl date, there's nothing to fix.

---

To find these pages across a whole site, verify it in SEOFix, connect Search Console and run an audit: every noindexed page that still gets clicks or impressions is listed by template. The first audit is free, up to 500 pages.