How to deal with name changes within a URL

[NickMNS]

My website tracks events over time. Logically, the name of the event appears in the url for each event. eg:
www.example.com/event-name/some-facet/uid

These events at times can change names, in which case the url should be updated with the new name. Ideally I would like to avoid creating a new page for the new name and I would also like to avoid keeping the old page (that is keep an old version frozen in time). The simplest approach would be to rename the page and then create a 301 redirect from the old to the new. But, this has potential, over time, of creating a Spaghetti Bolognese of redirect chains, as the names could change multiple times.

My content is generated dynamically based on the url, so I can have two urls pointing to the exact same content. Obviously, this can create a duplicate content issues. To avoid the dupe-issues was thinking of using rel=canonical tag setting the canonical to the latest name. Like that whether a user uses the old or new url they arrive at the same place.

Am I putting too much faith in the rel=cannonical link tag, and should I bite the bullet and devise a system to manage redirects?

I could also 404 or 410 the old url and simpy forget about it. But then I would loose any links pointing to it. So that approach is basically ruled out.

[notriddle]

[blockquote]Am I putting too much faith in the rel=cannonical link tag[/blockquote]

If both pages actually contain the same content, I'd say it's fine to rely on the canonical link tag. At least, for any usable search engine, they're already going to try to identify duplicate content anyway. If both pages are byte-for-byte identical, it should collapse them down to a single URL without issue.

[lucy24]

But, this has potential, over time, of creating a Spaghetti Bolognese of redirect chains, as the names could change multiple times.

Why would that necessarily create a redirect chain?
If
/page1
is renamed
/page2
and then at some later time becomes
/page3
and eventually
/page4
the redirect should be in the form
(page1|page2|page3) >> page4
in a single step. (Been there. Done that. But really, I don't think it will happen as often as you fear.)

[NickMNS]

@Notriddle, the more I think of this the more I'm convinced that I cannot rely on the canonical tag. As you mention, in this case as this will be byte for byte "copy" it will likely work, I just don't want to deal with the mess if or when it doesn't work, and with Google's reputation with these things you just can't be sure (eg: rel="nofollow").

the redirect should be in the form

The key being should. After giving this some more thought it will essentially need to work like that. As a side note the redirect will occur at the application level, and not at the Apache level.

Currently it works such that if a URL is entered including a valid UID (unique event identifier) it will check the db to see if the event name matches, if that all matches it shows the page, otherwise it shows a 404. The idea is to include the past names in the search, if a UID + past name are found it then explicitly redirects (301 response code) to the current URL with the UID and the current name. The UID will never change.

My concern is that this creates a possibility of having many URLs leading to the same content. Reasonably many would be 4 or 5, different URL's per event. But if one assumes many == many, then whether it is 5 or 5000, shouldn't be a concern. Thus, I could avoid the look-up for the past event-name and simply redirect any URL with a valid UID and any value as the event-name to the correct URL with the current name. Is this reasonable, or does that have to potential to create problems?

And assuming it is reasonable, is adding a canonical tag a useful precaution, or pointless?

[notriddle]

The biggest problem you're going to have to worry about is cases where Googlebot:

* Google discovers scans the old URL

* Then you change the old URL to the new one

* Then Google discovers and scans the new URL

* But it doesn't rescan the old one

If this happens, Google won't know about the equivalence between them, because it'll know of two pages with different content and won't know about your redirect. This will be the same problem whether you use a canonical url and a redirect. It won't make any difference.

You're best off not changing the URL at all. Don't change the URL is the best policy no matter what. If you must change the URL, I don't know of any reason to believe that it'll matter whether you're using a redirect or a canonical tag: either one will have to deal with a short intermediate state where both URLs are considered valid by the Google index.

[lucy24]

* But it doesn't rescan the old one

This is what we call a counter-factual proposition. I do not believe that there exists an URL in the history of the internet that G has not re-crawled ... again, and again, and again.

[notriddle]

Yes, it is eventually going to rescan it. But it's still likely there will be a delay between scanning the new URL and re-scanning the old one, at least sometimes. And it's a known fact that Google rescans the same URL multiple times before they "trust" the redirect to be permanent.

I understand not trusting Google to have a bug-free implementation of canonical URLs. I don't understand why you'd expect canonical URLs to be worse than redirects. Unless some people here have personal experience with canonical URL link tags being worse than redirects. Does anyone have that?