Pagination or Load More? Plan How Visitors Browse Your Website News
Back to News

Pagination or Load More? Plan How Visitors Browse Your Website News

Choose a news-list pattern around what readers need to find, not just how the first screen looks. Define navigation, return behaviour and crawlable routes before development.

Pagination or Load More? Plan How Visitors Browse Your Website News
Key takeaways
  • Choose the browsing pattern from real reader tasks and archive size.
  • Specify what happens when readers return from an article.
  • Keep older stories discoverable through crawlable page links.
  • Test loading, errors and the end of the list—not only the first screen.

Start with the reader who is not looking at page one

A news page often looks convincing in a design presentation: a neat grid, attractive covers and a few recent headlines. Its harder job begins when someone needs an older announcement, follows several stories in succession or returns from an article on a phone. Pagination and Load more are different answers to those tasks. Neither is automatically the modern or correct choice.

Before selecting a control, describe three realistic journeys. A prospect might browse recent work; an existing customer might find an announcement they remember from last year; a colleague might share a particular story. Decide which journeys matter most and whether readers usually know a date, subject or title. This is a navigation brief, not a request to add every possible filter.

Choose the pattern and its limits together

Pagination divides the archive into addressable sets. It can suit a long history where readers need a sense of position or a route back to an earlier group of results. Load more extends the current list after an explicit action. It can suit exploratory browsing, provided the growing page remains manageable. Infinite scrolling removes that explicit action, which makes the stopping point and access to the footer worth particular attention.

Write down the initial number of cards, the increment and the expected archive size. Treat these as prototype settings to test, not universal best-practice numbers. A list of short headlines and a list of large editorial cards impose different reading and loading costs. On mobile, avoid judging the result from a desktop screen simply narrowed in a presentation.

Make returning to the list part of the specification

Consider this illustrative test: open the archive, load two more groups, open a story near the bottom, then use the browser Back button. Does the reader return to that story in the list, or start again at the top? Specify the expected result for the supported browsers. Also decide what a refresh or copied list URL should preserve.

Where categories or dates are available, changing a selection should have a clear effect on the current position and loaded items. Agree whether it resets the list, how the active choice is shown and how readers clear it. Otherwise individually reasonable controls can combine into a confusing journey. Include a genuine empty result and a category with only one story in the prototype.

News browsing flow from list to article and back to the retained list position and filters.
Test the return journey as well as opening the next article. Illustrative browsing flow.

Separate the visible control from content discovery

Google’s guidance says its crawler generally discovers links through anchor href attributes; it does not normally press buttons to reveal more content. A working Load more button therefore does not by itself prove that older articles are discoverable. Ask the developer to demonstrate the underlying linked routes, rather than relying on the visual interaction.

For a paginated sequence, Google recommends a distinct URL and its own canonical for each page, with sequential crawlable links. Pointing every archive page’s canonical at page one is not the recommended pattern. These are implementation checks, not a promise that every story will be indexed or ranked. See Google Search Central’s pagination guidance in the sources below.

Review failure and completion states

Request examples of the button while loading, after a failed request and after the final item. A failed load should not silently look like the end of the archive. The reader should understand whether retrying is possible without losing the content already visible. The final state should make clear that the list is complete.

Test keyboard operation and whether newly added content can be understood without unexpected jumps. Check long titles, missing optional images and slow connections. Keep the review evidence simple: record the starting condition, action, expected result and actual result for each journey. A screenshot of the first nine cards cannot demonstrate these behaviours.

Give the website team a compact acceptance brief

The handover should name the chosen pattern, starting and incremental counts, sort rule, return behaviour, URL behaviour, filters and loading states. Add representative archive content and the journeys used for acceptance. Decide who will verify that newly published stories appear in the correct order. This keeps content management and front-end behaviour connected.

For a new corporate website or an archive redesign, discuss the list alongside the article template through Miracle’s website design service. The CUHK2030 project is also available as a website case reference. Define the behaviour your own readers need; another site’s pattern is a useful discussion point, not evidence that it will suit every archive.

Plan your website project

Explore Miracle website design and development

Related project: CUHK 2026–2030 Strategic Plan

Sources and further reading

Google Search Central: Pagination and incremental page loading

Miracle website design

Miracle CUHK2030 case

Frequently asked questions

Is Load more better for SEO than numbered pages?

Not inherently. The key technical question is whether search engines can discover the content through suitable links and URLs. Choose the reader interaction separately, then verify its crawlable implementation.

How many stories should the first screen load?

There is no universal number. Prototype with representative titles and images on target devices, then assess reading effort, loading behaviour and the size of the archive.

Do we need to redesign every article to improve the archive?

Not necessarily. The list can be a scoped change, but article links, Back navigation, card metadata and publishing order still need to be tested together.

Planning something similar?

Talk to Miracle