Fix WordPress pagination that Search Console flags as duplicate

The Page indexing report in Search Console fills with URLs ending in /page/2/, /page/3/, and beyond. They sit under "Duplicate without user-selected canonical" or "Alternate page with proper canonical tag", and the count grows every time you publish.

Most of those URLs are not an emergency. A few of them are. Telling the two apart takes about ten minutes inside WordPress.

Paginated archives usually get flagged for one of two reasons. Either a search engine optimization (SEO) plugin points every page in the series back to page one with a canonical tag, or the same posts repeat across category, tag, author, and date archives. The correction is a self-referencing canonical on each paginated URL and fewer archive types, not a blanket noindex.

What the report is telling you

The two statuses mean different things, and only one of them usually needs work.

• "Duplicate without user-selected canonical" means Google found near-identical pages, saw no clear preference in your markup, and picked a version itself.
• "Alternate page with proper canonical tag" means your markup told Google to ignore that URL, which is the tag doing its job.

The second status only becomes a problem when the canonical points somewhere it should not. That is exactly what happens when page two of an archive claims to be page one.

Why WordPress creates the duplicates

WordPress publishes the same post through several paths. One article can appear on the blog index, a category archive, one or more tag archives, an author archive, and a date archive, each with its own pagination.

Titles and descriptions repeat across those pages because the theme builds them from the archive name. The visible content differs only by which ten posts are listed, so near-duplicate signals stack up quickly.

Comment pagination adds another layer on busy posts. When a discussion splits across /comment-page-2/, those URLs enter the index as near copies of the article itself.

Two more variants show up on older installs. Some themes link to /page/1/, which duplicates the archive root, and some setups serve pagination through a query string as well as a path, so the same list is reachable at two addresses.

Find which pattern your site has

Start in Search Console. Open the flagged status, copy one URL, and run it through URL Inspection to see the Google-selected canonical. If Google chose a URL you did not expect, your markup is not clear enough.

Next, load page two of that archive and view the page source. Search for rel="canonical" and read the URL inside it. A self-referencing canonical points at page two. A misconfigured one points at the archive root.

Then open your SEO plugin. In Yoast, archive controls sit under Search Appearance and then Taxonomies. In Rank Math, the equivalent settings live under Titles and Meta. Check which archive types are still set to appear in search results.

Finish by checking scale. Sort the flagged URLs and count how many belong to tag archives against category archives. A handful of category pages is routine housekeeping. Several hundred tag pages points at a taxonomy problem rather than a canonical problem.

The fix that keeps archive pages indexable

Give every paginated URL a canonical that points to itself. Google treats page two as a separate page with a separate list of posts, and its documentation advises against canonicalizing a sequence back to the first page.

Make the titles unique. Most SEO plugins append the page number once that setting is enabled. If the theme hardcodes archive titles, the page number has to be added in the template, which is theme and template work rather than a plugin toggle.

Switch off archives that never earn traffic. Date and author archives rarely help a single-author site, and disabling them removes whole sets of duplicate URLs instead of patching them one at a time.

Keep internal links and the sitemap pointing at the same URLs you marked canonical. Mixed signals slow down reprocessing, because a sitemap entry and a canonical tag that disagree leave the decision back with Google.

Keep pagination links as plain anchor tags. Infinite scroll and load-more buttons hide older posts from crawlers unless real URLs sit behind them.

Three habits that make it worse

The first is canonicalizing every paginated URL to page one. Google treats a canonical as a strong hint rather than an instruction, and when the content clearly differs it often picks its own version anyway. You lose control without gaining consolidation.

The second is relying on rel="next" and rel="prev" to solve indexing. Google stopped using those tags as an indexing signal years ago. They cause no harm, but nothing gets fixed by adding them.

The third is applying noindex to the whole archive. If that archive is the only crawl path to older posts, those posts lose internal links and fade out of the index over the following months.

Where this belongs on your priority list

Pagination duplicates rarely cause a ranking drop on service or product pages. Google usually consolidates the archive on its own, so the report tends to look worse than the effect on traffic.

It matters more when the archive is the main path to older content, when thousands of tag pages exist, or when crawl coverage is already thin. On a small site with a few hundred posts, correct the canonical settings once and spend the remaining time on pages that earn clicks.

Expect the report to lag. Google recrawls archive pages on its own schedule, and a corrected canonical often takes several weeks to show as a status change. Confirm the fix in URL Inspection rather than waiting for the chart to move.

If the flagged count keeps climbing after the canonical settings are correct, the cause usually sits elsewhere in the crawl setup. That review is part of search and AI visibility work, and you can start with Get Free Assessment.