URL 设计常识

网站设计中经常容易被大家忽视的一个因素就是URL的设计。
虽然现在的内容管理系统都允许各种不同程度的URL自定义，但默认的URL地址往往并不是就适合你的网站，在网站设计的最后一步通常要考虑对默认的URL进行替换。简洁的URL是网站非常重要的一个组成部分。

URL（资源定位符）用来指定方向，URL指向的东西可以和URL名称上毫无关系，但是可以通过URL访问到。
URI（资源标识符）用来指定资源，网络上每一个文件都有URI，通过URI可以找的到，为了资源区别实现的

但是同一个的URL在不同的时间段，可能指向的是不同的东西，是为了方便用户使用

原则

• URL的唯一性和永久性

URL背后最基本的理念就是一个URL代表互联网上的一个数据对象。
保证URL的唯一性是非常重要的，这样才能保证一个URL与一个数据对象匹配。
虽然这是我们的目标，但是有时候却也不是那么容易实现的，很多站长由于考虑不周全就会出现“重复”问题。
像谷歌这样的大型搜索引擎比较关注“重复问题”，因此强烈建议使用 canonical URL来轻松解决这个问题。
使用 Canonical URL标签可以减少重复内容被搜索引擎发现，因而可以提升网站在搜索结果中的表现。

• URL还必需具有永久性。

  这主要是说在网站发布之前计划URL的时就必需选一个比较好的URL设计。否则可能以后就可能会需要修改URL结构来改进。
  如果真的有必要这么做时，请确保在服务器上设置了 HTTP 301永久迁移重定向。这样服务器才会告知浏览器和搜索引擎内容的新位置，同时才能保住旧的URL地址所积累的访问。

• 尽可能对用户友好

这点是URL设计时需要考虑的最根本因素。
URL设计时首先必需考虑最终用户。
搜索引擎优化（SEO ）和是否易于开发应该放在第二位。

而保持URL对用户友好的一种方式就是要使其言简意赅。
这意味着说要使用尽可能少的字符同时又能保证可用性。

也就是说 /about 就比 /about-acme-corp-page来得好。
但是在争取简洁的同时，不能牺牲用户的友好性， 像 /13d2 这样的URL地址对终端用户来说一点意义都没有。

相反的，在一些分享URL的场合下，却鼓励大家使用短链接。这对微薄还有其他共享的社交网站来说比较方便。
关于URL短网址服务，可以使用Bit.ly，也可以使用PrettyLink Pro (WordPress插件)或Short URL插件。

• 对内容或用户来说不重要的信息就不必在URL中出现。
  

  比较常见的反面例子就是使用数据库ID作为URL的一部分，如 /products/23。
  最终用户并不会关心该产品在数据库中的记录号是多少， 因此，/products/ballpoint-pen这样的URL相对而言对用户更加友好。

测试URL是否对用户友好的一种方法就是看它是否 “语音友好” ，也就是说你对一个朋友念一个地址的话，你的朋友能否听懂你在说什么。

• 一致性

一个站点的所有URL必需在格式上保持一致。
一旦选定一种URL结构之后，那么就一直遵照这种格式保持下去。
整个网站中只有部分URL结构比较良好的话，说明网站整体而言，URL结构还是糟糕的。
为了让用户能够明白你的URL地址是以某种格式运行的，那么整个网站的URL格式就必需要统一。

如果你一定要改变结构（可能更新一个之前URL设计欠佳的网站），那么记得使用前面讲到的301重定向。

• 易处理性

与一致性相关，URL结构应清晰明了易更改。

例

如果
/events/2010/01显示的是2010年1月份的事件
那么
/events/2009/01 应该显示2009年1月份的事件
/events/2010 应该显示2010年整年的事件
/events/2010/01/21应该显示2010年1月21日的事件

• 关键词

URL应该由该页面内容的重要关键词组成。
因此，如果一篇博客文章的标题非常长，那么只有那些对内容来说非常重要的关键词才应该出现在URL中。
例如，如果博客文章的标题是 “My Trip to Best Buy for Memory Cards,”
那么URL中那些不重要的虚词就没必要写进去了，
/posts/2010/07/02/trip-best-buy-memory-cards就足够了。
在URL中使用重要的关键词的一个好处就是可以提高SEO效果。

• 技术细节

不要显示使用的技术语言

URL地址里不应该出现.html, .htm, .aspx或其他任何相关的语言标识。最终用户不会关心你的网站是用ASP.NET (.aspx), ColdFusion (.cfm), 还是使用服务器端嵌入(.shtml) 制作的，至少大部分用户都不会关心这一点。增加这些信息只会增加书写错误的可能性。

不过，唯一例外的就是请求返回特定格式时，URL上需加上.atom, .rss, 或 .json之类的后缀。

• 不要加“WWW”

网站URL应该丢弃www，因为它不是必需的，与尽可能对用户友好以及不加入不必要的信息这两条原则都是相悖的。

不过，由于现在仍然有很多用户会输入www. 前缀，
因此， www.localhost.com 应该用301重定向到 localhost.com。
同样地，子域名也需要执行301重定向，将 www.subdomain.localhost.com重定向到 subdomain.localhost.com.。

• 格式

URI应该以下面的格式出现:

domain.com/[关键信息]/[名称]/?[修饰符]

关键信息是指非对象识别的信息(如博文标题)，但对对象访问来说仍然非常关键，它可能包括：

对象的类型(如，博文)
大的父类别 (如，科技)
关键数据 (如，发布日期)

修饰符是修饰浏览情况而非数据数据模型，因此它们是查询字符串的组成部分并不是URL本身。

关键信息应该保持在最低的限度，URL不应该过分嵌套。

在关键信息部分的任何一个字词都必需对寻找该页面具有非常关键的作用。

• URL应该呈现一个降级的次序

例如：

域名 http://domain.com
类型 /posts
分类 /servers
标题 /nginx-ubuntu-10.04

例: http://domain.com/posts/servers/nginx-ubuntu-10.04

碰到日期相关的条目，也应该遵守降级的格式：

年
月
日

例: http://domain.com/news/tech/2007/11/05/google-announces-android

补:

如果你希望网站内容能够被收录到谷歌新闻里，URL需符合这些需求 。
你的URL至少要包含一个三位以上的唯一数字,两位（或以下）的数字就无法被抓取，而且它们会无视看起来像年份的数字，因此最好选择五位数。

例：http://www.google.com/news/article23.html

• 全部小写

所有字符都必需小写，URL中大小写混杂是非常不可取的。
如果用户输入的URL是大小写混杂的情况下，应该用301重定向到小写的页面。
实施起来就是将所有的请求都重定向到某个文件，这个文件脚步将301重定向到小写状态。

• URL识别符必需对URL友好

URL可能包含了文章的标题，而标题可能包含了对URL不友好的字符。因此文章的标题应该尽量对URL友好

例如：

所有的大写字母改成小写字母
字符 é应该转换成e (等)
空格用连字符代替(-)
不常见的字符(!, @, #, $, %, ^, &, *, etc.) 应该用连字符代替
双连字符应该用一个连字符来代替

需要注意的是 W3C 建议使用 URI 取代 URL 一说 。

关于 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 的格式如下:

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

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 的长度上限

W3C 的 HTTP 协议 没有限定 URL 长度上限，
然而，在不同浏览器和 Web 服务器有不同的约定：

IE 的 URL 长度上限是 2083 字节，其中纯路径部分不能超过 2048 字节。
Firefox 浏览器的地址栏中超过 65536 字符后就不再显示。
Safari 浏览器一致测试到 80000 字符还工作得好好的。
Opera 浏览器测试到 190000 字符的时候，还正常工作。

Web 服务器：

Apache Web 服务器在接收到大约 4000 字符长的 URL 时候产生 413 Entity Too Large” 错误
IIS 默认接收的最大 URL 是 16384 字符

URL中不能包含中文或“.”等非英文字符的解决方法

.Net工程命名规则形如“company.project.web”的格式。

而最近当我安装微软URLScan防注入工具后，竟然导致IIS中所有网站都无法访问。

起初怀疑IIS坏了，卸载IIS重装后问题依旧，后来建了个测试站点，发现凡是URL中包含“.”或非英文的路径均拒绝访问，会跳转至404错误。

Google搜索问题发现是URLScan导致的，找到了原因就可对症下药。
打开“C:\WINDOWS\system32\inetsrv\urlscan”，找到UrlScan.ini文件

修改其中两个配置节

AllowHighBitCharacters=1
AllowDotInPath=1

重启IIS生效，问题解决。