mcpField
P
programmatic-seo

programmatic-seo

github.com/rampstackco营销与增长1.0k248 次安装2 周前更新
代码仓库

关于 programmatic-seo

面向 SEO 策略师和内容团队的程序化 SEO 指南,适用于规划或审查项目,重点关注数据质量、模板与 Schema 设计,以及大规模页面质检。

主要功能

  1. 01评估程序化 SEO 是否适用
  2. 02指导数据源评估
  3. 03涵盖模板与 Schema 设计
  4. 04制定抽样和自动质检方法
  5. 05追踪不同页面批次的质量

适用场景

  1. 01评估程序化 SEO 方案
  2. 02基于结构化数据设计页面
  3. 03审查表现不佳的生成页面集
  4. 04为持续扩大的页面集建立质检

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/rampstackco/claude-skills --skill programmatic-seo

安装后在 Claude Code 中输入/programmatic-seo确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

README.md
references/
aeo-geo-for-programmatic-pages.md
common-pseo-failures.md
crawl-budget-management.md
data-source-identification-patterns.md
internal-linking-at-scale.md
quality-control-at-scale.md
refresh-at-scale.md
schema-design-patterns.md
template-design-patterns.md
when-pseo-works-decision.md

详细介绍

程序化 SEO

资深 SEO 策略师的实战指南,教你如何设计和运营程序化 SEO 项目,以持续获取流量,而不是招致惩罚。

程序化 SEO 的口碑颇为复杂。Zillow、Airbnb、TripAdvisor、Indeed 和 Yelp 等网站通过 pSEO 打造了价值数十亿美元的流量引擎。另一些网站则搭建了 pSEO 项目,遭遇 Google 的实用内容更新,一周内流量损失了 80%。造成差异的很少是技术本身,关键在于底层数据质量,以及大规模运营时的质量控制规范。

本技能指南旨在帮助你把握好这一区别。它假设你已经决定了要覆盖的关键词领域(参见 seo-keyword),并规划好了整体内容项目的形态(参见 content-strategy)。它不会撰写单篇编辑内容(相关内容请参见 content-and-copy),也不会设计编辑主题中心(相关内容请参见 pillar-content-architecture)。它要教你的是:如何基于结构化数据源,以规范的方式批量生成页面,同时避免内容单薄、内容重复,或因规模扩张却缺乏实质价值而遭到惩罚。

适用场景:判断 pSEO 是否适合整个项目(这是最重要的问题);设计新的 pSEO 系统;审核现有的、排名不佳或受到算法更新冲击的 pSEO 页面集;或为增长速度超过质量流程的 pSEO 项目建立质量控制规范。


本技能指南的用途

本技能指南涵盖从数据源到质量控制的规模化内容项目。它与 5 项相关技能相辅相成,明确它们之间的区别,才能让每项技能各司其职。

  • content-strategy 面向项目范围:编辑支柱、日历、治理。它负责判断 pSEO 是否适合整个项目。
  • pillar-content-architecture 面向主题中心:围绕一个主题规划 10 到 15 篇有明确目的的编辑内容,具有编辑内容的性质。
  • content-brief-authoring 面向单篇内容:为一篇编辑内容撰写简报。
  • content-and-copy 面向执行:撰写单篇编辑内容。
  • 本技能指南面向规模化场景:基于结构化数据源,以程序化方式生成数百到数十万篇页面,每篇都针对一个长尾查询。

推荐的阅读顺序:content-strategy 判断 pSEO 是否适用,seo-keyword 发掘长尾关键词领域,本技能指南设计 pSEO 系统,editorial-qa(即将推出)提供针对整个页面集抽样开展质量控制的 QA 规范。content-and-copy 和 content-brief-authoring 不适用于规模化 pSEO;这些技能用于编辑内容,而非数据驱动的生成式页面。

适用对象:SEO 内容策略师、内容工程师、运营 pSEO 项目的代理机构,以及正在考虑将 pSEO 作为增长手段的内部团队。语气设定为资深 SEO 策略师对初级 PM 或营销人员。具体、有主见、坦诚。pSEO 的问题不在于其名声,而在于缺乏底层价值的 pSEO。

pSEO 适用的情形

这是关键问题。只有在以下条件全部成立时,pSEO 才有效。

1. 有真实的底层数据。 数据源是真实且结构化的,并且内容丰富:每条记录有 10 个以上字段,最好达到 20 个以上,数据来自第一方、由专家策划,或来自授权数据集。不能只是把抓取的数据或 AI 生成的事实包装成结构化记录。

2. 长尾查询量足以证明投入合理。 该计划要覆盖的查询即使单条流量较小,汇总起来也有可观的搜索量。房地产领域的“{neighborhood} 待售房屋”可以规模化运作。而针对每种形容词与小工具组合生成的“2026 年蓝色小工具评测”则不行,因为人们实际上不会搜索这些查询。

3. 用户意图可以通过查询满足。 用户的问题可以通过恰当呈现的结构化数据来回答,而不需要叙述性解释、判断,或数据无法提供的分析。

4. 更新频率与查询变化速度相匹配。 房源每天更新,数据刷新也与之同步。“[thing] 年度最佳 [year]”页面每年都会过时,因此需要预留预算并制定更新机制。

5. 质量控制在运营上切实可行。 团队有能力抽样审查整套页面、修复问题,并在页面数量增长时维持质量。不能只停留在设想,而要在人员编制中落实预算。

以下情况中,pSEO 不起作用:

  • 底层数据浅薄(只有 3 到 5 个字段,大多由 AI 生成,没有第一方信号)
  • 查询量只是虚幻的(无人实际搜索的长尾关键词)
  • 用户意图需要数据无法提供的叙述或判断
  • 没有为质量控制预留预算(写一堆页面,然后置之不理)
  • 该计划在没有独特数据的情况下,不断扩展由 AI 生成的单薄页面

坦诚地说,大多数询问“我们该做 pSEO 吗?”的团队,都应该听到这样的回答:“大概不该,除非底层数据独特,或者第一方专业知识能让页面真正有用。” 声誉问题不在于这种方法本身,而在于缺乏底层价值却仍然采用这种方法。

详见 references/when-pseo-works-decision.md。


识别数据来源

数据来源就是 pSEO 计划的基础。以下是一些常见的数据来源,其可防御性各不相同。

第一方数据。 客户交易、内容数据库、用户生成内容。由于其他人没有这些数据,因此具有可防御性。例如:Glassdoor 的员工评价、Yelp 的用户评分、TripAdvisor 的旅行者评价。

授权数据集。 行业数据库、监管数据、政府数据集、授权的第三方数据源。其可防御性来自许可条款和集成深度。例如:Zillow 的 MLS 合作关系、房地产经纪数据源、体育统计数据授权。

聚合公开数据。 抓取、清理并丰富的数据。其合法性需要具体判断(通常处于灰色地带,取决于 robots.txt、服务条款和司法管辖区规则)。其可防御性取决于清理和丰富数据所投入的工作。如果清理工作浅显,就很容易被复制。

专家策划的内容。 通过聘请专家填充数据集来构建内容。速度慢、质量高且具有可防御性。例如:Wirecutter 的产品测试、经专家审核的医疗内容、经策划的编辑数据库。

综合数据。 将多个来源组合成独特的视图。例如,将三个数据集组合起来,呈现“社区 × 学校 × 房价”的对比视图。其可防御性来自综合逻辑,以及对多来源数据管道的持续维护。

关于“护城河”的问题:竞争对手能否复制这个数据源?如果能,pSEO 计划就没有可防御性,任何人都能复制。如果不能,数据源就会成为不断积累优势的护城河。Zillow 的 MLS 合作关系、Glassdoor 的员工评价、Crunchbase 的融资数据,都是护城河。“抓取维基百科再用 AI 改写”则不是。

详见 references/data-source-identification-patterns.md。


模板设计

模板是数据填充的结构。设计原则如下。

首屏即呈现答案。 在渲染后页面的前 200 个词内回答用户的具体问题,并同时适合人类阅读和 AI 提取。答案是被引用的内容;其余部分则提供补充细节。

灵活适应信息密度。 模板应能容纳字段稀疏的记录(有些记录有 5 个数据点,另一些有 50 个),且页面不会显得残缺。信息稀疏的页面需要备用模式;信息密集的页面则需要渐进式披露,避免内容过载。

能体现数据的标题层级。 H2 和 H3 对应数据分区(概览、详情、比较、相关内容)。标题结构并非装饰,而是向爬虫和 AI 引擎说明页面涵盖的内容。

将 Schema 标记纳入模板。 嵌入模板的结构化数据(根据技术栈采用 JSON-LD、microdata 或 RDFa)可在整个页面集范围内大规模呈现机器可读信号。如果没有 Schema,页面集就无法被搜索引擎和问答引擎使用的结构化数据提取层识别。

内部链接占位符。 模板应包含相关记录交叉引用、父级类别链接和同级记录链接的链接位。对于内部链接完善的页面集,每页通常有 5 到 15 个内部链接。

每个页面都有独特价值。 每个生成的页面都必须提供用户无法通过返回父级页面或横向浏览同级页面获得的内容。如果页面只是重新组织父级页面的数据,那它就是凑数内容。

模板的质量标准:随机抽取页面集中的一个页面,单独查看时,也应能胜任地回答用户可能提出的问题。如果随机抽取的页面内容单薄,那么整个页面集都内容单薄。

详见 references/template-design-patterns.md。


Schema 设计

驱动模板的数据结构。设计原则如下。

字段数量体现内容深度。 每条记录有 5 个字段,内容单薄;有 15 到 20 个字段,内容合格;有 30 个以上字段,内容深入。字段数量不是虚荣指标;它决定模板能呈现多深入的内容,以及哪些部分会退化为凑数内容。

必填字段与可选字段。 明确哪些字段必须填充才能发布页面;对于可选字段的缺失,模板需要能够优雅降级。30 个可选字段中只填充了 3 个的页面不应发布;填充了 25 个的页面则可以发布。

计算字段。 根据源数据派生而来。例如,根据房源数据计算每平方英尺的平均价格,无需增加源数据即可丰富内容。计算字段相当于 pSEO 中作者补充的分析:数据只需分析一次,所有页面都能受益。

跨记录字段。 引用页面集内其他记录的字段可实现内部链接和比较。每个社区页面上的“最相似的 5 个社区”字段,无需人工整理,就能为同级链接版块提供内容。

更新频率标签。 标明哪些字段是静态的(地理特征、成立日期),哪些字段需要跟踪更新(当前价格、可用情况、当前统计数据)。如果不添加标签,更新就会变成“审查所有内容”,而不是“更新易变字段”。

“Schema 即产品”原则:驱动 pSEO 的 Schema 就是产品界面。应像对待面向客户的应用程序数据库 Schema 一样严格对待它,并做到版本化、经过评审、有文档记录,且能识别破坏性变更。

详见 references/schema-design-patterns.md。


大规模质量控制

逐一审核全部 100,000 个页面并不可行。需要严守质量控制流程。

抽样策略。 每个审核周期随机抽取 50 到 200 个页面,并覆盖不同的数据形态(稀疏、密集、近期、较旧、热门类别、小众类别)。样本不是“最新的 50 个页面”,而是分层抽样,能揭示特定数据形态的问题。

自动化检查。 检查标题结构、架构有效性、内部链接数量、字数阈值、重复内容和失效链接。按固定周期检查每个页面;将失败项列入待处理队列。

人工审核清单。 对抽样页面,检查前 200 个词的答案质量,确认页面能否满足用户的查询,并检查页面读起来是否有特色,而不是像套用模板。人工审核是自动化检查无法覆盖的环节。

失败阈值。 如果抽样页面中有超过 5% 未通过人工审核,就暂停生成新页面,并在进一步扩展前修复模板或数据。这个阈值不容妥协;没有它,质量就会在不知不觉中持续下滑,直到算法更新才暴露问题。

批次追踪。 不同时期生成的页面排名表现是否不同?这表明模板发生了变化或数据质量出现了漂移;应进行调查。批次追踪相当于 pSEO 中实验团队的漂移检测。

团队预算问题。一个包含 10,000 个页面的 pSEO 集合,需要投入约 0.5 到 1.0 个全职员工当量,持续执行质量控制。如果没有为此安排预算,项目就会衰退。上线时整个集合看起来会不错,但在 6 到 12 个月内,随着数据漂移、模板未经质量控制便发布,以及质量控制计划与实际执行周期之间的差距不断扩大,质量就会下降。

详情见 references/quality-control-at-scale.md。


整个集合的内部链接

pSEO 集合需要有意设计内部链接架构,才能形成复利效应。

中心页。 上级页面(例如“丹佛待售房屋”)会链接到所有子页面(具体街区)。中心页从主导航链接进入,是整个集合流量的入口。

同级页面互链。 每个页面链接到 5 到 15 个相关的同级页面:相似街区、相似价格区间、相似特色。同级链接根据架构中的跨记录字段计算得出;大规模情况下不会人工筛选。

反向链接。 子页面向上链接到中心页;同级页面之间双向链接。链接图是双向的;PageRank 双向流动。

锚文本多样化。 避免每个页面都使用相同的锚文本。根据记录特征进行变化(记录名称、描述性短语、上级类别)。大规模统一使用相同锚文本会向排名系统发出操纵信号。

利于抓取的架构。 中心页从主导航链接进入。可以通过中心页或分段站点地图访问子页面。不得有孤立的子页面。

PageRank 流动原则。内部链接是 pSEO 集合形成复利效应的关键。链接良好的集合会将排名信号分配到所有页面;链接不佳的集合则会出现中心页排名靠前、子页面孤立的情况。链接架构是整个项目的一半;另一半是数据。

详情见 references/internal-linking-at-scale.md。


爬取预算管理

搜索引擎有爬取预算。大规模 pSEO 页面集可能会耗尽这些预算。

站点地图分段。 按类别或更新时间拆分站点地图,让爬虫优先抓取活跃页面。与按类别或最后更新时间组织的 10 个、每个包含 10,000 条目的分段站点地图相比,包含 100,000 条目的单个站点地图更难处理。

对内容单薄的页面设置 noindex。 数据不足的页面应设置 noindex,而不是作为诱饵发布。应遵循以下原则:未达到架构必填字段阈值的页面不应获得公开 URL;在数据填充完成前,应将其作为草稿保留在系统中。

规范网址处理。 对比页面(X 与 Y)通常有反向页面(Y 与 X)。应将其中一个设为规范网址。对比页面互为重复内容且未设置规范网址,会分散排名信号。

爬取速率信号。 监控 Google Search Console 的爬取统计数据。如果页面数量不断增长,但爬取速率停滞不前,就说明页面集触及了预算限制。解决方法不是“发布更多页面”,而是“对内容单薄的页面设置 noindex,并改进内部链接,让爬虫优先抓取更优质的页面”。

清理标准。 6 个月或更长时间未能获得点击或展示的页面,应设置 noindex 或返回 410。清理是维护工作,并不代表失败。拥有 100,000 个页面且其中 60% 获得流量的页面集,比相同规模但只有 40% 获得流量、其余 60% 都是浪费爬取预算的无效页面的页面集更健康。

详见 references/crawl-budget-management.md。


面向程序化页面的 AEO 和 GEO

答案引擎对待程序化页面的方式与编辑内容页面不同。

直接答案提取。 AI 引擎会提取前 200 个词中的答案;开篇直接给出答案的模板更容易被引用。页面开头是被引用的候选内容;其余部分则提供深入的补充信息。

结构化数据信号。 AI 引擎会将包含全面架构标记的 JSON-LD 视为大规模权威性信号。即使底层数据相似,架构标记较少的程序化页面也不如架构标记深入的程序化页面。

引用模式。 对于事实类查询(价格、统计数据、对比、事实详情),AI 引擎倾向于引用程序化数据页面;对于分析类查询(为什么、如何、我应该怎么看),则倾向于引用编辑内容页面。设计模板时应适应事实类查询场景;不要试图让程序化页面与编辑内容争夺由后者主导的分析类查询。

对质量打击的敏感度。 除搜索引擎外,AI 引擎也有自己的质量信号。与传统搜索相比,内容单薄的程序化内容在 AI 界面中更快被降权。pSEO 的惩罚风险已转移到 AI 界面;同样需要坚持规模化质量管理,但容忍度更低。

“面向双引擎优化”的思路同样适用。pSEO 页面应同时服务于搜索引擎和答案引擎。大多数 pSEO 项目设计时尚未考虑 AEO,因此需要更新模板以适应新的展示环境:强化前 200 个词中的答案、深化架构标记,并在页面包含 FAQ 结构时添加 FAQPage 架构。

详见 references/aeo-geo-for-programmatic-pages.md。


大规模刷新与维护

如果不维护,pSEO 页面集就会逐渐失效。

数据刷新频率。 大多数数据集至少每季度刷新一次。对于时效性数据(房地产挂牌信息、价格、可用情况、最新统计数据),则需每日或每周刷新。项目启动时就应设定刷新频率;事后再补上会很昂贵。

模板版本迁移。 模板改进后,所有现有页面都需要迁移。分批次迁移并进行监控,优于一次性全面迁移。每批页面采用新模板,在监控下运行 30 天,然后再迁移下一批。

裁剪生命周期。 对生成时间超过 2 年且未获得流量的页面,应评估是否设置为 noindex 或移除。24 个月是标准的裁剪节点;某些类别可能需要更早或更晚裁剪。

页面集整体刷新。 随着用户预期演变、AI 引擎信号变化或类别惯例改变,有时整个页面集的模板都需要刷新。页面集整体刷新是为期 6 个月的项目,不是周末就能完成的清理工作。

详见 references/refresh-at-scale.md。


常见失败模式

快速列举。诊断详见 references/common-pseo-failures.md。

  • “我们生成了 50,000 个页面,结果受到处罚。”内容单薄、扩张过快、缺乏质量控制规范。
  • “我们有 10,000 个页面,但只有 200 个能获得排名。”缺少内链架构;子页面成了孤岛。
  • “抓取率停滞不前。”抓取预算已耗尽;将内容单薄的页面设为 noindex,并改进站点地图分段。
  • “页面看起来都一样。”模板缺乏变量密度;数据过于稀疏,无法体现差异。
  • “我们无法在不手动修复 10,000 处的情况下更新模板。”模板版本管理的设计没有考虑规模化。
  • “谁有空谁就负责质量控制。”缺少抽样规范、阈值和负责人。
  • “AI 引擎不会引用我们的页面。”页面顶部的 200 个词没有经过专门设计;结构化数据也不充分。
  • “我们的页面已经达到 100,000 个,互动却在下降。”页面集的规模已超出数据深度所能支撑的范围。
  • “竞争对手复制了我们的页面。”数据源不构成壁垒。
  • “刷新工作让人不堪重负。”刷新频率的设计没有考虑规模化;模板也不便于迁移。
  • “我们的 pSEO 带来了流量,却没有转化。”查询意图与买家意图不匹配;应重新考虑 pSEO 是否适合该项目目标。

框架:程序化 SEO 的 12 项考量

设计或审查程序化 SEO 项目时,请逐一检查以下 12 项考量。

  1. 是否适合该项目。 pSEO 需要真实的底层数据、可查询的意图,以及用于质量控制的预算。缺少任何一项时,默认选择不做。
  2. 以数据源构筑壁垒。 可复制的数据不构成防御力;第一方、授权、专家整理或综合生成的数据才可以。
  3. 模式深度。 每条记录至少包含 15 个字段;若要达到有竞争力的深度,则需 30 个以上。
  4. 模板变量密度。 能够妥善处理稀疏和密集的记录。
  5. 首屏答案。 前 200 个词就回答用户的具体查询。
  6. 规模化应用模式标记。 每个页面都使用结构化数据;这是 AEO/GEO 信号。
  7. 内链架构。 采用中心辐射式结构并链接同级页面,不留孤岛。
  8. 质量控制抽样。 每次审查 50 到 200 个页面,并按数据形态均衡抽样。
  9. 失败阈值。 抽样失败率达到 5% 时,应暂停生成,直到发布模板或数据修复。
  10. 抓取预算规范。 对站点地图分段,对内容单薄的页面设置 noindex,对重复页面进行规范化处理。
  11. 刷新频率。 至少每季度刷新一次数据;模板按批次迁移。
  12. 裁剪生命周期。 在 12 到 24 个月内未能获得流量的页面,应设置为 noindex 或移除。

该框架的产出是一份 pSEO 设计文档,团队可在每个阶段参考:明确数据源、为模式进行版本管理、指定模板、规划质量控制预算、绘制内链架构,并设定刷新频率。


所需数据不可用时

此技能的输出依赖于它无法自行生成的数据、测量结果或工具结果。当所需输入、工具或数据源不可用或无法核实时,合规的输出应是交付成果,并说明缺口:需要什么、实际获取或核实了什么,以及输出的哪些部分受到影响。绝不能为了完成交付成果而捏造、估算或插值出所需数字。说明缺口本身就是完整的答案。


参考文件


结语:要么大规模保持质量,要么干脆不做

唯一能够持久发展的 pSEO 项目,是那些能够在规模扩大的同时保持质量的项目。为了数量而牺牲质量的诱惑,正是 pSEO 背负恶名的根源。抵制这种诱惑、保持真实的数据深度、严格的质量控制和规范的更新机制的网站,能够多年持续获得有意义的流量。而做不到这些的网站,会在算法更新后的几个月内受到惩罚。

这套规范不可妥协,也不是免费的。在生成第一个页面之前就为其编列预算,否则就不要开始。

如果不确定 pSEO 项目是否已准备就绪,不妨问问:数据源是否确实独特?架构是否足够深入?模板是否将答案放在最前面?内部链接结构是否已规划?是否已按人员规模为 QC 编列预算?更新频率是否已确定?如果这些问题的答案全是“是”,就提交设计文档,开始工程工作。如果其中任何一项的答案是“否”,就先弥补缺口,再生成任何页面。

评论

支持 Markdown