作者：成都长风云Drupal开发团队

成都长风云Drupal开发团队已经从事Drupal相关开发17年（始于2008年）。我们全身心投入这份事业，本文所有内容，都源自我亲手搭建、迁移或是优化过排名的项目。

我遇到过的很多 Drupal 网站，都存在一类共性问题：相关模块已经安装，但配置却错误百出。Drupal 的 SEO 短板，从来都不是缺少功能 —— 社区贡献模块早在多年前就已经可以满足搜索引擎的各类需求。真正的问题在于，模块只是装上了，却没有正确配置，而正是这个差距，让网站的排名悄无声息地不断下滑。

我会把 SEO 和 Drupal 工程作为一套完整工作流程来处理，也就是说，我既要配置这些模块，也要直面模块最终产出的搜索结果。下面这套模块组合，是我在每一个新项目中都会部署的工具，包含我的安装顺序、关键配置项，以及我在其他网站上反复见到的错误。文章篇幅较长，因为细节才是重中之重。

这份清单有两条基本准则。第一：文中所有模块均兼容 Drupal 10/11，并且仍在积极维护，没有已经停止更新的僵尸模块。第二：我按照每小时配置工作所能带来的收益影响排序，而非模块的流行程度。排在前三位的模块，解决的 SEO 问题，比剩下七个模块加起来还要多。

1. Pathauto — 决定网站 URL 如何展示的模块

模块作用：根据你针对不同内容类型定义的规则，生成可读性高的 URL 别名，替代 Drupal 默认的`/node/4127`这类地址。

为什么排第一：URL 是网站信息架构的骨架。谷歌会解析 URL，用户也会在搜索结果中看到 URL；本文介绍的其他所有模块，都建立在 URL 别名的基础之上。如果上线之初 URL 规则设置错误，你要么只能被迫沿用这套错误规则，要么就要投入大量工作做重定向。

我的配置方式：

- 在创建内容之前就设计好 URL 规则。对于普通企业网站：页面使用`[node:title]`、博客文章使用`blog/[node:title]`、分类术语页使用`[term:vocabulary]/[term:name]`。尽量让 URL 层级保持浅短；URL 中的每一层目录，都代表一套你必须长期维护的网站结构。
- 将 “更新处理方式” 设置为 “创建新别名，保留原有别名继续生效”。这是绝大多数人都会搞错的设置。部分部署环境的默认行为是：当页面标题修改时，直接删除旧别名 —— 这会让所有指向该页面的外部链接出现 404 报错。配合下一节介绍的 Redirect 模块，该正确设置可以在每次修改标题时自动生成 301 重定向，避免链接失效。
- 标点符号配置：所有符号统一替换为连字符；直接删除撇号，不要做转换。`/whats‑new`的效果优于`/what‑s‑new`。
- 不要在正式生产站点直接点击批量生成按钮，除非你已经校验过 URL 规则，并且确认 Redirect 模块配置完成。没有配套重定向就批量重新生成 URL，是我见过最快摧毁网站排名的操作：一次定时任务就会改动成千上万条链接，却没有生成任何重定向。

很多人都会犯的错误：把 Pathauto 当作安装完就不用管的工具。模块安装完成即可运行，但自带的规则模板只是通用模板。如果网站所有内容类型都使用扁平化的`/节点标题`格式 URL，就浪费了向爬虫和用户传递主题结构的机会。

2. Redirect — 守护其他模块产出成果的模块

模块作用：通过可视化界面管理 301/302 重定向；最重要的是，当 URL 别名发生变更时，可以自动创建重定向。

为什么排第二：链接权重积累十分缓慢，丢失却只在一瞬间。每一个变更后没有配置重定向的 URL，都会把它积累的权重拱手送给竞争对手。在网站迁移项目中，这个模块直接决定你能否保住多年积累的 SEO 成果。我之前写过如何迁移拥有 5 万页面的网站且不损失排名，实话讲，一半的工作量都来自重定向的规范处理。

我的配置方式：

- 开启别名变更时自动创建重定向功能（和上面 Pathauto 的设置相辅相成）。
- 在网站上线或重构完成后的前 90 天，开启404 日志子模块。它会记录真实访客与爬虫实际访问到的失效链接，这就是一份优先级明确的待处理清单，而非凭空猜测。
- 每季度梳理重定向链。A→B→C 这类链式重定向，每跳转一次都会损耗链接权重与爬虫抓取配额。在模块列表页按源链接排序，就可以找出这类问题。多次网站重构之后，经常会出现三到四层跳转的链条，每多一跳，都会带来可量化的性能损耗。
- 批量导入重定向之后留意重定向循环。模块会给出警告，但前提是有人去查看状态报告。务必把这项加入上线检查清单。

所有人都会犯的错误：导入数百条迁移重定向，只手动点开其中两三条确认 “可以跳转”，却不去查看 404 日志，忽略大量没有映射关系的旧链接：图片路径、旧订阅源地址、带 UTM 参数的活动落地页等。

3. Metatag — 搜索引擎读取的全部信号，通过模板统一配置

模块作用：配置标题标签、元描述、规范链接、robots 指令、开放图谱、推特卡片；基于令牌模板，针对不同实体类型设置规则，同时支持单篇节点单独覆盖改写。

我的配置方式：

- 理解继承逻辑：全局默认设置 → 实体类型默认设置 → 内容包默认设置 → 单节点自定义覆盖。把内容包层级的模板配置妥当，几乎就不需要再去修改单篇节点的元数据。这点非常关键，因为单节点手动配置的元数据很容易过时：编辑人员离职，他们 2023 年手动写的元描述，却还在和早已迭代的内容绑定在一起。
- 标题模板：`[node:title] | [site:name]`是稳妥的默认方案。不要在后缀强行堆砌关键词；谷歌会改写有堆砌嫌疑的标题，一旦被改写，你就彻底失去了对搜索结果展示样式的控制权。
- 规范链接（canonical）：确认规范链接指向 URL 别名，而不是`/node/ID`这类原生路径，并且使用绝对地址。这可以解决 Drupal 经典的重复内容问题：同一份内容同时存在两套访问地址。
- 开启开放图谱和推特卡片子模块，并且设置一张通用的默认分享图。社交爬虫不会自行猜测配图。
- 为网站内没有排名价值的内容包设置 robots 禁止索引规则：站内搜索结果页、用户个人资料页、不打算参与排名的分类页、表单提交确认页。

所有人都会犯的错误：只配置全局默认，跳过内容包层级的设置，上线之后所有内容类型共用同一套笼统的元描述模板。这个模块的核心价值就在于：活动、产品、博客文章，理应拥有各自独立的元数据逻辑。

4. 站点地图之争：Simple XML Sitemap 对比 XML Sitemap

这是整套工具中唯一二选一的选择。社区经历过一次真正的迭代更替，因此值得拿来对比说明。

XML Sitemap是老牌模块，Drupal6、Drupal7 时代被广泛使用。如果你在维护老旧站点，大概率正在使用它。功能可用，但带有旧时代的局限：架构较重，大站点环境下一直存在性能诟病，数据模型诞生时还没有多语言的主流需求。

Simple XML Sitemap是现代的替代方案。对于所有 Drupal9/10/11 新项目，我都会毫不犹豫选用它。理由如下：

- 完善的多语言支持：在站点地图原生加入 hreflang 语言注解，这正是谷歌官方推荐的实现方式，也是旧模块原生无法做到的功能。对于任意双语及以上站点，单凭这一点就足以做出选择。
- 更合理的生成逻辑：支持批处理，依靠定时任务更新，即便站点拥有数十万条 URL 也可以稳定运行。
- 灵活的内容包级别包含开关：需要索引的内容类型纳入站点地图，工具类内容包排除，同时支持单实体单独改写。
- 图片站点地图支持：对于图片搜索能带来流量的网站来说，该功能价值很高。

结论：新项目直接选用 Simple XML Sitemap，无需纠结。正在运行的单语言老站点，如果使用 XML Sitemap 并且运行稳定，可以继续保留；一套正常工作的站点地图，不值得专门立项重构。但如果你正好要对站点做迁移，就趁迁移阶段完成切换，只需要一小时左右工作量。

通用配置要点：将站点地图地址提交到谷歌搜索控制台与必应站长工具。必应的数据会供给 DuckDuckGo，如今也服务 AI 搜索工具，因此这一步不可省略；不要把设置了 noindex 禁止索引的页面放进站点地图，避免两套信号互相矛盾。站点地图收录禁止索引的 URL，相当于向谷歌传递两套完全相反的指令，搜索控制台会持续向你发出告警。

5. [Schema.org](https://Schema.org) Metatag — 无需手写 JSON，即可输出结构化数据

模块作用：扩展 Metatag 模块，输出 JSON‑LD 格式的[Schema.org](https://Schema.org)结构化数据，复用同样的令牌模板系统，支持文章、机构、面包屑列表、活动、产品、常见问题等类型。

为什么重要：结构化数据是获取富展示结果（星级评分、FAQ 问答、面包屑、活动卡片）的基础，也让网站实体可以被机器解析，如今对 AI 搜索同样意义重大。依托 Metatag 的模板体系，你只需要针对内容包配置一次文章标记，网站内所有文章就会自动输出正确的 JSON‑LD 数据。

我的配置方式：首页配置机构信息标记（机构名称、logo、社交媒体账号关联链接）；博客文章配置文章标记，包含作者、发布时间、配图；面包屑列表标记要和页面实际展示的面包屑导航保持对应。配置完成后使用谷歌富结果测试工具校验。不是因为模块本身容易出错，而是你使用的令牌可能产生问题：图片字段为空、作者引用缺失，会生成语法合法，但业务信息无效的标记，模块无法识别这类业务层面缺陷。

什么时候需要手写代码：遇到高度定制化的 Schema 需求，复杂嵌套类型、多实体关联结构，有时候直接写预处理函数输出 JSON‑LD 会更简洁。该模块可以覆盖 90% 的常规场景；不要为了剩下 10% 特殊场景强行折腾模块 UI，直接写十几行 PHP 代码即可。

6. Easy Breadcrumb — 兼顾导航体验与排名信号的面包屑模块

模块作用：基于 URL 路径结构生成面包屑导航（得益于 Pathauto，URL 已经承载了层级关系），而非 Drupal 内核依赖菜单生成面包屑的逻辑。内核方案的缺陷是：一旦内容没有挂载到菜单，面包屑就会异常失效。

为什么入选清单：面包屑会替换原始 URL 展示在谷歌搜索摘要中；它会从每一个子页面向栏目页传递内部链接权重；深度浏览页面的用户也依靠面包屑理清位置。一个模块，三重收益，配置仅需 15 分钟。

配置要点：是否显示首页节点均可，但要和面包屑列表 Schema 保持统一；调整标题大小写规则，不要和内容标题互相冲突；确保面包屑路径中每一级中间页面，都是真实可被索引访问的页面。如果面包屑指向 403 无权限访问页面，这就是披着良好用户体验外衣的内链 bug。

7. Search 404 — 把死链接访问变成挽回流量的机会

模块作用：当访问链接失效时，不再展示空白 404 页面，而是从失效 URL 提取关键词，调用站内搜索。例如访问`/drupal‑migration‑guide‑old`，页面就会展示关键词 “drupal migration guide” 的站内搜索结果，而不是简单报错。

为什么值得部署：即便重定向工作做得再完美，外部链接依然会以各种不可预知的方式失效：新闻通讯里的打字错误、PDF 文档截断链接、指向从未真实上线页面的链接。访问这类链接的访客，本意是想要获取你的内容。借助该模块，就可以把访问死页的访客平稳引导，并且不需要后续持续维护。同时它还可以减少普通 404 页面带来的不良信号：访客打开页面两秒就立刻返回谷歌搜索结果。

重要提醒：务必保持 HTTP 状态码为 404（该模块默认就会正确处理）。有些站点出于 “友好” 目的，对不存在的页面返回 200 正常状态码，会造成大量伪 404 页面，爬虫会长期陷入这类无效页面。

8. RobotsTxt — 区分不同运行环境的爬虫访问控制

模块作用：将 robots.txt 从代码仓库静态文件，改为数据库内可视化配置项，不同环境可以独立编辑。

这不是无关紧要的小事，两点原因：第一，避免经典灾难：把测试环境`Disallow: /`禁止抓取的 robots.txt 部署到生产环境；或是反过来，测试站点对外开放索引，导致测试站在品牌关键词搜索结果里排名超过正式网站。我大概每审计 5 个网站，就会遇到一例测试站点被搜索引擎收录的问题，这是成熟网站上最常见的严重缺陷。依托配置管理实现环境隔离的 robots 配置，可以彻底杜绝这类故障。

第二，筛选器导航爬虫陷阱。任何带有筛选列表的网站（电商、出版物、课程），都会产生指数级增长的参数组合 URL：颜色 × 尺寸 × 排序 × 分页，会生成数万条高度近似的页面。谷歌爬虫抓取这些页面，会耗尽你的抓取配额，导致新的优质内容需要很久才会被发现。通过该模块配置参数屏蔽规则，配合 noindex 禁止索引策略，就可以解决该问题。大型网站部署之后，几周内就能在爬虫抓取统计图表看到明显改善。

9. Hreflang — 多语言网站，避免不同语言版本互相竞争排名

模块作用：为翻译后的内容输出 hreflang 语言切换标记，告诉搜索引擎，哪一个语言版本应该展示给哪一部分受众。

适用人群：使用内核内容翻译功能，并且拥有真实翻译内容的网站。没有正确配置 hreflang，谷歌就只能自行猜测；最常见的错误结果就是把英文页面展示给西班牙语搜索用户，用户看完直接跳出；或是把 en‑US 与 en‑GB 版本判定为互相竞争的重复页面。

绝大多数网站忽略的协同细节：hreflang 必须双向互相引用—— 英文页面指向阿拉伯语版本，阿拉伯语页面也必须回指英文页面。同时标记内容需要和 Simple XML Sitemap 站点地图中的 hreflang 数据保持一致。一旦信号互相冲突，整套注解就会被搜索引擎直接忽略；一处配置错误，会导致全部语言版本的标记失效。配置完成之后，不要仅凭肉眼检查页面源码，要到搜索控制台的国际定位报告做验证。

10. Real‑time SEO（大家关心的 Drupal 版 Yoast）：实用、可选，但被过度吹捧

很多从 WordPress 迁移到 Drupal 的用户，都会想要 Yoast 工具。Drupal 对应的方案就是 Real‑time SEO 模块，基于 Yoast 底层库开发。它给编辑提供熟悉的红绿灯内容分析：关键词出现情况、元描述长度、可读性提示。

我多年既部署也卸载过该模块，客观评价：它是编辑人员的辅助培训工具，而非 SEO 优化工具。绿灯只代表内容符合一套检查清单，不代表页面就可以拿到好排名。我见过不少全部绿灯的页面，完全没有排名，因为这套工具无法识别搜索意图、竞争激烈程度，也无法判断内容本身是否有用户需求。而所有真正决定技术层面排名的要素，前面 1‑9 号模块已经全部处理完毕，不需要编辑在每篇文章手动操作。

适合安装的场景：你的编辑团队规模大，多数撰稿人不懂 SEO，需要基础约束，并且有人可以向他们说明：绿灯只是最低标准，不是最终目标。建议跳过的场景：内容由少数懂搜索的人员产出。模块强制要求每篇文章设置目标关键词，会变成形式主义工作；形式主义流程很容易被人敷衍跳过，最后页面挂满红灯，只会打击编辑士气。

我刻意不会安装的模块

一份推荐清单，理应附带一份拒绝清单。简单说明：我不会安装：关键词密度分析工具（谷歌十多年前就已经不再以此作为排名信号）、自动内链模块（会生成非常不自然的锚文本，有被搜索引擎惩罚的风险，每一次编辑内容都会触发链接变动），以及所有号称 “一键完成 SEO” 的工具 —— 按钮可以一键点击，但 SEO 优化做不到。网站上每新增一个模块，都会带来攻击面、版本更新负担以及维护复杂度。拒绝哪些模块，和选择哪些模块同等重要。

新站点的模块安装顺序

搭建全新 Drupal10/11 站点，按这套顺序可以避免返工：优先安装 Pathauto（正式内容创建前就定好 URL 规则），其次安装 Redirect，保证从第一天起修改别名就可以安全重定向，第三安装 Metatag 与[Schema.org](https://Schema.org) Metatag（趁还在设计内容包的时候，配置好内容包层级模板），第四安装 Simple XML Sitemap（内容包确定后设置站点地图收录规则），剩下的模块可以在上线前任意顺序安装。整套模块完整细致配置，大约耗时一天。几乎可以覆盖技术 SEO 审计会检查的全部要点。

老站点的模块安装顺序

对于已经上线的老站点，顺序反过来：先用 Redirect 模块的 404 日志，配合爬虫扫描，找出已经存在的问题，先止损修复，再顺着清单逐步处理。在已有内容上补配 URL 规则，需要大量重定向处理。这就是为什么 “等上线之后再做 SEO” 的实际成本，远高于建站阶段就同步规划 SEO。