我们一起聊聊优雅 URL 的设计哲学

网络 网络管理
您可能会认为这听起来像是很多愚蠢、迂腐的工作。毕竟,如果您的 CMS 已经在生成高颜值的 URL,为什么还要为此徒增压力呢?如果您的网站的 URL 不那么简洁,那有什么大不了的?

本文属于是语冰的直男翻译了属于是,仅供粉丝参考,英文原味版请临幸 Your Website’s URLs Can and Should Be Beautiful。

图片图片

制作优雅 URL 的关键是平衡简洁和清晰。

可以肯定的是,没有人会用“二阶思维”思考 URL。顶多看过就过,仅此而已。我们点过一个又一个的链接,却从不考虑瞄一眼浏览器的 URL 地址栏。我们只是假设 URL 是有效的,且会带我们去诗和远方。事实上,Chrome 和 Safari 等浏览器甚至已经完全隐藏 URL。这是一个错误,因为精心制作的 URL 有某些美丽且值得欣赏的东东。

虽然但是,在过去,URL 看起来像乱码的情况屡见不鲜:

  • domain.com/blog/archive.php?cat_id=25&page=4
  • domain.com/products/view/?product_id=65847135468
  • domain.com/forums/view_topic.phtml?topic_id=25874

这些“URL 丑八怪”的问题在于,它们是为 Web 服务器编写的,而不是为 Web 冲浪者编写的。无论您盯着这些 URL 看多久,您都找不到任何关于其动机或目的地的真正线索,比如哪个产品与 65847135468 的 ID 相关联。找出答案的唯一方法是单击链接并希望它是您要查找的内容,这可能会令人沮丧、头大且耗时。

值得庆幸的是,您现在更有可能看到这样的 URL:

  • domain.com/blog/category/music/page/4
  • domain.com/products/view/awesome-product-title
  • domain.com/forums/topic/best-blues-albums-of-2023

像这样的高颜值的 URL(这是 WordPress 等 CMS 中的默认设置)可以提供有用的、人性化的上下文,让您在去那里之前了解会发现什么。举个栗子,根据该论坛主题的“slug” —— best-blues-albums-of-2023 可以合理地假设,如果您去那里,您会发现某些不错的音乐推荐。

简而言之,高颜值的 URL 使您的网站更易于访问和用户友好,同时还提供某些 SEO 优势。但是,即使您的 CMS 配置为创建高颜值的 URL,您仍然可以使它们变得更好、更漂亮。

简洁 vs 清晰

设计高颜值 URL 的关键是平衡简洁和清晰。换而言之,一个好的 URL 很短,但不会短到掩盖它所指向的内容。换而言之,一个好的 URL 包含足够多相关资源的信息以使其有用,但信息不会过载,以至于它会拖延并变得猪头。(我只想说,这通常更像是艺术而不是科学。)

请瞄一眼 Derek Severs 的网站。与鲜明的设计相得益彰,它的 URL 几乎短得滑稽可笑:

  • sive.rs/u
  • sive.rs/pnt
  • sive.rs/shc

瞄一下第一个 URL,您可能永远不会猜到它是为了 Useful Not True 这本书而设计的(因此其 slug 是 /u)。Sivers 为这种短 URL 提供若干原因,从实用(它们易于记忆和分享)到美观(它们看起来更好)。虽然我尊重并赞同 Sivers 对效率和减少数字污染的渴望,但其网站的 URL 走得太远了;它们当然很简短,但除了本人之外,任何人都无法一目了然。(此外,随着其网站与时俱进,我想知道它是否仍能够记住其所有 URL。)

某些 URL 可能很短。在许多网站上看到这样的 URL 是非常标准的:

  • domain.com/about
  • domain.com/contact
  • domain.com/faq

您几乎本能地看到 /about 或 /faq,且一目了然,它们分别用于网站的“关于我们”和“常见问题”页面。它们不需要多余的解释或上下文。事实上,看到这些 URL 的加长版几乎可以秒懂是错误设计:

  • domain.com/about-us
  • domain.com/contact-us
  • domain.com/frequently-asked-questions

从技术上讲,这些加长版比精简版不那么模棱两可,但这是不必要的,而且它们现在看起来因为猪头而猪头 —— 尤其是如果它们还有其他子页面。在这两个 URL 中,哪个颜值更高呢?

  • domain.com/about/team
  • domain.com/about-us/our-team-members

我的个人心证是,优雅无须多言。

URL 的美化方式

那么,创建优雅的 URL 同时仍然牢记简洁和清晰的平衡的最佳方法是什么?以下是我刻骨铭心的若干提示,适用于我正在处理的任何网站,无论是 Opus 还是其他地方。

1. URL 分段(URL Segments)要吝啬

URL 中的每个 / 都表示一个分段,这有助于识别站点的结构。尽管许多站点在数据库而不是文件系统上运行,但 URL 分段意味着类似于服务器上的文件夹和文件的层次结构。为了保持 URL 简短,您自然希望将分段数量保持在最低限度。这样做会迫使您真正考虑如何构建构建网站。可能需要像这样需要大量分段的 URL:

  • domain.com/about/locations/usa/nebraska/lincoln/havelock
  • domain.com/clothing/movies/star-wars/shirts/short-sleeve
  • domain.com/catalog/toys/robots/transformers/autobots/dinobots

但是,我敢打赌,您可以找到某些方法来简化和缩短它们,使网站更易于浏览和理解。(注意:这涉及网站结构开发和内容组织,这可能是其自身的系列博客文章。)

当 URL 包含大量分段时,我经常发现生成的页面内容非常单薄且分散,很难证明其合理性。这种方法可能有某些 SEO 福利,但作为用户,遇到无聊的页面很头大,而如果将所有这些内容收集到一个页面中会更方便。

回到上面的 URL,该组织真的在 Lincoln 有这么多地点,以至于 Havelock 需要专属 URL 吗?内布拉斯加州有这么多地方,Lincoln 需要自己的页面吗?您能用某些简洁的东东来代替吗,比如 domain.com/locations/havelock。

2. Slug 不需要匹配标题

我之前在解释为什么 domain.com/about 比 domain.com/about-us 更优雅时简单提到这点。可以假设,即使页面的标题是“关于我们”,-us 也是多余的。在此基础上,请瞄一下下列博客文章的 URL:

  • domain.com/blog/this-is-my-very-first-blog-post
  • domain.com/blog/i-finally-saw-the-shawshank-redemption-and-heres-my-review
  • domain.com/blog/ive-been-reading-comic-books-recently-and-these-are-some-of-my-favorites

很有可能,这些 URL slugs 基本上是帖子标题,但经过了 URL 格式化(比如,转换为小写字母,去掉标点符号,用破折号替换空格)。如果您点击了第一个 URL,那么可以肯定的是,该帖子的标题将是“这是我的第一篇博客文章”。但仅仅因为这是标题,并不意味着它也需要成为 slug。您可以缩短和简化帖子的标题,同时仍能捕捉到其标题的含义:

  • domain.com/blog/very-first-blog-post
  • domain.com/blog/shawshank-redemption-review
  • domain.com/blog/some-recent-comic-book-faves

有人可能会争辩说,这些精简版的 URL 缺乏加长版 URL 的个性,情况可能就是如此。如果您认为既臭又长的 URL 是您网站品牌的内在特征,那么请您务必继续使用它们。如果 SEO 是一个问题,请确保您的 URL 仍然包含任何相关的关键字。

值得一提的是,我对我所有的 URL 都使用这种方法,尤其是那些用于我的评论的 URL。以我对 Slowdive 最新专辑的评论为例。页面标题是“Everything Is Alive by Slowdive (Review)”,但这是评论的 URL:

  • opuszine.us/reviews/everything-is-alive-slowdive-2023-dead-oceans

没有必要在 slug 中重复 review,因为它已经是一个 URL 分段。因此,我的评论 slug 遵循这个惯例:发行标题、艺术家姓名、发行年份和出版商/唱片公司/工作室。这会导致 URL 如下所示:

  • opuszine.us/reviews/winks-kisses-20th-anniversary-deluxe-edition-airiel-2023-feeltrip-records
  • opuszine.us/reviews/ergo-proxy-shuko-murase-2006-manglobe
  • opuszine.us/reviews/saviour-machine-1993-intense-records

虽然但是,也有若干注意事项。举个栗子,自行发行的专辑中不会有任何标签信息。如你所见,这种约定可能会导致冗长的 URL。但目标是确保用户确切地知道正在审查的内容,如果 slug 较短或与帖子的标题完全匹配,这可能是不可能事件。

3. 停止使用“停顿词”(偶尔)

“停顿词" —— 包括“a”、“an”、“in”、“is”、“the”和“was” —— 是不会真正为 URL 增加任何价值的单词,尤其从 SEO 的角度来考虑(尽管它们不是主要因素)。它们往往是冠词、介词、连词和代词。因此,通常可以删除它们以简化 URL,就像我在上面的若干示例中所做的那样。

但请记住,优雅的 URL 会告知用户并为它们提供有用的上下文。这意味着,有时删除停顿词可能会导致 URL 变得更糟,因为它们是荒谬的,甚至具有误导性。比较:

  • domain.com/blog/i-ate-my-family
  • domain.com/blog/my-kid-annoying
  • domain.com/blog/practicing-drums-hard

对应的仍然存在停顿词的版本:

  • domain.com/blog/i-ate-with-my-family
  • domain.com/blog/my-kid-is-not-annoying
  • domain.com/blog/practicing-drums-can-be-hard

这两组博客文章一龙一猪。

我经常会从 slug 中删除所有停顿词,看看它是什么样子的。如果它是荒谬的或误导性的,那么我会添加一两个停顿词。或者我可能会重写标题,这样它就不会包含那么多的停顿词,这通常会设计出一个更简洁的 slug —— 甚至可能是一个更好的标题。

4. 不要纠结那个优雅的 URL

一旦您确定了一个优雅的 URL 并发布了您的博客文章、产品或页面,那就别再管它了,即使那天晚上在梦中出现了一个好十倍的 URL。把时间留给其他事情。

它们被称为永久链接(permalinks)是有原因的;它们应该是永久性的。网络已经太短暂了,网站消失了,链接腐烂了。如果您绝对必须更改网站的某个 URL,请务必添加从旧 URL 到新 URL 的“301”重定向。(有几种不同类型的重定向,但“301”重定向表示它是永久重定向,它会提醒搜索引擎更新其索引。)

您可能会认为这听起来像是很多愚蠢、迂腐的工作。毕竟,如果您的 CMS 已经在生成高颜值的 URL,为什么还要为此徒增压力呢?如果您的网站的 URL 不那么简洁,那有什么大不了的?

从功能上讲,这可能无关紧要。但这些建议都是创建一个精心制作的、精心设计的网站的一部分,为您发布到网络上的内容感到自豪,并减少数字污染(用德里克·西弗斯的术语)。

优化图像、使用语义 HTML 和避免深色模式都表明您关心用户体验,制作精美简洁且上下文丰富的 URL 也是如此。用户可能永远不会(有意识地)注意到这些努力,但它们几乎肯定会注意到它们的缺席,即使它们不能完全阐明怎么做或为什么。

我承认,我对漂亮 URL 的偏爱源于这样一个事实,即我一直觉得 URL 非常神奇。您在浏览器的 URL 栏中输入 https://,然后是一串字母、数字、破折号、下划线、句点和斜杠,然后您就会被带到另一个潜在的新闻、信息和资源宝库。

URL 就像地图轨迹、路标和咒语一样,都合二为一。如果有可能在不牺牲任何效用或功能的情况下使它们更高效、更美观,那么我真的想不出有什么理由不花点时间这样做。

责任编辑:武晓燕 来源: 人猫神话
相关推荐

2022-01-04 12:08:46

设计接口

2024-10-29 11:19:23

点赞系统同步

2022-10-08 00:00:05

SQL机制结构

2023-08-04 08:20:56

DockerfileDocker工具

2023-08-10 08:28:46

网络编程通信

2022-05-24 08:21:16

数据安全API

2023-09-10 21:42:31

2023-06-30 08:18:51

敏捷开发模式

2024-10-15 08:08:13

2023-04-26 07:30:00

promptUI非结构化

2024-02-20 21:34:16

循环GolangGo

2021-08-27 07:06:10

IOJava抽象

2024-07-12 08:28:09

聊天系统架构

2022-12-06 08:12:11

Java关键字

2023-08-02 08:35:54

文件操作数据源

2024-09-09 08:53:56

2024-06-14 09:32:12

2022-09-08 08:50:17

SSDOracleCPU

2023-03-26 23:47:32

Go内存模型

2022-02-23 08:41:58

NATIPv4IPv6
点赞
收藏

51CTO技术栈公众号