Sometimes URL slugs need to be changed — maybe someone mistyped a word, or information gets updated. Changing the URL is easy, but what about all those links on social channels and other websites that you can’t update? Redirect the original URL.

Redirects are handled, mechanically speaking, at the delivery part of your architecture. It’s a technical task that has multiple implications for your application and impacts SEO, and customers handle them in a variety of ways.

Managing at the delivery layer

Because Contentful has all the functionality of a headless CMS – and more besides – the routing of content is handled in your application, e.g., the “folder” in site.com/blog/blog-post-name. Typically, Contentful content that is mapped to a view or page has a slug field, and routing handled elsewhere (but inferred sometimes by your content type, like “Blog”). 

For example, with JamStack applications, it’s often easier to simply manage redirects in a single file at the host, such as Vercel or Netlify. It’s centrally managed, and there are powerful options; it gives customers the ability to specify complex redirect rules such as “splats” (wild cards), the type of redirect (301, 410 for retired content, etc.), index/noindex status and control over 404 page content — you might wish to redirect someone not finding blog content to a featured post, or a search feature. In addition, the order of these operations matters, and a single config file is fast and reliable.

The disadvantages to this approach are that, being a DevOps function, it’s sometimes separated from content creators who might be performing SEO activities. Depending on the quantity of redirects, this file can get quite large. That’s not necessarily a problem, just something to be aware of. 

Enabling control for content creators

Some customers have content creators tightly connected to SEO/SEM activities, and they have created Contentful fields for managing redirects—which then must be handled by the delivery architecture. This gives them the ability to add a redirect URL right in the UI, and have fields for specifying the server code, and other SEO fields. Some customers create a dedicated content type for this purpose, which then can be acted upon by other systems via webhooks or App Events. 

The disadvantages to this approach are increased system complexity, the need for more robust logic to handle order-of-operations and other negative conditions, and potential challenges created by decentralized governance of a critical delivery function. Another challenge is that it creates a lot of fields for content editors to manage because multiple fields are required to orchestrate this activity, 

Contentful’s extensibility capabilities let you handle these challenges. Here is one example of a third-party UI extension (a predecessor to our more powerful App Framework) that presents these fields as a grouped pane. This solves some of the editorial management challenges, at a slight technical cost over using native Contentful fields for this purpose. As the method above describes, it still requires application logic necessary to translate these for the server. 

Summary

Choosing the right approach for your application and business needs depends on multiple factors: team size and composition; level of training available; frequency of SEO activities like redirecting and retiring content; and the size of your content pool. 

Our Professional Services team can help you navigate these questions and arrive at the optimal set of solutions for your needs. One of the benefits of a composable content platform is that you can build a better version of URL redirect management that scales with your organization.

For an in-depth walkthrough on optimizing SEO with Contentful, please refer to this guide.

Start building

Sign up for a free Contentful account

Use your favorite tech stack, language, and framework of your choice.

Subscribe for updates

Build better digital experiences with Contentful updates direct to your inbox.