GEO新人接手项目，团队协作文档要覆盖哪些内容

新人接手时，先把项目全貌写明白

开头要交代服务对象、业务主题、重点页面、主要查询场景，以及当前工作处在规划、发布、观察还是调整阶段。这里写的是项目边界，不是口号，例如“围绕AI搜索中的产品选购问题，维护知识页、服务页和案例页”，新人才能知道哪些任务属于当前范围。

还应放一张任务总表，记录页面名称、页面地址、内容负责人、技术负责人、最近修改日期、当前状态和下一步。页面地址可以使用站内路径，不要把它写成无法追溯的“某篇文章”。如果任务暂停，也要写暂停原因和恢复条件，避免交接后重复劳动。

内容文档不能只写选题和关键词

每个主题都应有一张内容卡，包含用户问题、直接结论、适用条件、例外情况、相关实体、同义问法和不应延伸的范围。比如“结构化数据能做什么”与“结构化数据能带来什么效果”不是同一个问题，前者可以引用技术定义，后者需要通过自家数据验证，不能在文档里混成一句话。

内容卡还要注明事实、团队建议和待验证假设。事实旁边写对应页面、标准或文档名称；建议写执行人和完成方式；假设则写观察指标。这样编辑改文案时不会把经验判断改成确定事实，技术人员也能快速定位需要补充的依据。

页面能不能被访问和抓取，要单独留档

技术页建议记录HTTP响应状态、robots.txt相关规则、站点地图收录情况、规范链接、页面是否需要登录，以及移动端和主要浏览器的访问结果。根据Google Search Central《搜索抓取与索引指南》，抓取与索引涉及页面可访问性、允许抓取的规则和页面内容状态，这些内容应由技术人员按实际结果填写。

不要把“已提交站点地图”写成“已经被搜索引擎收录”，也不要把爬虫访问当成AI回答引用。团队可以在日志表中分开记录爬虫访问、页面进入自然搜索结果、答案中出现页面、AI引荐点击和后续业务动作；每一类信号的含义不同，不能互相替代。

结构化数据和实体信息要保持一套说法

结构化数据文档应写明页面采用的Schema.org类型、实际填写的属性、页面可见内容与标记内容是否一致，以及代码部署在哪个模板。Schema.org的类型与属性定义只能说明数据如何表达，不能据此推导AI引用、收录或转化结果。

实体表应统一名称、别名、产品类别、服务范围、所属组织、关联页面和引用来源。品牌名、产品名和业务术语一旦在标题、正文、面包屑、结构化数据中出现不同写法，就可能增加后续维护难度。遇到同名实体，文档要补充地区、品类或服务边界，避免团队成员各自理解。

引用来源要让编辑和技术都能接着用

来源表不要只放一串链接，而要写来源名称、具体页面或标准名称、支持的事实、适用范围和最近阅读日期。政府平台、标准组织、搜索引擎文档、检测机构报告等，可分别支撑法规标准、技术机制或检测结果；个人经验和团队观点应明确标成建议，不要伪装成外部事实。

一条来源只支撑相邻的一类事实。比如Google Search Central的抓取文档可以支持抓取规则和索引基础概念，Schema.org页面可以支持类型与属性定义，二者都不能支撑成本、周期、流量或订单判断。若来源页面发生变化，负责人应在版本记录里写明受影响的段落和处理结果。

查询测试和版本记录，决定交接是否顺畅

查询测试表至少包含测试日期、查询原句、使用的平台或搜索入口、看到的回答摘要、是否出现目标实体、引用页面、用户是否点击、落地页和后续业务状态。答案出现不等于用户点击，点击也不等于订单；如果要判断GEO效果，主转化事件只能选一个，例如有效表单或成交订单，并按实际销售周期设定归因窗口。

版本记录要写旧内容、新内容、修改原因、修改人、发布人、发布时间和观察安排。新人接手后，可以沿着“页面变化—抓取日志—查询结果—引荐点击—业务记录”这条链回看。若没有足够数据，结论应写成“待用自家数据验证”，不要填写行业平均周期、固定单量或固定成本。

交接当天可以按这几步走

1. 打开项目总表，标出正在编辑、已发布、暂停和待处理的页面，再与实际站点逐项比对。
2. 抽取一个重点页面，查看访问状态、页面正文、规范链接、站点地图位置和结构化数据，记录发现时间与页面版本。
3. 从内容卡中挑一组真实用户问法，重复查询并记录答案、引用页面、点击情况和异常表现，不把一次结果写成长期结论。
4. 沿来源表阅读支撑事实的具体材料，补齐来源用途、适用边界和阅读日期；无法支持的句子改成假设或行动建议。
5. 把交接后的负责人、截止时间、观察指标和下一次复盘日期写进任务表，后续只按记录更新，避免多人同时改同一处。

这套清单的价值不在于表格数量，而在于每个结论都能找到上下文，每次修改都能说明原因，每个效果判断都有对应数据入口。对于新人来说，能复现一次页面检查和查询记录，比读一堆没有日期的会议纪要更有用。