RTL 语言（阿拉伯语、希伯来语）的 SEO 与技术注意事项
RTL（Right-to-Left，从右到左）网站上线后排名不动，九成不是内容或翻译问题，而是三类技术错误叠加：dir="rtl" 属性没设在正确层级、字体 fallback 在阿拉伯语/希伯来语缺字时断裂、hreflang 遗漏 ar／he 语言代码。 这三者任何一个出错，谷歌都可能判定页面“无法正常渲染”或“找不到对应语言版本”，导致抓取正常却不收录、或收录了却不排名。
为什么 RTL 站的技术债特别隐蔽？
LTR（从左到右）语言网站的技术检查清单（网站地图、canonical、结构化数据）在 RTL 站上照搬一遍是不够的，因为 RTL 多了一层“排版方向”本身就是技术信号：
- 视觉正确不等于标记正确：浏览器常会自动识别阿拉伯文字并自行镜像版面，让开发者误以为不设
dir属性也没关系——但谷歌的渲染引擎与屏幕阅读器依赖的是 HTML 属性，不是视觉猜测。 - 字体子集化陷阱：许多网站字体只打包拉丁字符子集，阿拉伯语、希伯来语字符退回系统默认字体甚至变成方框（tofu），页面在爬虫眼中看似“内容存在”但实际可读性极低。
- hreflang 语言代码混淆：阿拉伯语有
ar（通用）与ar-SA、ar-EG等地区变体，希伯来语只有he（注意旧代码iw已弃用）——代码写错或漏加自我引用，会让整组 hreflang 集合失效。
错误一：dir 属性缺失或层级设错
dir="rtl" 必须设在 <html> 标签，而不是只设在正文 <div>：
<html lang="ar" dir="rtl">
<head>...</head>
<body>
<!-- 导航栏、页脚、表单都会自动继承 rtl -->
</body>
</html>常见的错误是只在文章内容区块加 dir="rtl"，导致导航菜单、面包屑、表单标签仍是 LTR 排版，形成“内容镜像、界面不镜像”的混乱版面。若同一页混杂阿拉伯文与英文品牌名，应在该行内用 dir="ltr" 局部覆盖，或改用 CSS 的 unicode-bidi: isolate 避免双向文字互相干扰标点符号位置。
错误二：字体 fallback 在 RTL 字符集断裂
font-family 的 fallback 列表若只列拉丁字体，阿拉伯语、希伯来语会直接退回操作系统默认字体，不同设备显示落差极大：
/* 错误：只覆盖拉丁字符 */
body { font-family: "Helvetica Neue", Arial, sans-serif; }
/* 正确：明确加入 RTL 字符集字体 */
body {
font-family: "Helvetica Neue", "Noto Sans Arabic",
"Noto Sans Hebrew", Arial, sans-serif;
}若使用 Google Fonts 或自建 web font，务必确认字体文件的 unicode-range 覆盖阿拉伯文（U+0600–U+06FF）或希伯来文（U+0590–U+05FF）区段，否则浏览器会静默 fallback，只有在浏览器开发者工具的“computed font”栏位才看得出来，一般预览画面看不出差异。
错误三：hreflang 遗漏或语言代码写错
RTL 语言的 hreflang 代码本身没有特殊语法，但因为多语言站常见的自动化脚本是以 LTR 语言为默认模板复制而来，RTL 版本经常被遗漏在 hreflang 集合外：
<link rel="alternate" hreflang="ar" href="https://example.com/ar/product/" />
<link rel="alternate" hreflang="he" href="https://example.com/he/product/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/product/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/product/" />三个常见错误：用已弃用的 iw 取代 he；用 ar-SA 却没有对应的通用 ar 兜底，导致非沙特地区的阿拉伯语用户匹配不到页面；以及最基本的——RTL 版本页面本身漏了自我引用那一行，让整组 hreflang 因为互相引用不完整而被谷歌忽略。
上线前 RTL 技术检查清单
| 检查项 | 验证方法 | 常见错误 |
|---|---|---|
dir="rtl" 设在 <html> |
查看源代码 <html> 标签属性 |
只设在正文 <div>，导航栏未镜像 |
| CSS 用逻辑属性而非物理属性 | 搜索 CSS 中的 margin-left／padding-right |
用物理方向属性，RTL 下版面错乱 |
| 字体 fallback 含阿拉伯文/希伯来文字体 | 开发者工具查看 computed font | fallback 列表只列拉丁字体 |
hreflang 含 ar／he 且自我引用完整 |
用 hreflang 验证工具逐页抽查 | 用已弃用的 iw，或漏掉自我引用 |
表单与按钮方向随 dir 翻转 |
手动测试表单排列与图标方向 | icon（如箭头）方向未跟着镜像 |
| 数字与日期格式维持 LTR 局部方向 | 检查价格、电话号码显示 | 阿拉伯数字被整段镜像导致顺序颠倒 |
CSS 建议改用逻辑属性（margin-inline-start 取代 margin-left），这样同一份样式表在 LTR、RTL 两种模式都能正确渲染，不必为 RTL 另外写一份镜像版 CSS，长期维护成本更低。
常见问题（FAQ）
Q1：RTL 网站需要独立的 CSS 文件吗？
不一定。用逻辑属性（margin-inline-start、padding-inline-end）取代物理属性（margin-left、padding-right），同一份 CSS 就能同时支持 LTR 与 RTL，只需搭配 dir 属性切换，不必维护两套样式表。
Q2：阿拉伯语要用 ar 还是 ar-SA 这类地区代码？
若内容没有地区差异（货币、法规、本地案例），用通用 ar 即可；只有在真的针对沙特、埃及等特定市场做本地化内容时，才加 ar-SA、ar-EG 等地区代码，并务必保留一行纯 ar 兜底非特定地区的用户。
Q3：希伯来语的语言代码是 he 还是 iw？
是 he。iw 是旧版 ISO 639-1 代码，已被弃用，部分老旧 CMS 模板仍残留这个错误，务必检查并更正，否则 hreflang 该行会被视为无效语言代码。
Q4：RTL 页面的结构化数据（Schema）需要特别处理吗？
Schema.org 的 JSON-LD 本身是语言中立的数据格式，不受页面方向影响，但 inLanguage 字段要正确填入 ar 或 he，且描述文字内容仍要通过人工审阅，确认双向文字（阿拉伯文中夹杂英文品牌名）没有因为渲染问题被截断。
Q5：只靠浏览器自动检测方向，不设 dir 属性可以吗？
不建议。浏览器的自动检测是基于文字内容猜测方向，对纯数字、品牌名开头或混合语言的段落经常误判，且搜索引擎爬虫与屏幕阅读器都是读取明确的 HTML 属性做判断，缺少 dir 属性等于把渲染正确性交给运气。
RTL 站的技术错误往往肉眼难以察觉——版面看起来镜像正确，但 dir 属性、字体 fallback、hreflang 三处可能同时出错，GeoSeoToday 的 GEO 检测工具 能协助找出这类跨语言技术债。若你的站点涉及多语言 hreflang 配置，建议先读〈hreflang 是什么？多语言站必备教程〉打好基础，再回头处理 RTL 专属的排版与字体问题。