[simcop2387]

The usual way I've seen to deal with this kind of ambiguity is by doing a 301 redirect so that bookmarks get changed and the url in the address bar is also changed. It doesn't fix external parties linking to the site with the now deprecated url but there was never anything you could reasonably do about that.

> If you are going to insist upon doing this, how about doing it using a # on the page, so at least everyone had a chance to know that it is extra, random data that can be dropped from the URL without penalty and might not come from the website and so shouldn't be trusted?

The fragment doesn't get indexed by search engines so not many will see it. Along with that, in my understanding, having something human readable in the URL helps with SEO in at least google an bing so doing this could hurt your search rankings which isn't a good thing.

[Tushon]

Minor correction, because dealing with this is a part of my job: Almost no browsers have implemented changing bookmarks in response to 301 redirects. Link has further context and some testing.

https://superuser.com/questions/151366/do-browsers-change-ur...

[simcop2387]

Interesting, I had always gone with that since the RFC says it should happen. Good to know.

[chrismorgan]

301 may be dangerous, because browsers cache them.

Suppose the client follows a link to old-slug after the slug has been changed to new-slug. The server responds 301 → new-slug. The client caches that redirect, so that if you request old-slug it will immediately take you to new-slug without querying the server.

Then the object’s slug is changed back to old-slug (perhaps the change was made in error). Now a request to new-slug produces a 301 → old-slug. This likewise is cached, and a client may new be stuck in an infinite redirect loop.

I’m not sure if this is actually what browsers do; they might detect the loop and decide to throw away their cached redirects. I haven’t tested it; but I wouldn’t count on it.

[always_good]

I just tried it locally in Chrome/Firefox/Safari. Ends up working, no issue.

[ademarre]

This used to be a serious problem. It may be fixed now, but Firefox would eternally cache 301s unless explicitly told not to. This is why I configure all of my servers to disallow caching of 301s.

[othersideofcoin]

Minor nitpick, I'm not sure if exact match in URL slugs matters from Google's perspective very much. I do read that searchers' eyes can be drawn towards the exact match (which are frequently bolded in the SERPs), possibly leading to a higher clickthrough rate.

[knome]

It's been a while since I was looking at how google's crawler worked. For items that had multiple ways of navigating there, I remember using the link rel="canonical" to let google know where the page would have been if not for the category information etc in the url.