Infinite Scrolling vs. Pagination on an eCommerce Site

[DownPour]

My company is looking at replacing our ecommerce site's paginated browsing with a Javascript infinite scroll function for when customers view internal search results--and possibly when they browse product categories also. Because our internal linking structure isn't very robust, I'm concerned that removing the pagination will make it harder to get the individual product pages to rank in the SERPs.

We have over 5,000 products, and most of them are internally linked to from the browsing results pages in the category structure: e.g. Blue Widgets, Widgets Under $250, etc.

I'm not too worried about removing pagination from the internal search results pages, but I'm concerned that doing the same for these category pages will result in de-linking the thousands of product pages that show up later in the browsing results and therefore won't be crawlable as internal links by the Googlebot.

Does anyone have any ideas on what to do here? I'm already arguing against the infinite scroll, but we're a fairly design-driven company and any ammunition or alternatives would really help.

For example, would serving a different page to the Googlebot in this case be a dangerous form of cloaking? (If the only difference is the presence of the pagination links.) Or is there any way to make rel=next and rel=prev tags work with infinite scrolling?

[AlanMosley]

you are coprrect, this will lead to de-indexing of your pages, unless your scroll page has every product on it at load, but this would mean a slow page for users. I assume that you are going to get pages on scroll via ajax or somthing on demand.

You would need to have to have other pages that link to the products.

[Saijo.George]

Its a bit technical but you can go through this https://developers.google.com/webmasters/ajax-crawling/ to make sure the dynamic page that you generate is actually indexable by Google.

That said 5000+ products infinite scroll is a bit scary and I would look at using rel=next and rel=prev for the pagination ( http://googlewebmastercentral.blogspot.com.au/2011/09/pagination-with-relnext-and-relprev.html )

I am not too sure what you mean by " internally linked to from the browsing results pages in the category structure: e.g. Blue Widgets, Widgets Under $250, etc. "

If you are referring to ability for users to sort through those products by picking one of the options like Blue Widgets, Widgets Under $250, etc. I would suggest rel canonical those pages to the base page . This should get you started http://support.google.com/webmasters/bin/answer.py?hl=en&answer=139394

[deltasystems]

You should have both. Keep the paged navigation at top, but keep the infinite scroll. Now you have the best of both worlds.

Although, I don't think the infinite scroll would end up 'delinking' thousands of pages. How often do you see store.com/category/page/6 in results, anyway? If it's a popular term, it's going to be for the main category landing page.

Serving up different content to Google is always a bad idea unless you have a good reason. This problem doesn't qualify.

[EppieVojt]

The correct way to handle this (and quite frankly, any javascript functionality) is to build it to work without javascript (keep the pagination), then have the javascript remove the pagination and implement infinite scrolling.  This ensures that visitors with JS disabled get the full experience of the site, search engines can easily crawl your full catalog, and users with JS enabled get the "enhanced" experience you desire from a UX standpoint.

It's not an "either or" scenario.  You can absolutely have an easily indexed site that extensively uses JS.

[DownPour]

Thanks for your replies everyone.

We weren't sure if Google would look at JS removing the page navigation as cloaking or not, so that's still a bit of a concern. We were reading Rand's post from 2008 on the subject http://www.seomoz.org/blog/white-hat-cloaking-it-exists-its-permitted-its-useful and Matt Cutts' replies on the subject.  We know it was a few years ago, but he still seemed to be saying to be over-cautious with that kind of thing.

Should we be worried about cloaking if we use JS to "hide" the page nav?

[nezona]

Hi Guys,

I was going to post a separate question here., but this thread seems to have answer the questions very well.

My client has infinite scrolling on his product pages but also have rel="prev" and rel="next" (but no actual physical page 1, page 2, page 3) buttons. I was just reading the rel="prev" and rel="next" should be in the in this case anyway. Does this mean we don't need actual buttons?

I am confirming the date this was put on, as I can't see any reduction in pages indexed which is one of the concerns above.

Regards

Neil