首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >\b这样去设计 URL,可以提高网站的访问量

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

作者头像
Phodal
发布2018-01-29 13:25:51
8950
发布2018-01-29 13:25:51
举报
文章被收录于专栏:phodalphodal

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

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2017-03-12,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 phodal 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 受 RESTful API 影响 的 URL 设计
相关产品与服务
Serverless HTTP 服务
Serverless HTTP 服务基于腾讯云 API 网关 和 Web Cloud Function(以下简称“Web Function”)建站云函数(云函数的一种类型)的产品能力,可以支持各种类型的 HTTP 服务开发,实现了 Serverless 与 Web 服务最优雅的结合。用户可以快速构建 Web 原生框架,把本地的 Express、Koa、Nextjs、Nuxtjs 等框架项目快速迁移到云端,同时也支持 Wordpress、Discuz Q 等现有应用模版一键快速创建。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档