searchParams Pagination prevents ISR / Static generation

[mkoreo]

Designing my site with Next.js 13/14 App directory, I started of showing results with searchParams pagination.
ex. https://someblog.azerty/greatblogsposts?page=3

That is logical and clear.
However, it prevents any form of static generation for next.js because you have to use searchParams prop in a page.ts file.
The route turns into a dynamic route (which cannot use generateStaticParams as the searchParams page param cannot be adressed).

Should I opt to change it to https://someblog.azerty/greatblogsposts/page-3 instead for best SEO and performance?
Isn't that "weird"?

[moonkorea00]

@mkoreo have you managed to find a solution?

[mkoreo]

Hey,

I reworked my website to use the later format, without searchParams.
Ex. https://someblog.azerty/greatblogsposts/page/3

So no, I could not find a solution to have the searchParams statically generated.

[moonkorea00]

i think the later format is the solution you would want to use.

the docs suggests to use suspense with useSearchParams in a client component which keeps the route to be statically rendered while the dynamic part that uses useSearchParams is client-side rendered. But the fallback would be your initial HTML and the susepended component would render client side.

using searchParams would trigger dynamic rendering.

i found this issue helpful as well.

[felipedeboni]

Yes, I was with an ugly workaround.

You can keep your querystring /whatever?page=x as long as you have a middleware that rewrites ?page=x to /whatever/page/x. If you ask me does not make any sense not being able to use search params with ISR, but it is what it is :)

[Ziothh]

Tbh this feels like a massive hole for websites that want to statically render for performance.

F.e.: I have a /search page that I want to statically render for good SEO. The content basically never changes.

I'd like to also statically render other variants of the page like /search?category=5&page=2.
These should just be computed once every day and stored in a CDN.

This isn't possible right now.

I know I can use unstable_cache() but there is still a performance difference.