本文作者：sitin（@sitinme）。版权归作者所有，未经授权禁止转载。
页面怎么进入监控
这套流程用了两个页面来源，一个是 Git 代码变更，一个是 Sitemap。
Git 变更负责告诉系统“发生了什么”。系统每天读取网站主分支的变化，识别新增、修改和删除的公开页面，同时记录提交人和 Commit。它适合追踪静态营销页、博客模板和代码中的页面调整。
Sitemap 负责告诉系统“线上有哪些页面”。博客、文档、模型详情页等内容不一定都能从文件路径直接推断，Sitemap 可以补齐这些动态页面，也能确认某个 URL 是否已经出现在生产环境。
第一次接入时，系统会把已有 URL 作为基线导入，不计入当天新增。之后每天比较 Sitemap，得到新增、更新和移除的页面，再按语言和页面类型分类。博客、产品页、文档和普通营销页可以使用不同的关注优先级。
Google 对 Sitemap 的定位很明确。它能帮助搜索引擎发现重要页面，也能提供页面更新时间和多语言版本等信息，但不保证其中的 URL 一定会被抓取和收录。Google 的 Sitemap 说明
Sitemap 里的 URL 应该使用完整的规范地址，只放希望进入搜索结果的页面。lastmod 也要尽量准确，反映正文、结构化数据或重要链接等显著更新。单纯修改版权年份，或者每次部署都刷新整批页面时间，会让这个信号失去价值。Google 的 Sitemap 构建规范
因此，我没有把 lastmod 直接当成页面内容更新。系统会观察同一批页面是否共享相同更新时间，并结合 Title、Description、H1、Canonical 和 Robots 等稳定信息生成内容指纹。批量构建造成的统一刷新会被降噪，真实页面变化才会进入复查。最近给一个出海网站搭了一套 SEO 页面监控流水线。
想做这套监控，是因为一篇新页面上线后，比较合理的检查顺序应该是：
技术上可收录 → Google 已发现 → 已抓取 → 已收录 → 有曝光 → 有点击
我把它当作页面上线后的运营检查链路。实际数据不一定严格按顺序发生，但沿着这条链路检查，可以比较快地判断页面卡在哪个环节，下一步应该处理技术问题、等待抓取，还是继续优化内容和点击率。
人工完成整条链路并不轻松。发布后要先打开页面检查状态码、robots、noindex 和 canonical，再到 Google Search Console 查询有没有被发现、抓取和收录。
过一段时间还要筛选 URL，看曝光、排名和点击。页面没有收录时，还需要分辨是页面有问题、Google 还没有抓取，还是内容暂时没有达到收录条件。
网站页面不多的时候，我会在发布后做这些检查。页面数量增加以后，每天上线的内容不只有新页面，还包括旧页面更新、产品页调整。检查路径长，等待周期也不同，很容易出现页面发出去了，却没有人继续跟进后续状态的情况。
所以我借助一部分 AI 和自动化能力，把重复查询、状态判断、异常复查和修复草案交给系统处理。人工主要关注系统筛选出来的少量异常页面，并在正式提交和部署前确认修改。
整套系统要完成一条完整流程：页面有变化时自动进入监控，先确认技术上可以收录，再跟踪 Google 的发现、抓取、收录、曝光、排名和点击。遇到临时错误自动重试，确认是代码问题再交给 Agent 排查，修复上线后继续复查，直到状态更新。
这是最初轻量版的流程：
页面怎么进入监控
这套流程用了两个页面来源，一个是 Git 代码变更，一个是 Sitemap。
Git 变更负责告诉系统“发生了什么”。系统每天读取网站主分支的变化，识别新增、修改和删除的公开页面，同时记录提交人和 Commit。它适合追踪静态营销页、博客模板和代码中的页面调整。
Sitemap 负责告诉系统“线上有哪些页面”。博客、文档、模型详情页等内容不一定都能从文件路径直接推断，Sitemap 可以补齐这些动态页面，也能确认某个 URL 是否已经出现在生产环境。
第一次接入时，系统会把已有 URL 作为基线导入，不计入当天新增。之后每天比较 Sitemap，得到新增、更新和移除的页面，再按语言和页面类型分类。博客、产品页、文档和普通营销页可以使用不同的关注优先级。
Google 对 Sitemap 的定位很明确。它能帮助搜索引擎发现重要页面，也能提供页面更新时间和多语言版本等信息，但不保证其中的 URL 一定会被抓取和收录。Google 的 Sitemap 说明
Sitemap 里的 URL 应该使用完整的规范地址，只放希望进入搜索结果的页面。lastmod 也要尽量准确，反映正文、结构化数据或重要链接等显著更新。单纯修改版权年份，或者每次部署都刷新整批页面时间，会让这个信号失去价值。Google 的 Sitemap 构建规范
因此，我没有把 lastmod 直接当成页面内容更新。系统会观察同一批页面是否共享相同更新时间，并结合 Title、Description、H1、Canonical 和 Robots 等稳定信息生成内容指纹。批量构建造成的统一刷新会被降噪，真实页面变化才会进入复查。
页面上线后先过技术检查
新页面进入监控后，不会立即把“有没有收录”当成唯一判断标准。系统会先检查线上页面本身是否具备被搜索引擎访问和索引的条件。
技术检查包括 HTTP 状态码、最终访问地址、robots.txt 抓取权限、页面级 noindex 和 canonical。
页面请求失败时会先重试，避免因为一次 DNS、TLS 或 CDN 波动，把不完整的 HTML 误判成“缺少 canonical”。
robots.txt 和 noindex 也需要分开理解。robots.txt 主要控制抓取行为，noindex 用来告诉搜索引擎不要把页面放进搜索结果。如果抓取器无法访问页面，也可能读不到页面里的 noindex。
Google 官方建议，需要阻止页面进入搜索结果时，使用 noindex、访问保护或移除页面，不能把 robots.txt 当成通用的去索引工具。Google 的 robots.txt 说明
canonical 用来表达站点希望采用的规范 URL。Google 会综合重定向、rel="canonical"、Sitemap 和内部链接等信号选择规范页，站点声明属于重要信号，但 Google 仍可能选择其他 URL。
对于应当独立收录的页面，会检查是否存在自指 canonical；筛选页、参数页和分页页面则按各自的规范化策略判断。Google 的 canonical 规范
技术检查通过后，页面才进入 Google 收录跟踪。发现 noindex、错误 canonical、抓取被阻止或异常状态码时，系统会保留技术问题，暂停无意义的 GSC 轮询。
这一步把“页面自身有问题”和“Google 还没来得及收录”分开了。新页面几天没有收录，并不能直接说明内容质量差。先确认技术条件正常，再结合时间和 GSC 返回的阶段继续观察，判断会更可靠。
分阶段跟踪 Google 收录和搜索表现
技术正常的页面会进入 D0、D1、D3、D7、D14 和长期观察几个阶段。
刚上线时查询一次，之后在第 1 天、第 3 天、第 7 天和第 14 天附近继续检查。已经收录的页面降低查询频率，长期未收录的页面保留在关注队列。这样既能覆盖新页面的关键阶段，也能避免每天对全站 URL 重复调用 GSC。
分批调度还有一个实际原因。Search Console 的 URL Inspection 存在按站点计算的每日使用限制，适合检查重点 URL 和分阶段跟踪，不适合把它当成无限量的全站爬虫。Google URL Inspection 帮助文档
每个页面会保存 Google 当前是否收录、覆盖状态、最近抓取时间、Google 选择的 canonical 和页面声明的 canonical。系统把结果归一为“等待发现”“等待抓取”“已抓取待收录”和“已收录”，方便按页面阶段筛选。
这里还有一个容易混淆的地方。URL Inspection API 返回的是 Google 索引中已有版本的状态，不能用来检查线上页面此刻是否可以被索引。页面在 Google 上显示正常，也可能在上次抓取后已经发生变化。因此，实时技术检查和 GSC 索引检查需要同时保留。URL Inspection API 官方说明
收录之后，系统会通过 Search Analytics API 按页面维度读取最近 28 天的曝光、点击、CTR 和平均排名。Search Analytics 支持按 page、query、country 和 device 等维度分组，返回的数据更适合做趋势和机会判断，不保证包含所有明细行。Search Analytics API 官方说明
这样一来，监控的目标就从“页面有没有进入 Google”延伸到了“页面有没有得到展示、点击和排名”。有收录但长期没有曝光的页面，需要回到关键词、内容和内部链接层面判断；已经进入前 20 的页面，则可以优先做标题、内容补充和 CTR 优化。
飞书承担人工查看，SQLite 保存真实状态
监控数据不会只放在日志里。底层使用 SQLite 保存每个 URL 的历史状态，飞书多维表格作为团队查看和筛选的界面。
每条页面记录会保存语言、页面类型、变更类型、提交人、技术检查结果、GSC 状态、首次发现时间、最近抓取时间、曝光、点击、CTR、排名、问题描述和建议动作。字段按“页面信息、技术检查、Google 收录、搜索表现、处理状态”分组，人工查看时可以快速切换不同视图。
例如，可以筛选最近新增但还在等待发现的页面，也可以只看已抓取但尚未收录的博客，或者查看已经有曝光但 CTR 偏低的页面。团队不需要逐个打开 GSC 检查 URL，日常关注集中在少数状态发生变化的页面上。
每天主任务完成后，系统先把变化同步到多维表格，再向飞书群发送一张飞书卡片。卡片展示当天新增和更新数量、新收录页面、上线 7 天仍未收录的页面、技术复查结果、自动重试数量、Agent 状态和同步后剩余记录。
SQLite 是状态源，飞书是人工界面，这个边界很重要。多维表格适合协作和筛选，但定时任务不应该依赖人工视图推断系统状态。即使飞书暂时同步失败，页面检查和下一轮调度仍然可以继续。
异常怎么进入处理闭环
监控运行中会遇到三类问题，它们需要走不同的路径。
curl 超时、TLS 失败和 Google 5xx 属于临时传输问题。单个请求会先自动重试，仍未恢复时保留页面原来的技术和索引状态，写入独立的 GSC 重试队列。自动化脚本每 6 小时只重试这些失败 URL，不重复执行整套日报。
OAuth 失效、权限不足、数据库或飞书配置错误属于监控系统问题。这类错误会直接通知人工检查运行环境，不会交给页面修复 Agent 修改网站代码。
页面持续返回 noindex、错误 canonical、异常状态码或 robots 抓取限制时，才进入代码问题流程。同一个技术问题需要连续两次复查确认，系统才创建 Agent 任务，减少瞬时部署波动带来的误报。
Agent 会在隔离的 Git worktree 中定位页面代码，准备修改并运行测试，再把根因、涉及文件、测试结果和风险发到飞书。commit、push 和正式部署前保留人工审批。修复上线后，监控会再次检查页面，通过后自动恢复状态并关闭旧任务。
整套流程由三个定时任务配合运行。每天一次的主任务负责发现页面、技术检查、GSC 分阶段查询、效果数据、飞书同步和日报；每 6 小时的任务只处理 GSC 临时失败；每 30 分钟的 Agent 任务只领取已经连续确认的技术异常。
页面新增或更新 → 技术条件检查 → GSC 分阶段收录跟踪 → 曝光、点击和排名观察 → 临时问题自动重试 → 持续技术异常交给 Agent → 飞书通知人工审批 → 提交部署 → 再次检查并更新状态
这套流水线目前已经覆盖站点的数百个页面。日常工作从逐页查询变成了查看状态变化和少量待处理项。团队提交新页面后，系统负责持续跟踪；出现代码问题时，Agent 先准备修复方案；涉及页面策略、线上提交和部署的动作，仍然由人工把关。做完这套流程后，我对 SEO 自动化的理解也更具体了。定时抓一遍数据只是起点，页面如何进入监控、状态如何变化、失败后由谁重试、什么情况需要改代码、修复后怎么确认恢复，这些环节连起来，页面监控才能长期运行。
欢迎关注，这个账号还会持续分享更多AI编程、出海工具、实战经验、踩坑记录。
想了解更多可以加我 vx: 257735 聊。
新注册用户送 50 张 GPT Image 2 免费额度，不用绑卡，需要快速出图的可以试试：👉 https://www.hiapi.ai/en/register?aff=AR3h
原文：https://mp.weixin.qq.com/s/o7NOuAG3fj-od4m9YNaE9A?scene=1
