When you have hundreds of posts, dozens of categories, and a cloud of tags, pagination pages multiply unnoticed. /page/2/, then /page/3/, then /page/15/, and before you know it Google is indexing a thousand junk URLs that carry no unique content but consume your crawl budget.

In older versions of Yoast SEO there was a built-in toggle called "Noindex subpages of archives." One checkbox and the problem was solved. But in 2020 the Yoast team removed this setting from the interface. The official position: Google has become smarter at handling paginated series and the setting is no longer needed.

In practice, it is needed. Especially for large sites where every extra page in the index eats into the crawl quota for URLs that actually should rank.

Yoast developers left a workaround: the wpseo_robots filter. With it you can programmatically set noindex, follow for any pagination pages. Below are two code options: a strict one (all /page/ URLs) and a selective one (category and tag archives only).

💡 Quick overview:

• Learn why Yoast removed the built-in option and when it's still necessary
• Get ready-to-use code for functions.php: two versions of the wpseo_robots filter
• Learn to verify results through page source code and Google Search Console

Why pagination pages should be blocked from indexing

Every pagination page has three problems. First, content duplication: /category/seo/, /category/seo/page/2/, and /category/seo/page/3/ display the same previews, just split across pages. Second, thin content: a pagination page has no full article, only a list of titles with excerpts. Third, crawl budget: Googlebot spends its crawl limit on URLs that have no search value instead of recrawling fresh posts.

Yoast SEO historically solved this task with a single checkbox in settings. But starting with version 14.0 the company reconsidered its approach. The logic was this: Google learned to recognize rel="prev" and rel="next", understands pagination structure, and directs users to the first page on its own. And noindex on subpages, in Yoast's view, reduces the number of crawls and prevents the search engine from rediscovering old articles through links on these pages.

This argument is debatable. If you have a small blog with 30 posts, fine, Google will figure it out. But if your site has grown to several thousand URLs with category, tag, and date archive pagination, the search engine wastes time on the wrong things. Blocking subpages from indexing via code is a controlled and reversible solution.

Option 1: noindex for all pagination pages

The simplest and most radical approach. The filter checks the is_paged() condition, a standard WordPress function that returns true on any pagination page (archives, categories, tags, homepage). If the condition is true, we substitute noindex, follow.

Add this code to your active theme's functions.php or via the Code Snippets plugin:

1
add_filter('wpseo_robots', function($robots) {
2
    if (is_paged()) {
3
        return 'noindex,follow';
4
    }
5
    return $robots;
6
});

What happens line by line:

• add_filter('wpseo_robots', ...) hooks into the Yoast SEO filter responsible for the robots meta tag content. The filter accepts the current $robots value and expects a string back.
• is_paged() is a built-in WordPress core function. It triggers on any URL where the paged variable is present (that is, /page/N/).
• return 'noindex,follow' tells the search engine: "don't index this page, but follow the links on it." Links within pagination continue to pass weight.
• return $robots returns the standard Yoast value unchanged for all other pages.

After adding the code, visit any page like /category/seo/page/2/ and open the HTML source (Ctrl+U). Find the line <meta name="robots". If you see content="noindex, follow", the filter worked.

Option 2: noindex only for category and tag archives

The first option hits all paginated pages indiscriminately, including the homepage (/page/2/). If your homepage displays post previews and you want to keep its subpages in the index, you need more targeted logic.

We add a second condition: is_archive(). This WordPress function returns true only on archive pages: categories, tags, date archives, author archives, and custom taxonomies.

1
add_filter('wpseo_robots', function($robots) {
2
    if (is_paged() && is_archive()) {
3
        return 'noindex,follow';
4
    }
5
    return $robots;
6
});

The difference from the first option is in the combination of conditions. is_paged() && is_archive() means: "pagination page AND archive page simultaneously." Homepage pagination (/page/2/) does not match the is_archive() condition, so its indexing is preserved.

Which option to choose:

How to verify the result

After inserting the code, check three things.

First, source code. Open any pagination page, Ctrl+U, search for <meta name="robots". Make sure you see content="noindex, follow", not content="index, follow".

Second, Google Search Console. Go to the URL inspection tool, paste the paginated page address and click "Test." In the "Indexing" block you will see the status: "Page is not indexed" with the reason "Excluded by noindex tag." This confirms that Googlebot received and processed the directive.

Third, index dynamics. In Search Console open "Index" → "Pages." Within 2-4 weeks after implementing the code you will see a growth in pages with the "Excluded by noindex tag" status and a reduction in indexed paginated URLs. The process is not instant: Googlebot must recrawl each URL to read the new tag.

Important limitations and precautions

The code changes site-wide behavior. Before implementing, make sure you understand the consequences.

Suddenly dropping thousands of pages from the index may temporarily cause a traffic dip. If the site lived with pagination indexing for several years and some subpages received search traffic, you will lose those visits. In return you will free up crawl budget for pages that actually should rank. But an adaptation period of 3-6 weeks is inevitable.

Make a backup of functions.php before editing. A syntax error in PHP code will bring down the entire site (white screen of death). If you use Code Snippets, the plugin will catch the fatal error and deactivate the snippet. If you edit functions.php directly, keep FTP access handy to roll back the file.

If the site has a caching plugin installed (WP Rocket, W3 Total Cache), clear the cache after adding the code. Otherwise old HTML copies of pages without the new robots meta tag will be served to visitors and search engines for several hours or days.

For a more detailed breakdown of all Yoast SEO capabilities, from installation to fine-tuning meta tags, see our guide to setting up Yoast SEO for WordPress.

⁉️🤔 Frequently asked questions

Why did Yoast SEO remove the built-in noindex option for subpages?

Google learned to recognize paginated series through rel="prev" and rel="next" tags and direct users to the first page. Yoast decided that forcing noindex on subpages reduces crawls and interferes with reindexing old articles through links from paginated pages. Yoast's official documentation confirms: the setting was removed from the interface, but the wpseo_robots filter remains for programmatic control.

Is the wpseo_robots filter still supported in 2026?

Yes. The wpseo_robots filter works in current Yoast SEO versions (24.x, 2026) and is documented in the Metadata API on developer.yoast.com. An important change: before version 19.8 the filter allowed returning false to remove the robots meta tag. Starting with 19.8, returning false is ignored; the filter expects only a string ('noindex,follow' or $robots). Both code versions from this article return a string and are fully compatible.

Will the code work if the site has a custom pagination structure?

The is_paged() function relies on the standard WordPress query parameter paged. If pagination is implemented through a custom parameter (for example, ?pg=2 or virtual scrolling), the condition will not trigger. For custom pagination replace is_paged() with a check for the specific query_var: get_query_var('custom_page_var'). Plugins like WP-PageNavi work through the standard paged, so there is no conflict.

How long until Google removes paginated pages from the index?

On average, 2 to 6 weeks. The speed depends on site size and crawl frequency: on a site with daily crawls Googlebot will recrawl main sections in 7-10 days; on a small blog with weekly crawls, in a month. You can speed this up through a manual recrawl request in Search Console ("Index" → "Pages" → select URL → "Request indexing"), but Google processes such requests on a queue basis.

Can pagination be blocked via robots.txt instead of noindex?

Technically yes: Disallow: */page/* in robots.txt will prohibit crawling of paginated URLs. But this is worse than noindex. The reason: robots.txt blocks page crawling, not its indexing. If external links point to a paginated page, Google may index it as a "page without description." At the same time, links from the page itself will also not be crawled, and you will lose weight transfer to posts. noindex, follow solves both tasks: the page is not indexed, but links from it are crawled.

Should you block pagination from indexing in your case

The answer comes down to two factors: site size and whether crawl budget is a scarce resource.

If you have 50 posts and three categories, don't bother. Google will figure out which pages to show in search results, and it will filter out the less valuable ones on its own. The wpseo_robots filter in this scenario is unnecessary complexity.

If you have 500+ posts, dozens of categories, an active blog with tags and date archives, pagination creates hundreds and thousands of URLs that the search engine crawls instead of fresh articles. Enable option 2 (archives) or option 1 (everything), verify the result through source code and Search Console, and give Google 3-4 weeks to recrawl.

The code is reversible: comment out the filter, and within a month all paginated pages will return to the index. No irreversible consequences.