SEO friendly URL with SSR-pages - how to?

[7iomka]

Good afternoon.
In our project, we add/edit our products from the admin panel (also uses Next.js and works through REST Api).
We want to make an SEO friendly URL for each product.

For example we have url to product page in next pages folder:
/:locale/catalog/product/[id]

Now this is an SSR page (we have a lot of products planned, and the process of creating / importing products will be a very voluminous task if you think about SSG).
Inside getServerSideProps we get id from ctx.query.
We make a request to our /api/products/${id}.
And we return result as prop to the page.

In the admin panel, we add a product, and among the product fields we made a seoUrl field, with a value.
For example /iphones/iphone-11, which corresponds to a product with id === 1.
seoUrl does not include :locale (it will be added by our separate utility).

QUESTION: What should we do so that, for example, the page /:locale/catalog/product/1 can be opened by the link /iphones/iphone-11?

Next.js has various options for doing something similar that we want.

For example - for static sites with a small number of rarely added and updated pages, you can use the exportPathMap option in next.config.js.
But we have an SSR page, the number of products will constantly grow, and we are not allowed to restart the server every time a new product is added or changed.

I also looked towards the rewrites option, this is an asynchronous function with which it would be possible to get some map refs from Api and, based on this, have an actual value, but again, you need to restart the next server every time. Moreover, I do not quite understand whether it is even possible to do the task I described with the help of rewrites.

What ideas do you have in this regard?
We have many languages, and we want the links to our products to look beautiful, but also to match the language, that is, to be translated.

I will be very grateful to you and grateful for any help in this direction.

I am very disappointed that in Next.js it is difficult to understand how to make SEO friendly urls, although it would seem that this should be the primary task of the framework, which is designed to simplify SSR.

Thanks!

[samuelcastro]

@7iomka Why don't you just keep using SSG with revalidate (Incremental Static Regeneration) and fallback: true to generate a fallback page (with a loading) while the page is being build up.

That would improve the user experience of your site quite a lot specially because with SSG pages and assets (JS, CSS, images, fonts, etc) will automatically be served from the Vercel's Edge Network, which is blazingly fast.

You have way more benefits:

• No spikes in latency. Pages are served consistently fast
• Pages never go offline. If the background page re-generation fails, the old page remains unaltered
• Low database and backend load. Pages are re-computed at most once concurrently

And if you still need to fetch more dynamic data you can always use client side fetching.

Just my 2 cents.

[GTOsss]

@samuelcastro
It is not very clear how SSG will solve the problem with url friendly?
The first page visit will most likely be made by Google, which means that it will lower the rating of the resource for a long response?

[Vadorequest]

It is not very clear how SSG will solve the problem with url friendly?

@GTOsss SSG with fallback allows you to build "on-the-fly" pages, coupled with "catch-all" page pattern, it can be used to build pages based on any number of inputs.

But, SSG/SSR isn't really the question at this point. Both can be used as @samuelcastro mentioned. I'd personally go for SSG with revalidate, so that the previously built page is used while the new version is getting built. It's indeed faster (better SEO score) and even if your product changes on the admin panel, it'd update the page at the next page generation. But, in the end you can use either, it's just a matter of choices and constraints. (does the page MUST be always sync in real time? Or, can it wait a bit? (30sec, 5mn, depending on your revalidation strategy) That is what you must ask yourself regarding the SSG/SSR choice/dilemna.

@7iomka Regarding the initial issue, there is an official RFC about this that is going on, I suggest you take a look at it and see if it would help your use-case. vercel/next.js#17078

But, the RFC isn't implemented yet, and in the meantime you'll need to resort to a homemade solution. I'd personally go for "catch-all" routes. See https://nextjs.org/docs/routing/dynamic-routes

"/:locale/[...slug].js" would match fr/iphones but also en/iphones/iphone-11. Coupled with NRN feature that redirects all routes who don't specify the locale (e.g: "/iphones/iphone-11" would be redirected to "/en/iphones/iphone-11"), I assume you could get the whole slug array of parameters ['iphones', 'iphone-11'] and have an internal lookup to see to which page it should redirect to.

I believe it could be possible to either build your own "mapping" where "/iphones/iphone-11" redirects to "/:locale/catalog/product/iphone-11" page, for instance. Or, you could also serve the page without any redirection.

This needs a bit of experimentation, but I don't see anything that would make it impossible.

Also, I'll convert this "issue" into a discussion, as it's not a real NRN issue but more of a question 😉

[7iomka]

"/:locale/[...slug].js" would match fr/iphones but also en/iphones/iphone-11. Coupled with NRN feature that redirects all routes who don't specify the locale (e.g: "/iphones/iphone-11" would be redirected to "/en/iphones/iphone-11"), I assume you could get the whole slug array of parameters ['iphones', 'iphone-11'] and have an internal lookup to see to which page it should redirect to.

Yes, we are currently settling on this solution. But this adds the complexity of the database query on the backend api side. For example if we have seoUrl not only in products but in public pages, created dynamically through api.
We receive url from query, make an api-call, backend search need to be stepwise - dependent on priority: first we search through all product that have that seoUrl, next - in all page, etc.. But, if there are no other solutions - this is the only workaround.

I believe it could be possible to either build your own "mapping" where "/iphones/iphone-11" redirects to "/:locale/catalog/product/iphone-11" page, for instance. Or, you could also serve the page without any redirection.

Own mapping need to be updated each time (if it stored local file that import needle data from api/db) when any unit in database that is dynamic in terms of Next.js is changed, and, how I understand, I need to restart the next server each time for this operation, and until process is stopped - the application will be unavailable? If not, can I have a look at the working solutions?

Many thanks, yeas this is not issue, but I decided to hear the opinions of the community in this way :)

[Vadorequest]

Yes, we are currently settling on this solution. But this adds the complexity of the database query on the backend api side. For example if we have seoUrl not only in products but in public pages, created dynamically through api.
We receive url from query, make an api-call, backend search need to be stepwise - dependent on priority: first we search through all product that have that seoUrl, next - in all page, etc.. But, if there are no other solutions - this is the only workaround.

Yes, it really depends on your own business logic, or data structure at this point.

Own mapping need to be updated each time (if it stored local file that import needle data from api/db) when any unit in database that is dynamic in terms of Next.js is changed, and, how I understand, I need to restart the next server each time for this operation, and until process is stopped - the application will be unavailable? If not, can I have a look at the working solutions?

It doesn't have to be that way, you could for instance query your backend API and once you've found a match of the SEO configuration for your current path, you could store it in memory, or in the filesystem. (on-disk caching) This way you can reduce round-trips by using the cached SEO metadata once they've been loaded.

I understand you don't run Next.js in serverless mode but rather as a node.js process on your own server then? Not that it would change anything here, but that's a detail worth mentioning.