URL slug 的 SEO 最佳实践：为什么首选 kebab-case
最好的 URL slug 是用连字符连接的几个小写单词：kebab-case-slugs，而不是 Kebab_Case_Slugs。Google 自己的文档推荐用连字符而不是下划线；而且 Google 把 URL 路径视为区分大小写，所以始终使用小写，能避免意外产生重复页面。人们谈论 URL slug 的其他大部分说法（理想长度、停用词、关键词位置）都属于经验判断，而不是硬性规则，本文会把二者区分开来。
连字符与下划线：Google 到底怎么说
这里不必听信 SEO 圈的坊间传言，因为 Google 在 URL 结构最佳实践中直接给出了说法：
We recommend using hyphens (-) instead of underscores (_) to separate words in your URLs, as it helps users and search engines better identify concepts in the URL.（译文：我们建议在 URL 中用连字符 (-) 而不是下划线 (_) 来分隔单词，因为这有助于用户和搜索引擎更好地识别 URL 中的概念。）
其中的道理不难理解。下划线本来就用来把单词连在一起：程序员把函数命名为 format_date，正是希望它被当作一个整体来读。相反，连字符读起来像是分开的单词之间的间隔。该页面用下面这样的例子说明这一点：
| URL 路径 | Google 的结论 |
|---|---|
/summer-clothing/filter?color-profile=dark-grey | 推荐（连字符） |
/summer_clothing/filter?color_profile=dark_grey | 不推荐（下划线） |
/greendress | 不推荐（单词连在一起） |
请注意 Google 没有说什么。它从没说过带下划线的 URL 无法获得排名，或者会被忽略。你会看到一些博客文章信誓旦旦地这么断言，请把它们当作传闻。文档里写明的立场是一条建议，并且附有合理的理由。
slug 里的关键词有多重要？
没有很多人以为的那么重要。Google 的 SEO 入门指南（SEO Starter Guide）把域名或 URL 路径中的关键词列在不必重点关注的事项里，并说从排名角度看，它们除了出现在面包屑导航中，几乎没有别的作用。不过同一份指南确实鼓励使用有描述性的 URL，因为 URL 的一部分会以面包屑的形式出现在搜索结果里，人们也会借此判断某个结果看起来有没有用。
所以，认真写好 URL slug，真正的理由是为了人。像 /blog/seo-url-slugs-kebab-case 这样的 slug，能让人在点击之前就知道会看到什么，粘贴到聊天里也不会走样，念出来也很容易。而 /p?id=8812 这样的 slug 一样都做不到。
这也回答了一个常见的担心：要不要把所有旧的 my_post URL 都改成 my-post？我们不建议这样做，除非你本来就在重构网站。改 URL 意味着要设置重定向，还要等搜索引擎跟上，而文档里提到的好处很小。新内容一律用连字符，已经能正常访问的 URL 就别动。如果你确实决定迁移，我们这篇讲永久链接、URL 结构与安全重定向的指南里有具体做法。
为什么 URL slug 应该用小写
URL 的主机部分（Example.com）不区分大小写，但它后面的所有内容都可能区分。Google 的文档明确说明它处理 URL 时区分大小写，并举了例子：/APPLE 和 /apple 会被视为两个不同的 URL，各有各的内容。
接下来会发生什么，取决于你的服务器。在许多配置下，/Blog/My-Post 会直接返回 404，因为没有哪个文件或路由叫这个确切的名字。在另一些配置下，不论怎样大写，返回的都是同一个页面，这就悄悄制造了重复页面。对第二种情况，Google 的建议是把所有文本统一成同一种大小写，这样更容易看出这些 URL 指向的是同一个页面。
小写是显而易见的选择。大多数人输入 URL 时都用小写，也没有人记得住到底是 Pricing 还是 pricing。如果你的服务器已经会响应大小写混用的请求，请为所有含大写字母的路径添加一个永久重定向，指向对应的小写路径。（域名和邮箱地址遵循的是另一套规则，我们在域名和邮箱中的大小写里有说明。）
把标题变成干净的 slug
典型的 slug 生成器遵循下面这个流程，你手动操作时也可以照着做：
- 全部转为小写。
- 删除撇号，而不是替换它，这样 don't 会变成
dont，而不是don-t。 - 把每一段连续的空格和标点替换成一个连字符。
- 去掉开头和结尾的连字符。
- 决定怎么处理带重音的字母和非拉丁字母。
- 读一遍结果，像人一样再编辑一下。
第六步才是真正考验功夫的地方。下面是用我们转换器里的“Slug 化”选项得到的几个真实转换结果：
| 标题 | 自动生成的 slug | 编辑之后 |
|---|---|---|
| SEO Best Practices for URL Slugs: Why kebab-case Wins | seo-best-practices-for-url-slugs-why-kebab-case-wins | seo-url-slugs-kebab-case |
| Don't Panic: 10 Tips for Café Owners! | dont-panic-10-tips-for-cafe-owners | cafe-owner-tips |
| C++ vs C# | c-vs-c | cpp-vs-csharp |
第一行就是本文的真实 slug。我们删掉了“best practices”“why”和“wins”，因为它们只增加长度，不增加含义。第三行说明了为什么不能跳过编辑这一步：+ 和 # 这样的符号承载了那个标题的全部含义，而机械生成的 slug 会把它们丢掉。
停用词：去掉废话，保留含义
去掉“a”“the”“of”这样的小词，是缩短过长 slug 的合理办法，但这不是规则。凡是会改变含义的短词都要保留：coffee-without-sugar 和 coffee-sugar 是不同的页面，“not”“no”和“vs”虽然很短，却举足轻重。
长度
Google 没有公布 slug 的字符数上限，它给出的指导只是让 URL 保持简单、易读。我们的经验法则是用三到六个点明主题的单词，这样 slug 放进面包屑里读起来顺畅，也短得便于分享。slug 不必重复整个标题，也不该在你每次微调标题时跟着变。
重音符号与其他语言
Google 建议在 URL 中使用你的受众所用语言的词。对于带重音的拉丁文字，许多 slug 生成器会去掉重音，所以 crème brûlée 会变成 creme-brulee。这通常没问题，但偶尔会改变一个词：德语的 schön（漂亮）会变成 schon（已经）。请读一遍结果。对于希腊文、西里尔文或日文这样的文字，你可以保留原来的字母；非 ASCII slug 的利弊，我们在永久链接指南里有讲。
ConvertCaseHQ 中的 kebab-case 与“Slug 化”
我们的大小写转换器里既有 kebab-case 选项，也有“Slug 化”选项，二者并不相同。两者都会转为小写、去掉撇号、保留希腊文、西里尔文和日文等非拉丁文字（空的 slug 对谁都没用），并用连字符连接单词。区别在于：
- 重音符号：“Slug 化”会去掉拉丁字母上的重音（é → e、ł → l、ß → ss）。kebab-case 会保留，所以 Café 会变成
café。 - camelCase 输入：kebab-case 会把它拆开（
XMLHttpRequest→xml-http-request），这正是写代码时想要的结果。“Slug 化”则把它当作一个词（xmlhttprequest）。
两个选项都不会去掉停用词，那由你来决定。两者都把整个文本框当作一个字符串，所以换行也会变成连字符。请一次只转换一个标题。
URL slug 速查清单
- 只用小写；如果你的服务器会响应大小写混用的地址，就把它们重定向。
- 单词之间用连字符。不用下划线，不用空格，也不要把单词连写在一起。
- 不要有撇号、标点或残留的符号，但符号有意义的标题要改写。
- 三到六个有实际意义的词。去掉废话，保留会改变含义的词。
- 写一次，然后别再动它。稳定的 URL 胜过完美的 URL。
