关于 URL 的一些准则
首先是与 URL 有关的一些准则。
一个 URL 必须唯一地，永久地代表一个在线对象
URL 的最基本的使命是唯一地代表 Internet 上的一个对象，URL 必须和 Internet 上的对象一对一匹配。然而现实中，这很难实现，我们经常可以通过多个 URL 到达同一个页面，比如， http://mysite.com/product/tv 和 http://mysite.com/product?name=tv，这种情形在现代 CMS 中更是比比皆是，针对这个问题，SEO moz 有一篇很好的文章，讲到了如何使用 Canonical URL 机制解决站点中的重复 URL 问题。
URL 应该是永久的，这就要求你在站点上线前就非常严谨地规划 URL。如果有一天，你不得不更改 URL，一定使用 HTTP 301 机制，告诉浏览器和搜索引擎，你的那个 URL 所代表的对象，已经搬迁到新地址，这个机制可以保证你旧地址所获得 PR 不会被清零。
尽可能用户友好
这是 URL 设计的根本，你的 URL 应该为最终用户而设计。保持 URL 友好的一个好办法是在保证可读性的同时让它尽可能短。比如 /about 就好过 /about-acme-corp-page，当然，保持简短不能牺牲可读性， /13d2 一类的地址短则短矣，但并不友好。如果要在 Twitter， Facebook 一类的社会媒体网络分享你的 URL，可以使用 Bit.ly 一类的网址缩短工具，但这种工具产生的缩短 URL 并不友好，在 Wordpress 一类的 CMS 中，可以使用 PrettyLink Pro 或 Short URL plugin 一类的可控制的地址缩短插件。
URL 的设计切忌使用一些对用户来说没有意义的内容，比如数据库的 ID 号， /products/23 这样的 URL 地址对用户是极不友好的，应当使用 /products/ballpoint-pen 一类的地址。
保持一致性
站点内的所有 URL 必须保持一致的格式和结构，这样可以为用户带来信任感，如果你必须更改 URL 格式和结构，需要使用 HTTP 301 机制。
可预测的 URL
这也是 URL 一致性的一个表现，如果你的 URL 拥有很好的一致性，用户可以根据 URL 猜测别的内容的 URL，假如 /events/2010/01 指向 2010 年 1 月份的日程内容，那
- /events/2009/01 应当指向 2009 年 1 月的日程。
- /events/2010 应当指向 2010 年全年的日程。
- /events/2010/01/21 应当指向2010年1月21日的日程。
URL中的关键词
URL 中应该包含本页重点内容的关键词，比如 /posts/2010/07/02/trip-best-buy-memory-cards 一类的 URL 本身就是对页面内容的反应。在 URL 包含重点内容关键词，也可以提高 SEO 性能。SEO 的一个很重要的原则就是，在 URL 地址中包含内容关键词。
关于 URL 的技术细节
下面说的是有关 URL 的一些技术细节。
URL 不应包含 .html, aspx, cfm 一类的后缀
这类信息对最终用户是没有意义的，却占了额外的空间，一个例外是 .atom, .rss, .json 一类的特殊地址，这类地址是有特别的意义的。译者注：在某些虚拟主机式 Web 服务器，这种做法未必现实。
URL 不应包含 WWW 部分
WWW 部分并不包含任何意义，是一个额外的负担，不友好。可以使用 HTTP 301 机制，将 www.domain.com 定向到 domain.com 。
URL 的格式
URL 的格式如下:
domain.com/[key information]/[name]/?[modifiers]
Key information 部分一般代表信息的类型或类别。Modifiers 部分则属于查询字符串范畴，它不应当代表数据结构，应当代表数据的修饰。Key information 部分应当尽可能简短，同时应当表现出一种层级关系，比如 http://domain.com/posts/servers/nginx-ubuntu-10.04，或 http://domain.com/news/tech/2007/11/05/google-announces-android。
Google News 对新闻源有一个有趣的要求，Google 要求新闻源页面的 URL 中必须包含至少 3 位唯一的数字，因为他们会忽略年份数字，因此，应该使用一个5位或5位以上的数字。另外，也应该提供 Google News 站点地图 。如果你想向 Google 提供新闻，必须按这样的结构提供 URL，当然保持一致性，可以预测性也是必需的。
使用小写字符
URL 中所有字符都应使用小写，这更容易阅读。
URL 中包含的行为元素
URL 查询字符串中可能包含一些表示行为的元素，比如 show, delete, edit 等。非破坏性的行为可以体现在 URL 中，破坏性的行为应该使用 POST 。
使用 URL 友好字符
在 URL 中体现网页标题的时候，往往会用到一些特殊字符，应当把它们转换为 URL 友好字符：
- 全部大写字符换成小写
- 诸如 é 一类的字符应转换成对应的 e
- 空格使用短划线代替
- 诸如 !, @, #, $, %, ^, &, * 一类的字符应该使用短划线代替
- 双短划线应该使用单短划线代替
另外，没有必要的话，避免使用 %20 一类的 URL 逃逸符。
更多观点
Chris Shiflett 建议，可以使用一些类似句子的 URL，如：
chriscoyier.net/authored/digging-into-wordpress/
chriscoyier.net/has-worked-for/chatman-design/
chriscoyier.net/likes/trailer-park-boys
jacobwg.com/thinks/this-post/is/basically-done
译者补充：URL 的长度上限
URL 的最大长度是多少？W3C 的 HTTP 协议 并没有限定，然而，在实际应用中，经过试验，不同浏览器和 Web 服务器有不同的约定：
- IE 的 URL 长度上限是 2083 字节，其中纯路径部分不能超过 2048 字节。
- Firefox 浏览器的地址栏中超过 65536 字符后就不再显示。
- Safari 浏览器一致测试到 80000 字符还工作得好好的。
- Opera 浏览器测试到 190000 字符的时候，还正常工作。
Web 服务器：
- Apache Web 服务器在接收到大约 4000 字符长的 URL 时候产生 413 Entity Too Large" 错误。
- IIS 默认接收的最大 URL 是 16384 字符。
