: Using rel = prev/next/canonical with the pagination of frequently updated content I am confused about what would be the proper markup for a paginated series, even after reading quite a lot of

@Sarah324

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


Now things make a lot more sense, as 'previous' is always a date in the past.
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.
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


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.
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.
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.

Vote Up Vote Down

@Samaraweera270

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.

Vote Up Vote Down

@Alves908

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.

Vote Up Vote Down