New Google metatags for multiple pages

[avalonwine]

Google recently announced the way to use meta tags to indicate to the bot that a group of pages are a multiple page list of products.

See the contents of the google blog info at the bottom of this topic.

Is there a way to do this in shopsite? I can add the metatag to the first page easily, I have a special template for paginated pages. But how do I add the metas to the 2nd, third, etc. pages?

I was thinking that there might be a way to say

[IF PRODUCTS ON THIS PAGE ARE 1-50] [METATAG 1] [OR] [IF PRODUCTS ON THIS PAGE ARE 51-100] [METATAG 2]

etc etc.

Is there a way to "see" that the page is number 2, number 3 etc and put the different metatag on it? Seems like there might be something that could be used in an if-then form...

Description of new muti-page tags:

Google’s latest blog post provides details and a video from Maile Ohye about how they handle the pagination attributes within a page’s source code. You can use these attributes to indicate pages in a series (such as a multi-page article or set of product listings), which enables Google to cluster the pages into a single entity and combine their indexing and other properties (such as incoming link value). Using these attributes is trickier than it may seem at first glance, so below, a few tips from the blog post, video, and the recent SMX West session I moderated, which featured Maile. (Keep in mind that currently, only Google supports these attributes.)
How the Pagination Attributes Work

The pagination attributes can be used for any set of content that spans multiple pages. Typical scenarios include multi-page articles, product listings, and forum discussions. Simply use the rel=next and rel=prev attributes to link all pages in a series together. For the following set of pages:

www.site.com/products?page=1
www.site.com/products?page=2
www.site.com/products?page=3

The pagination attributes would be as follows:

Page 1:

<link rel=”next” href=”http://www.site.com/products?page=2″>

Page 2:

<link rel=”prev” href=”http://www.site.com/products?page=1″>

<link rel=”next” href=”http://www.site.com/products?page=3″>

Page 3:

<link rel=”prev” href=”http:// site.com/products?page=2″>
When To Use Pagination Attributes Instead of Canonical Attributes

Some sites are set up to use the canonical attributes to point all pages in a series to page one. As Maile points out in the video, this isn’t the correct use of the canonicalization tag (in part because Google only indexes the content on the canonical page, so any content from the rest of the pages in the series would be ignored).

If the paginated content is a subset of the canonical page (such as when you have a view all version or a filtered result set) or is identical (such as when the sort order changes the display but not the content), then use the canonical attribute instead of the pagination attributes.
General Best Practices
Use Absolute URLs

The href values can be absolute or relative (the original version of this article said they had to be absolute, but that version was incorrect). But using absolute URLs is a best practice, both to combat scrapers and in case URLs are duplicated accidentally across directories or subdomains.
The Chain Can’t Be Broken

The rel=”next” and rel=”prev” values must match. If they don’t, the chain is broken. For instance, for the following pages:

www.site.com/products?page=1
www.site.com/products?page=2

The rel=”next” attribute for page=1 must point to page=2 and the rel=”prev” attribute for page=2 must point to page=1.

The pagination attributes can only link together URLs with matching parameters. For instance, the following URLs aren’t considered part of the same series, as the second URL would break the chain:

www.site.com/products?page=1
www.site.com/products?page=2&referrer=twitter
www.site.com/products?page=3

This means that ideally, you should dynamically insert the pagination values based on the fetched URL. In the case of the above example,when Googlebot fetches the page as:

www.site.com/products?page=2&referrer=twitter

The pagination values should be (dynamically inserted as):

<link rel=”prev” href=”http:// www.site.com/products?page=1&referrer=twitter”>

<link rel=”next” href=”http://www.site.com/products?page=3&referrer=twitter”>
Each page can be in only one pagination chain

A page can’t contain multiple rel=”next” attributes.
Multiple pages can’t have the same rel=”prev”.
A page that contains a rel=”canonical” attribute to another page can’t be part of the canonical URLs paginated series. It must be paginated with the URLs that match it (and then Google will use the canonical attributes to consolidate each page accordingly). See more on how this works at the end of this article.

Advanced Techniques

Product listings in particular often have additional complexity, such as sort orders and filtered navigation. It’s best to start with the simplest paginated series and then make canonicalization and pagination decisions for each level of complexity. You can’t specify one view/filter as canonical and point all other versions of the paginated series to that default set.
Viewing and Sorting Options

If a set of product listings has multiple view options and those listings span multiple pages, you have to create a pagination set for each view option separately (since the pages aren’t subsets of a default version). For instance, if you provide options to view 20 products at a time or 100 products at a time and to sort by newest, price, and ratings, you would need to implement a separate paginated series for each view option. As you might imagine, this could cause you to end up with a large number of paginated series’. Shown below are just two of the many possible:

Pagination and Sorting
Filtering (AKA Faceted Navigation)

Things get even more complex when you introduce filters.

If the filtered view is a subset of a single non-filtered page (perhaps the view=100 option), you can use the canonical attribute to point the filtered page to the non-filtered one. However, if the filtered view results in paginated content, this may not be viable (as each page may not be a subset of what you would like to point to as canonical).
If you want the filtered view to rank separately from the default view, you would create a paginated series for each filtered category. You would need to also paginate all of the various sort and view options separately. Take REI.com as an example. The site has a Snowboards section that would likely be paginated and (hopefully) rank for [snowboards] queries. But a filtered view of just Women’s Snowboards, while a subset of the snowboards content would likely be paginated separately in order to rank for [women's snowboards] queries. (On the other hand, REI probably doesn’t want the filter by size version to rank separately, so that variation could be canonicalized.)

Using the Canonical Attribute in Conjunction with the Pagination Attributes

Each URL that’s paginated separately should also contain a canonical attribute. In the case of the earlier example with the optional referrer parameter, for instance, Google will first consolidate the default paginated series separately, and then the paginated series that contained the referrer=twitter parameter separately, but then use the canonical attribute of the pages to further consolidate the pages to the default version. That means that the URL of:

www.site.com/products?page=2&referrer=twitter

Would end up with the following markup:

<link rel=”canonical” href=”http://www. site.com/products?page=2″>

<link rel=”prev” href=”http://www. site.com/products?page=1&referrer=twitter”>

<link rel=”next” href=”http:// www.site.com/products?page=3&referrer=twitter”>
Too Confusing To Implement?

I admit, all of this sounds confusing. But it’s not so bad if you take things step by step:

What is the canonical version of each URL? Add the canonical attribute to the pages.
What is the default view for each paginated series? Add the pagination attributes to these pages.
What views/filters are subsets of broader views? Add the canonical attribute to these pages to point to those broader views.
What views/filters are not subsets of broader views or you want to rank separately? Add separate pagination attributes to these pages to make each a separate series.