今天,很多网站的 URL 的设计都是“有问题”的。它们看起来一塌糊涂,仿佛是被人洗掉的脏数据一样,没有经过设计,没有经过思考。他们一点都不适合阅读,也不利于搜索引擎优化。
刚开始写博客的时候,我从来不会想着去自定义一个 URL。想好一个标题,没有敲好内容就直接提交了,可这个时候生成的 URL 总是很诡异。当我们去设计一个博客的时候,URL 是一个头疼的问题。设计之下,每个人选择的方案都有所不同:
直接使用博客的 ID,如 /blog/123,即省事又方便
自动生成 URL
将标题转换为拼音或者英语单词,如 blog/ruhe-sheji-yige-gaozhilang-de-url
根据日期和 ID 生成,诸如 blog/2017/02/123
等等
自定义 URL,诸如 blog/how-to-design-a-high-quality-url。如果要考虑到一些推荐的 URL 设计原因,如介词,这个 URL 应该变成 howto-design-hight-quality-url。
也因此,我们会发现大部分的架构设计里,都忽略了对 URL 的设计——只是为了更加方便的使用 RESTful。
受 RESTful API 影响 的 URL 设计
依据 RESTful API 原则,我们设计出来的 API 的 URL 都会有这样的缺陷。如下是 RESTful API 设计的一个简单的实例:
可是对于一个博客来说,每个博客的链接都是唯一的。因此,我们仍然可以使用``where slug="how-to-design-a-high-quality-url"。最后,我们设计出来的文章地址,可能就是 blog/123,又或者是 blog/58c286d7ac502e0062d7c84e。
因为,我们是依据这个 ID 到数据库去操作(CRUD)相应的值。ID 本身是自增的,并且是唯一的,所以这种设计因此就比较简单了。因此,我们到数据去查询的时候,我们只需要 where id="123"
即可。
于是,自定义 URL 就是其中的一种形式。
手动自定义 URL
与 URL 相比,ID 本身是不如记的。如我的专栏《我的职业是前端工程师》 的豆瓣上的链接是:https://read.douban.com/column/5945187/ ,而在知乎上则是 https://zhuanlan.zhihu.com/beafe。试问一下,如果要记下来的话,哪个更轻松?
以我的博客为例,正常的 URL 是这样的,https://www.phodal.com/blog/use-jenkinsfile-blue-ocean-visualization-pipeline/,对应的标题是:Jenkins 2.0 里使用 Jenkinsfile 设计更好的 Pipeline,这种设计本身可以将关键词融入 URL ,就更容易换得一个好的排名:
这里的 use-jenkinsfile-blue-ocean-visualization-pipeline 就是优化的部分。而为了设计方便,大部分的博客都会将 URL 设计成 /blog/123。结果便是,当用户搜索 jenkinsfile 和 pipline 时,就出现了一些劣势。
对应的,使用汉字搜索为主的中文网站来说,使用 wo-de-zhiye-shi-qianduan-gongchenshi 可能是一种更不错的选择。我们只需要使用一些分词库,就可以生成对应的中文拼音 URL。
当我们有大量的商品的时候,手动定义可能会让人有些厌烦。于是我们应该定义一些规则,然后生成相对应的 URL。
详情页 :简单的 URL 生成规则
考虑到手动生成的难度,以及一些 RESTful 设计的风格问题,我们可以考虑结合他们的形式,诸如:
动作 | URL | 行为 |
---|---|---|
GET | /blog/:id/:blog-slug | 获取某一个具体的文章 |
是的,只需要改进一下 URL 生成的规则就可以了。StackOverflow 采用的就是这种设计,当我们从 Google 访问一个 URL 的时候,我们访问的地址便是:questions/:question-id/:question-slug 这种形式,其中的 id 和 slug 都是自动生成的,如:
questions/20381976/rest-api-design-getting-a-resource-through-rest-with-different-parameters-but
而当我们使用 question/:question-id 的形式访问时,诸如 questions/20381976,就会被永久重定向到上面的带 slug 的地址。
与手动相比,使用这种方式,即可以保证 URL 的质量,又可以减轻后台的负担——我们不根据 URL 来获取数据,我们仍然使用 ID 来获取数据,仍然可以对数据进行缓存。
而 RESTful 原则主要解决的问题是:对于资源的分类。,我们就需要一些更高级的 URL 设计。
自动化 URL:分类与多级目录
假使我们的网站上拥有大量的商品时,那么我们采用 RESTful 来描述资源时,这个时候路径可能就会变成这样:
/markets/3c/sj/meizu/meizu-mx5
如果不考虑搜索引擎优化,这个 URL 本身是没有什么毛病的,除了:分类有点多。
分类多对于 SEO 来说,主要问题就是,Page Rank 会被分配到不同的分类上,而导致当前页面的 Page Rank 比较低。因而,对于不同的网站来说可能有不同的策略需求。有的网站可能需要主目录的 Rank 比较高,有的网站则需要详情页的 Rank 值比较高,因此也没有一个好的定论:
如果希望详情页的 Rank 比较高,那么应该减少分类
如果需要分类的 Rank 比较高,那么这样设计就是合理的
搜索结果页:将参数融入 URL
在上面的例子中,因为博客都是唯一的,所以要配置一个唯一的参数都是比较简单的。当我们需要搜索结果时,情况就变得有些复杂——我们需要搜索和过滤。
对于一个使用 RESTful API 表示的搜索结果页,我们会这样去配置它的 URL:
http://www.xxx.com/search/?q={keyword}&page={page}&size={size}
然后,再我们的 Link Header 里指定下一页的结果就可以了。这样的 API 设计看上去,非常适合我们的场景。用户在筛选条件里选好想要的条件,再填入关键词就可以了。
现在让我们来假设一种用户场景,我们想搜索一个 100~150 元左右的 移动电源,并且它还是深圳产的。这个时候,网页返回的 URL 可能就是:
search/?minPrice=100&maxPrice=150&product=powerbank&location=shenzhen&page=1
这个时候索引的结果,可就失去了分类的意义了。于是,我们需要一个更好的 URL,诸如:
product/powerbank/?minPrice=100&maxPrice=150&location=shenzhen&location=shenzhen
那么,对于 URL 索引的 Rank 将会加给 powerbank,点击量 + 页面数量可以让它有一个好的排名:
当然诸如淘宝、京东这样的网站就不需要这么做了,他们对于 SEO 的需求没有这么强烈——因为要在百度上排个好名,可不止 SEO 的事了。
而如果我们愿意的话,还可以将参数融入到 URL 中,powerbank/range-100-150-city-shenzhen/page-1。这样,不止移动电源上有一个好的排名,100~150 元的移动电源也可以有一个好的排名。这时候,我们需要使用正则来匹配这些规则,一个简单的示例 (\S+)-range-(\d+)-(\d+)-city-(\S+)
,匹配结果如下:
但是,不管怎样这些参数带来的影响,都是相当微弱的。正在要做好的是网站本身,以及相关的站点结构设计、网站内容。
你说呢?
节选自《我的职业是前端工程师【八】》 优化技巧 :如何设计一个高质量的URL及页面标题