Ecommerce Website Development in Pune: Pagination, "Load More" or Infinite Scroll — How to Page Through Your Product Listings Without Hiding Products From Google
For an online store with more products than fit on one screen, numbered pagination with a real link and a real URL on every page is the safest choice for search, and a "load more" button or infinite scroll is fine only if the same products are also reachable through ordinary links. Google's own documentation says its crawler generally follows URLs in href attributes of <a> elements and does not click buttons or trigger JavaScript that needs a user action. So a catalogue whose second page only appears after a click may look, to Google, like a catalogue with one page. This guide is for the owner or marketing head of a store in Pune or anywhere in India who is choosing, or has inherited, a listing design, and for the developer who has to build it. It explains the three patterns, what Google says about each, how to set URLs and canonical tags, how to test what a crawler sees, and what to put in a brief.
We rely on Google Search Central's documentation on pagination and incremental page loading throughout, and we say plainly where something is our judgement rather than Google's statement. We do not quote traffic or conversion lifts, because no honest number applies to your store before you measure it.
First, what problem are we solving?
A category such as "women's kurtas" or "LED panel lights" may hold 40 products or 4,000. Nobody wants all of them in one page: it would be slow to load and tiring to scan. So the store shows a first batch and offers a way to see more. There are three common ways.
Numbered pagination. Links labelled 1, 2, 3 and "Next". Each page is a separate address, such as /kurtas/?page=2.
"Load more" button. One page, with a button at the bottom that fetches the next batch and adds it below the products already shown.
Infinite scroll. The next batch loads automatically as the shopper nears the bottom.
Each pattern answers two different audiences. A shopper wants speed, orientation and the ability to come back to the same place. A search engine wants every product to be reachable through a link it can follow and every listing page to have a stable address. A design that suits only the first audience can quietly make most of your catalogue invisible to the second.
What Google actually says
Google's page on pagination and incremental page loading is short, and its main points are worth stating exactly.
- Link each page to the following page with
<a href>tags, and link from each page back to the first page of the collection. - Give each page a unique URL. A query parameter such as
?page=2is given as an example. - Do not use URL fragments (anything after
#) for page numbers, because Google ignores fragment identifiers. - Do not make the first page the canonical URL for the whole sequence. Give each page its own canonical URL.
- Google no longer uses
rel="next"andrel="prev". Other search engines may still use them, so they are harmless but no longer a Google signal. - Pages in a sequence do not need distinct titles or descriptions, because Google tries to recognise the sequence.
- "Load more" and infinite scroll are usually built with JavaScript, and Googlebot does not click buttons. Follow JavaScript SEO best practice, make sure links are crawlable, and consider a sitemap or a Google Merchant Center feed to help Google find all your products.
- Google notes that "load more" cannot handle very large numbers of results well, and that infinite scroll can cause scrolling fatigue.
- Filtered or re-sorted variations of a listing should be kept out of the index with a
noindexrobots meta tag, or crawling discouraged through robots.txt.
Notice what is not in that list: a recommended number of products per page. Google does not give one, so any figure you hear is a design judgement, not a rule.
Pattern one: numbered pagination
This is the pattern Google's guidance fits most directly. Every page exists at its own address, every page links to the next, and a crawler can walk the whole sequence using plain links.
What to build.
- A real link on every page number and on "Next" and "Previous", written as an anchor with an
hrefthat points to the next address. Buttons that call a script and have no link underneath do not count. - A stable, readable URL pattern.
?page=2is Google's example; a path such as/kurtas/page/2/is equally valid. Choose one and use it everywhere. - A link from every page back to page one of the collection, which usually the category name or breadcrumb already provides.
- A self-referencing canonical on every page. Page 2's canonical is page 2.
- A sensible response when someone requests a page that does not exist. Page 99 of a category with eight pages should return a proper "not found" response, not an empty page that looks fine to a crawler.
Where it goes wrong.
- Canonical pointing at page one. This is the most common mistake in stores we review. It is tempting because it "consolidates" the sequence, but Google explicitly says not to, and it tells the crawler that the products on pages two onward are not worth treating as separate content.
- Page numbers in the fragment. An address such as
/kurtas#page=2looks like pagination to a shopper and like a single page to Google. - Links that exist only after JavaScript runs. If the page-number links are inserted by a script after load, they may still be found, but you are depending on rendering. Plain links in the initial HTML are the safer build.
- Filters mixed into pagination.
?colour=red&page=3and?page=3&colour=redare two addresses for one page. Our article on faceted navigation explains how to decide which filter combinations deserve to exist and how to keep the rest out of the index.
What shoppers need. Show the current page, the total number of pages or products, and a way to jump forward without clicking "Next" twelve times. Keep the position when a shopper opens a product and presses Back. On mobile, make the targets large enough to tap.
Pattern two: the "load more" button
A "load more" button keeps the shopper on one page, preserves scroll position and lets them compare products without a page reload. It also suits mobile, where tapping small page numbers is awkward.
The risk is exactly what Google describes: the products behind the button are fetched by JavaScript after a click, and Googlebot does not click. If the only route to products 25 to 48 is that button, those products may be discoverable only through your sitemap or product feed, and the category page may never be associated with them.
The safer build is progressive enhancement. Start with real pagination links in the HTML, as in pattern one. Then use JavaScript to turn the "Next" link into a "load more" behaviour for people who have it. A crawler or a visitor with scripts blocked sees ordinary links; a typical shopper sees the smoother experience. The same address is used both ways, so sharing a link or reloading the page works.
Whether you also update the browser address as more products load is a design choice. Google's page does not discuss it, so treat what follows as our reasoning rather than Google's statement: if the address stays on page one after the shopper has loaded four batches, a shared link or a refresh drops them back at the top, which is frustrating. Updating the address to reflect what they have loaded is friendlier, but only worth building if you test it properly.
Other limits. Google's own note that "load more" cannot handle very large numbers of results is a reminder to cap it. A category with thousands of items needs filters, sub-categories and search so that nobody has to page through everything. See our guide to site search and category navigation.
Pattern three: infinite scroll
Infinite scroll is the most fragile for search and the hardest to make pleasant. The footer can never be reached because new products keep appearing. There is no stable "page 3" to refer to. A shopper who clicks a product and returns may land at the top of an empty-looking list while it reloads. Google mentions scrolling fatigue directly.
If the business insists on it, for a fashion catalogue that is browsed like a feed for example, apply the same principle as pattern two: the underlying structure is paginated, with real links and real addresses, and scrolling is only an enhancement on top. Add a visible way to reach the footer, keep the shopper's place on return, and make sure the paginated version works with scripts disabled.
For most Indian stores we would not start here. If you sell 80 products you do not need it, and if you sell 8,000 you need better filtering more than you need endless scrolling.
Choosing: a practical decision table
| Your situation | Suggested pattern |
|---|---|
| Fewer than a few dozen products per category | Show them all on one page; no paging needed |
| A broad catalogue, mostly organic search traffic | Numbered pagination with real links |
| Mobile-heavy audience, browsed like a feed | "Load more" built on top of real pagination links |
| Very large catalogue | Better filters, sub-categories and search first; pagination underneath |
| Content browsed for inspiration (lookbooks, editorial) | Infinite scroll only as an enhancement over paginated pages |
This table is our judgement, not Google's, and the first row has no fixed threshold. Pick based on your own catalogue.
Product count per page: how to choose without a rule
Google gives no recommended number, so decide using your own evidence.
- Page weight. Each product card includes an image. Heavy first pages hurt load time on the mid-range phones many Indian shoppers use. Measure with PageSpeed Insights and your Core Web Vitals report before and after changing the count; our guide to store speed covers how.
- Grid shape. A multiple of the number of columns avoids a half-empty last row. A four-column desktop grid and a two-column mobile grid both divide evenly into 24 or 48, which is a reason designers choose them, not a Google requirement.
- How shoppers behave. Look at how far down listings people scroll in your own analytics or a recording tool before deciding. If most visitors never pass the first twelve products, a longer first page buys little.
How pagination interacts with other things on the page
Titles and descriptions. Google says pages in a sequence need not have distinct titles or descriptions. You can add "Page 2" to the heading for human clarity if you wish, but you do not need to rewrite metadata across fifty pages.
Category introduction copy. Put the descriptive text on page one only. Repeating a long paragraph across every page adds nothing for shoppers. Our article on collection page content covers how much to write and where.
Sorting. "Price low to high" produces a different ordering of the same products. Treat sort orders like filters: usable by shoppers, kept out of the index, as Google advises for re-sorted variations.
Sitemaps. Include your product addresses in the XML sitemap so they can be found even if a listing page is not crawled deeply. This is the safety net Google itself suggests, not a replacement for crawlable links.
Structured data. Product markup belongs on the product page. Do not mark up a listing page as though it were one product. See product schema for Shopify and WooCommerce.
Out-of-stock items. Decide whether they stay in the list or move to the end, and keep the product page live as described in our article on out-of-stock and discontinued product pages.
Platform notes
We do not claim to know what every theme does today, because behaviour changes with theme versions and plugins. What we can say is how to find out for your store.
- Shopify. Collection pages commonly offer a paginated listing, and many themes offer a "load more" or infinite option. Check which your theme uses, and whether the underlying page links are present in the page source.
- WooCommerce. Standard archives are paginated, and plugins and page builders can swap this for load-more or infinite scroll. After any such plugin is installed, repeat the tests below.
- Custom or headless stores. Here the developer decides everything, so put the requirements in the brief. Pre-rendered or server-rendered HTML for listing pages makes the link requirement easy to meet.
In every case the test below is the same, and it takes a few minutes.
How to test what Google can see
- View the page source. In your browser, view the source of a category page (not "Inspect", which shows the page after scripts run). Search for the address of the second page. If the link is in the source, a crawler gets it without running scripts.
- Turn JavaScript off. In your browser's developer settings disable JavaScript and reload the category. Can you still reach page two with a click?
- Use the URL Inspection tool. In Google Search Console, inspect a category page and view the rendered result. Check that the product list and the next-page links appear. Then inspect the address of a deep page, such as page 5, and check that it can be inspected and is not reported as redirected to page one.
- Check canonicals. Open pages 1, 2 and 3 and read the canonical in the source. Each should name itself.
- Search for a deep product. Use a search for the exact product name together with your store name, or use the Pages report in Search Console, to see whether products that live only on later pages are indexed. Indexing is never guaranteed and takes time, so do this a few weeks after launch, not the next day.
- Crawl the site. A crawling tool can follow links the way a crawler does and report which products are reachable and how many clicks away they sit. Products that appear in the sitemap but are not reachable by links are the ones to fix first.
A worked example (illustrative)
Imagine a Pune home-lighting store with about 600 products across twelve categories. The largest category, ceiling lights, has 180 products. The old theme showed 24 products and a "Load more" button that fetched the rest through a script, with no links in the source.
On review the developer finds three things: page two of the category has no address of its own, products 25 and onward are listed only in the sitemap, and the category page's internal links reach only 24 products. The fix is to rebuild the listing with real page links and ?page= addresses, give each page a self-referencing canonical, keep "load more" as an enhancement over those links, and add filters for type and room so shoppers narrow 180 products to a dozen.
This example is an illustration created for this article, not a client result, and we give no traffic or sales figure for it because none exists.
Mistakes we see repeatedly
- A canonical tag pointing every page of the sequence to page one.
- Page numbers placed in the part of the address after
#. - "Load more" or infinite scroll with no link underneath.
- Filter and sort parameters left indexable, producing thousands of near-duplicate listing addresses.
- Fifty pages of the same long category description.
- Empty pages that return a normal success response when the page number is too high.
- Never testing with JavaScript off or in Search Console after a theme update.
What to put in your brief to a developer
- Listing pages use numbered pagination with real
<a href>links in the HTML, or a "load more" feature built on top of such links. - Each page in a sequence has its own unique URL and a self-referencing canonical; none canonicalises to page one.
- No page numbers in URL fragments.
- Pages beyond the last return a proper not-found response.
- Filter and sort variations are noindexed or blocked from crawling per the agreed rules.
- All product addresses are in the XML sitemap.
- Acceptance test: the category can be walked to its last page with JavaScript disabled, and URL Inspection shows the next-page links in the rendered result.
- Before and after PageSpeed Insights results for a category page, so a heavier first page is caught.
Working with Govindani Infotech
We build and review online stores on Shopify, WooCommerce and custom stacks from our office in Pune. If you would like a second opinion on how your listings are built, our website creation service and SEO service pages describe what we do, or you can contact us on 092019 58274. Scope and pricing are confirmed after we have looked at your store.
Frequently Asked Questions
Is infinite scroll bad for SEO?
Not automatically, but it is risky. Google says its crawler does not click buttons or trigger scripts that need a user action, and infinite scroll is usually built that way. If the products are also reachable through ordinary links with their own URLs, infinite scroll can sit on top safely. If scrolling is the only way to see them, some products may not be discovered through that page.
Should every paginated page have a canonical tag pointing to page one?
No. Google says not to make the first page the canonical for the whole sequence. Each page should have its own canonical URL that points to itself.
Does Google still use rel="next" and rel="prev"?
No. Google's documentation says it no longer uses them, although other search engines may. You can leave them in place, but you should not rely on them for Google.
How many products should I show per page?
Google does not give a number. Choose a figure that keeps the page light on mobile, fits your grid, and matches how far shoppers actually scroll in your own data, then test the page with PageSpeed Insights.
Should I noindex page two onward of a category?
Google's guidance is to give each page a unique URL and its own canonical, and to noindex filtered or re-sorted variations. It does not advise hiding the later pages of a plain sequence, because they are how products are found.
Sources
- Google Search Central, "Pagination and incremental page loading best practices": link with
<a href>, unique URLs, no fragments for page numbers, self-referencing canonicals, no longer usingrel="next"andrel="prev", crawling of "load more" and infinite scroll, sitemap or Merchant Center feed, and noindex or robots.txt for filtered and re-sorted variations. - Our own judgement is labelled as such: the decision table, the products-per-page reasoning and the address-update discussion are not Google statements.
- The lighting-store example is an illustration created for this article, not a client result. We cite no traffic, speed or sales figures because we have not measured any that would apply to your store.
About the author and next step
This guide was written by the ecommerce team at Govindani Infotech, a website design and development company at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009.
Related reading: If you plan to advertise the catalogue on Facebook and Instagram, read how to connect your store to Meta catalog ads without wrong products or broken pixels.