2 replaced http://stackoverflow.com/ with https://stackoverflow.com/
source | link

I have used two different scenario's in the past.

  1. /id/some-slug where the id is used to lookup, the slug not. Thus the slug can be anything. But, when the slug does not match with the actual slug, the user is redirected to the current version.

  2. /permalink for cases where we didn't want an id in the url or where the url should never change, even though there is an id available (see [1][1] and [2][2]). Of course, in this case the permalink is used for the lookup. Both the current slug and the permalink (the first slug) are stored in the database.

In neither of these ways you need to keep a history of slugs in your database, which would get problematic very soon.


ps: In the second case you'll need some very specific routing to keep social credits:

  • if you want, redirect users to the current (non permalink) url
  • have the permalink used as the url in the social buttons
  • always redirect the facebook crawler to the permalink

See [1][1] and [2][2] again.

I have used two different scenario's in the past.

  1. /id/some-slug where the id is used to lookup, the slug not. Thus the slug can be anything. But, when the slug does not match with the actual slug, the user is redirected to the current version.

  2. /permalink for cases where we didn't want an id in the url or where the url should never change, even though there is an id available (see [1] and [2]). Of course, in this case the permalink is used for the lookup. Both the current slug and the permalink (the first slug) are stored in the database.

In neither of these ways you need to keep a history of slugs in your database, which would get problematic very soon.


ps: In the second case you'll need some very specific routing to keep social credits:

  • if you want, redirect users to the current (non permalink) url
  • have the permalink used as the url in the social buttons
  • always redirect the facebook crawler to the permalink

See [1] and [2] again.

I have used two different scenario's in the past.

  1. /id/some-slug where the id is used to lookup, the slug not. Thus the slug can be anything. But, when the slug does not match with the actual slug, the user is redirected to the current version.

  2. /permalink for cases where we didn't want an id in the url or where the url should never change, even though there is an id available (see [1] and [2]). Of course, in this case the permalink is used for the lookup. Both the current slug and the permalink (the first slug) are stored in the database.

In neither of these ways you need to keep a history of slugs in your database, which would get problematic very soon.


ps: In the second case you'll need some very specific routing to keep social credits:

  • if you want, redirect users to the current (non permalink) url
  • have the permalink used as the url in the social buttons
  • always redirect the facebook crawler to the permalink

See [1] and [2] again.

1
source | link

I have used two different scenario's in the past.

  1. /id/some-slug where the id is used to lookup, the slug not. Thus the slug can be anything. But, when the slug does not match with the actual slug, the user is redirected to the current version.

  2. /permalink for cases where we didn't want an id in the url or where the url should never change, even though there is an id available (see [1] and [2]). Of course, in this case the permalink is used for the lookup. Both the current slug and the permalink (the first slug) are stored in the database.

In neither of these ways you need to keep a history of slugs in your database, which would get problematic very soon.


ps: In the second case you'll need some very specific routing to keep social credits:

  • if you want, redirect users to the current (non permalink) url
  • have the permalink used as the url in the social buttons
  • always redirect the facebook crawler to the permalink

See [1] and [2] again.