Pagination with rel=“next” and rel=“prev”
-
Hey mozzers
Would be interested to know if anyone has used the rel=“next” and rel=“prev” attributes more info here http://googlewebmastercentral.blogspot.com/2011/09/pagination-with-relnext-and-relprev.html
If you have used it, has it worked and what are your thoughts etc:?
And for those that have used it, is it a better way of handling pagination other than the obvious of Google saying so.
Thanks
-
Hey Craig,
We implemented it recently and saw immediate effect within 24 hours. Google indexed our priority landing pages, and our paginated pages were offered up as effectively 'sitelinks'.
In effect we got one of our landing pages ranking No.1 on a strong keyword phrase, and we gained 4 extra paginated links just below the meta description.
Seems to be the best way to handle pagination.
Truly awesome, and very happy.
Croozie.
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
-
Is Google able to see child pages in our AJAX pagination?
We upgraded our site to a new platform the first week of August. The product listing pages have a canonical issue. Page 2 of the paginated series has a canonical pointing to page 1 of the series. Google lists this as a "mistake" and we're planning on implementing best practice (https://webmasters.googleblog.com/2013/04/5-common-mistakes-with-relcanonical.html) We want to implement rel=next,prev. The URLs are constructed using a hashtag and a string of query parameters. You'll notice that these parameters are ¶meter:value vs ¶meter=value. /products#facet:&productBeginIndex:0&orderBy:&pageView:grid&minPrice:&maxPrice:&pageSize:& None of the URLs are included in any indexed URLs because the canonical is the page URL without the AJAX parameters. So these results are expected. Screamingfrog only finds the product links on page 1 and doesn't move to page 2. The link to page 2 is AJAX. ScreamingFrog only crawls AJAX if its in Google's deprecated recommendations as far as I know. The "facet" parameter is noted in search console, but the example URLs are for an unrelated URL that uses the "?facet=" format. None of the other parameters have been added by Google to the console. Other unrelated parameters from the new site are in the console. When using the fetch as Google tool, Google ignores everything after the "#" and shows only the main URL. I tested to see if it was just pulling the canonical of the page for the test, but that was not the case. None of the "#facet" strings appear in the Moz crawl I don't think Google is reading the "productBeginIndex" to specify the start of a page 2 and so on. One thought is to add the parameter in search console, remove the canonical, and test one category to see how Google treats the pages. Making the URLs SEO friendly (/page2.../page3) is a heavy lift. Any ideas how to diagnose/solve this issue?
Intermediate & Advanced SEO | | Jason.Capshaw0 -
Rel=canonical on pre-migration website
I have an e-commerce client that is migrating platforms. The current structure of their existing website has led to what I would believe to be mass duplicate content. They have something north of 150,000 indexed URLs. However, 143,000+ of these have query strings and the content is identical to pages without any query string. Even so, the site does pretty well from an organic stand point compared to many of its direct competitors. Here is my question: (1) I am assuming that I should go into WMT (Google/Bing) and tell both search engines to ignore query strings. (2) In a review of back links, it does appear that there is a mish mash of good incoming links both to the clean and the dirty URLs. Should I add a rel=canonical via a script to all the pages with query strings before we make our migration and allow the search engines some time to process? (3) I'm assuming I can continue to watch the indexation of the URLs, but should I also tell search engines to remove the URLs of the dirty URLs? (4) Should I do Fetch in WMT? And if so, what sequence should I do for 1-4. How long should I wait between doing the above and undertaking the migration?
Intermediate & Advanced SEO | | ExploreConsulting0 -
Can you use multiple rel alternate tags for different device subdomains?
When redirecting from desktop to mobile with a separate URL structure, you need to have a rel alternate - rel canonical handshake to define the relationship between the pages. But if you have a different subdomain for different mobile devices, can you add more than one rel alternate tag on the desktop page? EG if site.com is redirecting to iphone.site.com, m.site.com, android.site.com
Intermediate & Advanced SEO | | AdiRste0 -
Pagination Tag and Canonical
Once and for all - I would really like to get a few opinions regarding what is the best method working for you. For most of the all timers in here there's no need to introduce the pagination tag. The big question for me is regarding the canonical tag in those case. There are 2 options, as far as I consider: Options 1 will be implementing canonical tag directing to the main category page: For instance: example.com/shoes example.com/shoes?page=2 example.com/shoes?page=3 In this case all the three URL's will direct to the main category which is example.com/shoes Option 2 - using self-referral canonical for every page. In this case - example.com/shoes?page=2 will direct its canonical tag to example.com/shoes?page=2 and so on. What's the logic behind this? To make sure there are no floating pages onsite. If I'll use canonical that directs to the main category (option 1) then these pages won't get indexed and techniclly there won't be any indexed links to these pages. Your opinion?
Intermediate & Advanced SEO | | seoperad0 -
Rel=prev/next and canonical tags on paginated pages?
Hi there, I'm using rel="prev" and rel="next" on paginated category pages. On 1st page I'm also setting a canonical tag, since that page happens to get hits to an URL with parameters. The site also uses mobile version of pages on a subdomain. Here's what markup the 1st desktop page has: Here's what markup the 2nd desktop page has: Here's what markup the 1st MOBILE page has: Here's what markup the 2nd MOBILE page has: Questions: 1. On desktop pages starting from page 2 to page X, if these pages get traffic to their versions with parameters, will I'll have duplicate issues or the canonical tag on 1st page makes me safe? 2. Should I use canonical tags on mobile pages starting from page 2 to page X? Are there any better solutions of avoiding duplicate content issues?
Intermediate & Advanced SEO | | poiseo1 -
High level rel=canonical conceptual question
Hi community. Your advice and perspective is greatly appreciated. We are doing a site replatform and I fear that serious SEO fundamentals were overlooked and I am not getting straight answers to a simple question: How are we communicating to search engines the single URL we want indexed? Backstory: Current site has major duplicate content issues. Rel-canonical is not used. There are currently 2 versions of every category and product detail page. Both are indexed in certain instances. A 60 page audit has recommends rel=canonical at least 10 times for the similar situations an ecommerce site has with dupe urls/content. New site: We are rolling out 2 URLS AGAIN!!! URL A is an internal URL generated by the systerm. We have developed this fancy dynamic sitemap generator which looks/maps to URL A and creates a SEO optimized URL that I call URL B. URL B is then inserted into the site map and the sitemap is communicated externally to google. URL B does an internal 301 redirect back to URL A...so in an essence, the URL a customer sees is not the same as what we want google to see. I still think there is potential for duplicate indexing. What do you think? Is rel=canonical the answer? In my research on this site, past projects and google I think the correct solution is this on each customer facing category and pdp: The head section (With the optimized Meta Title and Meta Description) needs to have the rel-canonical pointing to URL B
Intermediate & Advanced SEO | | mm916157
example of the meta area of URL A: What do you think? I am open to all ideas and I can provide more details if needed.0 -
Rel=canonical an iframed version of the same website?
My issue is that we have two websites with the same content. For the sake of an example lets say they are: jackson.com jacksonboats.com When you go to jacksonboats.com, the website is an iframed version of jackson.com. However all of the companies email addresses are example@jacksonboats.com so a 301 is not possible. What would be the best way to forward over the link juice from jacksonboats.com to jackson.com? I'm thinking a rel=canonical tag, but I wanted to ask first. Thanks,
Intermediate & Advanced SEO | | BenGMKT0 -
Rel canonical and duplicate subdomains
Hi, I'm working with a site that has multiple sub domains of entirely duplicate content. So, the production level site that visitors see is (for made-up illustrative example): 123abc456.edu Then, there are sub domains which are used by different developers to work on their own changes to the production site, before those changes are pushed to production: Larry.123abc456.edu Moe.123abc456.edu Curly.123abc456.edu Google ends up indexing these duplicate sub domains, which is of course not good. If we add a canonical tag to the head section of the production page (and therefor all of the duplicate sub domains) will that cause some kind of problem... having a canonical tag on a page pointing to itself? Is it okay to have a canonical tag on a page pointing to that same page? To complete the example... In this example, where our production page is 123abc456.edu, our canonical tag on all pages (this page and therefor the duplicate subdomains) would be: Is that going to be okay and fix this without causing some new problem of a canonical tag pointing to the page it's on? Thanks!
Intermediate & Advanced SEO | | 945010