The points are solid, and early planning where possible is great. MVP often contains uncertainty, so there are a couple of methods I've used to afford flexibility in the future (although it still helps to codify this better when the flux settles)<p>For applications with low expected item limits within taxonomies it can help to use a numeric id, combined with an open-ended rewrite of the user-readable content.<p><a href="http://www.example.org/items/12-really-awesome-thing" rel="nofollow">http://www.example.org/items/12-really-awesome-thing</a><p>RewriteRule ^/items/(\d+)[a-zA-Z0-9_\ -]+$ index.code?route=items&id=$1<p>Although you probably index your titles anyway, simple numeric key lookup makes the DB layer happy. Combine this with rel=canonical to your preferred url, and you can be more flexible with case, specific terms etc. It has the added bonus of reducing 404s through typo'd links and such.<p>A couple of other anecdotal points:<p>* Underscore is considered a letter, not a space, for most purposes<p>* Pages should either have a (faux) file extension, or no trailing slash. Reserve trailing slash for directories<p>* Rel Canonical also allows you to carry non-critical data in query string using [QSA] in the RewriteRule, without polluting the search index with duplicate content. Consider this for, example, default view of output (CD cover vs. title list)
- Short over long. Consider removing useless words from the url like <a href="http://www.example.com/tips-for-designing-good-urls" rel="nofollow">http://www.example.com/tips-for-designing-good-urls</a><p>- Concise To the point, describe the page content from the url<p>- Use lowercase. Generally the best idea, for sharing links and technical issues (Apache is case-sensitive sometimes)<p>- Consistenty. Stay consistent, make a style guide for URL's if necessary<p>- Trailing slashes. Stick with trailing slashes or no trailing slashes<p>- Be logical. Follow a logical structure, that follows the structure of the site. A good URL might read like a breadcrumb: site.com/category/product-name, this works for silo'ing your content. Other sites (such as news sites or without a category) might benefit more from the shortest url possible.<p>- Dashes for spaces. No underscores or %20 spaces.<p>- No special chars. Consider replacing é with e and removing any non-alphabet non-number character like: ' " (<p>- Canonical. There should be only 1 URL in Google's index with a page content. Use canonical or 301's or smart use of URL's to make sure this is the case.<p>- Degradable. What happens if a user visits site.com/category/product-name/ and then removes the /product-name/ part? The URL-structure should allow for this and site.com/category/ should return content (preferably the category description)<p>- Timeless. If you have an event and you set the date inside the URL, then after this date has passed, this URL gets less valuable. Either 301 these aged URL's to the current event URL, or make it so your URL's can be "re-used" for future events.<p>- Optimized. for search Use a keyword tool, to find out what users might be searching for and use the relevant keywords inside your URL. Keyword in URL is a ranking factor.<p>- No excessive use of dynamic variables. These will confuse your users and search engines.
I am an absolute advocate for rich urls - they improve user experience, especially now browsers such as Chrome are limiting the visibility of page titles. The SEO benefits are undisputed, and in general I'd always recommend.<p>There is still a case for Devil's Advocate here though. Consider one of the most popular internet properties, Youtube.<p>Youtube could switch on rich urls tomorrow, but they don't. In industry where pageviews are king and you have trusted branding (no shock redirects), then I believe Youtube's ugly hash urls might well benefit them.<p>More than a few times I've visited links which I otherwise wouldn't have if the title was embedded in the url. Occasionally I've been pleasantly surprised by the content and stayed to watch. Considering the hokey titles of some of the better content, I think their url structure might genuinely be a benefit. Also, without their structure there would be no oHg5SJYRHA0<p>A few other large properties use this (flickr...), and while I think for early growth you are basically throwing away potential traffic, for sites of a certain level, there could be gains by not having rich url structure - not least they can ignore a bunch of complex DB dupe indexing issues by throwing away titles.
Thinking about your URL design in the first stages of a project is only required when using a framework that inextricably links URL structure to functionality like django, RoR, symfony etc.<p>I'd prefer to use big hideous query strings until the project works, then use mod_rewrite to do whatever the hell I want with my URLs.