90 天不是「等三个月见效」，而是一段有明确节点的施工：前 30 天打地基，中间 30 天生产页面，后 30 天复测与归因。 三段各有交付物，也各有会卡住的地方。
把 90 天当成「三个月后看结果」，几乎一定会失败——因为第 1 个月没拍下基线， 第 3 个月就没有任何东西可以证明变化。反过来，按节点推进的项目，到第 60 天就能看出方向对不对。
下面给的是我们实际执行的排期。它不保证你的项目一定成功，但能保证你在任何一周都知道「现在该干什么、谁在拖」。
一、三个三十天，各干一件事
很多人把 GEO 想成「持续写文章」，于是从第一天就开始写。这是最常见的时间浪费—— 在口径没统一、结构没修的情况下写出来的页面，三个月后大概率要重写。
正确的顺序是：先把「AI 会读到的错误信息」清理干净，再批量生产正确信息，最后用固定口径验证。三段的分工如下：
| 阶段 | 周次 | 核心任务 | 交付物 | 过关标准 |
|---|---|---|---|---|
| 打地基 | W1–W4 | 统一口径、拍基线、修技术结构 | 口径手册、240 条基线记录、结构诊断报告 | 10 个问句能查到；3 个关键数字有出处；首页能被纯文本读取 |
| 生产 | W5–W10 | 事实页、问答页、证据页、参数表 | 17–20 个页面、一张参数总表、站内互链 | 每个页面能回答一个具体问法，而不是介绍一家公司 |
| 验证 | W11–W13 | 两次复测、差异归因、定下一批 | 复测记录、差异清单、下季度排期 | 能说清哪几条变了、为什么变、下个月改什么 |
这三段的长度不是平均分配的。真正决定成败的是第一段——它只占三分之一时间，却决定了后面三分之二有没有意义。
二、前 10 天：三件事不做完，后面全是返工
项目启动后的前 10 天只做三件事，都不产出「内容」，但缺一件后面就要返工：
第一件：老板口径访谈，90 分钟。不是问愿景，是问「哪些数字你敢对外说、哪些绝对不能说」。 典型产出是一张两列表：可以说（设备台数、幅面、交期区间、认证编号）／不能说（客户名单、良率、单价、产能利用率）。 这张表决定后面所有页面的边界。没有它，写稿的人会反复回来问，或者干脆编。
第二件：基线采样，一次拍完。10 个问句 ×8 个平台 ×3 次 = 240 条记录，全部截图存档。 这是整个项目里唯一一次能拍到「改之前」的机会，做完就永远没有了。 具体问句怎么设计、记录表怎么填，见《怎么知道自己公司在 AI 里被怎么说》。
第三件：技术结构诊断，2 小时。只看四件事：模板能不能改、正文是不是图片或 PDF、 有没有服务端渲染（决定了 AI 抓取时能不能读到内容）、结构化数据现状。 这四项里任何一项不过关，内容做得再好也传不出去。
第 8 周再补拍，你拍到的是「已经改了一半」的状态，无法与最终结果对比。 很多项目最后说不清效果，不是方法无效，而是从来没拍过一张干净的「之前」。
三、D1–D30 打地基：口径、基线、结构
| 周次 | 动作 | 谁做 | 产出 |
|---|---|---|---|
| W1 | 启动会 + 老板口径访谈 90 分钟 | 老板 + 项目负责人 | 可说／不可说清单 |
| W1–W2 | 技术口述：料、机、法、测、界五问 | 生产或技术负责人 | 40–60 条事实底稿 |
| W2 | 基线采样 240 条 | 运营（一人固定完成） | 带时间的截图档案 |
| W3 | 技术结构诊断 + 改造清单 | 建站方或技术 | 四页诊断报告 |
| W4 | 上线第一批：首页三句、口径对照页、Organization 结构化数据 | 技术 + 内容 | 3 个页面 + 1 段 JSON-LD |
第一段里最容易被跳过的是 W2 的口述。很多企业觉得「我们的情况写不出来」，实际上一小时口述能出 25–30 条事实， 关键是问对问题（料从哪来、机器什么型号、工艺怎么定、怎么检测、做到多少为止）。 方法见《企业知识库怎么建，要多少内容》。
W4 的三样东西看着少，但它们的作用是「定调」：首页三句话决定了 AI 怎么归类你， 口径对照页决定了信息冲突时以谁为准，结构化数据决定了实体能不能被正确识别。 这三样没做，W5 之后写的页面就是在流沙上盖楼。
四、D31–D60 生产：十七个页面怎么排
生产段的排法只有一条原则：先写「客户会问的」，再写「你想说的」。按这个原则，六个周排出十七个页面：
| 周次 | 页面类型 | 数量 | 内容要点 |
|---|---|---|---|
| W5–W6 | 事实页 | 5 | 能力范围、设备清单、工艺路线、能力边界、交付流程 |
| W7–W8 | 问答页 | 12 | 从客户真实问法倒推，一问一页，标题就是问句 |
| W9 | 参数表 + 证据页 | 3–4 | 把图片和 PDF 里的参数转成真表格；案例、检测、认证 |
| W10 | 互链 + 补漏 | — | 每页三条相关链接；补上 W11 复测前发现的知识空洞 |
这里有个产能现实：一个人兼职做，每周稳定产出 2–3 页已经是上限（单页真实成本约 4 小时）。 所以十七个页面排六周是紧的，如果没有专职人手，正确做法是砍到 10 页、拉长到 9 周，而不是每周硬塞 5 页。 排期方法见《没人手怎么排内容计划》。
参数表那一步值得单独说。制造业网站最常见的浪费，是把设备参数做成图片或 PDF—— 人能看到，AI 读不到。把它改成真正的 HTML 表格，工作量约每页 2–3 小时， 但对「能不能被引用」的影响比再写五篇文章都大。写法见《产品页要不要改成参数表》。
五、D61–D90 验证：复测、归因、改下一批
最后 30 天不是「等结果」，而是项目里信息密度最高的 30 天：
W11，第一次复测。条件必须与 W2 完全一致：同样的 10 个问句、同样的平台、每条问 3 次、 同一个人操作。任何一项变了，两次数据就不可比。这时候通常能看到 2–4 个问句出现变化， 大部分是「从查不到变成查得到」，少部分是「从说错变成说对」。
W12，差异归因。把复测里所有「AI 说错」的条目逐条回溯：这句话可能来自哪个页面、 哪篇旧稿、哪个平台词条。这一步最容易被跳过，但它的复利最高—— 每修掉一个源头，同类错误在所有平台上一起消失。这也是 GEO 与投放在方法上的根本差别： 投放是买流量，GEO 是修信息。
W13，第二次复测 + 90 天报告。报告只写四页：基线是什么、现在是什么、哪几条变了、 下个季度改哪三条。不要写成「成果汇报」，要写成「差异说明书」—— 前者没人信，后者能直接指导下一轮。
六、三个最容易崩的节点
| 崩点 | 典型表现 | 后果 | 预防动作 |
|---|---|---|---|
| 第 3 周技术不出人 | 结构诊断约不上，模板改不了，「等排期」 | 内容上线了但抓不到，等于白做 | 启动会就把技术排期写进项目表，W3 定为硬节点 |
| 第 6 周产能掉 | 前两周写了 6 页，第三周开始拖，老板问「怎么没动静」 | 项目被暂停，前面投入沉没 | 排期按 2–3 页／周定，不按 5 页；把「已上线页数」作为周报唯一指标 |
| 第 9 周没人复测 | 「最近忙，下个月再测」 | 没有对照数据，钱花完说不清效果 | W2 就把 W11、W13 两个复测日写进日历，指定固定的人 |
三个崩点有一个共同点：都不是方法问题，是「没人对这个节点负责」。 所以 90 天流程真正的核心不是排期表，是每个节点后面写一个名字。
七、第 90 天该拿到哪五样东西
判断一个 GEO 项目有没有真的做完，不看发了多少篇文章，看有没有这五样可交接的东西：
口径手册：公司全称、成立年份、人数、产能、认证、服务范围，每项一个数字加一个出处。
事实底稿：40–60 条结构化事实，后续所有页面从这里派生，避免一事实多版本。
两份采样记录：W2 的基线、W13 的复测，条件一致，可被第三方复核。
改造执行记录：改了哪些页面、改了什么、谁改的、什么时候上线。
下季度排期：写清接下来三个月写哪 10 个问句，而不是「继续优化」。
这五样东西的价值在于：换一家服务商、换一个运营，项目能接着跑。 拿不到这五样，说明项目实际上是「外包了一段内容生产」，不是「建立了能力」。
八、90 天不该期待的三件事
把预期写清楚，比把排期写清楚更重要。90 天里，这三件事基本不会发生：
一、不会有「排名」。AI 不给排名，它给的是一段话和几个引用来源。 你要看的是「有没有被提到、说得对不对」，不是「第几名」。任何承诺排名的说法都不成立。
二、询盘不会翻倍。90 天够让 AI 正确理解你，不够让大量客户形成「先问 AI」的习惯并找到你。 多数企业的第一个可观察变化出现在第 3 个月末，而且是质量变化而不是数量变化。 详见《做完 GEO 之后询盘质量有没有变化》。
三、不会所有平台一起动。不同平台的知识更新节奏差别很大， 90 天内通常是 2–3 个平台先出现变化，其余滞后。只看一个平台就下结论，容易误判。
这三条预期如果提前对齐，第 60 天的「怎么没动静」就不会变成停项理由。 反过来说，如果服务商在第 30 天就报告「大幅提升」，你先要问的是：基线是什么时候拍的、条件是否一致。 验证方法见《效果怎么验证，数据谁说了算》。
常见问题
本文由上海育贤信息科技内容团队撰写。排期为我们在长三角制造业客户中的实际执行节奏， 不同品类、不同技术条件下会有出入，请按自身产能调整，不要把周次当成硬指标。
利益相关声明 我们承接 GEO 与官网改造项目，本文描述的流程即我们的工作方式， 建议对我们有利。但排期表、交付清单与三个卡点均可自行套用，不依赖我们。
更新 2026-11-07
