How to properly handle URL slug changes in Next.js
From Author:
If you're using a headless CMS for storing content, you also work with URL slugs, the last parts of any URL. The problem is, content editors are able to freely change the slugs which can cause 404 errors, lost page ranks, broken links, and in the end confused visitors on your site. In this talk, I will present a solution for keeping a history of URL slugs in the CMS and explain how to implement a proper redirect mechanism (using TypeScript!) for dynamically generated pages on a Next.js website.
Add to the talk notes: https://github.com/ondrabus/kontent-boilerplate-next-js-ts-congress-2022
This talk has been presented at TypeScript Congress 2022, check out the latest edition of this JavaScript Conference.
FAQ
Not handling URL slug changes properly can lead to 404 errors, loss of SEO ranking, and a poor user experience as visitors may encounter broken links, especially if they follow links from external sources or outdated marketing materials.
The 'getStaticPaths' function in Next.js is used to define which paths should be pre-rendered based on URL slugs. It should include all historic and current slugs to ensure that each one corresponds to a valid page, preventing 404 errors for outdated URLs.
In a headless CMS like Content by Kentico, you can track URL slug history using a custom element such as 'urlslug-history'. This element records every change made to a URL slug and stores these changes within the content item, allowing for an accessible history of slugs.
To manage URL slug changes in Next.js, first track the history of URL slugs for each content item. Then, use the Next.js functions 'getStaticPaths' to generate pages for all historical and current slugs, and 'getStaticProps' to implement redirects from old slugs to the current slug.
In Next.js, redirects for historical URL slugs are implemented in 'getStaticProps'. By checking if a requested slug is historical, the function can return a redirect object pointing to the current slug, ensuring users are directed to the correct page.
Handling URL slug changes is crucial because when a URL slug is altered, the old URL ceases to exist, potentially causing 404 errors. This can negatively affect SEO and disrupt visitors who use the old URL, especially if it was used in marketing campaigns or had a good search engine rank.
Video Transcription
1. Handling URL Slack Changes in Next.js
Hello, everyone. I'm Andrey, developer evangelist at Content by Kentico. Today, I'll explain how to handle URL Slack changes in Next.js. Every content item in the headless CMS contains a URL slag, and when the editor changes it, the old URL slag ceases to exist, resulting in 404 errors for visitors. To properly handle this, we need to know the URL slag history and use the getstaticpaths and getstaticprops methods in Next.js to issue redirects. Let's start with the content side, where we can use the urlslug-history custom element to track URL slag changes.
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.
2. Implementation of URL Slug Changes in Next.js
In Next.js, 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. We create a list of all the slugs and all the current slugs that they should redirect to. We store all the paths in the cache and provide all the slugs, historic ones and current ones, back to Next.js. We issue a proper redirect if we find out we should.
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.
Comments