A few weeks ago, a llama posed a seemingly simple question: “Does anyone know the details of canonical URLs and pagination?”. But here’s the thing about llamas – we don’t do well with non-definitive answers. Thus began the digging and twists and turns into the rabbit hole of canonical tags and Magento’s native capabilities.
Here is what we know to be true:
With a site full of content, products, and categories, it’s pretty common for the same content to be on multiple URLs. That’s where Canonical Tags (rel=”canonical”) come in. This tag tells Google what your preferred URL is so that search results will be more likely to show that URL in SERPs. Without using canonical tags in these instances, you can suffer duplicate content issues. In addition, you are forcing Google to decide which to give SEO value to, or splitting its value.
Canonical tags are kind of a hybrid of a NOINDEX tag and a 301. You’re basically telling Google – 1) Don’t show the other pages with similar content in search results, and 2) Push ranking signals to this page. It also reduces a number of resources that Google Bots will spend crawling pages, so it’s a win-win-win.
Paginated content occurs when you have a series. For example, 5 pages of products under the category “Women’s Shirts”. Using tags like the following indicates the relationship between these unique URLs:
The URL string used in pagination tells Google that you want them to treat the series as a logical sequence. This will then link their properties and SEO value while sending searchers to the first page.
How Magento Handles Category Pages
Natively you can turn on or off canonical tags for categories under the Catalog > Search Engine Optimization settings in your store’s configuration. Turning this setting on adds the
rel=”canonical” link tag to all category pages.
This is helpful for telling search engines what the “main” version of your category page is. If you’re using layered navigation to filter a category, parameters are added to the URL for each filter which can create many variations of your main category URL. The canonical tag tells search engines to treat all of those variations of the category as if they are the “main” canonical version. Therefore any SEO value these variations provide is transferred to your main category URL.
The same is true for pagination parameters. From page 2 on, a parameter such as ?p=2 will be added to the main URL to indicate which page of the category you are on. The canonical tag is going to tell the search engine to only show the “main” version of the page in search results, but transfer any link value of the additional pages to the canonical URL, because it is likely not going to index any of the following pages. However, a canonical tag is designed to be used on pages that contain the same (or very similar) content. On a category product listing page, your category description and some content may be the same on each version, but the products listed on the page will be different for each page. That’s the whole point of pagination- to break up a large category into multiple pages. So, this presents a conflict in the way a canonical tag is meant to be used.
What do those facts tell us?
We can surmise from the above that with your Magento store, you can either tell Google that the first page in a series is the most important or let Google decide on its own. Those are currently your only two options.
Notice that there is an option recommended by Google that isn’t natively available with Magento: Use
rel=“prev” to indicate the relationship between component URLs. Without that option, how does one create that synchronicity in the series other than just hoping Google will figure it out? This leads to more questions – Is Magento’s default way of handling this all wrong? And does it really matter if they aren’t in line with Google’s recommendations? And then all of our heads exploded, because WHAT THE HECK. Further research and a lot of discussions have led us to some answers for these questions.
What are the potential ramifications of doing this incorrectly?
The damage occurs in a few ways. If you enable canonical tags, you’re losing potentially valuable keywords because you’re telling Google to ignore everything after the first page. If you don’t, then you run the risk of creating duplicate content issues and/or Google simply not recognizing the pagination at all.
In addition, we have also theorized that if you are migrating from a different platform that might have employed rel=next/prev, and then move to Magento where your URL structure will undoubtedly change, you can create some very undesirable results by canonicalizing one page (effectively asking Google to ignore the series). You have a strong possibility of really damaging your SEO and seeing a big dip in organic traffic, because you are pushing Google to ignore content that it previously crawled, devaluing your pages.
What is the right course of action?
Option 1, Do Nothing. This isn’t a great option. Yes, Google is pretty smart. But you’re relying on “hopefully they get what we’re trying to do” rather than explicitly stating your preference, and you’re leaving the SEO value of those pages to chance.
Option 2, Enabling a ‘View All’ page. This is great… if you have a small catalog. If ‘View All’ produces a page with 500 products your user experience just tanked due to slow site speed and you’re increasing the potential to lose that customer. This would only solve the problem in combination with the right customization: Enabling a “View All” page on your categories doesn’t automatically make that the URL that is used for the canonical link tag. We would have to customize Magento to do so.
That leaves us with Option 3: Use
rel=”prev”, which is what we are recommending. Hallelujah, we have an answer! Well, kind of.
We’ve had a lot of internal discussions about scenarios in which it would make sense to set a canonical tag in conjunction with rel-”next/prev”. In each scenario, it wouldn’t ever have been an issue if the URL structure was set to best practice. However, let’s say for some reason yours isn’t set to best practices, and you are not currently in the position to change that, you would want to set a canonical tag on the first page so that you don’t run into duplicate content issues, and in addition use rel=next/prev to identify pagination.
An example of this would be:
A site has a direct link to “Women’s Shirts” at
store.com/womensshirts, but this category can also be navigated to through a subcategory where the URL then changes to
store.com/womens/womensshirts. You would then want to set the canonical tag to the main category page but also include next/prev so that all pages are indexed, and also so that you do not encounter any duplicate content issues. This is one of those rabbit hole situations I referred to earlier. Because technically, having both of these categories/subcategories with the same content but a different URL path is a wrong taxonomy. Best SEO practices dictate that no matter how you navigate to a page, the URL should be the same. This example isn’t a very clean way to handle pagination and is really only a band-aid because in general, cleaning up your URL structure will solve a lot of “what if” scenarios concerning canonical or next/prev.
So, Magento didn’t technically get it “wrong”. But a broad-sweeping approach, which is what the native functionality does, won’t work for the vast majority of Magento clients. Each case should be evaluated individually to determine the best course of action.
Identifying that using rel=next/prev rather than a canonical tag on the first page is only the first step to solving this problem. Currently, Magento does not have a native setting for using next/prev. Here at Classy Llama, we are currently working on an extension that we can use going forward* as next/prev will be the answer more times than it’s not. Having something on hand will not only save us and our clients time and money in the long run but will also reduce the risk of lost revenue when combined with other SEO practices.
Overall, technical SEO has become a big focus for Classy Llama, both in Marketing Services and on the Development teams. Keep an eye out in the coming months for a lot more information from us on the importance of this and how you can redesign or migrate your site without losing traffic and revenue.
* Update December 16th, 2017: This functionality now exists as a part of the Rebar package that is available to all Classy Llama clients.