关键词自相蚕食检测周报

原文要点

原模板每周一运行（也可在网站迁移后手动触发）：调用Search Console Search Analytics API取两个28天窗口、按query+page分组的数据，找出同一查询对应多个URL的情况，过滤掉site:类操作符查询和超长零点击查询；对剩余候选逐个抓取URL（不跟随重定向），读取HTTP状态、Location头、canonical和hreflang，把查询分类为重定向、canonical重复、hreflang语言版本或真实重叠；已在n8n Data Table记录过且展示量未明显增长的配对会被抑制；真实重叠一次性发给OpenAI兼容模型建议保留哪个页面，结果经Gmail发周报并写回Data Table。原工作流需在模板页自行导入。

这次做成什么

搭好这套每周关键词自相蚕食检测：配好Search Console访问权限、Settings参数和query_overlaps数据表，跑通后每周收到一封只含真实重叠与处理建议的邮件。

准备什么

• 一个Google服务账号（或OAuth），其邮箱已被加为目标Search Console资源的用户，仅拥有Cloud项目不算数
• n8n实例及从模板页导入的原工作流
• Search Console属性ID，形如sc-domain:example.com或https://example.com/
• Gmail发送凭据和一个OpenAI兼容的模型凭据（LangChain ChatOpenAI节点）
• n8n版本支持Data Tables功能，用于建query_overlaps表

具体怎么做

1. 开通Search Console访问

   在Google Cloud建服务账号并启用Search Console API，把服务账号邮箱（形如xxx@project.iam.gserviceaccount.com）加到Search Console属性的用户列表，权限选“完整”或“受限”均可读数据。在n8n建对应Google凭据。

2. 创建query_overlaps数据表

   在n8n的Data Tables里新建名为query_overlaps的表，逐列添加pair_key、query、urls、verdict、impressions、last_seen，类型按下方示例设置。这张表负责历史记录与重复抑制，表名和列名必须完全一致。

3. 填Settings节点参数

   在Settings节点填入propertyId、时间窗口天数、minImpressions、maxQueryLength、locale_prefixes（如/en/,/ja/，无多语言则留空数组）和digest收件邮箱。locale_prefixes决定语言版本页面是否被误判为竞争，务必按你的站点结构填。

4. 配模型凭据并手动首跑

   为ChatOpenAI节点选择你的OpenAI兼容凭据和模型。手动执行一次：确认GSC查询返回数据、候选URL抓取拿到状态码/canonical/hreflang、分类计数合理、邮件发出且query_overlaps写入记录。之后启用每周一的Schedule Trigger，或在迁移后手动触发。

可直接复制的材料

{
  "propertyId": "sc-domain:example.com",
  "windowDays": 28,
  "minImpressions": 20,
  "maxQueryLength": 120,
  "locale_prefixes": ["/en/", "/ja/"],
  "digestRecipient": "seo-team@example.com",
  "impressionsGrowthPct": 50
}

列定义：
pair_key (string, 主键), query (string), urls (string), verdict (string), impressions (number), last_seen (date)

示例行：
pair_key=ai写作工具::/blog/ai-tools|/products/writer
query=ai写作工具
urls=/blog/ai-tools|/products/writer
verdict=keep_blog_noindex_product
impressions=340
last_seen=2026-08-31

你是SEO技术顾问。以下是经过重定向/canonical/hreflang核验后确认为真实自相蚕食的关键词-URL配对。对每一组，判断哪个URL应该拥有该查询，并给出对另一个URL的处理动作。

判定依据优先级：搜索意图匹配度 > 内容深度 > 转化目标。
可选动作：保留并强化 / 301重定向到胜出页 / 对败者加canonical指向胜出页 / noindex / 合并内容。

输入数据（JSON数组）：
[{"query": "ai写作工具", "urls": [{"url": "/blog/ai-tools", "clicks": 12, "impressions": 340, "position": 8.2}, {"url": "/products/writer", "clicks": 3, "impressions": 120, "position": 15.6}]}]

只输出JSON数组，每项格式：
{"query": "...", "keep": "...", "action_on_other": "...", "reason": "一句话中文理由"}

输入与输出示例

本站虚构演示，数字与输出均为示意，非真实GSC或模型返回，未实际运行。

输入

查询“ai写作工具”在过去28天有两个URL：/blog/ai-tools（12点击/340展示/排名8.2）和/products/writer（3点击/120展示/排名15.6）；抓取核验两者均返回200、canonical各自指向自己、无hreflang互指，pair_key未在query_overlaps中。

对应输出

分类为真实重叠进入模型环节。模型返回：{"query":"ai写作工具","keep":"/blog/ai-tools","action_on_other":"对/products/writer内该关键词的站内锚文本改指/blog/ai-tools，并在产品页加canonical到博客页或弱化该词定位","reason":"信息型查询与博客内容匹配，且展示与排名明显占优"}。周报邮件含此条建议及被排除的重定向/canonical/hreflang计数；query_overlaps新增一行，last_seen为本周一。

做完检查这些

• Search Console节点能返回query+page两个28天窗口的数据，无403权限错误
• 含site:的查询和超过maxQueryLength的超长查询不出现在候选列表
• 同一内容的/en/与/ja/版本被归为hreflang语言版本而非真实重叠
• 上周已报告且展示量未明显增长的配对本周邮件中不再出现
• query_overlaps中新增行的pair_key、verdict、impressions与邮件内容一致

容易卡住的地方

• 服务账号邮箱没加成Search Console用户是常见失败原因，Cloud项目所有权不等于GSC权限
• locale_prefixes留空会导致多语言站点大量误报为自相蚕食
• 抓取URL时不跟随重定向是设计行为，301状态要靠Location头判断而非最终页
• impressionsGrowthPct类抑制阈值若原模板未提供该字段，以导入后的Settings节点实际字段为准
• 模型建议只是参考，301或noindex操作前需人工确认，别自动执行