How to handle redirects in Kontent.ai
A redirect is an instruction to your web app about a resource’s new location. For instance, when you autogenerate SEO-friendly URLs for your articles, these URLs change when you rename the articles.
That’s when you need to redirect. Search engines and other websites keep using the old URLs, and your redirects ensure that people find your articles even after you change their URLs by moving or renaming them.
In Kontent.ai, you need to set up redirects both in your content model and in your app. This article shows you how to approach redirects based on your use case.
Table of contents
- Internal redirects change your visitor’s destination within your web portal; external redirects lead outside your portal.
- Your internal redirect approach depends on your URL structure.
- External redirects are best achieved using a dedicated content type.
- Use temporary redirects except for permanent domain changes to avoid redirect caching issues.
It’s best to enable your business users to manage the redirect rules without needing help from developers. All the approaches in this article use redirect rules accessible directly from within the Kontent.ai app.
Internal redirects
Internal redirects are for redirecting your visitors to another place within your app. Typical use cases are renaming an article, moving it to another category, or archiving it in favor of a newer one.
If you need to redirect outside your app, look at external redirects.
Your handling of internal redirects depends on what parts of URLs you need to redirect:
- For a flat hierarchy, such as
/blog/best-coffee-grinders, you only need to redirect URL slugs – the last part of the URL path, usually auto-generated from a title-like text element. - For a content tree hierarchy, such as
/blog/coffee/preparation/best-coffee-grinders, you need to redirect URL slugs and the category parts of your URL paths (coffeeandpreparation). That’s because when you change the placement of an article in the tree, you need to redirect between the categories.
Redirects for flat hierarchies
If it’s only the last part of URLs that changes, you can use a custom element that watches for URL slug changes. The great aspect of this approach is that it works autonomously without human intervention.
When the slug changes, the custom element saves the previous slug value to a slug history list. Your app can use the list to redirect the old URL slugs to the content item’s current URL.
Redirects for content tree hierarchies
For redirecting in a more complex URL hierarchy, you need to save the history of the whole URL path. The URL path consists of the categories in the URL and the URL slug itself.
The most intuitive way to keep the URL paths history list is to add a text element to your content items and keep the history list there. When the content item’s URL slug or hierarchy placement changes, insert the previous URL path into the text element.
When inserting URL paths into the history list, always use relative URLs – that means /blog/coffee/preparation/best-coffee-grinders without the https://mydomain.org part. This ensures your redirects work even if your domain changes.
Similarly to the URL slug history approach, your app uses the URL paths history list and builds redirects from the old URLs to the content item’s current URL. The content item with the URL paths history list needs to be published.
Validate the format of the URL paths history list
Since the history list is built manually by people, it’s beneficial to validate it using regex rules. This helps to ensure the format is correct or that there are no absolute URLs.
For example, to ensure each URL path is on a separate line, starts with a forward slash, and ends with a semicolon: ^(\/[a-zA-Z0-9\.\/\-]+;\n)*\/[a-zA-Z0-9\.\/\-]+;$
External redirects
To redirect your visitors outside your app, set up external redirects. The “outside” may either be still within your domain or under a completely different domain:
- Outside, but still within your domain:
mydomain.org/blog/best-coffee-grinders→mydomain.org/shop/cofee-grinders- You have multiple web apps running different parts of your web portal, such as blog and shop, for example.
- You want to shorten a URL, for example,
/blog/best-coffee-grinders→/good-morning. - You no longer have a content item for an internal redirect because you archived it, for instance.
- Outside your domain:
mydomain.org/blog/best-coffee-grinders→somewhere.com/help/coffee- You have multiple domains and need to redirect between them.
- You decide it’s best to redirect visitors to a 3rd-party website instead of serving them your own content.
Dedicated content type for external redirects
For external redirects, you need an approach different from internal redirects because your app doesn’t control the target landing page.
To build rules for external redirects, create a dedicated content type called Redirect rule, for instance. Add two text elements to this content type, one for the source URL and the other for the target URL.
Let’s say you need to redirect from mydomain.org/blog/best-coffee-grinders to somewhere.com/help/coffee:
- Create a content item of the Redirect rule type.
- Type
mydomain.org/blog/best-coffee-grindersinto the source URL text element. - Type
somewhere.com/help/coffeeinto the target URL field.
With this approach, your app looks for content items of the Redirect rule type and builds redirects based on their source and target URL values.
301 or 302? Permanent vs. temporary redirects
There are two main types of redirects – permanent and temporary. We recommend using temporary redirects for most cases. Here’s why:
- 301 – permanent redirect: When this redirect type is used, the server only responds with a new location of the requested resource. It’s a bit tricky because anything with a cache, be it a web browser or search engine, caches the redirection and never again sends a request to the old location. Use permanent redirects for domain changes, for instance. Not for “usual” redirects like article renames.
- 302 – temporary redirect: With a temporary redirect, browsers and search engines don’t cache the redirection. They’ll keep asking for the original resource with each subsequent visit. This makes it easier to change and maintain the temporary redirect rules.