Some questions about slugs in ASP.NET MVC content system

Question

In my application I'm currently using forms which allow to enter Title and Slug fields. Now I've been struggling with the slugs thing for a while because I can never decide once and for all how to handle them.

1) Make Title and Slug indenpendent

Should I allow users to enter both Title and Slug separetely? This is what I had first. I also had an option that if user did not enter the Slug it was derived from the Title. If both were enter, the Slug field took precedence.

2) Derive Slug from Title, when content is inserted that's it for the Slug, no more changes

Then, I switched to only Title field and derive Slug from title. While doing it I found out that now I have to change all the forms that allowed user to enter a slug. This way of doing it also prevents users to change Slugs - they can change the Title but it has no effect on the Slug. You can think of it like Slug is uniqued ID.

3) Now I'm thinking again of allowing users to change slug

Though I don't think it is all that useful. How many times does the content that someone already added, spent time on writing it, even require a change of either Title or slug? I don't think it is that many times.

The biggest problem with the 3rd option is that If I use Slugs as IDs, I need to update the reference all over the place when Slug changes. Or maintain a table that would contain somekind of Slug history.

What are you thoughts on these, I hope, valid questions?

If someone has a sample DB design for this, it would be appreciated if you share it here.

Answer 1

Personally I would suggest letting the user edit the title and the other contents of the record for the page. Once they have done this you can derive the slug from the title (or anything else you feel like). If they change the title then the slug can change but you could keep a record of the old slugs associated with the same page. If someone comes to the site with an old slug then you can send them 301 response and redirect them to the new page. This would be via an interception page handled by your routing.

Another question would be if they are changing the title, surely it's a new page with new content and with a new slug?

Thoughts?

Answer 2

How about only allowing the user to edit the title or slug while the page is in draft. When the page is published the title and slug become permanent.

Or as @WestDiscGolf said, keep a record of all old slugs and send a redirect.

Answer 3

I've just been going through all of this with a client, sorting out the rules around the URLs, etc.

Your slug should be at the very least slightly independent of the title, if only to ensure that you can take out standard "stop words" - most SEO's would recommend that the page path be as keyword rich as possible so a page title of:

Darling: we will cut deeper and tougher than Thatcher

Could become a slug of:

alistair-darling-cut-deeper-margaret-thatcher

But if possible, you should automate it as much as possible when the author is creating the post, so as they tab/move out of the Title field you populate the Slug/Name/Path field with a string that has removed all symbols, (ideally) removed an agreed list of stop words and replaced spaces with hyphens, so the automated slug from that title could be:

darling-will-cut-deeper-tougher-than-thatcher

But you need to give the author the ability to tweak beyond that.

We've also specified that this automation will only happen when the author creates the post, so subsequent edits would not automatically change the slug, to ensure that we don't suffer from external link rot (the CMS we're using manages all the internal links).

The only time the author should really be changing the slug would be if they'd published a typo, or something libellous.