Avoid 404s with redirects

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:

1. Create a content item of the Redirect rule type.
2. Type mydomain.org/blog/best-coffee-grinders into the source URL text element.
3. 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