Hot answers tagged

8

For my paginated results, what I did was dynamically add page numbers and a result index. For example: <meta name="description" content="Page 3 of 11, nike shoes 30 to 40 out of 300. Buy good quality nike shoes blah blah"> In the above example, page 3 of 11 and pages 30 to 40 out of 300 would dynamically be generated using PHP or similar. This is ...


7

I think you've mixed up lot of things here. There are several problems with your website's pagination structure. By putting rel="canonical" in the paginated pages, you are telling google to show the nopaging page in the search results. If you don't want that, you need to remove the rel="canonical" tag. What is happening in your current structure is on one ...


5

I believe Google's primary goal when analysing rel=prev and rel=next link elements is to (usually) return the first page of a series in the SERPs, and to avoid returning multiple results from the same series of paginated pages. It should be noted that: rel=”prev” and rel=”next” act as hints to Google, not absolute directives. And... When ...


4

You should include to your sitemap all the URLs you want to see in a search engine's index.


4

Pagination with rel=“next” and rel=“prev” Much like rel=”canonical” acts a strong hint for duplicate content, you can now use the HTML link elements rel=”next” and rel=”prev” to indicate the relationship between component URLs in a paginated series. Throughout the web, a paginated series of content may take many shapes—it can be an article ...


4

It's a good question. Unfortunately, there is no correct answer as each option has its trade offs and you need to decide based on your use case. Previous/Next Links - The major problem with this implementation is crawling of your website as page 20 can be at a very deep level from homepage. Also, for user, the navigation might be problematic. I would ...


4

I don’t think that it’s a good practice to paginate articles (unless they are so long that it would affect the performance in the browser), because having exactly one canonical URL is preferable for so many reasons. I think there are two reasons why paginating articles was/is done: It increases the pages views. If a visitor is reading an article split up ...


3

I agree that previous needs to be on the left and next on the right. You can probably find many sites that use that convention as evidence. One way of getting round the objection about screen readers is to place them the other way in the HTML and then use CSS floats so that they look the way you want (previous - next) on the screen. I see less and less ...


3

Yes, using rel-canonical for these URLs would be (most of the time) incorrect. RFC 6596 defines: The target (canonical) IRI MUST identify content that is either duplicative or a superset of the content at the context (referring) IRI. This is not the case for your content. If you have a page that lists all products (without pagination), you could use ...


3

Duplicates like these are a thing of the past if you have set up proper schemas/relations/canonicals in regards to pagination: https://support.google.com/webmasters/answer/1663744?hl=en Note this too from the bottom of that article: rel="next" and rel="prev" are orthogonal concepts to rel="canonical". This means that each page is it's own canonical, ...


2

You can use both, according to Google's documentation. Whether or not you should depends on the circumstances: if you've got other duplication problems, separate from the pagination problem (as per the example in the documentation), then you could set a canonical link element (CLE) for each page of the series – so the CLE manages duplication on each page, ...


2

You probably should not add a rel="canonical" element to your paginated pages, unless it is specifically required. The canonical link element is not required for pagination, it is used to resolve canonical URL issues. The canonical URL of a page in a series is probably not the first page of that series. Your rel="next" and rel="prev" elements already provide ...


2

If I start to utilise Rel="prev" and rel="next" should I set page 2 onwards as index,follow or noindex,follow? Neither. Use rel="prev" etc. throughout the entire paginated series. Obviously page 1 will only have rel="next", and the last page only rel="prev". There's no need to use noindex anywhere in a series which uses pagination markup. The whole point ...


2

There is no difference. As long as you are consistent (by always using the slash or always omitting it), the URIs are just a string of text to search engines.


2

What are you hoping for from pagination? Users to click through multiple pages to find what they are looking for? Googlebot to be able to find all your items and crawl their pages? A way to distribute "pagerank" to each of your products so that the individual product pages work well? Organic search engine traffic to each of the paginated pages? These are ...


2

It does not pay to fight clients on UI - this is generally the one aspect of the project which the client feels he or she knows best about, particularly if he or she will be using the interface. Share your reservations and then implement exactly as requested - time will tell if the client reneges on his or her judgment call, but I can assure you that only ...


2

Using rel prev and rel next isn't going to solve the duplicate title and meta description problem. Several people on Google's blog post that it doesn't prevent these errors in Webmaster Tools. For example: cynthiacoffield said... I've had similar duplicate title tag issues that are resolved with rel prev/next canonical. I would recommend putting ...


2

I don't want to add paginated results to search engines. But I need my index.php to be in search engines. If you want index.php to be indexed, but the paginated links not to be indexed, then noindex,follow will do the opposite: The noindex tells search engines not to index the page, and the follow tells them to follow links on the page. To tell search ...


2

Perhaps the term you're looking for is a Wizard? 'Pagination' usually refers to a set of results that are too numerous to display at once (e.g. a search result) 'Breadcrumbs' are specifically navigation links that lead you 'back up the path' (as in Hansel and Gretel) to provide navigational context for each page. I have not heard of a 'wayfinder'.


2

Pagination markup might be more appropriate here. Using the <link> element in <head>, we specify next and previous pages as follows: On page 1 <link rel="next" href="http://www.example.com/article-part2.html"> On page 2 <link rel="next" href="http://www.example.com/article-part3.html"> <link rel="prev" href="http://www.example....


2

Actually in that situation, where you have one long document spread through multiple pages, you want to link the pages together using the next and previous links in your <head> tag. For example, for page 3 you could have something like this: <link rel="prev" type="text/html" title="Page 2" href="/youth-basketball-tournaments/kansas?page=2"/> &...


2

Safe? Yes. Effective? No. Pagination and Pagerank You are hoping to get more Pagerank passed to the pages that are not on page one. It won't work. Pagination can serve the same SEO purpose as a sitemap: it will get Googlebot to crawl and index all your content. But, just like a sitemap, it won't help the pages rank much. Consider the case in ...


2

I would leave everything as is and let SEO by Yoast do the work for you. You should use rel="canonical" on your subsequent pages or rel="prev" and rel="next". Or you can use both. Here is what Google recommends: In cases of paginated content, we recommend either a rel=canonical from component pages to a single-page version of the article, or to use ...


2

Neither em nor i are appropriate elements. Nothing in their definitions would suggest that they could be used for this purpose. The b element might be appropriate here ("a span of text to which attention is being drawn"). But instead (or in addition to b), you might want to consider removing the link to the current page: <ul> <li><a href="...


2

you shouldn't set your canonical to the first, but to the current page, like big G said.


2

The more unique the tags are from page to page, the better. Making it unique only by changing a digit might not be good enough. If you can't make the tags more unique than just digits, you can consider using the word version of each number. For example, instead of: <h1>Something - Page 1</h1> <h1>Something - Page 2</h1> <h1>...


2

I would assume a big big reason for advertisement driven websites is that every time you change a page you can be presented with a different advertisement. I don't have enough points to make this just a comment. I see no other reason for the stumpy little pages some major websites offer.


1

I think here is a good example of pagination in MediaWiki: https://semantic-mediawiki.org/wiki/Demo:Listwidget_paginated_list Maybe you can figure out, how it works.


1

Set a canonical link on each of your item pages (not pagination pages) and make sure all the item page URLs are registered in your sitemap.xml. Make sure this sitemap is defined in your robots.txt. Then, let crawlers do their job.


1

I'd say that if you divide a long page into small chunks(may be for more Ad revenue), which actually should have been single page then using prev/next attributes give clear signal to the search engines about the main page so that the search engines can show the main page in the SERPs and attach less significance to chunks. About duplicate content, we should ...



Only top voted, non community-wiki answers of a minimum length are eligible