How to properly handle URL slug changes in Next.js

Hello, everyone. I'm Andrey, developer evangelist at Content by Kentico. And today, I want to tell you how to properly handle URL Slack changes in Next.js.

Now, first of all, why should we care about the URL slags? Every content item that is stored in the headless CMS and you are actually storing it or displaying it as a page in your site implementation contains a URL slag. Now, the problem is when editor comes into that content item, changes the URL slag, and your site implementation just takes the change, rebuilds the page, and the old page, the old URL slag just ceases to exist. The problem is if that page used to have a good page rank on search engines, or you used that page in your marketing campaigns, all those visitors that are using that URL will now get 404 errors. And these days we cannot really afford confused visitors, right?

So, what we need to do is, first, we need to know for every page, every content item, we need to know the URL slag history. You see here, the example is that the current page has a URL slug, hello-typescript-congress, but in the past it used to have a URL slug, typescript-congress and hello-conference, we need to know the history in order to be able to issue the redirects properly. Next thing is for the Next.js, now we're going to be using Next.js and content in this example, but if you're using a different framework, you can apply the same principles there. Here we're just talking about Next.js, so we have two methods. We have getstaticpaths and getstaticprops. In getstaticpaths, we need to provide all the URL slugs where there is a page for us to generate. In that case, we need to provide all the three URL slugs. So, that's the history ones and the current ones as well. And the last step, the third step is to add a proper redirect in getstaticprops. There we need to find out based on the slug, whether this is a current slug, like the hello-typescript-congress, which is the target page, or whether the slug that we're using is a historic one, and we should redirect the visitor to a current page. In this case, that would be the typescript-congress, hello-conferences, which will issue redirects. So how can we do this in Next.js? Let's take a look. Let's start in content first. On the content side of things, I prepared one content type called conference. And when you look at the content item, that's already using that content type. You see in content we have a special urlslug-history custom element that you can use on your project. It's available open source, so we can just deploy it to Netlify or Vercel and use it just like I'm using it here. It actually tracks all the changes you do to a urlslug. So you see here, now the urlslug is typescript-congress-2022. If I change it to typescript-congress, it automatically registers the change. And when I publish the page, it's going to store the change within the content item. So you see this is in the history. Now, we can do this as many times as we want. We're just going to get a list of strings out of the API, but this is the first step.

You need to know all the urlslugs, the historic ones and the current ones. Now let's take a look at the implementation. In Next.js, I have a simple page, slug-tsx. Now this whole thing is based on a Next.js content boilerplate, so there is not a ton of functionality. But here you see there are two methods, getStaticPaths, getStaticProps. And as I mentioned in the presentation at the start, you need to provide all the paths to getStaticPaths or as a result, to Next.js.

In getStaticProps, you need to issue the redirect if it's a page that should be redirected. So here we just need to do one simple change and add to the elements parameter the history as well. So before, we were only using the URL slug, but now we want to use the URL slug history as well to get really all the paths. And now we need to get all the paths in a simple list.

Now the thing is, if we only get the paths in getStaticProps, we would have to do one additional API check with the content API to see if the slug is a historic one or a current one. So what I'm going to do is I'm going to create a list of all the slugs and all the current slugs that they should redirect to. Now, I'm going to do the implementation here, I'm going to fast forward and then I'm going to explain the code in a second.

Right, so what I implemented here is we're getting all paths from the content CMS, and we're actually providing all those paths back as an IPagePath structure, which you can see contains just two properties path and redirectsTo. Path is the URL slug, the current one, and redirectsTo is, in case we're working with the historic path, here we're going to hold the current path of any page. So you see that for the actual item coming from content, we're providing a path that is the current path of the item, the one of the published version of the page. And then we're creating a structure of the historic paths, historic slugs, and they redirect all to the current page path.

Now the problem is, we cannot really take the whole structure and provide it to Next.js so that we get it in getStaticProps. The reason is, Next.js will only allow us to transfer the slug, because it's in the filename, it's the variable on the way to the page. So we're not going to be able to transfer this to getStaticProps and avoid the performance problems. So what we're going to do is, we're going to do a workaround suggested by Versal, where we're just going to take all the paths, we're going to serialize them into a physical file, and then we're going to take that file back in getStaticProps. I'm just going to again do the implementation and fast forward.

Now you see here that I'm storing all the paths in the cache. The last thing I need to do here is to provide all the slugs, right, this is the second point from the presentation. We need to get all the paths, historic ones and current ones, and return it back to Next.js here. Because we're just telling Next.js, on this path, there is not a 404, there is a page here. And now we need to do the third step, and that is issue a proper redirect if we find out we should. So, in this case, we're just taking the path from cache and if there is a page that should be redirected, it will have the redirects.to field. Because these are all the historic URLs slugs, and we need to redirect them to this path. So, we can do a simple condition here, if path.redirects.to exists.

In that case, we want to do the redirect. So, we're going to return a redirect object, and the redirect object only needs to contain a destination and a permanent. So, permanent, if you want to do 307 or 308 redirect, based on that, set the permanent field. I want permanent to be true. And in the destination, just remember if you're in the subfolder or if you're in the root, this is going to be destination from the root of your site. So in my case it's just a slash and path it redirects to. So let's save this.

There is still a problem here under get static paths. Right. I forgot. Yes there is path dot path, because here we're getting just the object, so we want the slack in there. Now, this is fine. So let's try to run the site. And let's go back to the browser and refresh this page. Now, the current URL slack is TypeScript Congress. So on that page on the URL slack we should have TypeScript Congress page. So you see this is working. And the previous slack was TypeScript Congress 2022. So if we append here 2022 we should get redirected to TypeScript Congress. So it works as expected.

Now, the implementation isn't ideal to be honest, but it works this way and lets us put everything in order. And it does not, that's the most important thing, it does not require editors to do any extra steps. It just works. And that's all from me. If you want to get more information about this solution or you want to share your experience handling URL slacks, then definitely reach out to me. You can find me on Twitter.