Does WordPress need rel="next" and rel="prev" on paginated pages?

What core does on paginated pages

Take a blog index or category with more posts than fit on one page. WordPress creates /page/2/, /page/3/ and so on, and for each of them:

• Title. Core appends the page number to the document title: Brewing – Page 2 – Site Name. That keeps titles unique across the series.
• Robots. The same default as any public page, so paginated pages are indexable.
• Canonical. None. Core prints a canonical tag on single posts and pages only, not on archives.
• Head link tags for the series. None. There is no <link rel="next"> or <link rel="prev"> in the head from core.
• Navigation. The theme prints "Older posts", "Newer posts" or numbered links in the page body. These are plain <a href> links.

Core does contain a function that prints head links to the previous and next single posts, but it is not attached to the page head by default, and it was about adjacent articles, not paginated lists.

SEO plugins often add rel="next" and rel="prev" tags to archives. They are valid HTML and harmless. They are also unnecessary for Google.

What Google says about pagination now

Google's guidance for paginated content comes down to three points:

1. Link the pages sequentially with normal anchor links, so the crawler can walk from page 1 to 2 to 3.
2. Give each page its own URL, and do not use fragment identifiers (#page=2) for page numbers, since Google ignores fragments.
3. Do not make page one the canonical of the others. Each page in the series lists different items, so each should be canonical to itself.

It also notes that Google no longer uses rel="next" and rel="prev", while acknowledging other search engines may. So the markup is optional; the links in the body are what carry the weight.

Default WordPress pagination meets all three points without any configuration. Problems arrive with customisation.

Ways pagination gets broken

"Load more" buttons and infinite scroll with no links. If further posts appear only when a script runs on click or scroll, and there is no href to /page/2/, crawlers cannot reach older posts through the archive. Keep real paginated URLs behind the button; most infinite scroll implementations for WordPress can do this.

Canonical to page one. A setting or snippet that points every /page/N/ at the first page tells Google the deeper pages are duplicates. Posts linked only from those pages lose their crawl path. Hydrogen SEO gives each paginated archive page a self-referencing canonical; see canonical URLs.

Noindexing page 2 onward. Sometimes recommended to keep "thin" list pages out of results. On a blog where old posts are reachable only through pagination, those list pages are the crawl path to your archive, and taking them out of the index risks weakening it. Leave them indexable, or make sure every post has another path: category pages, internal links, an HTML sitemap.

Very deep series. With 10 posts per page and 2,000 posts, the oldest article is 200 clicks from the homepage by pagination alone. Raising the posts-per-page number helps a little; real internal links help much more. The orphan pages guide shows how to find posts with no links from other content.

A short checklist

• Open /page/2/ of your blog and a category. Confirm it returns 200 and lists different posts from page 1.
• View source and search for rel="canonical". If present, it should name the page you are on.
• Check the title contains the page number, so page 2 is not a duplicate title of page 1.
• Disable JavaScript and confirm you can still reach page 2 by a link.
• Search the head for rel="next". Present or absent, it needs no action.
• Request a page number far past the end, such as /page/9999/. WordPress should answer 404, not an empty 200 page.

That last behaviour is built in: core returns a 404 when a paginated request finds no posts.