Should I create a slug on the fly or store in DB?

Question

A slug is part of a URL that describes or titles a page and is usually keyword rich for that page improving SEO. e.g. In this URL http://stackoverflow.com/questions/103707/php-js-create-thumbnails-on-the-fly-or-store-as-files that last section "php-js-create-thumbnails-on-the-fly-or-store-as-files" is the slug.

Currently I am storing the slug for each page with the page's record in the DB. The slug is generated from the Title field when the page is generated and stored with the page. However, I'm considering generating the slug on the fly in case I want to change it. I'm trying to work out which is better and what others have done.

So far I've come up with these pro points for each one:

Store slug: - "Faster" processor doesn't need to generate it each time (is generated once)

Generate-on-the fly: - Flexible (can adjust slug algorithm and don't need to regen for whole table). - Uses less space in DB - Less data transferred from DB to App

What else have I missed and how do/would you do it?

EDIT:

I'd just like to clarify what looks like a misunderstanding in the answers. The slug has no effect on landing on the correct page. To understand this just chop off or mangle any part of the slug on this site. e.g.:

http://stackoverflow.com/questions/103707/php-js-create-thumbnails-on-the-fly-or-store-as-files

http://stackoverflow.com/questions/103707/php-js-create-thumbnails-on-the-fly-

http://stackoverflow.com/questions/103707/php-js-create-thumbnails

will all take you to the same page. The slug is never indexed.

You wouldn't need to save the old slugs. If you landed on a page which had an "old slug" then you can detected that and just do a 301 redirect to the correctly "slugged" one. In the examples above, if Stack Overflow implemented it, then when you landed on any of the links with truncated slugs above, it would compare the slug in the url to the one generated by the current slug algorithm and if different it would do a 301 redirect to the same page but with the new slug.

Remember that all internally generated links would immediately be using the new algorithm and only links from outside pointing in would be using the old slug.

Answer 1

Wouldn't changing the slugs for existing pages be a really bad idea? It would break all your inlinks for a start.

Edit, following Guy's clarification in the question: You still need to take old slugs into account. For instance: if you change your slug algorithm Google could start to see multiple versions of each page, and you could suffer a duplicate content penalty, or at best end up sharing PR and SERPs between multiple versions of the same page. To avoid that, you'd need a canonical version of the page that any non-canonical slugs redirected to - and hence you'd need the canonical slug in the database anyway.

Answer 2

For slug generation I don't think that generation time should be an issue, unless your slug algorithm is insanely complicated! Similarly, storage space won't be an issue.

I would store the slug in the database for the simple reason that slugs usually form part of a permalink and once a permalink is out in the wild it should be considered immutable. Having the ability to change a slug for published data seems like a bad idea.

Answer 3

You might need to take another thing into consideration, what if you want the user/yourself to be able to define their own slugs. Maybe the algorithm isn't always sufficient.

If so you more or less need to store it in the database anyhow.

If not I don't think it matters much, you could generate them on the fly, but if you are unsure whether you want to change them or not let them be in the database. In my eyes there is no real performance issue with either method (unless the on-the-fly generation is very slow or something like that).

Choose the one which is the most flexible.