How to handle changes to url paths

[NickMNS]

I have a website that provides info about events, the path for each event is the event name. Simple, intuitive and user friendly.

The issue is that event names change over time. From a strictly technical perspective, the solution is simple, if a user enters/follows a link to the old name I simply redirect the user to the page with the new name. But from a UX perspective if the user expects the "ABC Event" but instead is redirected to the "XYZ Event" (which is still the same event but with the new name) the user may be confused. So should I, keep the old page and show a message "The ABC Event is now the XYZ Event, click here to go to the page" or "The ABC Event is now the XYZ Event, you will be redirected to the new event in 5 secs". What are the SEO impacts of such configuration?

Additional consideration, I sometimes have links between events (different, distinct events) that are included in the event descriptions. If I have a link on the page for 123 Event and it points to ABC Event, but the name changes for ABC to XYZ. I then have internal links pointing the wrong page. The redirect will point the user to the right place but I will continue send the wrong signals to Googlebot. Should I implement another path for internal links, using a unique id that doesn't change as the path and then implementing a redirect directly to the correct page.

The other solution would be to keep record of inbound internal links to each page, then if the name changes the inbound pages would need updating too, but would be easily findable and the change could be automated. But this seems like a lot of added complexity.

[lucy24]

You should definitely keep your internal links current. A link that leads to a redirect on your own site must be high on the “questionable technical quality” list.

But users? Bah. Do you have reason to think many of them look at URLs--assuming they’re using a device that even shows the whole thing rather than just “example.com”?

There exist reasons for making people wait to be redirected, but generally it’s just an annoyance. For you as well as them, since it gives potential users an extra five seconds to leave before ever seeing what you have to offer. Just make sure the visible text says plainly “XYZ event, formerly ABC event” with whatever wording (and font, and size, and color) is most likely to be helpful.

[not2easy]

If it can be done conveniently, it could be better to keep the old page active for a determined time frame (30, 60, 90? days) with a note about the more current content and a link to go there. Google doesn't like redirected search results, considers them a soft 404 and 'manipulative'. Google wants people to see the results they expected from the indexed URL and yes, the redirect to updated content may well be what they hoped to land on. Visitors might not appreciate the redirect, but might appreciate the option to decide.

As lucy24 mentioned, the message and its visibility should be clear and prominent enough to be noticed. If it must redirect, you should consider "noindex,noarchive" for the older page.

This is older info (2007): [googleblog.blogspot.com...] but it can help when you want to let Google know that a page/URL will be going away. The format is

<META NAME="GOOGLEBOT" CONTENT="unavailable_after: 31-Aug-2025 15:00:00 EST">

The more current information on Google/bots/meta includes the unavailable_after meta/X-robots info also, found here: [developers.google.com...]

[NickMNS]

I think I have come up with a way to solve the main issue. When the server receives the request for an old event name it will return a redirect as response and then with the response I will include a custom header,

{"x-old-event": "old-event-name" }

When the redirect request is received (technically when any request for that url is received), I will check the headers, if the x-old-event header is present, I will display small modal informing the user of the name change.

I haven't actually tried this yet, but it should be pretty simple to implement. I will try it in the coming days.

You should definitely keep your internal links current.

This suggests that I should use a unique-id for internal links. But the problem with that is that I then will have two sets of urls pointing to the same content. While I can use link canonical, Google may still prefer the UID links. Does it matter? Probably not, as long as Google is showing the pages in Search.

But the cases where this is really an issue are likely going to be few. And if the link and name isn't updated then probably using the redirect (as described above) provides a better UX (informs user of change) and keeps only a single set of urls.

it could be better to keep the old page active for a determined time frame (30, 60, 90? days)

I want to keep references to the old name indefinitely as people may search for the old name well into the future. Now that I think this through, I should really add a section to the page with "previous names for this event". As for keeping an old/archived page, that is actually tricky in my case as I am keeping rolling stats on the event. I would need to clone the event (with all its data) in the DB after each name change, which could accelerate the rate of growth of the data. Names can potentially change each year. I archive events that are no longer held, which is straight forward as data is just not updated.

Thanks for the input it has really got me thinking about the right way to get this done.

[lucy24]

When the redirect request is received (technically when any request for that url is received), I will check the headers

Please let us know if this works. I don't understand how a non-standard response header turns into a request header on a subsequent separate request (which technically is what a redirect does).

I was also thinking a bit about keeping old content. For search engines, the redirect needs to remain forever, though after a few years you might yield to exasperation and start returning a 410 instead (assuming, of course, that by this time your internal links lead to the current URL). But for humans looking at visible page content, it would depend on frequency of events. If it's annual, keep the “formerly known as” text for a couple of years; it it’s weekly, in some cases as little as a few months.

[NickMNS]

I don't understand how a non-standard response header turns into a request header on a subsequent separate request

Well it seemed a little too easy! I could write the header, but it wasn't received after the redirect. I still got it to work though, I had to create Cookie instead.