2

My application relies heavily on the hierarchy of its entities and the hierarchy also gives needed context to the entities details page. Hence my current URL scheme represents the hierarchy: /grandparent/parent/child

Since I'm working towards having everything be user created content, the nesting is bound to change from time to time. But I really hate dead links, so I think my options are:

  • append -[ID] to every URL and redirect the path if an already changed path is opened
  • same as above but without the path (URL would only change, when the name of the entity is changed
  • track all the path changes and redirect to new path if an old path is opened. This might get weird, when a new entity has a path that once existed. I would need to display a message saying, that the user possibly meant to visit a different resource that once was at that location

I like the third option insofar as the URLs stay clean and ID free, but I think the first option is the most solid one. Am I missing something?

unor
  • 21,739
  • 3
  • 46
  • 117
Gregor Weber
  • 121
  • 2
  • I am not sure how to begin to answer this except to say that the path is an extremely important clue for SEO. You may want to get some background from this answer: http://webmasters.stackexchange.com/questions/74633/well-structured-urls-vs-urls-optimized-for-seo/74639#74639 While I am not a fan of IDs, you will see that SE uses them so there is a place where using IDs makes sense. In that respect, IDs are okay. – closetnoc Dec 11 '15 at 14:24

1 Answers1

3

Ideally all URL changes would be tracked and you would implement redirects from any old URL to a new URL. Doing so is important so that inbound links to your site don't break and so that search engines continue to index and rank your content when it moves.

I love semantic URLs, but I'm not a fan of deep hierarchies in URLs. URLs should:

  • Uniquely identify the resource
  • Describe the resource adequetly
  • Be easy to type for best usability
  • Be easy to remember for best usability

Because of the last two, I would tend to drop parents from the URL when possible. I prefer /widgets over /household/kitchen/widgets. If you also have other widgets I might even do /kitchen-widgets or possibly /kitchen/widgets if you have a /kitchen/ page.

Having a hierarchy URL certainly complicates renames. Especially when it is a parent or grandparent that is renamed. If you do have those in the URL, an ID in the URL would make it a lot easier.

IDs are also good for user generated content because you don't have to force users to come up with unique names. Forcing users to do so can decrease the number of people willing to create content.

Stephen Ostermiller
  • 98,758
  • 18
  • 137
  • 361
  • I forgot to mention that the names of the entities are only unique on their level in the hierarchy. So if I don't got with a hierarchy, ID would be a must. I'd like shorter URLs too, but sadly the only thing that gives describes the resource adequately is it's name AND the hierarchy. – Gregor Weber Dec 11 '15 at 14:26
  • If you need them, you need them. Keeping track of moves and renames with them is certainly harder though. – Stephen Ostermiller Dec 11 '15 at 14:32