URL Slug 设计指南：长度、关键词与中文的取舍

slug 是 URL 里你唯一能完全控制的部分

一条 URL 的构成里，域名、协议、路径结构都轮不到内容作者说话，slug——那截标题变成的路径——是唯一逐字由内容决定的。它同时服务三个读者：搜索爬虫（词形与相关性）、搜索用户（结果页里 URL 的可读性影响点击）、以及未来粘贴这个链接的人。

设计 slug 的本质是四个决策：分隔符、长度、关键词、语言。这篇逐个讲清楚，最后给批量生成的动线。

决策一：短横线，几乎无条件

Google 的官方 SEO 文档写得很直白：用短横线分隔 URL 里的词，不要用下划线。历史上 Google 的分词器把下划线当词内字符处理过（url_slug 可能被读成一个词 urlslug），短横线则始终是分隔符。其他主流引擎与 CMS（WordPress 默认）都按短横线生态运作。下划线的正确用途是文件名和编程标识符（snake_case）——那是另一个场景。

决策二：长度是信息密度问题

slug 不是标题的完整复刻——标题为吸引点击可以长，slug 只需要承载检索信号：

• 3-5 个词、60 字符以内是经验甜点：搜索结果页 URL 展示空间有限，超长会截断
• 第 6 个词之后的 SEO 权重趋近于零，把虚词、停用词、语气词删掉
• 保留信息量最大的实体词：《The Beginner's Guide to Café Marketing in 2026》→ cafe-marketing-guide 而不是全标题转写

决策三：关键词放前面，但别堆

把内容的核心关键词放进 slug（尽量靠前），一个就够。url-slug-design 优于 some-thoughts-about-url-and-slug-design。堆砌（url-slug-slug-url-generator）在算法上是负面信号。

决策四：中文的取舍

中文标题生成 slug 有两条路线，各有适用场景：

1. 保留中文（中文标题-测试 形态）：URL 编码后依然可收录，现代浏览器地址栏直接显示原文字，中文用户粘贴分享无障碍——中文站（知乎、哔哩哔哩等）大量使用
2. 仅 ASCII（移除中文得纯英文 slug）：面向国际受众、技术社区（代码仓库、文档站）更稳，避免编码长度膨胀与跨系统显示差异

没有唯一正确答案，但站内要统一。混排输入（标题里夹英文产品名）在保留模式下中文与英文各成词正常连接。

转换规则速查

设计定了，转换时的硬规则：

批量生成的动线

真实场景是一批标题：迁移博客、给产品列表补 slug。slug 生成器支持逐行批量——标题清单一次粘贴每行独立生成；中文默认保留、「仅 ASCII」一键切纯英文；分隔符短横线/下划线切换。生成的 slug 放进 URL 前用 URL 编码工具预览编码形态；配套的 大小写转换器 处理变量命名场景的 camelCase/snake_case——命名这件事的两类需求一站覆盖。

常见问题

URL slug 用短横线还是下划线？

短横线。Google 官方文档明确把短横线当作词分隔符推荐使用，下划线在部分系统（包括 Google 的分词历史行为）里被当作词的一部分，url-slug 和 url_slug 的权重传递可能不同。下划线留给文件名与编程标识符场景。

URL slug 的长度控制在多少合适？

经验值 3-5 个词、60 个字符以内：足够承载关键词，又不会在搜索结果里被截断。超长 slug 的信息增量极低（第 6 个词之后的权重几乎为零），把标题前几个信息量最大的词留下即可。

中文标题应该生成中文 slug 还是英文 slug？

看站点受众：中文站的中文 slug（URL 编码后依然可收录可点击，浏览器地址栏会显示原文字）对中文搜索是合法且常见的形态；面向国际受众或技术社区的内容用英文 slug 更稳。「仅 ASCII」开关两类需求都能覆盖，混排输入会保留中文并连接英文部分。

标题里的变音符号和特殊字符怎么处理？

变音符号折叠到基础字母：café → cafe、Việt → viet（这是 slug 的通行规则，保住可读性）；撇号直接删除（Facebook's → facebooks）；其他特殊符号去除且不转写（$34B → 34-b，不会变成 dollar34b）。