Pagination on Blog and Doctor Listings After rel=prev/next: What Still Works

This post is for the marketing manager or SEO of a healthcare site with two long lists: a doctor directory of several hundred profiles, and a blog archive of several hundred posts. Both have to be broken into pages somehow, and the way you do it decides whether Google can find the individual doctors and articles at the bottom of the list.

Many teams still have a memory of rel="prev" and rel="next" as the SEO answer to pagination. That advice is out of date. This post explains what replaced it, compares the three common patterns on two realistic cases, and gives you a way to test your own listing with a crawl.

It assumes the basics: you know what a canonical tag is and how to read a Search Console report. If you want the broader picture first, our overview of healthcare SEO in 2026 and the post on website best practices for speed, accessibility and SEO cover the ground this builds on.

What Google says now

Google's page on pagination and incremental page loading is direct on the main points:

• Google no longer uses <link rel="next"> and <link rel="prev">. Other search engines may still use them, and they do no harm, but Google does not rely on them.
• Do not use the first page of a sequence as the canonical for every page. Give each page its own canonical URL.
• "Load more" and infinite scroll are usually built with JavaScript, and Google does not click buttons or trigger scripts that need user action, so content behind them may not be found.
• Google generally follows URLs in <a href> elements. Link pages in sequence with real anchors, and consider a sitemap to help Google find all items.

The practical reading: each page of results should be a real URL, reachable by a real link, with its own canonical, and the items on it should link to their own pages. Everything else is a question of how many items to put on each page.

Why this matters for doctor and blog lists

Google reaches a profile or article through links. If the only route to an old blog post is page 37 of an archive, and page 37 is reachable only by clicking a "Load more" button 36 times, then to a crawler that post is close to orphaned. It may still be found through the sitemap, but internal links are the stronger discovery path and the one that passes context.

The same applies to a doctor directory. The specialist at position 600 in an alphabetical list is invisible unless there are links that reach their profile.

The three patterns compared

Pattern 1: View-all (one long page)

All 800 doctors or 400 posts on one URL.

Strengths. One URL, one canonical, every item linked from one place. Nothing to paginate.

Weaknesses. Page weight and render time grow with the list. An 800-item page with images is slow on the mobile connections many patients use, which affects Core Web Vitals and usability. Lazy loading helps, but the item links must be in the HTML. It also becomes hard to navigate.

Where it fits. Small lists (a few dozen items) or an A-to-Z index of lightweight text links. A single page with 800 doctor names as text links, no photographs and a jump menu can work. An 800-card page with photographs and rating widgets usually will not.

Pattern 2: Load-more or infinite scroll

The page shows 20 items, and more are fetched by script.

Strengths. Smooth experience for users who browse.

Weaknesses. Without a crawlable fallback, items beyond the first batch may never be discovered. Google's guidance says that content which needs a click or scroll to trigger a script may not be found.

How to make it work. Build it as progressive enhancement on top of numbered pages. Each "page" must exist as its own URL (/doctors/?page=2), reachable by a real <a href>. The script then enhances the experience by loading the next page's items in place and updating the address with the History API. Without the script, the link goes to page 2. Google's JavaScript guidance also says single-page apps should use the History API rather than URL fragments.

Pattern 3: Numbered pages (classic pagination)

Twenty to fifty items per page, with links to previous, next and numbered pages.

Strengths. Every page is a stable URL. Easy to crawl and measure. Works without JavaScript.

Weaknesses. Deep pages are many clicks from the top. A long run of "Next" links makes the final page far from the home page. Users rarely go beyond a few pages.

How to improve. Add links to the first and last pages and to several pages around the current one, so crawl depth stays low. Show a larger page size if performance allows. Link to category and specialty pages so items are reachable by more than one route.

A decision table for the two cases

The most reliable fix for an 800-doctor list is to avoid having one 800-item list at all. Split it by specialty and by location, so each list has a natural size. A specialty page with 25 cardiologists does not need pagination.

Practical details for the blog archive

A 400-post health blog usually ages badly under pure date-ordered pagination. New posts push older ones one slot deeper every time something is published, so a post that sat on page 3 last year now sits on page 20. Its internal link path gets longer without anyone touching it.

Three habits reduce that problem. First, build topic hubs: a page for each major subject (diabetes, maternal health, orthopaedics) that links to the best posts on it, whatever their date. Second, link new posts to older relevant ones in the body text, so older articles gain a second route that does not depend on the archive. Third, give each post breadcrumbs that include its category, so the category archive, which is shorter than the main archive, becomes a natural parent.

Clinical content also ages. A post that discusses guidance or screening intervals needs a review date and a named reviewer. Pagination can bury a stale article where nobody sees it, yet it remains indexed and can still be found by a search. Use the same crawl to list every post beyond a certain depth and send that list to the clinical reviewer, who can decide whether each one is updated, merged or removed.

Practical details for the doctor directory

For the directory, the item that matters is the profile page, not the list. Check that each profile has at least two internal routes: one from its specialty list and one from its location or department page. If a doctor appears only in a deep page of an alphabetical list, the profile has a single weak route.

Keep list pages light. A card should hold a name, specialty, location and a link, not a full biography. If the card shows availability or a rating, make sure those values load without delaying the links. Where the list is filtered, apply the facet rules in your decision matrix so that only worthwhile combinations become paginated, indexable URLs.

Rules that apply to all three

1. Self-referencing canonicals. Page 2 canonicalises to page 2.
2. Distinct titles and headings if indexable. "Cardiologists in Pune, page 2" is better than repeating the page 1 title. Some sites choose to noindex deep pages; that is a business choice, but Google needs to follow links through them if it is to discover items, so consider keeping them indexable and crawlable.
3. Real anchors. Use <a href> for next, previous and numbered links.
4. 404 for out-of-range pages. Page 99 of a list with 12 pages should return 404, not an empty 200.
5. Stable ordering. If new posts shift older posts to later pages every day, links to them change. For blogs, category hubs and "related" modules help older content stay close to the top.
6. Sitemaps for items. List the item URLs (doctors, posts) in the sitemap, not the pagination pages.
7. Avoid parameter chaos. Keep a fixed parameter order, and keep sort options from creating new indexable URLs.

The test: crawl one listing with three patterns

This is a method for your own site. We do not report outcomes.

1. Choose one listing, such as the blog archive.
2. Make three staging copies, one for each pattern, or use the pattern you currently have as a baseline and add the others one at a time.
3. Crawl each version with a crawler that does not execute JavaScript, and again with JavaScript rendering enabled.
4. For each crawl, record: the number of item URLs discovered, the click depth of the deepest item, the number of pagination URLs, and the page weight of the list page.
5. Compare discovery against the sitemap. Any item in the sitemap but not found by crawling the links is an orphan under that pattern.
6. In Search Console, after launch, watch the indexed count for the item URLs, and the Page indexing report for the pagination URLs.

If the non-JavaScript crawl finds fewer items than the rendered crawl, your list depends on scripts to be navigated.

Where to start

• Count the items in each listing and the click depth of the last one.
• Run a non-JavaScript crawl and compare with the sitemap.
• Replace any load-more button that is not backed by a real link.
• Split long lists by specialty, city or topic so each list is a natural size.
• Set self-canonicals and 404s for out-of-range pages.

For wider technical work on listings and crawling, see our technical SEO audit.