Redirects ensure that people find your content even after its URL is changed. For instance, when you autogenerate SEO-friendly URLs for your articles, these URLs change when you rename the articles.This lesson explores how to approach redirects based on your needs. All the approaches mentioned here let your business users manage the redirects without any developer help.
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.Your handling of internal redirects depends on what parts of URLs you need to redirect:
For a flat hierarchy with short URLs, 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 hierarchical URLs, such as /blog/coffee/preparation/best-coffee-grinders, you need to redirect URL slugs and the category parts of your URL paths (coffee and preparation). That’s because when you change the placement of an article in the tree, you need to redirect between the categories.
Redirects for short URLs
If only the last part of the URL 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 URL 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 hierarchical URLs
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.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.
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 the 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-grinders into thesource URL text element.
Type somewhere.com/help/coffee into 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.
Sign in with your Kontent.ai credentials or sign up for free to unlock the full lesson, track your progress, and access exclusive expert insights and tips!
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.
Validate the format of the URL paths history listSince 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\.\/\-]+;$
. The great aspect of this approach is that it works autonomously without human intervention.
When the URL 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.
