Pagination attributes: link rel=”next” and rel=”prev”

By Raghav Tayal

Rel=Prev and Rel=Next enable Google to truly understand what it is searching for and forward users to the most relevant page, which is usually the first one in the series. If they are not used, pages 2, 3, or 4 of an article may appear higher in Google’s search results than the first page.

What is Pagination?

Pagination is the method of splitting content into multiple pages. It is a popular and commonly used website technique for dividing lists of editorials or products into manageable forms.

Pagination is most typically found on the websites listed below:

  • Forums
  • Blogs
  • eCommerce
  • News Publishers

The biggest concern with search pagination is that information is distributed across various pages rather than being loaded on a single page. This problem was previously solved by using rel=”next” and rel=”prev,” but Google recently confirmed that it no longer includes this link component as an indexing signal.

The rel=”next” and rel=”prev” pagination attributes are used to demonstrate to search engines the relationship between element URLs in a paginated series. They aid in the consolidation of indexing properties in the sequence and direct users to the most relevant URL in the series.

They are frequently used on eCommerce web pages that showcase many products spread across multiple URLs, articles that have been separated into shorter pieces, or forum threads, to name a few examples.

When feasible, we recommend avoiding passing information across multiple pages. Even lengthy information can usually be made comprehensible and navigable with good UX design. Google announced these functions in September 2011 to help with the challenge of copied content. The Rel=Prev and Rel=Next tags are added to a website’s HTML code to inform search results that a specific selection of sequential web pages should be indexed together.

While pagination attributes are a measurable concept, it is extremely common for websites to incorporate them incorrectly. Google officially confirmed on March 21, 2019, that they have not used rel=”next” and rel=”prev” in indexing for a long time; however, other web pages, such as Bing (which also powers Yahoo), continue to use it as a glimpse for exploration and comprehension site map.

When do you need to use the pagination attributes?

Rel=Prev and Rel=Next are required for information that cannot be fit onto a single page without causing the page to keep going well below the fold. Each page has a ‘previous’ or a ‘next’ button at the lower edge. This will take you to another page of the article or the previous page. If you do not use these features, Google will have a much more difficult time sorting the pages. Google may also presume that the information isn’t paginated and treat it as redundant versions of the same subject.

Category pages on eCommerce websites are a widely used application for pagination characteristics. Typically, categorization pages contain several different products and are thus split into different pages, with each page displaying a subset of the category. The disadvantage of this is that these pages appear to be very similar, resulting in duplicate content. By using the pagination attributes to make the relationships between several pages clear to search results, you give search engines scope and avoid redundant data.

Benefits of Pagination

Better User Experience

When there is too much data on one page, the website visitor may become swamped. Website owners can present a considerable amount of data in small, bite-sized chunks by using pagination. On the home page of an e-commerce site, for example, the product image and cost will be displayed. If a user wants to learn more about the product or service, they can click on the image/price/link with a call-to-action option. Pagination also makes it easier for users to gather the information they seek.

Improves Content Quality
Google regards all pagination pages the same way. Web developers face the difficult task of upgrading the efficiency of content on all web pages, so reusing the same content to save time is not an option. In an interview with English Hangouts on March 22, 2019, John Mueller made the following suggestion to webmasters:

“I would like to recommend specialists to make sure that all pagination pages can work independently. That is, when moving to another section, the user was able to find something useful for himself. Therefore, it should be borne in mind that due to changes in the algorithms of search engines, pagination is not just a group of pages from 1 to 100 with different types of products, each of them must contain relevant information. However, you can always define a priority root page for yourself and spend more time optimizing it.“

That is, pagination should enhance the user experience first and second and the information should be relevant to the viewer’s search terms. There is no need for each web page to have its own text content. Duplicates can simply be removed. You can check the resemblance of the pagination pages using third-party services.

Simpler navigation

The pagination example in our previous example, impact on YouTube, is a CTA. It can assist the individual who wants to go through the whole information and navigate more easily.

Even when CTAs are not used, pagination helps in browsing. When a user comes to the end of a page or has seen multiple items in a specific category, it is natural for them to be willing to see more results. When numbering is used, the visitor can choose how many other pages they want to look at. It also provides an idea of the size of the data set. A massive data set may attract a user seeking variation. It should be noted that it is best practice to always use CTAs.

The accumulated pagination data can then be assessed in columns to verify that the execution is correct. You have the option of filtering by the following criteria –

  • It is Paginated – URL contains rel = “next” and / or rel = “prev” attributes. This means that it is part of the paginated sequence.
  • First page – URL contains only the rel = “next” attribute. This means that it is the initial page of the paginated sequence. It’s useful to look up these URLs to ensure they run correctly on the parent page of the series.
  • Paginated 2+ pages – URL has a rel = “prev” attribute. This indicates that this is not the first page, but the paginated page of the series. Again, if you scroll through all these URLs, only the paginated pages will be displayed under this filter.
  • Pagination URL not found in anchor tag – URL embedded in the page’s rel = “next” or rel = “prev” attribute is not recognized as a hyperlink to the HTML anchor component of the page itself. Consistent with integration you need to use links to navigate to paginated pages so that users can in turn click the next page to explore. Google will move between pages, and PageRank will in turn between web pages in the series.
  • Non-200 pagination URLs – URLs with “next” and rel = “prev” attributes will respond 200’OK’ Does not provide code. URLs blocked by robots.txt, no reply, 3XX (redirect), 4XX (client error), or 5XX are examples (server error). Pagination URLs must be fully functional and indexable, so URLs other than 200 will be treated as errors and ignored in search results. You can bulk export non-200 pagination URLs using Report> Pagination> Non-200 Pagination URL Export.
  • Unlinked pagination URLs- URLs with the rel = “next” and rel = “prev” attributes are not assigned anywhere on the website. The pagination feature may not go through PageRank like traditional anchor components. This may indicate a problem with the URL embedded in the link building or pagination feature. Unlinked pagination URLs can be outsourced in bulk using the Report> Pagination> Unlinked Pagination URL export.
  • Non-Indexable – The paginated URL cannot be indexed. Only if there is a ‘view-all’ page set, or there are additional factors on pagination URLs that necessitate canonicalization to a single URL, they ought to be indexable. One of the basic mistakes is canonicalizing paginated pages on page 2+ to the first page of a sequence. Google advises against using this method because the component pages do not consist of redundant data. Another typical blunder is using ‘noindex,’ which means Google removes paginated URLs from the index and prevents following outlinks from those web pages, which can be problematic for the goods on those pages. This filter will aid in the identification of these common configuration issues.
  • Multiple Pagination URLs – There are multiple rel=”next” and rel=”prev” attributes on the page (when only one rel=”next” or rel=”prev” attribute ought to be present). This could imply that they are dismissed by search engines.
  • Pagination Loop – Shows URLs with rel=”next” and rel=”prev” attributes that loop back to a previously encountered URL. Again, this could imply that the search results simply disregard the presented pagination series.
  • Sequence Error – This displays URLs that have an error in the sequence of the rel=”next” and rel=”prev” HTML link elements. This standard procedure makes sure that URLs contained within HTML link elements with rel=”next” and rel=”prev” reciprocate and verify their connection in the sequence.

Architecture of links

The browsing of a website should be easy and crawlable, with pages not more than three clicks behind the home page. Pagination divides a piece of information into various pages, increasing the number of clicks from the main page of a website. Since Google no longer combines paginated pages into a single piece of information, SEOs must rely on traditional site layout best practices.

In this segment, we’ll go over the best practices for link architecture that SEOs should keep in mind when optimizing pagination.

The number of clicks away from the home page

The number of clicks ahead of the home page is among the most important on-page SEO best practices with link structure. The importance of click depth is due to the link authority (PageRank) that is carried from the home page to the next.

Google’s PageRank algorithm is one of the signals it tries to describe relevant pages in search engine results. This is one of many indicators used by Google to ascertain how well websites rank and how frequently Googlebot crawls pages.

If the pagination is too extensive, both the paginated pages and all the pages attributed to from these extensively paginated URLs will obtain less PageRank than pages higher up in the link architecture.

With Google’s recent statement and change in pagination handling, paginated pages must now be considered the same as any other category or page. They must be no more than three clicks away from the home page (or as close to it as possible).

Reduced click intensity will allow paginated pages to be crawled more regularly. It will also improve the chances of pages linked from pagination ranking in Google Search for relevant questions.

Although determining the click intensity of paginated pages and thorough level pages is critical, internal linking practices must be used to significantly lower clicks ahead of the home page.

Tips:

  • – Crawl the website to determine the paginated page click scope from the home page.
  • – Analyze the depth of the pages linked to paginated pages and determine the click intensity of paginated page-reliant pages.
  • – For paginated pages and deeper level pages, choose internal linking ways of reducing click depth.

Don’t interrupt the pattern.

Don’t break the page series. If you do, search engines will frequently dismiss the pagination and simply index and return all pages, potentially resulting in duplicate content concerns. For example, forgetting the rel=”prev” reference from page 2 to the first page would break the page sequence.

Reduce using citing redirects.

Prevent using pagination characteristics and canonical URL links that reroute to other pages. For search engines, this is puzzling.

Make use of absolute URLs.

Even if it is not against the link tag requirement, the general opinion is to avoid using relative URLs when establishing pagination attributes. Search engines are more likely to misinterpret relative URLs. The same best practices apply to the link tag’s other uses: canonical URL, Hreflang characteristics, and mobile attribute.

Remember not to noindex paginated pages.

Do not add noindex robots to paginated pages. What can be the reason? There are two:

  • – If the page hasn’t been indexed for a long time, Google will eventually stop crawling the page, and as a result, it won’t follow the link.
  • – When using the rel = “next” and rel = “prev” attributes, the browser recognizes the correlation between pages. So, when someone searches for information that normally exists only on those pages, only the paginated pages are displayed.

Introducing noindex to pages will eliminate them from the index.

Those pages are no longer qualified for ranking, and PageRank will not be passed to them. While the links on the website may be crawled at first, this may change over time. Noindex pages will be regarded as nofollow at a certain point, according to Google Webmaster Trends Analyst John Mueller, but it’s unclear how long that would take.

When some other Webmaster Trends Analyst, Gary Illyes, was questioned about it, he appeared to believe they might still be wriggled. Without properly understanding how this performs, it’s best to explore the possibility of warning and not noindex these pages only if you have a backup indexing path.

We also don’t recommend Nofollow links to paginated pages.

The nofollow link attribute is mainly used to inform search engines about two things:

  • Not to click the link.
  • It doesn’t trust the site, hence, does not give credit.

Keeping that in mind, using nofollow to the paginated page is a bad idea. It prevents the browser from browsing the paginated pages or discovering new content. If you do this, you may lose link permissions too.

Nofollow should not be used for internal links to other paginated pages. Nofollow is now a Google indication, and your ideal scenario is that they overlook what users mark nofollow. What happens is that you can disable scurrying and the transmission of signals such as PageRank through your website, resulting in orphaned web pages.

Do not include paginated pages in your sitemap XML.

Pages can be indexed, but they should not be included in XML wireframes. An XML sitemap is a specific document that lists all the pages on your site and gives your browser a complete picture of all the content. XML sitemaps are highly recommended, especially for large websites (with 500 pages and above).

We believe that XML sitemaps should only include pages that you want to rank high in search engines. In most cases, paginated pages do not fall into this category. The only exception to this rule is when you implement pagination on the Show All page instead of using the rel = “next” and rel = “prev” attributes. The XML site map can include Show All Pages. When you include the pagination attribute, the following mistakes are common:

  • No self-referenced canonical URL: Instead of using a self-referenced canonical URL, canonicalizing the first page of the sequence is better.
  • Use pagination on unpaginated pages: Try implementing pagination on unpaginated pages such as blog posts. Blog article A has a rel = “next” link to blog article B, blog article B has a rel = “prev” link to blog article A, and blog article C has a rel = “next” link to blog article C. This is incorrect and is used in many WordPress themes for some reason.
  • Adding a relationship to a link: Instead of identifying the link in the header, use the pagination attribute for the link in the body. Search results do not encourage this.
  • Adding the noindexrobots directive to paginated pages: In addition to using the pagination attribute, users periodically apply the noindex directive to paginated pages. Not true.

When Google announced that rel=prev/next mark-up had not been used for years, it sparked a surge in internet sites modifying their execution and actively harming their sites. Let’s take a look at what is different now and what you should do.

The rel=prev/next attribute is used to represent paginated pages in a sequence. Google first used the markup to communicate signals with a cluster of paginated pages while still switching to show the most applicable page in their search results. Normal use cases would include breaking up content into sections and making multiple pages for product lists, discussion threads, and blog lists.

What does a code look like for a three-page website series?

1st Page

They just require the reference of the next page. It looks like this:

link rel=”next” href=”https://website.com/page/2″

2nd Page

This page will require both the previous page and the next page reference. It looks like this:

link rel=”next” href=”https://website.com/page/3″
link rel=”prev” href=”https://website.com/page/1″

3rd Page

Since it is the last page, it only requires the previous page reference. It looks like this:

link rel=”prev” href=”https://website.com/page/2″

However, Google announced in 2019 that they would no longer use rel=prev/next for pagination. Worse, it appears they had not even used it in years.

This change however did not affect SEO. In terms of copied content, having some portions of text that are the same will not harm your web page and will not result in a penalty. Google will continue to look for a suitable version of that content to display.

So, what’s the deal with the modification? And, if anything, what to do about it?

Why did Google eliminate rel=prev/next support?

Before Google declared that rel=prev/next would no longer be used, one of the official guides provided an overview to do nothing about pagination and let them recognize it.

Don’t do anything. Paginated content is very frequent, and Google is doing an excellent job of getting the most appropriate information to people irrespective of whether the information is distributed over multiple pages.

Recognizing this, the most likely reason they ended using rel=prev/next is that they improved at finding it out and didn’t need additional indications.

Aside from rel=prev/next, Google has many possibilities for identifying the webpage in a sequence. Websites, for the most part, incorporate paginated web pages consistently, and Google can look at issues like:

    • Headings
    • Page titles

 

It’s also plausible that the pagination suggestions were causing poor customer experiences as web pages spread their information across various pages. The majority of the time, this was done to increase page clicks and ad sales, but the interaction was irritating to users and made it hard to find what it was they were looking for.

How could SEO professionals have known rel=prev/next didn’t work?

When Google confirmed that they hadn’t backed rel=prev/next in years, one of the very first questions that arose from SEO professionals was, “Why did technical SEOs not know this?”

The quick answer is that there was no way of knowing. We would not have known if Google hadn’t already informed us.

If the pagination worked, Google would combine commands for the set of pages. Although they would typically show the first page in the series, they also would swap which page was being shown if the search terms contained a more meaningful page from the set. If the pagination didn’t work, the very same thing would happen as that’s how Google works—it displays the most appropriate page for the query.

Should SEOs get rid of rel=prev/next?

No. Do not eliminate rel=prev/next if you have already applied it on your website. This information was not only used by Google. W3C to this day recommends it and uses it for user experience and ADA adherence. It is also used by some web browsers for caching. Other search engines, such as Bing, continue to use the markup.

Implementations of appropriate pagination

The majority of rel=prev/next setups have used self-referencing canonical tags. Make no changes to this configuration. Consider the pages like any other indexable page on the website, and make absolutely sure to include internal links to other pages in the pagination series. You also can canonicalize paginated pages by directing them to a view-all page that shows all of the information. The content can still be divided into separate pages for customers in this manner, but the searchable version will consist of all of the subject matter.

Some pointers on category optimization

What can you do to optimize your category pages now that rel=prev/next has been removed? Here are a few suggestions:

  • – First, ensure that the majority of your content is on the first page of the classification. That will help with indexing. Text, pictures, and videos are examples of content.
  • – Not just that, but it will aid in indexing for the appropriate search queries. People can find other pages once they get there at your category page.
  • – Then, on your primary category page, optimize your featured image. You can have a thumbnail with a search term in the file name and alt text. This provides Google with added information about the nature and location of your pages. Additionally, optimized pictures will drive traffic from Google Image Search.In some cases, this one can be tricky. What if a particular category contains 10,000 items? See if you really can separate them into subcategories. Then, on the category page, include a representative from every specific category.When it comes to e-commerce you can have between 30 and 60 products in each classification. You should not however create a sub-group unless you have five distinct goods.ry.

The big question is, do you remove rel next rel prev?

As there is already a canonical, Google will simply accredit all of the significance to the first page. As a result, you have the option to, Keep it in place and it will function just like a rel canonical. Remove rel next rel prev and treat everything the similar way, but don’t bother about legacy code.

Set up a no index on all pages except the classification. Some people like this even if you use a no index or a robots.txt block, you might save the crawl budget, which means Google will cram the pagination less frequently.

Final Thoughts

If you’ve already used rel=prev/next for pagination, let it be. There’s no point in changing it, and you’ll probably end up causing more harm than good.

If you want to alter the pagination even though you believe the paginated pages are of poor quality or do not provide enough value, consider grouping the pages in a way that is both beneficial for individuals and offers an alternate crawl path for browsers. For example, if you wished to group a lot of blog posts using classifications, that’s probably more effective to users than a bunch of paginated pages that contain posts on a variety of topics. These category pages, which contain posts about a single topic, have a chance of occurring in the SERPs for specific terms related to the classification.

FAQs

1. Why are search results disregarding my pagination characteristics?

The rel=”next” and rel=”prev” qualities are signals as opposed to directives. Although search results are not needed to adhere to your description of pagination characteristics, they generally do.

2. Is it possible to use rel=”previous” rather than rel=”prev”?

Yes, both work, so for the sake of conciseness, we prefer rel=”prev.”

3. Will search engine results in index my paginated pages?

Yes, but they will not usually appear in search engine result pages because search results typically bring back the first page in the series. However if one of the paginated pages contains unique content, that page may also rank in search engine results.

4. Can I use the HTTP header to define the rel=”next” and rel=”prev” attributes?

While the 2011 article on Google’s Webmaster Forum(opens in a new tab) claims it still does, it is not widely practiced.

5. Can I use the XML sitemap to define the rel=”next” and rel=”prev” attributes?

No, that’s not currently possible now.

6. Should my paginated pages be included in my XML sitemap?

No. We think that only pages that you just want to rank with must be included in your XML sitemap. Your paginated pages, for most cases, do not fit into that category. The only exception to this rule is when you choose to install pagination with a View All page rather than using the rel=”next” and rel=”prev” attributes. Your XML sitemap must include View All pages.