By SitemapFixer Team
Updated April 2026

Noindex Follow: Does It Still Work in 2026?

Audit your noindex tags freeScan my site free

The noindex,follow directive is one of the most misunderstood patterns in technical SEO. For years it was the standard recommendation for paginated archives, faceted navigation, and any page you wanted excluded from the index but still useful for passing link equity. Then in 2019 Google quietly changed how it treats long-term noindex,follow pages — and most SEO advice never caught up. This guide covers what the directive actually does today, when it still works, and what to use instead for the most common use cases.

What Noindex Follow Was Designed To Do

The noindex,follow meta robots combination was originally meant to give SEOs surgical control: exclude a specific page from the search index while still letting Google crawl outbound links and pass PageRank through them. The classic use case was a paginated category archive — page 2 of /blog/ shouldn't rank on its own, but the article links on it should still benefit the linked posts.

The full directive set looked like this:

<!-- Classic noindex,follow meta tag -->
<meta name="robots" content="noindex, follow">

<!-- Targeted at Googlebot only -->
<meta name="googlebot" content="noindex, follow">

<!-- Targeted at Bingbot only -->
<meta name="bingbot" content="noindex, follow">

<!-- Combined with other directives -->
<meta name="robots" content="noindex, follow, noarchive, nosnippet">

The promise: the page itself disappears from search results, but it still functions as a link conduit. For paginated archives, faceted navigation pages, internal search results pages, and thin tag archives, this seemed like the perfect compromise. SEOs deployed it at scale across millions of pages on enterprise sites.

Google's 2019 Deprecation Announcement

In an October 2019 Webmaster Hangout, John Mueller stated that Google effectively treats long-term noindex pages as nofollow regardless of what the meta tag says. The exact mechanism: when Google encounters a page with noindex for an extended period, it eventually drops the page from its crawl schedule. Once a page is no longer being recrawled, the follow directive becomes meaningless because Google isn't reading the links on it.

Mueller's exact phrasing was that Google treats long-term noindex'd pages "similar to a soft 404," eventually treating them as if they don't exist for crawling purposes. Gary Illyes followed up on Twitter clarifying that the transition isn't instant — there's a window during which follow still works, but it's on the order of weeks to months, not years.

This was not a policy change announced in a blog post. It was confirmation of existing behavior that contradicted years of SEO documentation. The practical effect: every site relying on noindex,follow for permanent pagination handling was leaking link equity it thought it was preserving.

What Still Works Short-Term

The deprecation applies to long-term noindex pages. For genuinely short-term use — say, a staging environment going live, a product page during a temporary stockout, or a campaign landing page that will be permanent within weeks — noindex,follow still functions as advertised. During the initial crawl window, Google reads the page, follows the links, and excludes the page from the index.

The threshold isn't documented precisely, but observed behavior suggests:

First crawl after deployment: follow is fully respected. Links on the page pass equity normally and the page is excluded from indexing.

Weeks 2 through ~8: Google continues recrawling on its normal schedule, but recrawl frequency starts dropping because the page returns no indexable content.

Beyond ~3 months: Recrawl frequency may drop to once every several weeks or stop entirely. At that point follow is effectively dead because Google isn't reading the page often enough to register link changes.

If you remove the noindex within the first few weeks, the page returns to normal crawling and indexing without issue. If you remove it after months, expect a recovery delay while Google rediscovers the page.

HTTP Header and X-Robots-Tag Equivalents

The same directives can be delivered via HTTP response header instead of a meta tag — useful for non-HTML files (PDFs, images) or when you can't modify the page template. The behavior, including the long-term deprecation issue, is identical to the meta tag.

# nginx — add X-Robots-Tag for a directory
location /staging/ {
  add_header X-Robots-Tag "noindex, follow" always;
}

# Apache .htaccess — same directive for PDFs
<FilesMatch "\.pdf$">
  Header set X-Robots-Tag "noindex, follow"
</FilesMatch>

# Apache .htaccess — applied site-wide
Header set X-Robots-Tag "noindex, follow"

# Express.js / Node middleware
app.use((req, res, next) => {
  res.setHeader('X-Robots-Tag', 'noindex, follow');
  next();
});

For Next.js applications, the App Router exposes a typed metadata API that handles meta robots output for you — no manual head injection required:

// app/staging/page.tsx — Next.js 14+ App Router
import type { Metadata } from 'next';

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

export default function StagingPage() {
  return <div>Temporary staging content</div>;
}

// Or via headers in middleware.ts for entire route groups
import { NextResponse } from 'next/server';

export function middleware() {
  const response = NextResponse.next();
  response.headers.set('X-Robots-Tag', 'noindex, follow');
  return response;
}

Use Cases That Used to Work but Don't Anymore

The patterns below were standard practice before 2019 and are now bad practice. If your site still uses noindex,follow for any of these, the directive is doing nothing for you long-term.

Paginated archives. The classic /blog/page/2/, /blog/page/3/ with noindex,follow on every page. After the first few months, Google stops crawling deep pagination, which means the article links on those pages stop passing equity. The articles themselves don't get the link signals you assumed they were getting.

Faceted navigation. E-commerce filter pages like /shoes/?color=red&size=10 noindexed but follow. Same problem: Google deprioritizes recrawl, the filter links stop carrying weight, and you lose the internal linking benefit you thought you had.

Tag archives. WordPress sites with thin tag pages that were noindexed but kept follow to feed links to the tagged posts. After deprecation, the tag pages are functionally invisible to Google's link graph.

Internal search results. Sites that noindex their /search?q= pages but rely on follow to surface deep content. Google now treats these as effectively dead-end pages.

Print and AMP variants. Older sites with /print/ or /amp/ alternatives marked noindex,follow. The intent — link equity flows through the variants — no longer holds.

Modern Alternatives by Use Case

The right replacement depends on why you used noindex,follow in the first place. Here are the modern equivalents:

Paginated archives → self-canonical each page. Don't noindex pagination. Let each pagination page self-canonicalize, ensure it has unique content (different articles or products), and trust Google to consolidate ranking signals to the category page naturally. See our pagination canonical guide for the full pattern.

Faceted navigation → canonical to parent + parameter handling. For filter combinations with no real search demand, set the canonical to the unfiltered category URL. For filter combinations with genuine search demand (e.g., "red running shoes"), give them their own indexable URL with self-referencing canonical.

Retired pages → 410 Gone. When content is permanently removed, return HTTP 410 (or 404 if 410 isn't configurable). This tells Google the page is gone for good and removes it from the index faster than noindex ever did.

International alternates → hreflang, not noindex. If you have language or region variants of a page, use hreflang annotations. Never noindex an international variant — it removes the page from regional search entirely.

Internal search results → robots.txt disallow. Search results pages should be blocked at the crawl level via robots.txt, not at the index level. This saves crawl budget and prevents the long-term deprecation issue entirely.

Truly thin or duplicate content → consolidate or canonical. If a page is thin enough that you're tempted to noindex it, the better answer is usually to merge it into a stronger page or canonical it to the better version.

Migrating a Site Away From Noindex Follow

If your site has thousands of pages on noindex,follow and you want to migrate to modern patterns, here's the process I use:

Step 1: Inventory. Crawl the site and export every URL with a noindex directive (meta tag or X-Robots-Tag header). Group them by pattern: pagination, facets, tags, internal search, retired pages, etc.

Step 2: Decide per-pattern. For each group, decide the correct modern handling based on the alternatives above. Don't treat all noindex pages the same — pagination needs self-canonical, retired content needs 410, faceted nav needs canonical-to-parent.

Step 3: Deploy in phases. Start with the lowest-risk group (usually retired pages → 410). Watch GSC for 2–3 weeks before moving to the next group. This isolates the impact of each change.

Step 4: Monitor coverage reports. The "Excluded by noindex" count in GSC should drop as you remove the tags. Watch for migration patterns: if pagination URLs move from "Excluded by noindex" to "Crawled - currently not indexed", that's expected and fine. If they move to "Duplicate, Google chose different canonical", your canonicals are wrong.

Recovery Timeline After Removing Noindex

When you remove a noindex directive from a page that's been excluded for a long time, the recovery follows a predictable curve:

Days 1–7: Google needs to recrawl the page to see the directive change. If the page hasn't been crawled in months, this can be slow. Submit the URL via GSC's URL Inspection "Request Indexing" to accelerate.

Days 7–21: Once Google sees the page is indexable again, it enters the indexing pipeline. For high-quality pages this typically results in indexing within 1–3 weeks. Thin or duplicate pages may stay in "Crawled - currently not indexed" longer.

Weeks 3–8: Ranking signals rebuild. Pages don't come back at their previous positions immediately because Google has been treating them as non-existent. Internal links to the page need to be recrawled too, which compounds the delay.

Months 2–6: Full recovery if the underlying content is strong. If pages don't recover after 6 months, the issue is content quality, not residual noindex handling.

To verify the directive change is registered, use URL Inspection in GSC and check the "Indexing allowed?" field — it should say "Yes" once Google has recrawled and read the updated page.

When Noindex Follow Is Still the Right Answer

Despite the deprecation, there are still narrow cases where noindex,follow is correct:

Genuinely short-term exclusions. A landing page going live in 2 weeks, a product page during a 30-day stockout, a beta feature page during private testing. The deprecation timeline is long enough that short-term use is fine.

Pages you actively want crawled but not indexed. Site search pages, login pages, or admin URLs where you don't want them in results but you do want Google to discover linked content during the initial crawl. Acceptable as long as you don't expect the follow behavior to persist forever.

Transitional states during migrations. Mid-migration, you may want pages noindexed temporarily while still letting Google follow links to discover the new structure. As long as you complete the migration within weeks, this works.

For permanent cases — pagination, facets, tags, retired content — use the modern alternatives. The deprecation isn't coming back.

Related Guides

Audit every noindex tag on your site
Free analysis in 60 seconds
Analyze My Site Free
Related guides