Best approach to manage content item aliases

Question

We are thinking about migration from Kentico CMS to Kontent. So far we are found answers to most of our navigation related questions. But one question remains not clear. How to implement page aliases in MVC.NET+Kontent application.

Not rare business case when some page, let's say sub-productAA is being moved from productA to ProductB.

For instance: from /products/ProductA/sub-productAA it becomes /products/ProductB/sub-productsAA . Let's assume, that sub-productAA was advertised in a 3rd party website by it's original URL: /products/ProductA/sub-productAA .

Now original URL is dead. How to handle this situation?

Another example that product has been renamed and slug has been renamed as well to better address product mean. And original URL has been published elsewhere. How handle it and properly redirect to a new URL?

Thank you,

Answer 1

Kontent doesn't provide you with any built-in means to handle page aliases. As a headless CMS, it is up to you to decide how you map content items to URLs.

I don't think there is any single correct solution for this. If you don't have a huge number of aliases to manage you could handle them within Kontent by creating a content type that has a slug and a linked item so you can use this to store aliases and redirect to the correct content item. For your example:

• product content type item has a slug of "ProductB/sub-productsAA"
• alias content type item has a slug of "ProductA/sub-productAA"

you then have an action that retrieves content by slug from products:

var response = await _deliveryClient.GetItemsAsync<Product>(new EqualsFilter($"elements.{Product.SlugCodename}", productUrlSlug));

and if none is returned do another search against aliases:

var response = await _deliveryClient.GetItemsAsync<ProductAlias>(new EqualsFilter($"elements.{ProductAlias.SlugCodename}", productUrlSlug));

That way you only make the second call if the first fails. You can then retrieve the slug for the linked item and redirect the client to the correct URL.

The downside approach is that it requires content editors to manage aliases. Not a bad thing, as they should be thinking about the consequences of changing URLs.

An alternative approach would be to track aliases on your server. You could use webhooks to receive a notification about content changes. If a product slug has been modified you could store the old value and use custom middleware to redirect to the new version. More work, but no editor effort required.