When a category is renamed, the previous URL should redirect to the new one

(Camille Roux) #1


When a category is renamed or moved in a new parent category, its URL is changed. Sadly, the previous URL returns a 500 error, which is bad for SEO.

(Sam Saffron) #2

This is another one of those reason I prefer to keep ids as canonical like we did at Stack Overflow.




cc @eviltrout @codinghorror

(Jeff Atwood) #3

Different issue, why would we return a 500? That means code error.

(Sam Saffron) #4

Why would we?

Because of this.

NoMethodError (undefined method `description' for nil:NilClass):
  app/controllers/list_controller.rb:255:in `set_category'
  lib/middleware/anonymous_cache.rb:119:in `call'
  config/initializers/quiet_logger.rb:10:in `call_with_quiet_assets'
  config/initializers/silence_logger.rb:24:in `call'
  lib/middleware/unicorn_oobgc.rb:95:in `process_client'

Still I don’t think a 404 would do any better for SEO. Rename a category 1 year in and you are hosed.

(Sam Saffron) #5

FYI, I fixed the 500 error (We now get a 404 “correctly” if you go to https://meta.discourse.org/category/unknown )

However I stand by my original objection:

It really should be:

https://meta.discourse.org/category/1/feature-requests so when people rename it to https://meta.discourse.org/category/1/features existing links don’t 404.

I also think it should be


(Jeff Atwood) #6

Possibly, or we could record the previous name and redirect to that. Shouldn’t the history of these renames be tracked, to some level, anyway?

We certainly track the history of posts, why not the history of a category?

(Sam Saffron) #7

That is introducing a mountain of complexity for little gain

What happens when multiple cats had the same name in the past

(Jeff Atwood) #8

You know very well we tracked username history on Stack Exchange for good reason. We had to, because later situations demanded it.

Same reason we track revision history on posts here, isn’t it?

Within reason (don’t allow renaming to previously used category names), it’s fine – you’re arguing for a perfect solution, I’m arguing for basic history, which is useful even outside handling the 404 redirect scenario. What if an angry moderator renames a category to “poo”?

(Sam Saffron) #9

I think we already track it, we could put something in place that works better than what we have now. However it is an imperfect solution with edge cases.

Putting a hard restriction on the system on all historic category names is crazytown. It basically means that mods can “burn” a category name forever. A horrible idea.

(Jeff Atwood) #10

Not crazy – you can “burn” a username on GitHub and on Twitter just by signing up and then deleting your account. Forever, even!

I think only protecting history for 1 level deep (the name, and the previous name) is probably fine.

Really not a fan of IDs in urls for categories, or usernames… I like it in topics though.

(Michael Downey) #11

According to the W3C, “cool URIs don’t change”. (Ever.)


(Christian Simplicity) #12

Was anything ever decided on this? I suppose the same issue exists for Topic titles.

I’m a few days into a new forum. We created a new topic and have some decent ranking external links now coming into that topic. The topic has a relatively long name and I’d like to shorten it some. However doing so would kill the few inbound links that are bringing traffic.

(Rodrigo Farcas) #13

Also when you change a category from “child” to “father” the old URL should redirect

(Benjamin Kampmann) #14

Considering we have a permalink-redirect-facility now, shouldn’t it be enough to create a permalink every time a category’s slug is changed? That shouldn’t be too hard I think …

(Salman, Freelance Developer) #15

@lightyear The link in your post is broken (the irony!)

(Jeff Atwood) #16

Er… no it’s not? What are you talking about?

Oh I see, viewing edit history, it was


Well that’s an odd way to enter an URL…

(Jeff Widman) #17

I certainly prefer this myself. Even if the ID is at the end of the url, it still makes life a lot simpler when mass editing urls or writing regexs for 301 redirects in Apache/Nginx.

For example, I did a forum software migration recently (to software other than Discourse–Discourse was the wrong fit for that site), and had to rewrite urls to users, categories, threads, and posts. If both the old and new forum software hadn’t included IDs it would have been a total nightmare. But since both used IDs, it was simple to use a regex on the post and PM contents to rewrite everything. And I’m not worried about those urls breaking if the username or category name changes.

So personally I vote for Discourse URLs to 1) include category/user_id, and 2) support url expansions based off the ID.

That way, my redirects don’t have to look up the user/category name, they just redirect to discourse.com/user/user_id and get redirected to the full url.

I like how this is already supported for threads, although I very much wish specific posts had unique IDs as well.

There’s a particular site that I’m planning to migrate to Discourse, and they don’t have id’s in the username, and it’s just going to make my Nginx rewrite rules brittle if the user ever wants to change their username (it happens from time to time for various valid reasons). If I’m going to go through the pain of migrating and rewriting all my internal urls, I’d rather the new url structure include ID’s wherever possible.

Does Discourse support unique post IDs?
(Jeff Atwood) #18

One critical thing we learned at Stack Overflow: if you allow users to easily change unique usernames, long term your life becomes a bag of pain. I can explain it in Prisoner’s Dilemma game theory terms if that helps?

Changing unique usernames should be strongly discouraged, and only possible during a limited window at signup.

So I for one am 100% comfortable with usernames as unique IDs for users in the URL since it represents what I believe to be, based on my experience, correct design.

(For topics and categories, renaming is a way of life. But people should not really be renaming themselves outside of freakish, rare life events.)

(Sam Saffron) #19

I think there is a pretty compelling case for changing:








People suck at category naming and often create very long category names for no reason and later revise it, there is no reason to 404 all those old google crawled links. 302 is a way friendlier way of dealing with it.

(Jeff Atwood) #20

This is already handled though, check it out:

If you rename a category, the old slug still stays as-is, unless you change it too.