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 PHP/JS - Create thumbnails on the fly or st

Answer 1

The best way to handle slugs is to only store the speaking part of the slug in the database and keep the routing part with the unique identifier for dynamic generation. Otherwise (if you store the whole url or uri) in the database it might become a massive task to rewrite all the slugs in the database first if you changed your mind about how to call them.

Let's take this questions SO slug as example:

/questions/807195/should-i-create-a-slug-on-the-fly-or-store-in-db

it's:

/route/unique-ID/the-speaking-part-thats-not-so-important

The dynamic part is obviously:

/route/unique-ID/

And the one I would store in the database is the speaking part:

the-speaking-part-thats-not-so-important

This allows you to always change your mind about the route's name and do the proper redirects without to have to look inside the database first and you're not forced to do db changes. The unique Id is always your database data unique Id so you can identify it correctly and you of cause know what your routes are.

And don't forget to set the canonical tag. If you take a look inside this page code it's there:

<link rel="canonical" href="http://stackoverflow.com/questions/807195/should-i-create-a-slug-on-the-fly-or-store-in-db" />

This allows search engines to identify the correct page link and ignore others in case you have duplicate content.

Answer 2

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 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.

Answer 4

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.