Using rel = prev/next/canonical with the pagination of frequently updated content

Question

I am confused about what would be the proper markup for a paginated series, even after reading quite a lot of advice, from google included.

The common wisdom seems to be this:

• Use rel="next" to point to each subsequent page in a series, rel="prev" to go backwards.

• Either rel="canonical" each paginated page to itself OR rel="canonical" all of them to a "wiew all" version OR don't do it at all.

My problem is that this setup seems to assume a rather static setup, such as online stores.

But how about blogging/publishing?

1st of all, posts are displayed newest first so rel="next" for previous posts is not too intuitive, to say the least. Wolud it be more useful if it were rel="prev" for older entries?

2nd, with content being updated constantly, the content of a paginated url will change with every post published until eventually page 2 becomes page 3 and so on. Do these pages even deserve an indexed link of their own?

3rd, a "view all" is certainly not an option with hundreds of posts or more.

So what's the best route to take?

1. Follow common wisdom.

2. Just reverse direction to make sure that older posts are "prev" and newer are "next".

3. Rel-canonical pages to entry page without prev / next.

4. Rel-canonical to entry page but also use prev / next.

5. Noindex and/or nofollow all subsequent pages and forget about them.

Or something else?

Update - expected user behavior:

Paginated archives are not unique content but rather a quick reference for what else a site (or an author etc.) wrote in the past.

So readers would e.g. click on an authors name to see what else they wrote and thus get the latest entries. If they want to see even more, they'd use pagination.

If somebody gets to the list via google (after let's say searching for "articles by X") that's fine too. But I see little point in people landing on example.com/author-X/page/3 just because they searched about "articles by X about zebras" and that's where one of the zebra posts is currently index. In this case, I'd rather have google take the searcher to the zebra post itself.

Answer 1

1st of all, posts are displayed newest first so rel="next" for previous posts is not too intuitive, to say the least. Wolud it be more useful if it were rel="prev" for older entries?

rel="next" specifies the next item of a logical sequence, it does not mean "the newer published posts", but "the next page of this series of pages", which in this context is the previous published posts page

2nd, with content being updated constantly, the content of a paginated url will change with every post published until eventually page 2 becomes page 3 and so on. Do these pages even deserve an indexed link of their own?

If having a list of posts for each author from older to newer makes sense then their pages will be "fixed" and you won't have the changing pages content problem.

If the order of your post lists is from newest to older, your paginated lists will contain a list of post that will be changing their URLs often as you say, so Google will detect that and increase their crawling rate there, visiting them often.

From personal experience it is unlikely to visit a paginated list of pages out of synch, or even a page from that list from Google, it has only happened to me in forum posts that sometimes the page cached in Google didn't contain the post I was looking for but it was on older pages in the thread.

In the example you gave, looking for "articles by X about zebras" I think it would make more sense if Google shows directly the link to the post about zebras in SERP, which will also have the author in the page, instead of a link to the post in a list of author posts (but that will depend on the titles and description of list/post).

3rd, a "view all" is certainly not an option with hundreds of posts or more.

As Webmaster guidelines suggests:

Limit the number of links on a page to a reasonable number (a few thousand at most).

My suggestion is:

• keep the order from newer to older, as this is what people expects from posts lists in blogs (not the other way around)
• implement rel="next" and rel="prev" links to indicate the relationship between URLs and trust Google will keep crawling them often.
• Monitor search queries and landing pages in Search Console to see if you are receiving traffic to you paginated content or directly to posts.

Answer 2

But how about blogging/publishing?

You seem to misunderstand what rel next/prev is for.

Any time you've split content, you can suggest to Google it's one large meta-post instead of each page being indexed as separate content. Otherwise page 2 of your guide is going to be indexed heavily for keyword xxx whereas people should read it from the beginning to get context.

Your blog posts are not one large piece of content. They're lots of separate pieces. Disregard how a user would navigate between content and focus on if they should or shouldn't land in the middle of multi-page content.

An example of where prev/next is necessary is a 10 page published post on 'how to clean up your Javascript'. Or a static directory of 3,000 popular links, which has been split into 30 pages of 100 links.

Answer 3

Ok, so what I did in the end was to take the long way round. For this one I'll be using the date-based archives for pagination and linking the series to the homepage as the starting point. So my code that goes in the header looks like this:

<? if(is_home()) { ?>
<link rel="prev" type="text/html" href="/<? echo date('Y-m-d'); ?>" /> 
<? } 
if(is_day()) { 
$date = isset($_GET['date']) ? $_GET['date'] : get_the_time('Y-m-d'); 
$today = date('Y-m-d');
$oldest = '[get the date of the first post somehow or just hardcode it as I did]'; 
if ($date != $oldest) { ?>
<link rel="prev" type="text/html" href="/<? echo date('Y-m-d', strtotime($date .' -1 day')); ?>" /> 
<? } if ($date != $today) { ?>
<link rel="next" type="text/html" href="/<? echo date('Y-m-d', strtotime($date .' +1 day')); ?>" /> 
<? } if ($date == $today) { ?>
<link rel="next" type="text/html" href="/" /> 
<? } } ?>

It works well for the current concept, as there will be no less than 10 and no more than 20 posts every day.

Advantages

1. Now things make a lot more sense, as 'previous' is always a date in the past.

2. Content stays in place, so it even makes sense to have a rel=canonical on each page while rel=prev/next tells googlebot that it's part of a series.

3. Getting rid of classical pagination links so less duplicate content. Usually one would keep those and get rid of the archives to attain the same purpose, but I think this way it's more intuitive.

Caveats

1. You need to publish at least one post every day or the chain will be broken. This can be solved with more coding (only get dates with published posts), but I don't need that myself.

2. The first post of the day better be published at exactly midnight, else the homepage will point to an empty archive until you post something. Again, more code would solve this as well.

3. Doing it for each taxonomy term is possible but a bit more complicated (back to #1 and #2). For now i'd rather set the loop limit to something like 100 on archives and see later where this goes.

Conclusion

Basically, archived pages in fixed increments are suboptimal for publishing - date-based archives fare a bit better, but for now you're on your own out there.