\b这样去设计 URL,可以提高网站的访问量

今天,很多网站的 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及页面标题

原文发布于微信公众号 - phodal(phodal-weixin)

原文发表时间:2017-03-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏程序员宝库

Golang 大杀器之性能剖析 PProf

想要进行性能优化,首先瞩目在 Go 自身提供的工具链来作为分析依据,本文将带你学习、使用 Go 后花园,涉及如下:

32030
来自专栏电光石火

idea 创建的maven+spring+mybatis项目整合 报错无法创建bean

最近在做一个由maven构建的spring+spring mvc+mybatis项目,刚开始的时候是用自己的电脑Win10环境下的eclipse写的,托管到了码...

20180
来自专栏企鹅号快讯

Java知识点归纳-J2EE and Web 部分

J2EE(Java2 Enterprise Edition) 刚出现时一般会用于开发企业内部的应用系统,特别是web应用,所以渐渐,有些人就会把J2EE和web...

20590
来自专栏Java后端技术

几款效率神器助你走上人生巅峰

  在我的工作和生活中,我一直都很注重效率工具的使用,这么些年下来也积累好几款很不错,但是又不为大多数人所熟知的软件工具,我用起来得心应手,很不错。那我就像在此...

11430
来自专栏北京马哥教育

8种主流NoSQL数据库对比

摘要:虽然SQL数据库是非常有用的工具,但经历了15年的一支独秀之后垄断即将被打破。这只是时间问题:被迫使用关系数据库,但最终发现不能适应需求的情况不胜枚举。 ...

2.3K40
来自专栏一名叫大蕉的程序员

企业神奇中间件-RPC No.96

13120
来自专栏技术专栏

慕课网高并发实战(一)-并发与高并发基本概念

11410
来自专栏FreeBuf

国产WEB扫描器北极熊有哪些使用技巧?

【北极熊扫描器】到目前为止已经度过了3个年头,作者一直在学习中,坚持更新软件,改进程序,修正BUG,那么接下来我将给大家介绍一下,【北极熊扫描器】这款软件怎么玩...

23360
来自专栏FreeBuf

PayPal曝远程代码执行漏洞(含视频)

日前知名在线支付公司PayPal被曝存在严重的远程代码执行漏洞,攻击者可以利用该漏洞在PayPal的web应用服务器上执行恶意命令,最终获得服务器控制权限。 漏...

280100
来自专栏不止思考

数据库的这些性能优化,你做了吗?

我们可能会采取各种方式去优化,比如之前文章提到的缓存方案,SQL优化等等,除了这些方式以外,这里再分享几个针对数据库优化的常规手段:「数据读写分离」与「数据库S...

12120

扫码关注云+社区

领取腾讯云代金券