A smaller catalogue page without losing crawlable navigation

A developer published a teaching example showing how to keep a catalogue page small while preserving crawlable navigation: the server returns only the current page's items and total count, full public metadata is fetched in the browser only when a search begins, and pagination uses real anchor links with distinct URLs rather than JavaScript-only buttons. The example includes a client-side loader with per-locale caching, a shared in-flight Promise to avoid duplicate reads, an 8-second timeout, and strict response validation, and it explicitly notes the code is illustrative, not production application code, and reports no measured performance or ranking improvement.

Disclosure: This article was primarily drafted by an AI assistant using official documentation and a reviewed technical example. The code is a generic teaching example, not production application code. It does not report a measured performance or search-ranking improvement. A catalogue page has at least two different jobs. It lets people browse a stable page of linked items, and it may let them search a much larger collection. A visitor reading one page does not necessarily need the entire search index in the initial HTML or hydration data. One way to separate those jobs is to return the current page’s items and total count from the server, then request full public metadata in the browser only when somebody starts a search. Normal browsing can use links such as /en/catalogue?page=2, so navigating the collection does not depend on a JavaScript-only button. A page size such as 60 items is an implementation choice, not a Google rule or a universal performance threshold. Choose a page size based on the information people need and measure the resulting document. Before introducing search, make the basic browse path work. Each item should have a real destination link. Each page should have a real URL and a sensible title. Previous/next controls should use anchors. A search interaction can be richer, but it should not be the only way to discover the catalogue. Google’s pagination guidance describes how crawlers find content through links and recommends distinct URLs for pages in a sequence. It also explains why button-driven incremental loading needs attention. This is discoverability guidance, not a promise that every linked item will be indexed. For example: <nav aria-label="Catalogue pages" <a href="https://dev.to/en/catalogue" Previous</a <a href="https://dev.to/en/catalogue?page=2" aria-current="page" 2</a <a href="https://dev.to/en/catalogue?page=3" Next</a </nav Treat each actual browse page consistently in canonical and language metadata. Do not canonicalize every distinct page to page one simply because it belongs to the same catalogue. The following loader illustrates the client boundary. It expects an example same-origin endpoint, /demo/catalog.json?lang=en, returning items with id and name, a boolean partial field, and optionally unavailable=true. This endpoint is illustrative; you would need to implement it for your application. It includes no credentials and must only be used for public metadata. Do not reuse this shared cache for wallets, messages, orders or identity. A shared Promise prevents multiple consumers in the same loader instance from starting identical reads simultaneously. It is not cross-browser, cross-worker or globally distributed deduplication. // Educational browser loader. /demo/catalog.json is an example endpoint. // Public metadata only; never cache account data here. export function createCatalogLoader fetcher = fetch, now = Date.now { const locales = new Set 'en', 'tr', 'pt', 'de', 'ru', 'id', 'bn', 'es' ; const cache = new Map ; const pending = new Map ; return async function loadCatalog locale { if locales.has locale throw new Error 'UNSUPPORTED LOCALE' ; const hit = cache.get locale ; if hit && now - hit.at < hit.value.partial ? 15 000 : 300 000 { return hit.value; } if pending.has locale return pending.get locale ; const work = async = { const response = await fetcher /demo/catalog.json?lang=${locale} , { credentials: 'omit', cache: 'no-store', signal: AbortSignal.timeout 8 000 , } ; if response.ok throw new Error 'CATALOG UNAVAILABLE' ; const raw = await response.json ; if raw || raw.unavailable === true || typeof raw.partial == 'boolean' || Array.isArray raw.items || raw.items.length 10 000 || raw.items.every row = row && typeof row.id === 'string' && typeof row.name === 'string' { throw new Error 'CATALOG UNAVAILABLE' ; } const value = Object.freeze { partial: raw.partial, items: Object.freeze raw.items.map row = Object.freeze {id: row.id, name: row.name} , } ; cache.set locale, {at: now , value} ; return value; } ; pending.set locale, work ; try { return await work; } finally { pending.delete locale ; } }; } There are deliberate limits. The metadata endpoint still needs its own server-side controls and appropriate size limits. The example validates the fields it consumes, not every possible input. AbortSignal.timeout needs a compatible runtime. Its timer measures active time and is not a universal wall-clock SLA. Adapt browser compatibility handling to your audience. An unavailable request and a successful empty result mean different things. Rendering “no matches” after a timeout tells a user something the interface does not know. Keep these states distinct: | State | Useful user-facing behavior | |---|---| | Browsing | Keep the server-rendered page and its links usable. | | Loading search | Announce loading through a status region. | | Complete search | Show matches; an empty message is now meaningful. | | Partial search | Show available matches with an explicit incomplete-data notice. | | Unavailable search | Explain that search could not load and offer retry. | A partial response with zero records must not silently become a complete empty result. That is why the partial flag remains in the return value instead of being discarded after parsing. In React, also guard the context in which a response is displayed. If somebody changes language while the previous language’s request is still running, its result must not overwrite the current screen. An Effect cleanup flag can ignore a late result for a replaced context. React’s own documentation demonstrates this kind of race-condition guard. Cancellation and ignoring obsolete results solve related but different problems; a shared request may still have another active reader. First compare decoded HTML size and the number of requests before anyone touches search. Then start search and check whether one public read is reused. Test a delayed response, a failed response followed by retry, a partial empty response and a language change during loading. Finally, clear search and verify that the original page is useful again. Use a browser performance tool for LCP, INP and CLS. A smaller HTML payload is not, by itself, a measured Core Web Vitals improvement. Neither a successful build nor an indexable URL establishes search ranking gains or a better user experience. To test the loader without external services, inject a mocked fetcher and clock. Check concurrent reads, cache expiry, unsupported locale rejection, retries after failure and the shorter lifetime of partial data. Keep fixture results separate from claims about real network behavior. For a modest public metadata catalogue, a first-use full index can be reasonable. If it becomes large enough that loading it on the first query is expensive, switch the optional search path to a bounded server search endpoint instead. Keep browse URLs usable in either case. The useful outcome is simple: initial HTML serves the visitor’s present task, optional JavaScript serves the next task, and an error message describes what the system knows. Sources: