Does `rel=prev/next` still help with pagination?

Not for Google. Google stopped using `rel=prev/next` for indexing in 2019. It is not harmful, and Bing plus some other engines still read it, so there is no urgency to remove existing tags.

Should page 2+ canonical to page 1?

No. Google ignores a canonical between non-duplicate pages, and pages 2/3/4 are different content from page 1. Give each paginated page a self-referencing canonical.

Is `noindex,follow` ever safe on pagination?

Only if discovery does not depend on those pages — every article must also be in the sitemap and linked from indexable pages. Even then, expect Google to eventually stop following links on the long-lived `noindex` pages, so don't rely on them for crawl paths.

How long until "noindex" turns into effectively "nofollow"?

There is no published timer. Mueller said it depends on crawl frequency — a frequently crawled page reaches that state faster. Treat anything held in `noindex` for weeks as no longer passing link signals.

Should I `noindex` only the very last paginated page?

No. Either all paginated pages are indexable or none; mixing signals across a sequence just confuses crawlers without solving the discovery problem.

Will fixed articles definitely come back?

Usually, if they are genuinely useful and now have indexable inbound links. Thin or zero-signal old posts may stay out — that is a content/link problem, not a pagination one.

Troubleshooting

noindex,follow on Page 2+ Is Orphaning Your Deep Articles

An old SEO tip says put `noindex,follow` on paginated pages. Google treats long-term noindex,follow as noindex,nofollow, so articles reachable only via page 2+ quietly drop out of the index. Here is the fix.

Published: May 24, 2026 Updated: Jun 21, 2026 Author: AI Productivity Guide Team 🌐 查看中文版本

TL;DR: Switch your paginated pages (/blog/page/2/, /category/x/page/3/, etc.) from noindex,follow to index,follow with a self-referencing canonical, and add every article URL to your XML sitemap so discovery never depends on crawling through pagination. That combination is Google’s own recommended setup and clears “Discovered/Crawled – currently not indexed” on the affected articles within 2–4 weeks.

A blog hub like /blog/page/2/, /blog/page/3/ got the popular SEO advice: add <meta name="robots" content="noindex,follow"> so pagination doesn’t compete with the main hub but link equity still flows through. Six months later, articles linked only from page 3+ disappear from the index. Search Console shows them under Page indexing as “Discovered – currently not indexed” or “Crawled – currently not indexed.” The trick sounds clever but contradicts how Google actually treats long-term noindex,follow.

Google’s John Mueller has said it plainly: when a page carries noindex long enough, Google decides “this page really doesn’t want to be in search,” drops it, and stops following its links — so a long-lived noindex,follow ends up behaving like noindex,nofollow. There is no fixed timer; it depends on how often Google recrawls the page. Once that happens, if page 2+ is the only internal path to articles 11 through 200, those articles become orphans with no link Google trusts.

This is also why the major SEO plugins changed course: Yoast removed its “noindex subpages of archives” option back in version 6.3 for exactly this reason, and Google’s current pagination guidance is to keep paginated pages indexable with a self-referencing canonical on each one (as of June 2026).

Which bucket are you in

Run one check first: open a paginated URL (yoursite.com/blog/page/2/), view-source:, and search for robots and canonical. Then match the result to the table.

What you see in page 2 source	Likely cause	Jump to
`<meta name="robots" content="noindex,follow">`	Plugin filter, theme code, or a framework template forcing noindex on page 2+	Causes 1, 2
`index,follow` but deep articles still dropped	Pagination is the only discovery path; sitemap omits them	Causes 3, 4
`canonical` points to page 1 (not self)	Canonical-to-hub mistake; Google ignores it between non-duplicate pages	Cause 5
No `<a href=".../page/2/">` in raw HTML at all	JS “Load More” hides deep links from Googlebot	Cause 6

Common causes

1. WordPress plugin filter, theme code, or a legacy “noindex archive subpages” setting

Important update for June 2026: Yoast no longer ships a built-in “noindex subpages of archives” toggle. Yoast removed it in version 6.3 precisely because long-term noindex on page 2+ starves deep articles of the internal links they need. So if a Yoast site is emitting noindex,follow on /category/x/page/2/, it is coming from custom code (a wpseo_robots filter), an old theme, or another plugin — not a current Yoast checkbox.

Rank Math is different: it still exposes the toggle. Under Rank Math SEO → Titles & Meta → Misc Pages there is a “Noindex Paginated Single Pages” option; older Rank Math builds also expose pagination noindex here. Some “ideal settings” guides still recommend turning it on, which is what plants noindex on your paginated archives.

How to spot it: Visit yoursite.com/category/whatever/page/2/, view-source:, search for robots. If you see noindex,follow, something is setting it. To find what, search your theme and active plugins for wpseo_robots, rank_math/frontend/robots, or a hard-coded noindex near a is_paged() / paged > 1 check.

2. Astro / Next.js paginated routes with a blanket meta tag

A template like [page].astro emits <meta name="robots" content="noindex,follow"> when page > 1. The dev who wrote it read a 2014 Moz post.

How to spot it: Inspect getStaticPaths / dynamic route file. Look for any noindex branch keyed on pageNumber > 1.

3. Pagination is the ONLY internal path to deep content

Hub page links to article 1-10. Page 2 links to 11-20. Page 3 links to 21-30. No category index, no related links, no sitemap entry for articles 11+. If page 2+ is noindex, articles 11+ have zero in-links Google trusts.

How to spot it: Pick an article that lives on page 3 of your hub. Use Search Console URL Inspection → “Referring page.” If the only referrer is a noindex page, you’ve found it.

4. Sitemap omits paginated URLs and articles

Sitemap lists only the hub /blog/ and feature articles. Article URLs on page 2+ never appear. Combined with paginated pages being noindex, Googlebot has no way in.

How to spot it: Download your sitemap. Grep for one of the dropped article URLs. If absent, sitemap isn’t helping.

5. Mistaking `noindex,follow` for `index,follow` with canonical to hub

Some teams want pagination to “consolidate” with the hub via rel=canonical pointing all paginated pages back to page 1. Google ignores canonicals between non-duplicate pages. The paginated pages still get crawled, but the canonical signal is wasted and you’ve added confusion.

How to spot it: Page 2’s <link rel="canonical"> points to page 1 (different content). Search Console will report “Duplicate, Google chose different canonical” or just ignore the directive.

6. JavaScript “load more” hides the deep articles entirely

A variant: instead of paginated URLs, the hub uses a “Load More” button that fetches via JS but doesn’t push a URL. Googlebot never sees article 11+ links at all.

How to spot it: Disable JavaScript in DevTools, reload the hub. If only 10 articles appear and there’s no <a href="/blog/page/2/">, your deep articles are JS-only.

Shortest path to fix

Step 1: Decide your pagination strategy explicitly

Three options exist. Pick one:

A. Index all paginated pages with index,follow and a self-referencing canonical (page 2’s canonical points to page 2). This is what Google’s current docs recommend, and Google handles the partial overlap between hub pages fine. Safest for discovery.
B. Keep noindex,follow on page 2+ BUT add a separate sitemap of every article URL so discovery never relies on crawling through pagination. This survives the noindex-becomes-nofollow drift because the sitemap, not the paginated links, is the discovery path.
C. Do NOT canonical paginated pages to page 1. This is a trap, not an option. Google explicitly says: don’t use the first page of a paginated sequence as the canonical for the others; give each page its own self-referencing canonical. Pages 2, 3, 4 are not duplicates of page 1, so Google ignores a canonical-to-page-1 and you have wasted the signal.

Option A is the cleanest. Option B is acceptable only if the article sitemap is genuinely complete and kept in sync.

Step 2: Remove the blanket noindex on page 2+ and self-reference the canonical

In Astro:

---
const { page } = Astro.props;
// Remove the noindex-on-page-2 branch:
// const robots = page.currentPage > 1 ? 'noindex,follow' : 'index,follow';
const robots = 'index,follow';
---
<meta name="robots" content={robots}>
<link rel="canonical" href={Astro.url.href} />

In WordPress:

Rank Math → Titles & Meta → Misc Pages → turn OFF “Noindex Paginated Single Pages” (and any pagination-noindex toggle your version exposes). Rank Math already adds a self-referencing canonical to paginated pages by default.
Yoast has no pagination-noindex checkbox to flip anymore (removed in 6.3) and already self-canonicalizes paginated archives. If you still see noindex on page 2+, hunt down the wpseo_robots filter or theme code adding it and delete that branch.

Verify the result: reload view-source: on page 2 and confirm it now reads index,follow with <link rel="canonical"> pointing to page 2 itself, not page 1.

Step 3: Add ALL article URLs to your sitemap

Don’t rely on crawl-through-pagination. Generate sitemap from your full article list, not from paginated HTML:

// scripts/generate-sitemap.mjs
import fs from 'node:fs';
const articles = JSON.parse(fs.readFileSync('articles.json', 'utf8'));
const urls = articles.map(a => `<url><loc>https://example.com/articles/${a.slug}/</loc></url>`);
fs.writeFileSync('public/sitemap-articles.xml', `<urlset>${urls.join('')}</urlset>`);

Step 4: Resubmit the sitemap and request reindexing

Search Console → Sitemaps → submit the article sitemap URL (resubmitting an existing entry is fine; it re-triggers processing). Then for 5–10 of the dropped articles, paste each URL into the “Inspect any URL” bar at the top of Search Console and click Request Indexing. This adds them to a priority crawl queue. Submitting the same URL repeatedly does not improve its position, so do it once per URL and wait.

Step 5: Add secondary internal links to deep articles

Don’t leave any article reachable only via paginated archives. Cross-link from related articles, tag pages, and “more from this author” widgets so each deep article has at least one or two links that live on indexable pages.

Step 6: Monitor in Search Console

Page indexing → “Discovered – currently not indexed” and “Crawled – currently not indexed” counts should fall over 2–4 weeks as Googlebot rediscovers articles via the sitemap and new internal links. Search Console data lags a few days, and a requested URL may still show as not-indexed for 24–48 hours after the request, so don’t panic on day one.

How to confirm it’s fixed

view-source: on /blog/page/2/ shows index,follow and a canonical pointing to page 2 itself.
URL Inspection on a previously dropped article → “Page is indexed,” or at minimum “URL is on Google” after a recrawl.
In URL Inspection, the “Referring page(s)” / discovery section now lists an indexable referrer (sitemap or a normal article), not only a noindex paginated page.
The “Discovered/Crawled – currently not indexed” buckets in Page indexing trend downward week over week rather than flat or climbing.

When this is not on you

Old archived blog posts with zero external signals may never come back even after fixing pagination. That’s a content-quality / inlink problem, not a pagination directive problem.

Easy to misdiagnose as

A site speed or thin content issue. The articles themselves are fine; the problem is they became orphans because the only inbound internal link was on a noindex page Google stopped trusting as a link source.

Prevention

Default to index,follow with a self-referencing canonical on paginated archives unless you have a specific reason not to.
Never make pagination the only discovery path. Always also expose articles via sitemap and cross-links.
If you must noindex page 2+, treat the sitemap as the discovery path and run a quarterly orphan-page audit.
Don’t canonical paginated pages to page 1 — they aren’t duplicates, and Google says to self-reference each one.
Distrust pagination advice written before ~2019. rel=prev/next was dropped by Google in 2019, and the “noindex page 2+” trick predates Google confirming it eventually nofollows those links.

Authoritative references:

Google Search Central: Pagination best practices (give each page its own self-referencing canonical; rel=prev/next no longer used).
Yoast: Pagination SEO best practices (why the noindex-subpages option was removed in 6.3).

FAQ

Does rel=prev/next still help with pagination? Not for Google. Google stopped using rel=prev/next for indexing in 2019. It is not harmful, and Bing plus some other engines still read it, so there is no urgency to remove existing tags.
Should page 2+ canonical to page 1? No. Google ignores a canonical between non-duplicate pages, and pages 2/3/4 are different content from page 1. Give each paginated page a self-referencing canonical.
Is noindex,follow ever safe on pagination? Only if discovery does not depend on those pages — every article must also be in the sitemap and linked from indexable pages. Even then, expect Google to eventually stop following links on the long-lived noindex pages, so don’t rely on them for crawl paths.
How long until “noindex” turns into effectively “nofollow”? There is no published timer. Mueller said it depends on crawl frequency — a frequently crawled page reaches that state faster. Treat anything held in noindex for weeks as no longer passing link signals.
Should I noindex only the very last paginated page? No. Either all paginated pages are indexable or none; mixing signals across a sequence just confuses crawlers without solving the discovery problem.
Will fixed articles definitely come back? Usually, if they are genuinely useful and now have indexable inbound links. Thin or zero-signal old posts may stay out — that is a content/link problem, not a pagination one.

Tags: #SEO #Troubleshooting #Indexing #Search Console #pagination #noindex