知识库 / 入门教学 / 编者补充
CMS 的 SEO 能力清单与配置分工
选 CMS、或者给研发提建站需求时，最怕的不是"没做 SEO"，而是上线之后才发现某个字段后台改不了——canonical 写死在模板里、改个 URL 不会自动生成 301、搜索结果页想加 noindex 得排一次版。等到那时候再补，成本是开发期的好几倍。
这一页把"一个适合 SEO 的 CMS 至少该具备什么能力"列成清单，可以直接拿去当选型评估表，或者当需求文档的附件。最后一节讲这些配置项通常由谁来填。
配套阅读：训练营第 6 课 · 技术SEO与开发协作 + 内链 讲的是怎么把这些需求"翻译"成开发能验收的规范；第 25 讲 · 改版与迁移的运营侧 讲 URL 变更时的 301 与回滚。
一、能力清单（选型评估表）#
| 功能 | 是否建议支持 | 是否后台可配置 |
|---|---|---|
| SEO Title | 必须 | 是 |
| Meta Description | 必须 | 是 |
| URL Slug（自定义 URL） | 必须 | 是 |
| H1 | 必须 | 是 |
| Canonical | 必须 | 是 |
| Robots（index/noindex、follow/nofollow） | 必须 | 是 |
| 图片 Alt | 必须 | 是 |
| Meta Robots | 必须 | 是 |
| Open Graph（Facebook） | 建议 | 是 |
| Twitter Card | 建议 | 是 |
| Breadcrumb Schema | 建议 | 自动生成或配置 |
| FAQ Schema | 建议 | 可配置 |
| Product Schema | 电商必须 | 可配置 |
| Organization Schema | 建议 | 全站配置 |
| Sitemap 自动生成 | 必须 | 自动 |
| robots.txt | 必须 | 可编辑 |
| 301 Redirect | 必须 | 后台维护 |
| 404 页面 | 必须 | 可配置 |
| hreflang（多语言） | 多语言必须 | 可配置 |
二、页面级 SEO 配置#
上面这些能力，每一类页面都应该能独立设置，而不是全站共用一套。常见的页面类型有：
- 首页
- Products（产品列表）
- Category（分类页）
- Product Detail（产品详情）
- Blog
- Case Study
- About Us
- Contact
- Landing Page
理论上每个页面都要能单独配：
- SEO Title
- Meta Description
- URL
- H1
- Canonical
- 图片 Alt
- 是否 Index
- 是否 Follow
- OG Title
- OG Description
- Social Image
三、栏目模板（Template）#
页面级配置解决"单页要精调"，模板解决"批量别手填"。很多公司都会做这一层：给每个栏目定一套生成规则，SEO 人员只维护内容，CMS 自动生成标签。
Blog
- Title：
{{Article Title}} | Brand - Description：
{{Summary}} - Canonical：自动
- Schema：Article
Product
- Title：
{{Product Name}} Manufacturer | Brand - Description：
{{Product Summary}} - Schema：Product
Category
- Title：
{{Category}} Supplier | Brand
这是大型网站比较常见的方式。
四、SEO 规则（Rule）#
比模板再往上一层，是全站规则。新增几千篇文章时，不需要一条条填。
URL Rule
/blog/xxx
/product/xxx
/category/xxx
Title Rule
{{Product Name}} | Brand
{{Blog Title}} | Brand
Meta Rule
{{Summary}}
五、容易被遗漏的十项#
① Canonical#
很多 CMS 有 Title，却没有 Canonical。实际上 example.com/a 和 example.com/a?sort=1 是两个 URL，没有 canonical 就很容易出现重复内容问题。
② Robots#
最好后台能直接勾选：Index / Noindex / Follow / Nofollow。例如站内搜索结果页，通常需要 noindex。
③ Sitemap#
CMS 自动生成 sitemap.xml，新增文章自动更新。否则维护成本会很高。
④ Redirect#
后台支持"旧 URL → 新 URL"填写，自动生成 301。否则每次改 URL 都要研发去改服务器配置。
⑤ Hreflang（多语言）#
如果站点有 en / fr / de / jp 多个版本，CMS 最好能自动输出 hreflang，否则国际 SEO 会比较麻烦。
⑥ Structured Data#
Article、FAQ、Product、Organization、Breadcrumb 这些最好由 CMS 自动生成，SEO 不需要手写 JSON-LD。
⑦ Image SEO#
不只是 Alt，还包括：图片 Title、Caption、文件名（可选）、WebP 支持、Lazy Load。
⑧ URL 修改提醒#
修改 URL 时弹出提示"是否自动生成 301？"——这个功能非常有价值，能挡掉绝大多数因改 URL 造成的流量损失。
⑨ 自定义 Head#
有时候需要插入 Google Tag Manager、GA4、Pixel、Schema、站点验证代码。后台最好支持在 Head / Body / Footer 三个位置插代码，否则研发要频繁上线。
⑩ 页面收录控制#
是否加入 Sitemap、是否允许 Index、Canonical 指向、是否生成 RSS，最好都能在后台单页控制。
六、这些通常由谁配置#
取决于公司规模、CMS 能力以及配置内容，常见三种模式。
1. SEO 人员直接配置（最常见）#
成熟 CMS（如 WordPress 配合 SEO 插件，或企业自研 CMS 已具备完善 SEO 模块）通常会把页面级配置开放给 SEO 人员：SEO Title、Meta Description、H1、URL Slug（在允许修改的前提下）、Canonical、图片 Alt、Index/Noindex、Open Graph 信息、301 Redirect（如果后台提供该功能）。
这种方式效率最高，也减少了研发介入。
2. SEO 提需求，研发实现（项目初期最常见）#
网站刚上线或 CMS 功能不足时，SEO 输出需求，例如：新增 Canonical 配置项、支持 hreflang、自动生成 Sitemap、增加 Schema 输出、支持 Robots 设置、增加 Redirect 管理、优化 URL 规则。研发开发一次，功能上线后再交由 SEO 日常维护。
3. 前后台共同配合（大型企业常见）#
职责划分得比较清晰：
- SEO 团队：制定 SEO 策略、页面优化方案、关键词布局、内容优化、配置页面级 SEO 参数、监控效果。
- 研发团队：开发和维护 CMS 的 SEO 能力，处理模板、Schema 输出逻辑、Sitemap 生成、Redirect 功能、性能优化、爬虫可访问性等底层实现。
- 产品或运营团队：负责页面内容、栏目管理以及发布流程。
这种模式能够兼顾灵活性与系统稳定性。
七、综合建议：把需求分成两类#
如果是新建网站或新 CMS，建议一开始就把需求拆成两摞：
研发一次性实现的能力：URL 规则、模板规则、Schema 输出、Sitemap、robots.txt、Canonical 逻辑、301 Redirect、hreflang、页面模板、性能优化。
SEO 日常维护的内容：SEO Title、Meta Description、H1、图片 Alt、Canonical（如需覆盖默认值）、Index/Noindex、关键词布局、OG 信息。
这样分工，既能减少研发反复介入，也能让 SEO 团队快速响应优化需求，是目前较为常见且高效的实践方式。
下一步：上线前再过一遍总检#
选完 CMS、开发完成之后，接着用新站上线前 SEO 自检清单按上线时间轴走一遍。那一页把本页的能力项和手册里其余八份清单串成了一条从立项到上线首周的检查线，并标出了哪些决定上线后就很难改（域名、URL 结构、分类栏目）——这三样正好都要在选 CMS 的同一阶段定下来。