Partial reloads vs. full visits for paginated Inertia tables when SEO and history matter

Context

An Inertia.js application renders a large dataset using Laravel's LengthAwarePaginator serialized into Inertia's pagination object. The product team requires indexable URLs for each page (e.g., /posts?page=3) and browser history support so users can navigate back to a specific page. At the same time, the UX goal is to avoid full-page flashes when moving between pages.

Constraint

The pagination mechanism must preserve a shareable, crawlable URL per page and maintain history entries, while minimizing perceived latency during page changes.

Trade-off

Two documented patterns are available:

• Full Inertia visits (router.visit(url) or router.get(url)) update the URL, push history, and are SEO-friendly by default, but trigger a complete page replacement including re-mounting components.
• Partial reloads (router.reload({ only: ['posts'] })) fetch only the paginated prop, keeping the component mounted and avoiding a flash, but they do not update the browser URL or history stack unless manually augmented.

Both approaches can return the same paginated JSON structure from the backend.

Open questions

1. When SEO and deep-linking are hard requirements, is the accepted pattern to use full visits and accept the re-mount cost, or to combine partial reloads with a manual history.pushState call to sync the URL?
2. If manual history manipulation is used with partial reloads, what are the edge cases around browser back/forward navigation that Inertia's built-in visit handling would otherwise manage?
3. Does the preserveScroll option (or a custom scroll restoration strategy) behave differently between these two approaches when the component stays mounted versus re-mounting?