```
## Load more: a link that becomes a button
A load-more control is the most robust form of infinite loading, because the visitor asks for more content and the footer stays reachable. Build it as a link to the next page, then let the script take over:
```js
const link = document.querySelector('#load-more');
link?.addEventListener('click', async (event) => {
event.preventDefault();
const url = new URL(link.href);
const res = await fetch(url, { headers: { Accept: 'text/html' } });
const doc = new DOMParser().parseFromString(await res.text(), 'text/html');
// Append the next page's items and take over its "next" link.
document.querySelector('#product-list').append(...doc.querySelectorAll('#product-list > li'));
const next = doc.querySelector('#load-more');
history.pushState({ page: url.searchParams.get('page') }, '', url);
if (next) link.href = next.href;
else link.remove();
});
```
Fetching the next page's HTML keeps the script and the paginated pages consistent by construction: there is only one source of truth for what page 3 contains. A JSON endpoint works too, as long as it returns exactly the same items.
To make it load automatically as the visitor scrolls, observe the link instead of waiting for a click:
```js
const observer = new IntersectionObserver((entries) => {
if (entries.some((e) => e.isIntersecting)) link?.click();
}, { rootMargin: '600px' });
if (link) observer.observe(link);
```
`IntersectionObserver` fires when the element comes near the viewport. It is also the method Google's [lazy-loading guidance](https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading) recommends for content, because it does not depend on scroll events.
### pushState or replaceState?
`pushState` adds a history entry per batch, so the back button steps through the pages; `replaceState` only updates the current entry, so back leaves the list. Either is acceptable for Google, which reads the paginated URLs and not the history stack. For visitors, `replaceState` usually feels better on a long feed, while `pushState` suits load-more buttons where each click is a deliberate step. Whichever you choose, the URL in the address bar should always open the batch the visitor is looking at.
## Canonicals, titles and indexing
- **Canonical:** each page points at itself. `/shoes/?page=2` has ``. Pointing all pages at page 1 tells Google that page 2 is a copy, and it may stop crawling the links on it.
- **Titles:** add the page number ("Running shoes – page 2"), so the pages are not duplicates of each other in titles.
- **Indexing:** do not `noindex` pages 2 and beyond. They are how Google reaches the older products and posts.
- **rel="prev" and rel="next":** Google stopped using them as an indexing signal in 2019. They do no harm, and other tools read them, so keep them if your platform emits them. The report lists them as information only.
- **Sort orders and filters:** paginate the default order only. Sorted and filtered variants of the same list are best canonicalised or kept out of the index; the guide on [faceted navigation and parameter URLs](https://getreport.app/guides/faceted-navigation-and-parameter-urls) covers the choice.
The guide on [pagination after rel=prev/next](https://getreport.app/guides/pagination-after-rel-prev-next) goes deeper into paginated series in WordPress, WooCommerce and Shopify.
## Lazy-loaded images and content
Lazy loading and infinite scroll are often confused. Lazy loading defers images or sections that are already part of the page until they near the viewport. It is safe for SEO when it uses the browser's native `loading="lazy"` or an `IntersectionObserver`, and when the image URL is in the HTML (`src` or `srcset`), not only in a `data-src` attribute a script swaps in on scroll.
Three rules keep it safe:
1. **Never lazy-load the first screen.** The hero or LCP image loads eagerly.
2. **Put the real URL in `src`** with `loading="lazy"`, or at least in a `