Rel="prev" / "next"
-
Hi guys,
The tech department implemented rel="prev" and rel="next" on this website a long time ago.
We also added a canonical tag to the 'own' page.We're talking about the following situation:
However we still see a situation where a lot of paginated pages are visible in the SERP.
Is this just a case of rel="prev" and "next" being directives to Google?
And in this specific case, Google deciding to not only show the 1st page in the SERP, but still show most of the paginated pages in the SERP?Please let me know, what you think.
Regards,
Tom -
Interesting development which may be of interest to you Ernst:
Google admitted just the other day that they "haven't supported rel=next/prev for years." https://searchengineland.com/google-apologizes-for-relnext-prev-mixup-314494
"Should you remove the markup? Probably not. Google has communicated this morning in a video hangout that while it may not use rel=next/prev for search, it can still be used by other search engines and by browsers, among other reasons. So while Google may not use it for search indexing, rel=prev/next can still be useful for users. Specifically some browsers might use those annotations for things like prefetching and accessibility purposes."
-
I was looking into this today and happened across this line in Google's Search Console Help documents:
rel="next" and rel="prev" are compatible with rel="canonical" values. You can include both declarations in the same page. For example, a page can contain both of the following HTML tags:
Here's the link to the doc - https://support.google.com/webmasters/answer/1663744?hl=en
But I wouldn't be using a canonical to somewhere else and the rel="next" directives.
-
I had never actually considered that. My thought is, no. I'd literally just leave canonicals entirely off ambiguous URLs like that. Have seen a lot of instances lately where over-zealous sculpting has led to loss of traffic. In the instance of this exact comment / reply, it's just my hunch here. I'd just remove the tag entirely. There's always risk in adding layers of unrequired complexity, even if it's not immediately obvious
-
I'm going to second what @effectdigital is outlining here. Google does what they want, and sometimes they index paginated pages on your site. If you have things setup properly and you are still seeing paginated pages when you do a site: search in Google then you likely need to strengthen your content elsewhere because Google still sees these paginated URLs as authoritative for your domain.
I have a question for you @effectdigital - Do you still self-canonical with rel= prev / next? I mean, I knew that you wouldn't want to canonical to another URL, but I hadn't really thought about the self-canonical until I read something you said above. Hadn't really thought about that one haha.
Thanks!
-
Both are directives to google. All of the "rel=" links are directives, including hreflang, alternate/mobile, AMP, prev/next
It's not really necessary to use a canonical tag in addition to any of the other "rel=" family links
A canonical tag says to Google: "I am not the real version of this page, I am non-canonical. For the canonical version of the page, please follow this canonical tag. Don't index me at all, index the canonical destination URL"
The pagination based prev/next links say to Google: "I am the main version of this page, or one of the other paginated URLs. Did you know, if you follow this link - you can find and index more pages of content if you want to"
So the problem you create by using both, is creating the following dialogue to Google:
1.) "Hey Google. Follow this link to index paginated URLs if they happen to have useful content on"
*Google goes to paginated URL
2.) "WHAT ARE YOU DOING HERE Google!? I am not canonical, go back where you came from #buildawall"
*Google goes backwards to non-paginated URL
3.) "Hey Google. Follow this link to index paginated URLs if they happen to have useful content on"
*Google goes to paginated URL
4.) "WHAT ARE YOU DOING HERE Google!? I am not canonical, go back where you came from"
*Google goes backwards to non-paginated URL
... etc.
As you can see, it's confusing to tell Google to crawl and index URLs with one tag, then tell them not to with another. All your indexation factors (canonical tags, other rel links, robots tags, HTTP header X-Robots, sitemap, robots.txt files) should tell the SAME, logical story (not different stories, which contradict each other directly)
If you point to a web page via any indexation method (rel links, sitemap links) then don't turn around and say, actually no I've changed my mind I don't want this page indexed (by 'canonicalling' that URL elsewhere). If you didn't want a page to be indexed, then don't even point to it via other indexation methods
A) If you do want those URLs to be indexed by Google:
1) Keep in mind that by using rel prev/next, Google will know they are pagination URLs and won't weight them very strongly. If however, Google decides that some paginated content is very useful - it may decide to rank such URLs
2) If you want this, remove the canonical tags and leave rel=prev/next deployment as-is
B) If you don't want those URLs to be indexed by Google:
1) This is only a directive, Google can disregard it but it will be much more effective as you won't be contradicting yourself
2) Remove the rel= prev / next stuff completely from paginated URLs. Leave the canonical tag in place and also add a Meta no-index tag to paginated URLs
Keep in mind that, just because you block Google from indexing the paginated URLs, it doesn't necessarily mean that the non-paginated URLs will rank in the same place (with the same power) as the paginated URLs (which will be, mostly lost from the rankings). You may get lucky in that area, you may not (depending upon the content similarity of both URLs, depending whether or not Google's perceived reason to rank that URL - hinged strongly on a piece of content that exists only in the paginated URL variant)
My advice? Don't be a control freak and use option (B). Instead use option (A). Free traffic is free traffic, don't turn your nose up at it
Got a burning SEO question?
Subscribe to Moz Pro to gain full access to Q&A, answer questions, and ask your own.
Browse Questions
Explore more categories
-
Moz Tools
Chat with the community about the Moz tools.
-
SEO Tactics
Discuss the SEO process with fellow marketers
-
Community
Discuss industry events, jobs, and news!
-
Digital Marketing
Chat about tactics outside of SEO
-
Research & Trends
Dive into research and trends in the search industry.
-
Support
Connect on product support and feature requests.
Related Questions
-
Optimization for "Search by Photos" feature
Howdy, fellow mozzers, Does anyone know what affects a given company photos show up in the "Search by Photos" section? I can't find any decent info.. Here is the link to SEL, describing the feature (not even google themselves seem to have an announcement about it). https://searchengineland.com/google-showing-mobile-search-by-photos-option-in-selected-local-verticals-323237 Thanks in advance!
Intermediate & Advanced SEO | | DmitriiK0 -
How to Rank for "Interesting Finds" on Google Mobile?
Hi! Some of the sites I work with, when doing searches for their top terms, I am seeing some articles listed under "Interesting Finds". I have read some people thought it deals with AMP, others do not. Some thing it has to do with the structured data added to the page, some do not. Does anyone have a definitive answer on how to increase your chances of being listed here? Any example is attached. Any ideas? Uoi4Jyh
Intermediate & Advanced SEO | | vetofunk0 -
Internal search pages (and faceted navigation) solutions for 2018! Canonical or meta robots "noindex,follow"?
There seems to conflicting information on how best to handle internal search results pages. To recap - they are problematic because these pages generally result in lots of query parameters being appended to the URL string for every kind of search - whilst the title, meta-description and general framework of the page remain the same - which is flagged in Moz Pro Site Crawl - as duplicate, meta descriptions/h1s etc. The general advice these days is NOT to disallow these pages in robots.txt anymore - because there is still value in their being crawled for all the links that appear on the page. But in order to handle the duplicate issues - the advice varies into two camps on what to do: 1. Add meta robots tag - with "noindex,follow" to the page
Intermediate & Advanced SEO | | SWEMII
This means the page will not be indexed with all it's myriad queries and parameters. And so takes care of any duplicate meta /markup issues - but any other links from the page can still be crawled and indexed = better crawling, indexing of the site, however you lose any value the page itself might bring.
This is the advice Yoast recommends in 2017 : https://yoast.com/blocking-your-sites-search-results/ - who are adamant that Google just doesn't like or want to serve this kind of page anyway... 2. Just add a canonical link tag - this will ensure that the search results page is still indexed as well.
All the different query string URLs, and the array of results they serve - are 'canonicalised' as the same.
However - this seems a bit duplicitous as the results in the page body could all be very different. Also - all the paginated results pages - would be 'canonicalised' to the main search page - which we know Google states is not correct implementation of canonical tag
https://webmasters.googleblog.com/2013/04/5-common-mistakes-with-relcanonical.html this picks up on this older discussion here from 2012
https://moz.com/community/q/internal-search-rel-canonical-vs-noindex-vs-robots-txt
Where the advice was leaning towards using canonicals because the user was seeing a percentage of inbound into these search result pages - but i wonder if it will still be the case ? As the older discussion is now 6 years old - just wondering if there is any new approach or how others have chosen to handle internal search I think a lot of the same issues occur with faceted navigation as discussed here in 2017
https://moz.com/blog/large-site-seo-basics-faceted-navigation1 -
Should I put rel next and rel prev and canonical on tags pages
Hi I have a tag pages on a news website each tag page is divided to several pages, but Google does't crawled those pages because the links are in javaScript, I want to do the following things: Change the links to html href Add rel=pref rel=next Add a canonical in each page with the url of the main tag page Do you agree with my solution? Thanks Roy
Intermediate & Advanced SEO | | kadut1 -
Rel=Alternate on Paginated Pages
I've a question about setting up the rel=alternate & rel=canonical tags between desktop and a dedicated mobile site in specific regards to paginated pages. On the desktop and mobile site, all paginated pages have the rel=canonical set towards a single URL as per usual. On the desktop site though, should the rel=alternate be to the relevant paginated page on the mobile site (ie a different rel=alternate on every paginated page) or to a single URL just as it is vice versa. Cheers chaps.
Intermediate & Advanced SEO | | eventurerob1 -
"No Index, No Follow" or No Index, Follow" for URLs with Thin Content?
Greetings MOZ community: If I have a site with about 200 thin content pages that I want Google to remove from their index, should I set them to "No Index, No Follow" or to "No Index, Follow"? My SEO firm has advised me to set them to "No Index, Follow" but on a recent MOZ help forum post someone suggested "No Index, No Follow". The MOZ poster said that telling Google the content was should not be indexed but the links should be followed was inconstant and could get me into trouble. This make a lot of sense. What is proper form? As background, I think I have recently been hit with a Panda 4.0 penalty for thin content. I have several hundred URLs with less than 50 words and want them de-indexed. My site is a commercial real estate site and the listings apparently have too little content. Thanks, Alan
Intermediate & Advanced SEO | | Kingalan10 -
Sitemaps / Google Indexing / Submitted
We just submitted a new sitemap to google for our new rails app - http://www.thesquarefoot.com/sitemap.xml Which has over 1,400 pages, however Google is only seeing 114. About 1,200 are in the listings folder / 250 blog posts / and 15 landing pages. Any help would be appreciated! Aron sitemap.png
Intermediate & Advanced SEO | | TheSquareFoot0 -
<rel canonical="">and Query Strings</rel>
How are you supposed to <rel canonical="" tag="">a page with a query string that has already been indexed? It's not like you're serving that page from a CMS where you have an original page with content to add to the head tag.</rel> For example.... Original Page = http://www.example.com/about/products.php Query String Page = http://www.example.com/about/products.php?src=FrontDoorBox Would adding the <rel canonical="" tag="">to the original page, referencing itself, be the solution so that the next time the original page is crawled, the bot will know that the previously indexed URL with query string should actually be the "original"? That's the only solution I can come up with because there's no way to find the query string rendered page to tag with the canonical.....</rel>
Intermediate & Advanced SEO | | Yun0