如果你在问“谷歌 SEO 前 90 天到底怎么排优先级”，最实用的答案不是“先发内容”或“先做外链”，而是按阶段推进：前 30 天先确认重要页面具备被 Google 发现、抓取、渲染和索引的资格；中间 30 天发布最小可用的话题集群；最后 30 天用 Search Console 复盘曝光、点击、CTR 和转化，再决定扩张还是收缩。
Google 的 SEO 入门指南和 Search Essentials仍然是第一性原则。对于 AI Overviews 和 AI Mode，Google 在 AI features and your website 里明确表示：现有 SEO 基础仍然适用，没有额外技术门槛。
直接答案：三个 30 天各自应该做什么
第一个 30 天解决“有没有资格进搜索”；第二个 30 天解决“页面分工和内链是否合理”；第三个 30 天解决“已经获得的可见度有没有变成点击和下一步动作”。
只要网站还卡在发现、抓取、渲染或索引层，就不要把重心提前切到“多写几篇”“加大外链”或“频繁改标题”。
第 0 天：先把执行范围锁定
正式开始前，先定好五件事：
| 决策 | 需要锁定什么 | 为什么要先定 |
|---|---|---|
| 首选站点版本 | 最终 canonical 域名与协议 | 避免把两个版本混在一起统计 |
| Search Console 范围 | 用哪个 property 做验证 | 保证索引与效果数据口径一致 |
| URL 样本 | 首页、产品页、英中文章对、Wiki 页、一个排除页 | 避免只检查首页 |
| 转化动作 | 审计启动、Demo、工具使用、下载等真实下一步 | 把流量和业务结果分开 |
| 基线窗口 | 通常是最近 28 个完整日 | 后续对比才有可解释性 |
同时准备一张执行表，至少记录 URL、失败层级、证据、负责人、修复动作和验证日期。没有 URL 和证据的“建议”，不要直接排进执行队列。
谷歌 SEO 30／60／90 天执行表
| 时间窗 | 核心目标 | 必做动作 | 验证方式 | 常见失败模式 |
|---|---|---|---|---|
| 第 1-30 天 | 建立搜索资格 | 验证站点、提交规范 Sitemap、抽查 URL 检查、修复状态码/robots/canonical/渲染问题、整理现有页面意图 | 重要模板返回正确状态，Google 能抓取页面，索引阻断已记录或修复 | 还没证明页面能被处理，就先改标题和加内容 |
| 第 31-60 天 | 发布并连接话题集群 | 上线一篇支柱页、两到三篇单一问题子页、优化首屏答案、加可抓取内链、抽查移动端模板 | 新 URL 可抓取、有内链、在 Sitemap 中、语言版本路由正确 | 一次发太多重叠页面，彼此内链又弱 |
| 第 61-90 天 | 衡量结果、获得外部证据、迭代 | 在 Search Console 比较时间窗、更新高曝光低 CTR 页面、发布一个可引用资产、记录有效动作和无效动作 | 查询、页面、设备、语言维度都有记录，且能对应到改动批次 | 看一张排名截图就宣布成功或失败 |
第 1-30 天：先让页面具备进入 Google 的资格
Google 说明大多数页面会被自动发现，但“被发现”不等于“适合索引”，更不等于“能稳定获得曝光”。第一阶段的任务，是确认重要页面具备被发现、抓取、渲染和纳入索引评估的基本条件。
这 30 天要做什么
- 完成 Search Console 验证，并提交规范 Sitemap。
- 用 URL 检查工具抽查代表性 URL。
- 查看 网页索引报告，区分“预期排除”与“真实问题”。
- 按 Google 的链接最佳实践检查重要内链是否为真实
<a href>。 - 对至少一个依赖 JavaScript 的页面，比对原始 HTML、渲染后 DOM 和 Google 视图，参考 JavaScript SEO 基础。
- 给现有 URL 做意图分工：保留、合并、重定向或 noindex。
这阶段怎么验收
- 最终 URL 返回预期状态码。
- 不该被挡住的页面没有被 robots 规则阻止。
- canonical、内链、重定向目标和 Sitemap 指向同一个首选 URL。
- 关键标题、正文、canonical 和链接不依赖一个容易失败的客户端请求。
这阶段最容易犯的错
- 没先判断页面本来该不该索引，就把所有排除状态都当成问题。
- 模板级问题还没修完，就对每个 URL 单独请求收录。
- 基础模板还存在状态码或 canonical 冲突，就开始大规模扩写内容。
适合怎么用 Fennec
先用 Fennec SEO Audit 找候选问题，再用 Robots.txt 检查工具、Canonical 检查工具、Sitemap 检查工具和 Bot Simulator逐项验证。工具输出只是线索，不应直接当结论。
第 31-60 天：发布最小可用的话题集群
第二阶段不是“开始海量发文”，而是建立最小可用页面组：一篇支柱页，外加两到三篇各自解决独立问题的子页面。目标是覆盖不同搜索任务，而不是让多个页面争同一个大词。
如果你需要完整工作流，可以先看 Google SEO 指南。首批子页面通常可以是：Google SEO Audit 清单、Google 关键词研究指南和 Google 收录故障排查。
这 30 天要做什么
- 上线负责总流程的支柱页。
- 上线每篇只解决一个问题的子文章。
- 优化 title、H1 和首屏答案，让用户在前 100-150 字知道页面解决什么。
- 在支柱页、子文章、产品页和 Wiki 之间添加描述性内链。
- 抽查一篇移动端文章页和一个产品页的布局、渲染和导航可用性。
- 保持英中版本事实、日期、限制一致，但中文稿按“谷歌 SEO”搜索意图自然重写。
这阶段怎么验收
- 每个新页面至少从一个可抓取页面获得真实内链，并出现在 Sitemap。
- 英文和中文页面具备 reciprocal translations、自引用 canonical、
hreflang="en"、hreflang="zh"与英文x-default。 - 首屏直接回答页面任务，不用一大段背景介绍拖延答案。
- 产品页继续负责工具和转化，Wiki 继续负责定义，子文章继续聚焦单一问题。
这阶段最容易犯的错
- 支柱页和子页面都想覆盖同一个宽泛主词，最后互相蚕食。
- 把英文稿逐句翻成中文，结果没有回答中文用户真实执行问题。
- 内链依赖按钮或脚本跳转，而不是稳定、可抓取的链接。
适合怎么用 Fennec
用 链接检查工具确认新页面不是孤岛，再把 GSC Management 页面作为发布后的运营承接点，专门处理查询、收录和页面表现跟踪。
第 61-90 天：用数据复盘，并补上可引用证据
第三阶段的重点不是“继续加量”，而是把已经获得的早期可见度转成更可靠的判断。Search Console 效果报告提供 clicks、impressions、average CTR 和 average position，应把这些指标当成运营信号，而不是单点因果证明。
Google 也说明，AI 搜索功能带来的流量仍计入 Search Console 的 Web 搜索表现，因此没必要另外发明一套与现有 SEO 完全割裂的“AI 排名面板”。
这 30 天要做什么
- 在 Search Console 比较两个相同口径的时间窗，通常是完整 28 天对完整 28 天。
- 先按页面和查询拆开看，再决定是否改标题或重写首屏。
- 对已有曝光但 CTR 偏弱的页面做针对性更新。
- 发布一个值得被引用的资产、数据集、工作表或决策模型。
- 记录哪些 URL 开始拿到曝光，哪些仍未收录，哪些页面开始重叠同一查询。
- 每次重要修改都写明日期、URL 和预期结果。
这阶段怎么验收
- 新增曝光落在正确语言页面上。
- CTR 问题在查询层级排查，而不是只看站点平均值。
- 转化或下一步使用与流量分开衡量。
- 第 60 天之后的修改能追溯到具体页面、模板或查询组，而不是模糊的“做了一波 SEO”。
这阶段最容易犯的错
- 在低量窗口里因为没有可见点击，就宣布页面失败。
- 只看 average position 就决定重写整页。
- 把一次请求收录当成恢复已经完成的证明。
适合怎么用 Fennec
用 Google SEO 指南保持完整诊断顺序，用 SEO Audit 清单保证证据结构一致；如果团队需要持续盯查询、收录和页面级复盘，可以交给 GSC Management承接。
一份示例执行日志
下面这张表使用的是示例数据，不是生产站点的真实监测结果。
| 日期 | URL | 观察到的问题 | 证据类型 | 动作 | 验证日期 |
|---|---|---|---|---|---|
| Day 7 | /blog/example-guide/ | 已抓取但未索引 | URL 检查 + 网页索引报告 | 对比 canonical、Sitemap 与内链 | Day 14 |
| Day 18 | /product/example/ | 首图文案未出现在渲染后 HTML | 原始 HTML 对比渲染 DOM | 把关键文案前移到服务端输出 | Day 25 |
| Day 43 | /zh/blog/example-guide/ | 曝光上涨但 CTR 偏弱 | Search Console 查询报告 | 重写 title 和首屏答案 | Day 57 |
| Day 72 | /blog/example-guide/ | 两个页面开始承接同一查询 | Search Console 页面对比 | 明确页面角色，必要时合并 | Day 90 |
这张日志的价值不是预测结果，而是防止团队忘记：改了什么、为什么改、准备用什么证据验收。
性能应该放在什么位置
Core Web Vitals 仍然重要，因为它们衡量加载、交互和视觉稳定性。web.dev 把 Web Vitals 定义为帮助站点衡量用户体验质量的一组统一信号。它们值得持续优化，但在前 90 天里，不应让一个边际性能项目抢在硬性索引阻断之前。
前 90 天最实用的判断规则
如果只记住一句话，就记住这句：
先修最早失败的层级，再发布覆盖不同意图的最小页面组，最后用同一测量窗口比较结果。
这条规则能同时避免两种常见失误：Google 还没稳定处理页面，就已经扩写了太多内容；以及证据窗口还不成熟，就先对排名成败下结论。
问答
90 天足够判断谷歌 SEO 成败吗？
90 天足够建立技术资格、上线一组聚焦页面并看到早期曝光与点击信号，但不足以保证竞争性关键词排名或流量恢复一定发生。
新站前 30 天要先做外链吗？
如果页面还存在发现、抓取、渲染或索引阻断，就不应该先把重点放在外链上。先修复最早失败的层级。
曝光上涨但点击没涨，下一步看什么？
先检查查询与页面是否匹配、标题和首屏答案是否准确、摘要是否兑现承诺，以及英文页和中文页是否路由到了正确受众。
