用 Gemini Deep Research 做技术 SEO 审计：3 步搭出可落地的排查清单
目录
几个月前，我给一家出版类网站做技术 SEO 审计。它过去 6 个月里悄悄掉了 40% 的自然流量。接手之前的代理商给了客户一份 60 页的 PDF——里面大部分是 Screaming Frog（爬虫工具）导出的截图，再加 12 页"缺 alt 标签"那种注水内容。客户付了 14,000 美元，到头来还是不知道真正坏在哪。
我用 Gemini Deep Research 跑了一遍同样的网站，配一个 prompt（提示词）。8 分钟后，它直接命中了真凶：开发团队 3 月份上线了一处全站级的 canonical（规范化链接）调整，把所有分页归档页都指向了它们自己。Google 在接下来几周里悄悄地把 3,200 个 URL 从索引里拿掉了。这个问题在 Screaming Frog 爬虫里完全没标红——因为这些 URL 还都在返回 200。
就是从那一刻起，我不再把 Gemini Deep Research 当成"研究摘要工具"，而是每次做技术审计的第一道工序。下面是我实际跑的工作流，附 prompt 模板、还有我踩过的坑。
为什么是 Gemini（不是 ChatGPT、也不是 Perplexity）
这三家 Deep Research 工具我按场景轮换用。但技术 SEO 审计这个具体活，Gemini 赢在三个点——而且这三点能在产出里看出来：
上下文窗口比你想的更重要。 一份真正像样的技术 SEO 审计要吃进：5 万+ 行爬虫记录、页面级 schema 标记（结构化数据）、内链图、重定向地图、日志文件样本、还有竞品的 HTML header。这种输入跑到一半就会撑爆 ChatGPT Deep Research 的工作记忆。Gemini 的 1M+ token 窗口能把一个 18 万行的爬虫导出文件一口吞下去。我直接把这个文件作为附件粘贴进去，它一行一行地读。
多步浏览能抓跨站模式。 一份合格的技术审计不只是看自己网站——它要拿你的设置和目标关键词排名靠前的竞品做对比：它们都上了 HTTP/2 还是 HTTP/3？分类页都用了同一种 schema 吗？ChatGPT Deep Research 这块做得还行；Perplexity 更快但更浅。Gemini 的浏览循环是那种"稳定地跳第二跳、第三跳"的那种——打开竞品页面、读源码、点进他们的 sitemap、再跳到 CDN 配置。
引用是贴着结论的。 当 Gemini 说"目标关键词的前 10 名结果里，85% 用了面包屑 schema"，你可以点引用去看出处。数字有大约 8% 的概率是错的（下面细说），但链接永远在。这就是我能不能把报告直接交给客户的关键——能交，和必须一行一行重新核实，是两个不同的事。
成本那点也值得说。Gemini Deep Research 包含在 Google AI Pro 套餐里，$20/月，附带相当宽松的日查询额度。ChatGPT 对应的能力一个月跑超过 10 次审计就要升 $200/月 的 Pro 套餐。对独立顾问和小团队，这不是小差别。
3 步工作流
我把每次技术 SEO 审计拆成三个串行的 Deep Research 任务。试图一个 prompt 搞定一切，是最常见的错误——你只会得到一份通用的 SEO 清单，跟你实际网站没什么关系。
第 1 步：分诊明显问题（5 分钟）
在 Gemini 能干任何有用的事之前，你需要把网站的原始数据喂给它。拉一份 Screaming Frog（或者 Sitebulb，看你用啥）的爬虫导出，覆盖 5,000–10,000 个 URL，外加 robots.txt、sitemap.xml、再加 50 个不同模板类型（首页、分类页、产品/文章页、分页页）的页面源码样本。全部一次性附在一个消息里。
Prompt 模板：
你正在为 [域名] 做技术 SEO 审计，这是一个 [网站类型] 领域的 [细分赛道] 站点。附件包含：完整爬虫导出（CSV）、robots.txt、sitemap.xml，以及 50 个覆盖首页、分类页、产品/文章页、分页模板的页面源码样本。
- 识别任何会阻碍或严重限制收录的阻塞性问题：robots.txt 规则、noindex 标签、canonical 错误、重定向链、软 404 模式、分页处理错误、孤立 URL、以及分页与 canonical 的冲突。请具体说明——指出 URL 模式、问题、从爬虫数据里看到的影响 URL 数。
- 识别任何看起来异常的全站级模式：全站 canonical 指向单一 URL、所有页面返回相同的 title 标签、整批模板都缺结构化数据、重定向循环、hreflang 冲突。
- 对每个问题，引用附件数据中能证明该问题的具体行或 URL。不要从 SEO 最佳实践泛泛而谈——只标数据里看到的问题。
- 按预估流量影响从高到低排序。把任何可能解释近期流量下降的项单独标出。
最后这条指令是"把通用审计变成一份分诊文档"的关键。模型仍然会把低影响的问题排得偏高，但这个结构逼着它去排优先级。
"不要从 SEO 最佳实践泛泛而谈"这句是命门。少了它，Gemini 会花半份报告跟你说"你应该加结构化数据"——而你真正的问题是 40% 的产品 URL 走了重定向链。你花钱买的不是教科书，是诊断。
第 2 步：和排名靠前的竞品做对比（15–20 分钟）
站点自身的问题挖完，第二轮就要往外看了。挑 5–8 个在目标搜索词下稳定出现在前 10 名的竞品。别只挑直接竞品——挑 Google 实际在奖励的那些，哪怕是不同商业模式。
Prompt 模板：
我从附件里已经识别了 [你的域名] 的技术问题。现在请把 [你的域名] 的技术设置和下列目标搜索词的前列竞品做对比：
目标词列表：[列出 10–20 个搜索词]
请分析的竞品：[列出 5–8 个域名]
对每个竞品，记录：
- 站点架构——URL 结构、分类层级深度、子域 vs. 子目录的使用
- 页面体验信号——公开 CrUX（Chrome 用户体验报告）数据里的 Core Web Vitals（核心网页指标）、服务器响应时间、CDN 使用情况、图片格式组合（WebP/AVIF？）
- 结构化数据——部署了哪些 schema 类型，部署在哪些模板
- 内链模式——典型锚文本分布、面包屑使用、hub-and-spoke（中心辐射）vs. 扁平结构
- 收录面——大致索引规模、分面导航（faceted nav）的使用、参数处理方式
然后产出一份差距分析表：行 = 审计项，列 = 每个竞品 + 你的网站，单元格 = ✓/✗/部分 + 备注。标出最可能拖后腿的 3–5 个差距。
用 CrUX、W3C 技术校验、BuiltWith 等可靠的公开数据源。不要编造你无法验证的指标。
差距分析表就是交付物。它是直接摆到客户面前的东西。没有这张表，你递给客户的就是一堆观察；有这张表，他们能一眼看到每个竞品做了什么、自己没做什么。
两个要盯住的点：
- Gemini 有时会"脑补"它没有的竞品数据。如果某个竞品屏蔽了 CrUX 或者隐藏了技术栈，模型会基于行业惯例去猜。一定要复核表里那些"会改变建议方向"的单元格。
- 15–20 分钟的运行时间是真实的。这是一次跨 5–8 个网站的长循环浏览。不要中途打断——你打断它，就丢了上下文链。
第 3 步：综合与排优先级（5 分钟）
第三轮最短但最重要。把前两轮的产出贴进来，强制它给出一个结论（thesis）。
Prompt 模板：
基于附件里对 [你的域名] 的技术审计和竞品差距分析，请产出一份排好优先级的行动方案：
- 关键修复（本周做）——正在抑制排名或造成索引膨胀的问题。每条：具体修复、由团队里谁负责、验证步骤。
- 快速胜利（本月做）——几小时就能改完、移除某个已知排名因子约束的改动。
- 战略改进（下季度做）——需要规划的较大改动，例如 URL 结构重做、分面导航重构、模板级结构化数据上线。
- 反建议（anti-recommendations）——那些常被推荐但对这个具体网站不适用的 SEO 建议。（比如："别折腾 XML sitemap"——如果站点索引化已经完美；"别折腾 HSTS"——如果只是信息类站点。）
行动方案控制在 5 页以内。不要凑字数、不要"综上所述"段落、不要打鸡血的收尾。
反建议（anti-recommendations）这一节是客户最喜欢的部分。它告诉你什么不用再担心。我审计过的网站里，大部分都有 3–5 条常被引用的"SEO 最佳实践"跟它们没半毛钱关系，把这些从客户脑子里的"待办列表"上划掉，价值占了一半。
Gemini 会骗你的地方
"无脑信 Deep Research 产出"这个错误我犯过不止一次。下面是技术 SEO 审计里专属的几个失败模式：
结构化数据幻觉。 Gemini 有时会"检测到"实际上不在源码里的 schema。打开它引用的那个页面，真的去看 <script type="application/ld+json"> 块里的内容。有一次审计，它说某个竞品 80% 的页面有 FAQ schema，实际只有 20%——模型是从页面可见内容做模式匹配，不是真的去解析 markup。
CrUX 数据新鲜度。 CrUX 数据滞后大约一个月。如果模型引用了"上周"的 CrUX 数字，那数据是不存在的——它至少是 28 天前的。做时间敏感的审计时，请明确写"只用最近一期月度发布的 CrUX 数据"。
编造的重定向数量。 模型有时会引用一个和爬虫数据对不上的重定向链长度。"分类 URL 有三次重定向跳转"是个有用的信号，但请用重定向地图里随机抽 10 个 URL 复核一下。我见过模型把"重定向链"和"重定向循环"搞混——这两者的修法是完全不一样的。
"最佳实践"污染。 这是最常见的失败。你问的是你网站的问题，模型返回的是一份泛 SEO 建议，跟你的爬虫数据没关系。第 1 步里那句"不要从 SEO 最佳实践泛泛而谈"能压住一部分，但压不干净。每一条标出来的问题，都要回头在附件的爬虫数据里交叉验证。
过时的平台假设。 Gemini 偶尔还会按"WordPress + Yoast"的思路来理解站点，或者假设是 Apache rewrite 规则，而你的网站其实在 Cloudflare 后面、用的是 headless CMS。在第一个 prompt 里把平台和基础设施写清楚，能避免掉一多半这类通用建议。
哪些事它做不了
Gemini Deep Research 是效率倍增器，不是替代品。它做得不好的事：
日志文件分析。 读 5GB 的日志文件、去重爬虫会话、关联抓取频率和索引膨胀——这是正经的工程活。请用 Screaming Frog Log Analyzer、OnCrawl 或者自己写个 Python 脚本来做。AI 能解读结果，啃不动日志文件本身。
JS 渲染页面的自定义抽取。 如果你的网站是 React/Vue/Angular SPA（单页应用），Gemini 看到的是 curl 看到的，不是用户看到的。你需要 headless 浏览器（Puppeteer、Playwright）把页面渲染完，再去抓水合（hydration）后的 DOM。审计基于你自己的导出文件跑，不是基于 Gemini 的浏览。
在生产环境上做假设验证。 审计给出一个修复建议，你仍然要先在 staging 环境上落实、验证结果、再上生产。审计是假设，修复是实验。这是不可省的。
业务侧判断。 审计会告诉你分类页内容稀薄。但它不会告诉你"这个分类主要用来交叉销售，正解是加 bundle schema（捆绑销售结构化数据），不是重写 200 个产品描述"。这种判断永远在懂业务的那个人脑子里。
真正的变化
3 年前，一个初级 SEO 花一周跑一份技术审计，仍然可能漏掉"分页归档页的 canonical 问题"——就是我在开头举的那个例子。今天，一个中级营销人 + Gemini Deep Research + 一份干净的爬虫导出，8 分钟就能挖出这个问题。
工具没有替代专业能力。它压缩了"我感觉哪里不对"和"我清楚地知道哪里不对"之间的时间。剩下的活——解读输出、设计修复、上线不出别的岔子、衡量恢复——这才是现在值钱的地方。
如果你还没在自己的网站上跑过 Deep Research 审计，挑一个表现最差的模板，按上面这套 3 步工作流跑一遍。最差的结果：你发现自己的网站比你担心的健康。最好的结果：你找到那个让你丢了半年流量的真凶——而且在下一个季度的下滑发生之前找到它。