在SEO中允许非英文（ASCII）字符出现在URL中吗？

Question

我有很多UTF-8内容，想将其插入到URL中以进行SEO。例如，我想在URI中包含的帖子标签（site.com/tags/id/TAG-NAME）。但是，标准只允许ASCII字符。

  

允许在URI中但没有保留用途的字符     称为未保留。 这些包括     大写字母和小写字母，     十进制数字，连字符，句点，     下划线和波浪号。

解决方案似乎是：

• 使用UTF-8编码将字符串转换为字节序列
• 将每个不是ASCII字母或数字的字节转换为%HH，其中HH是字节的十六进制值

但是，这会将易读的（且对SEO有价值的）单词转换为无意义的字符。 因此，我想知道Google是否仍然足够聪明，能够处理包含编码数据的URL的搜索，还是我应该尝试将这些非英语字符转换为其半ASCII对应项（这可能有助于拉丁语系）？

- Xeoncross

---

有没有真实的证据表明 G、B 或 Y 查看 URL？ - TFD

谷歌的 allinurl: 搜索选项 ;) - Xeoncross

无论如何，普通的G用户都不会使用那个，对吧！那又跟SEO有什么关系呢？最佳的SEO就是制作一个易于阅读的网站。 - TFD

Answer 1

首先，搜索引擎并不关心URL。它们有助于访问者：访问者链接到网站，而搜索引擎关心这一点。如果他们关心URL，那么会有垃圾邮件的倾向。没有一个主要的搜索引擎想要那样的情况。 allinurl:只是谷歌的一个功能，用来帮助高级用户，不会影响自然排名。使用更自然的URL可能会带来一些好处，但这只是PR的附属效应，因为较差的搜索引擎索引您的网站 - 这可能会对负面PR造成一些影响。

来自Google网站管理员中心

这是否意味着我应该避免完全重写动态URL？

这是我们的建议，除非您的重写仅限于删除不必要的参数，或者您非常勤奋地删除可能会导致问题的所有参数。如果您将动态URL转换为静态URL，使其看起来像静态URL，您应该知道我们可能无法在所有情况下正确解释信息。如果您想提供您网站的静态等效版本，您可能需要考虑通过为所有路径生成文件并使其可访问来转换底层内容，以便在您的网站上使用。但是，如果您正在使用URL重写（而不是复制内容）从动态站点生成静态外观的URL，则可能会造成伤害而不是好处。请放心向我们提供您的标准动态URL，我们将自动查找不必要的参数。

我个人认为这并不重要，除了获得更多的点击次数并帮助用户外。至于Unicode，您不了解它的工作原理：请求发送到十六进制编码的Unicode目标，但呈现引擎必须知道如何处理它们，如果希望将它们解码回某些视觉上吸引人的东西。 Google将正确呈现（解码）Unicode（编码）URL。

一些浏览器会使这变得稍微复杂一些，因为它们始终对主机名部分进行编码，原因是使用相同外观的表意文字进行网络钓鱼攻击。

我想给你展示一个例子，这里是通过wget发出的对http://hy.wikipedia.org/wiki/Գլխավոր_Էջ的请求：

Hypertext Transfer Protocol
    GET /wiki/%D4%B3%D5%AC%D5%AD%D5%A1%D5%BE%D5%B8%D6%80_%D4%B7%D5%BB HTTP/1.0\r\n
        [Expert Info (Chat/Sequence): GET /wiki/%D4%B3%D5%AC%D5%AD%D5%A1%D5%BE%D5%B8%D6%80_%D4%B7%D5%BB HTTP/1.0\r\n]
            [Message: GET /wiki/%D4%B3%D5%AC%D5%AD%D5%A1%D5%BE%D5%B8%D6%80_%D4%B7%D5%BB HTTP/1.0\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: GET
        Request URI: /wiki/%D4%B3%D5%AC%D5%AD%D5%A1%D5%BE%D5%B8%D6%80_%D4%B7%D5%BB
        Request Version: HTTP/1.0
    User-Agent: Wget/1.11.4\r\n
    Accept: */*\r\n
    Host: hy.wikipedia.org\r\n
    Connection: Keep-Alive\r\n
    \r\n

正如你所见，wget和其他浏览器一样，只会为你编码目标地址，并继续请求已编码的目标地址。解码后的域名仅存在于视觉上的便利。

- Evan Carroll

---

只要链接所在的页面（以及链接本身）都是有效的UTF8（具有正确的头文件和元标记），那么浏览器/蜘蛛就会自动将链接编码为%HH？根据这篇文章，似乎直接跳过标签并使用site.com/tags/id可能更好。 - Xeoncross

不，它并不更好：只是一样的。/$id 会让用户稍微困难一些。在进行请求之前，所有 URL 必须按照 rfc3986 进行编码。你的浏览器能够对给定的链接进行编码只是一种便利。从技术上讲，如果服务器这样做了，你就会开放自己几乎不存在的市场，因为没有能力解码/编码 Unicode 链接，维基百科也是这样做的（Unicode 表示是锚点，链接被编码）。根据规范，这就是应该的方式。 - Evan Carroll

那么我该怎么办呢？当我创建一个包含UTF8字符串的链接，比如<a href="site.com/tags/id/non-ascii-tag">non-ascii-tag</a>，我应该只是相信浏览器来编码URI，还是应该通过某种编码器函数来运行它，以便浏览器不必这样做？ - Xeoncross

将其通过编码器运行，浏览器将解码URL的路径和查询部分以获得视觉效果，但无论如何，这对搜索引擎几乎没有影响。我想象他们会通过编码规范化所有Unicode URL。 - Evan Carroll

@Evan，我不明白你发布的Google站长信息如何导致结论：Google不关心URL中的内容 - 它只是说明Google可以处理动态URL。毫无疑问，将页面内容与URL关键字和用户搜索的关键字配对的URL将排名更高。我并不是说这是万能药 - 但它肯定有一定的影响。 - calumbrodie

Answer 2

你知道所有内容都是用什么语言编写的吗？是否都是拉丁语系的？

如果是这样，我建议建立一个查找表，在可能（且不冲突）的情况下将UTF-8转换为ASCII。类似这样的东西会将Ź转换为Z等，当发生冲突或字符不存在于您的查找表中时，则使用%HH。

- Earlz

---

好的，我借用了一个口音转换表（将Ź转换为Z），你可以在WordPress代码库中找到它。但是我不知道你所说的“％HH”是什么意思。 - Xeoncross

Convert each byte that is not an ASCII letter or digit to %HH, where HH is the hexadecimal value of the byte - Earlz

你如何将每个字节转换为十六进制？ - Xeoncross