创见日期：2026年8月27日
前四篇一直在建立控制系统：为什么SEO自动化不能等同于AI批量生产，Orchestrator、Agent、状态机、SEO Intelligence、Source Registry、Fact Check和Evidence Chain应该怎样组合。
做到这里以后，系统终于可以进入真正的执行层。第一个非常适合自动化的执行场景，就是Technical SEO审核。
因为Technical SEO天然包含大量重复检查、规则判断、URL比较、状态码验证、HTML解析、日志记录和异常聚类，这些工作非常适合程序和Agent完成。
但很多所谓“Technical SEO自动化”，最终只是把Crawler导出的几万行问题，再交给AI总结一次。这仍然只是自动生成报告，并没有真正解决哪个问题最严重、证据是什么、为什么发生、应该修改什么、修改以后怎样验证，以及如果修改错误如何回滚。
真正的Technical SEO Agent，不应该只是Crawler Summary Agent，而应该是Technical SEO Diagnosis + Decision System。
一、Technical SEO自动化真正困难的不是“发现问题”
今天发现Technical SEO问题并不难。Crawler可以发现404、Redirect、Canonical、Noindex、Blocked URL、Duplicate Title、Missing H1、Structured Data Error、Broken Internal Link和Slow Page；Search Console又可以看到Indexing、Crawling、Canonical、Sitemap和Enhancement；服务器日志还能告诉我们Googlebot抓了什么、返回什么状态以及抓取频率。
真正困难的问题已经不是“有没有数据”，而是怎样把这些数据转化成可靠判断。
例如Crawler发现10,000个URL没有被索引，这不一定严重，因为它们可能全部是筛选参数、站内搜索页、分页变体、重复URL，本来就不应该进入索引。相反，如果一个网站只有30个核心产品页，其中10个被错误添加noindex，问题数量只有10，但业务严重程度可能直接是P0。
Issue Count ≠ Business Severity。
二、先回答两个问题：能不能抓，能不能索引
一个URL最终进入Google Search，前面至少要经历Discover → Crawl → Fetch → Render → Index → Canonical Selection → Serve。
所以当一个页面“没有排名”时，Agent不应该一上来分析Title、关键词或内容长度，而应该先回答：Google能不能发现这个URL？Googlebot能不能请求？服务器返回什么？页面是否允许索引？Google看到的Canonical是谁？关键内容是否可以被渲染和理解？
因此推荐固定诊断顺序：URL → Robots → Meta/X-Robots → Canonical → Sitemap → HTTP → Content Quality/Duplication → Internal Links → Rendering → Google Crawl/Index Evidence。
三、URL标准化必须先于所有诊断
同一个页面可能存在HTTP/HTTPS、www/non-www、尾斜杠、参数URL等多个变体。如果系统把它们全部当成独立页面，后续Duplicate、Canonical、Internal Link、Sitemap和Indexing统计都会产生大量噪声。
进入诊断前，建议统一保存url、normalized_url、protocol、host、path、query_parameters、fragment、http_status、final_url与redirect_chain，再判断哪些URL是真正独立内容，哪些只是同一资源的变体。
四、Robots.txt不能只判断Blocked / Not Blocked
真正的Robots诊断至少要继续回答：被阻止的是哪个Crawler？规则来自哪里？URL本来应该被抓吗？是否和Sitemap矛盾？是否仍有Internal Link指向？是否同时存在noindex？是否因为Robots阻止导致Google无法看到页面级索引指令？
Robots.txt主要控制Crawler能否抓取URL，并不等同于一个可靠的“删除Google索引”机制。因此Agent看到一条Disallow规则后，必须结合页面类型与业务角色判断严重程度。
如果整个产品目录意外被禁止抓取，Severity可能是P0；如果被阻止的是站内搜索页，则可能完全正常。同一条技术规则，在不同页面类型上可以得到完全不同的结论。
五、Meta Robots和X-Robots-Tag必须同时检查
页面级索引控制不能只检查HTML中的meta robots，还要检查HTTP Header中的X-Robots-Tag，尤其是PDF、图片和其他非HTML资源。
Agent至少应采集meta_robots、googlebot_meta、x_robots_tag与rendered_meta_robots，并判断是否存在冲突。例如HTML声明index,follow，但HTTP响应中出现X-Robots-Tag: noindex，那么真正的问题是Indexing Directive Conflict。
六、JavaScript页面不能只看浏览器最后显示什么
现代浏览器最终看到的是Rendered DOM，但Crawler首先获得的是Initial HTML。两者可能不同。因此成熟的Agent至少要比较raw_html与rendered_html，重点检查Title、Meta Robots、Canonical、H1、Main Content、Internal Links和Structured Data。
Google官方JavaScript SEO文档特别提醒，对于noindex必须谨慎：如果原始页面已经包含noindex，不能假设JavaScript后续删除该指令就一定得到预期结果。参考：Google JavaScript SEO Basics。
真正应该检查的不是“网站是否使用JavaScript”，而是关键内容与SEO信号在抓取和渲染流程中是否稳定存在。
七、Canonical不是Correct / Incorrect字段
Canonical是最容易被自动化工具误判的字段之一。Google官方明确说明，rel=canonical属于Canonical偏好信号而非绝对指令，Google会综合Redirect、Sitemap、Canonical Annotation等信号，并可能选择不同于站长声明的Canonical。参考：Google Canonicalization。
因此Agent应区分Declared Canonical、Google-selected Canonical和Business-preferred Canonical。这三个URL不一定相同。
Non-self Canonical ≠ Error。真正需要判断的是Canonical目标是否符合内容等价关系和业务意图。
八、Canonical冲突要检查信号一致性
出现Google选择不同Canonical时，应先确认Google-selected Canonical，再检查Canonical、Sitemap、Internal Links、Redirect、hreflang和页面内容是否给出了相互矛盾的信号。
真正的修复往往不是“再加一个Canonical标签”，而是让技术信号统一。参考：Google Canonical Troubleshooting。
九、Canonical还要区分技术问题与内容问题
即使技术Canonical信号正确，如果页面内容高度相似，Google仍可能把页面聚类。因此当Agent发现两个页面被Canonical到一起时，还应该判断两页是否真的具有足够不同的主内容。
如果两个Landing Page只有Title和URL不同、正文几乎一致，这更可能是Content Differentiation Problem，而不是单纯Technical Canonical Problem。
十、Sitemap审核不能只检查“有没有Sitemap”
真正有价值的Sitemap Audit应该检查：Sitemap能否访问、是否返回200、是否使用最终Canonical URL、是否包含Redirect、404、Noindex、Blocked或Parameter URL，以及重要页面是否遗漏。
Sitemap更准确的定义不是“网站所有URL清单”，而应接近网站希望搜索引擎优先发现和处理的Canonical URL集合。
因此Agent应识别Sitemap Pollution，并为每个URL记录sitemap_url、http_status、indexability、canonical_status、internal_link_status、page_type和lastmod。
十一、HTTP Status必须结合URL意图判断
Technical SEO自动化不能把所有非200页面都叫Error。301可能完全正确，404也可能完全正确。真正的问题是：这个URL按照网站意图应该返回什么状态？
已经永久移除且没有替代页面时，404或410可能是正确设计；但核心Category突然404就是高风险事件。大量旧URL统一301到首页也不等于“没有问题”。Google网站迁移指南明确提醒，不要把大量旧URL重定向到一个无关页面，否则可能被视为Soft 404。参考：Google Site Move Guide。
十二、Redirect Chain和Redirect Loop必须进入自动诊断
对于A → B → C → D，系统应计算redirect_hops，并判断是否可以直接A → D。存在两跳以上不应自动升级成P0，还需要结合流量、Internal Link规模、Crawler频率与模板范围判断。
但A → B → A这类Redirect Loop通常可以直接进入High Severity。
十三、Internal Link审核不能只统计Broken Link
内部链接连接Discovery、Crawling、Information Architecture、Page Importance与User Navigation。Agent至少需要生成inlinks、outlinks、crawl_depth、anchor_text、source_page_type与target_page_type，再识别Broken Internal Link、Redirected Internal Link、Orphan Page、Excessive Depth、Weak Important Page与Template-wide Mislink。
Crawl Depth必须结合Page Type判断。
十四、Orphan Page不能只靠Crawler判断
Crawler从首页开始爬不到某个URL，并不一定意味着页面不存在。真正的Orphan Page检测应该交叉Crawler URL Set、Sitemap URL Set、GSC URL Set、GA4 Landing Page Set与Log URL Set。
更加有业务意义的定义是：存在真实访问、索引或发现证据，但缺乏内部链接入口的页面。
十五、Structured Data必须区分语法、资格和真实性
Structured Data审核建议分三层：Syntax、Eligibility与Truthfulness。第三层最重要，因为Schema必须描述页面真实存在的内容，不能成为给搜索引擎单独看的“隐藏SEO层”。
因此Agent不能看到“缺少FAQ Schema”就直接建议添加FAQ Schema，而应先确认页面是否真实存在符合条件的FAQ内容，以及对应Search Feature当前是否仍受支持。
十六、JavaScript Rendering审核应采用差异检测
最实用的方法不是讨论SSR、CSR、ISR哪个“更SEO”，而是直接比较Initial HTML与Rendered DOM，尤其是Title、Canonical、Main Content、Internal Links与Structured Data。
如果Canonical在初始HTML和渲染后发生变化，这比“使用JavaScript”本身更值得警惕。自动Diff可以直接暴露这种不一致。
十七、必须区分Finding与Diagnosis
Crawler发现“1,274 URLs: Canonicalized”只是一条Finding。真正的Technical SEO Issue至少应该包括：
issue_id
severity
affected_urls
evidence
probable_cause
business_impact
recommended_action
risk
validation
rollback例如系统发现产品变体模板被统一Canonical到父产品，同时GSC显示大量Google-selected Canonical冲突，这时才可以把Finding升级为可执行的诊断任务。
十八、Severity不能只靠技术规则决定
建议Technical SEO Severity至少综合五个维度：Scope、Page Value、Search Impact、Business Impact与Confidence。
一个Homepage错误Canonical可能是P0；50,000个无价值Filter URL缺少Self Canonical可能只是P2。数量不能替代优先级判断。
十九、自动修复前必须增加Change Risk
建议每一个Action增加change_risk：LOW、MEDIUM、HIGH、CRITICAL。
低风险动作可以允许自动创建Patch；中风险可以自动生成PR；高风险需要Technical Review；Critical需要生产变更审批。
例如修复少量Broken Internal Link风险较低，但修改全站Canonical模板、Robots.txt、Sitemap Generator或服务器Redirect都属于高风险变更。
二十、Codex不应该接收“修复SEO”的模糊任务
Technical SEO Agent发现问题后，不应直接告诉Codex“修复Canonical问题”，而应转换成工程任务，至少包含PROJECT、OBJECTIVE、REPOSITORY、BRANCH、CONTEXT、FILES TO INSPECT、CONSTRAINTS、DO NOT、IMPLEMENT、VALIDATE、ACCEPTANCE CRITERIA、OUTPUT与ROLLBACK。
例如目标是修复产品变体模板Canonical，应明确只检查相关模板与过滤器，不修改robots.txt、不改无关文件、不直接发布生产环境，并在修改后抽样抓取、检查Raw/Rendered HTML与Canonical输出。
二十一、修复完成以后必须自动验证
每一个Issue都必须同时定义Validation Plan。Canonical修改后应重新抓取样本URL、检查Raw HTML、Rendered DOM、Canonical目标、Internal Links与Sitemap；Robots修改后检查文件状态、规则解析、抽样URL和Search Console；Redirect修改后检查源URL、最终状态、Redirect Hop、Loop与目标相关性。
没有验证的Fix，只能叫Change，不能叫Resolved。
二十二、Google重新处理Technical SEO修改通常需要时间
网站代码修复完成，不等于Google立即更新状态。因此状态机不应该是FIX_DEPLOYED → RESOLVED，而更适合：FIX_DEPLOYED → TECHNICALLY_VERIFIED → GOOGLE_REPROCESSING → SEARCH_VALIDATED → RESOLVED。
这样系统才能避免今天改完Canonical、明天Search Console还没有变化，就立刻判断“修复失败”。
二十三、重大Technical Change必须记录SEO Event Annotation
每一次重大Technical Change都应该记录date、change_type、affected_scope、release_id、owner、expected_effect与rollback_reference。
Google Update、Site Migration、Theme Change、Major Deployment、Tracking Change、Canonical、Robots、Sitemap与Internal Link Change都应该进入事件记录，否则两周以后排名发生变化时，团队可能根本不知道网站自己改过什么。
二十四、一个真正可运行的Technical SEO Agent Pipeline
DISCOVER → CRAWL → NORMALIZE → RULE CHECK → EVIDENCE ENRICHMENT → DIAGNOSE → SEVERITY → RECOMMEND → HUMAN/AUTO GATE → IMPLEMENT → TECHNICAL VALIDATION → SEARCH MONITORING → RESOLVED/ROLLBACK
其中最关键的不是CRAWL，而是EVIDENCE ENRICHMENT。Crawler只看到网站现在是什么样，真正判断问题还需要结合Sitemap、GSC、GA4、服务器日志、Page Type、Business Value与历史变更。
二十五、项目原创判断：Technical SEO自动化的终点不是“无人审核”
很多人想象中的Technical SEO自动化最终形态是AI每天扫描网站、发现错误、自动改代码并自动部署。但真正成熟的系统不是让所有Technical SEO动作都无人介入，而是让系统知道哪些动作根本不需要人、哪些只需要审批、哪些必须由人判断。
自动收集Status Code、发现Broken Link、生成修复候选都可以高度自动化；批量修改Canonical模板、Robots或大规模Redirect则应该进入更严格的审核。
Technical SEO自动化真正成熟的标志，不是AI拥有最高权限，而是每种技术变化都有与其风险匹配的权限。
当Technical SEO Agent真正做到知道问题是什么、证据在哪里、为什么需要修改、修改风险、如何测试、怎样回滚，以及什么时候等待Google重新处理，它才真正从SEO检查工具升级为Technical SEO Operations System。
下一篇
《SEO / GEO 工作自动化部署与实践规范（六）：自动化索引诊断——为什么页面“不收录”不能只看Search Console一个状态》
下一篇将继续深入URL Discovery、Robots、Noindex、Canonical、Sitemap、Internal Links、Rendering、Content Duplication、Google-selected Canonical、Crawl Evidence与Index Evidence，并建立Indexing Decision Tree。
来源与延伸阅读
- Google Search Central：Canonicalization
- Google Search Central：Canonical Troubleshooting
- Google Search Central：Site Moves and Migrations
- Google Search Central：JavaScript SEO Basics
- SEO & GEO工作自动化专项：SEO + GEO Operating Standard、MASTER INSTRUCTIONS、CODEX + GITHUB STANDARD。