创见日期：2026年8月27日
第五篇把Technical SEO自动审核正式带入Execution Layer。第六篇继续把问题收窄到SEO项目中最常见、也最容易被误诊的一句话：“这个页面为什么Google不收录？”
传统处理方法通常是打开Google Search Console，输入URL，看URL Inspection，看到 Crawled – currently not indexed 或 Discovered – currently not indexed，然后开始加字数、改Title、增加关键词、补Schema、增加内链，再重新提交索引。
但这里存在一个根本问题：“没有出现在Google索引中”只是最终结果，不是原因。
一个URL没有进入Google索引，可能发生在完全不同的环节：没有被发现、已经发现但没有抓取、抓取失败、Robots阻止抓取、允许抓取但禁止索引、Canonical指向其他URL、Google选择其他Canonical、内容高度重复、渲染后缺少主体内容、已经抓取但暂未选择索引，或者曾经索引后来退出。
这些情况最终都可能被团队概括成一句“不收录”，但它们的处理方法完全不同。所以真正的自动化Indexing Agent，第一项任务不是自动提交Google，而是：自动判断URL究竟卡在哪一层。
一、“索引”不是一个动作，而是一条处理链
一个URL进入搜索系统，至少要经历：Discover → Crawl → Fetch → Render → Index → Canonical Selection → Serve。
因此，对每个URL，Agent至少应该回答：URL是否存在；搜索引擎是否能够发现；是否允许Googlebot抓取；HTTP请求是否成功；是否存在索引禁止指令；页面声明的Canonical是谁；Google实际选择的Canonical是谁；Sitemap是否包含；是否存在有效Internal Links；Raw HTML与Rendered HTML是否一致；主体内容是否足够独立；Google是否存在Crawl Evidence与Index Evidence；当前状态与历史状态相比是否发生变化。
自动化索引诊断的对象不能只是一个URL，而应该是一个结构化的Indexing Evidence Object。
二、第一步不是查GSC，而是确认URL本身
用户提交的URL可能已经发生HTTP→HTTPS、www→non-www、末尾斜杠或目录级重定向。因此Agent首先应该执行URL Resolution，记录requested_url、normalized_url、http_status、redirect_chain、final_url和final_status。
后续所有Indexing判断都必须围绕最终可访问URL进行，否则团队可能一直在检查一个已经不是最终页面的地址。
三、第二步：Google到底有没有机会发现这个URL？
页面没有被索引，最先应该区分Undiscovered和Discovered but not indexed。URL Discovery可能来自Internal Links、XML Sitemap、External Links、Redirect、历史抓取记录或其他页面引用。
如果一个URL不在Sitemap、没有任何Internal Link、没有外链、服务器日志没有Googlebot记录，GSC也没有有效发现证据，那么它的问题首先不是“内容质量不够”，而是Discovery Failure。
四、Internal Link应该成为索引诊断的一等证据
很多团队遇到不收录页面以后第一件事是重新提交Sitemap，但Internal Link Architecture往往更值得优先检查。
如果一个新产品页存在于Sitemap，却全站没有任何页面链接过去，那么从信息架构角度看它仍然是Orphan Page。Agent应该记录inlinks、crawl_depth、sitemap和gsc_discovered，并给出“URL可以通过Sitemap发现，但缺乏内部链接支持”这样的可执行结论，而不是机械建议重新提交Google。
五、第三步：Robots.txt检查的是“能不能抓”，不是简单判断“收不收录”
Robots.txt首先解决Crawler Access。Agent应该判断当前URL是否匹配规则、哪个Crawler受影响、这个目录本来是否应该被抓取，以及是否和Sitemap产生冲突。
如果sitemap=true但robots_allowed=false，就是明显的Signal Conflict。网站一边通过Sitemap告诉搜索引擎这里有URL，另一边又通过Robots告诉Crawler不要抓。此时系统不应该继续执行内容优化，而应该先处理Crawl Control。
六、第四步：HTTP状态决定页面是否具备正常索引基础
Agent需要区分2xx、3xx、4xx和5xx。对目标Canonical页面通常希望看到稳定的200 OK；301意味着继续检查最终目标；404/410要判断是否已正式移除；5xx则进入服务器或基础设施层。
同时还应警惕Soft 404：服务器返回200，但页面实际是产品不存在、空模板、错误页或极薄弱页面。因此HTTP 200并不能自动得到Indexable=true。
七、第五步：Meta Robots和X-Robots-Tag必须一起检查
页面级索引控制不能只检查HTML中的meta robots，还必须检查HTTP Header中的X-Robots-Tag，尤其是PDF、图片与非HTML资源。建议记录robots_allowed、meta_robots、googlebot_meta和x_robots_tag，并进一步定位Directive Source：CMS、SEO插件、模板、服务器、CDN还是应用代码。
知道存在noindex，和知道是谁生成noindex，是两个完全不同层级的诊断。
八、不要把“Indexable”误解成“Google必须Index”
一个页面满足200、Robots允许、没有noindex、Canonical正常、存在Internal Links和Sitemap，并不意味着Google必须收录。
技术上的Indexable更准确的意思是：当前没有发现明确的技术索引阻断条件。它不是Guaranteed Indexed。因此自动化报告更应该写：“当前未发现明确Technical Indexing Blocker，应继续进入Canonical、内容独立性、渲染和Google处理证据诊断。”
九、第六步：Declared Canonical是谁？
如果当前页面A声明Canonical到页面B，Agent必须先判断这是设计意图还是配置错误。建议记录current_url、declared_canonical、self_canonical与canonical_status，并验证Canonical目标是否200、允许索引、内容等价且属于同一页面族。
如果页面本来应该独立存在，却Canonical到其他页面，这本身就可能解释为什么它没有作为独立URL进入索引。
十、真正关键的是Google-selected Canonical
网站声明Canonical只是站长提供的信号，Google最终仍可能选择其他URL作为Canonical。因此成熟的Indexing Agent应该同时记录user_declared_canonical与google_selected_canonical。
如果二者不一致，就进入Canonical Divergence。此时不应该机械输出“Google错选Canonical”，而要继续检查Internal Links、Sitemap、Redirect、页面相似度、hreflang、URL参数和内容差异，因为网站自身可能正在发送互相冲突的Canonical信号。
十一、“Duplicate”通常不是一个标签问题
如果Google选择另一个Canonical，很多团队会立刻重新添加Self Canonical。但如果两个页面Title不同、URL不同，正文却几乎一样，问题很可能不是Canonical标签，而是页面没有足够独立的内容价值。
因此Indexing Agent需要比较Title、H1、Main Content、实体、产品参数、FAQ与Internal Anchor Context，判断这是Technical Duplicate、Near Duplicate、Template Duplicate还是Business-intended Variant。
十二、参数URL尤其需要单独处理
电商、B2B产品站和大型内容站常见?color=、?sort=、?filter=、?page=和utm参数。如果Agent把所有参数URL都当成“未收录页面”，报告很快就会失去意义。
URL Classification必须先判断URL属于Canonical Page、Filter、Sort、Tracking Parameter、Pagination、Search Result、Variant还是Session URL，然后才能决定它究竟应该索引、可以索引，还是本来就不应该成为独立索引页面。
没有URL Type，就没有可靠的Indexing Diagnosis。
十三、第七步：Sitemap只能提供一个信号
在Sitemap里不等于一定收录。Agent应该检查in_sitemap、sitemap_status、sitemap_lastmod、canonical_consistency和indexability_consistency。
URL在Sitemap中但meta robots=noindex，是Sitemap / Indexing Conflict；Sitemap提交A而Canonical指向B，则是Canonical Signal Conflict。Sitemap不是单纯“提交工具”，而是Canonical与Discovery信号体系的一部分。
十四、第八步：Raw HTML和Rendered HTML必须比较
JavaScript站点尤其需要Render Diff。至少比较raw_title/rendered_title、raw_canonical/rendered_canonical、raw_robots/rendered_robots、raw_main_content/rendered_main_content、raw_internal_links/rendered_internal_links。
真正值得关注的不是“页面使用JavaScript”，而是关键SEO信号在渲染前后是否发生冲突，例如Raw HTML是noindex而Rendered DOM变成index，或者Raw Canonical=A、Rendered Canonical=B。
十五、第九步：检查Googlebot真实抓取证据
到了这里，系统已经知道URL理论上是否可以被抓取和索引。下一步应该问：Google实际上来过吗？
服务器日志能够提供非常强的Crawl Evidence，例如Googlebot最后抓取时间、返回状态和响应时间。如果日志显示Googlebot持续抓取页面，就不能继续把问题归因于“Google找不到这个页面”。
十六、GSC不是唯一证据，但它是Google处理状态的重要证据
这时再进入Search Console，记录inspection_status、last_crawl、crawl_allowed、page_fetch、indexing_allowed、user_canonical和google_canonical，并与Crawler和Log Evidence进行交叉。
例如Crawler显示200、index、self canonical，Log显示Googlebot昨天已抓取，而GSC显示Crawled – currently not indexed，这时就可以排除Discovery Failure、Robots Block、HTTP Failure和Noindex，诊断应继续进入Selection、Quality、Duplication与Canonical Evaluation，而不是重复提交十次。
十七、Discovered – currently not indexed 应该怎样自动诊断
如果GSC返回Discovered – currently not indexed，Agent首先应检查Internal Link、Sitemap、Crawl Depth、服务器稳定性、Googlebot历史访问、同类URL数量、是否突然批量创建大量页面，以及是否存在大量参数空间。
如果URL已被Google知晓、没有近期抓取证据、没有技术阻断、内部链接较弱且属于大规模低优先级URL集群，那么建议动作可能是改善信息架构、减少低价值URL空间、增强核心页面内链与清理Sitemap，而不是“再提交一次”。
十八、Crawled – currently not indexed 又是另一类问题
如果Google已经抓取，诊断方向就不同。Agent应该重点检查Content Similarity、Canonical Cluster、Thin Content、Soft 404 Signals、Template Duplication、Main Content、Rendered Content、Internal Link Context与页面业务独立性。
例如100个城市页除了城市名不同、正文几乎完全一样，即使技术上全部200、index、self canonical、Sitemap正常，问题也已经不是Technical Block，而是这些URL是否真的值得作为100个独立Search Documents存在。
Technical Indexability和Index Selection必须分开。
十九、不要让Agent自动把“不收录”归因于“内容质量”
“内容质量”不应该成为不知道原因时的垃圾桶。系统应把结论拆成Confirmed、Strongly Supported、Observed、Hypothesis与Unknown。
例如：Confirmed—Googlebot成功抓取；Confirmed—没有noindex；Confirmed—Declared Canonical为self；Observed—与14个已索引页面主内容相似度91%；Hypothesis—Google可能正在将其与高度相似页面聚类；Confidence—Medium。
这比“因为内容质量差所以不收录”专业得多，也符合整个系列建立的Evidence Discipline。
二十、必须加入“Previously Indexed”状态
曾经收录、现在消失，与从未收录是完全不同的问题。Agent应该自动检查最近是否修改Canonical、Noindex、Robots、URL、模板、Internal Links，是否发生5xx、内容大幅变化、Site Migration，或者时间上是否与Google Update窗口重叠。
因此系统需要保留index_history并与SEO Event Annotation对齐。例如8月20日修改Canonical模板，8月22日大量URL退出索引，这是重要的Temporal Evidence，但仍然不能自动升级为Confirmed Causality。
二十一、Indexing Agent应该输出原因树，而不是一句结论
最终输出不应该只有Not Indexed，而应该包含Discovery、Crawl Access、HTTP、Index Directives、Declared Canonical、Google Canonical、Sitemap、Internal Links、Rendering、Content Similarity、Google Crawl Evidence、Index Evidence、Primary Diagnosis、Confidence和Recommended Action。
只有把证据逐层展开，Agent的输出才真正能够进入下一步修复或人工决策。
二十二、推荐建立Indexing Decision Tree
核心逻辑可以简化为：
- URL存在吗？如果否，进入URL / HTTP问题。
- Google能发现吗？如果否，进入Discovery问题。
- 允许抓取吗？如果否，进入Robots问题。
- Fetch成功吗？如果否，进入HTTP / Server问题。
- 允许索引吗？如果否，进入Meta / X-Robots问题。
- Canonical是否符合页面意图？如果否，进入Canonical Intent检查。
- Google-selected Canonical是否一致？如果否，进入Canonical Cluster诊断。
- 内容是否稳定渲染？如果否，进入Rendering问题。
- Google是否实际抓取？如果否，进入Crawl / Discovery / Priority。
- Google是否索引？如果否，再进入Duplicate / Selection / Content / Unknown。
这个Decision Tree应该成为Indexing Agent的核心规则。
二十三、不要把“请求编入索引”设计成默认修复动作
错误设计是：Not Indexed → Request Indexing。
更合理的是：Not Indexed → Diagnose → Fix Root Cause → Validate → Allow Reprocessing → Monitor。
只有当页面确实应该索引、没有Technical Block、页面已经准备好，并且请求操作本身符合平台限制和实际需要时，才考虑Request Indexing。提交不是修复。
二十四、批量索引问题必须优先找“模板级原因”
如果1个URL不收录，可以做URL级分析；如果8,000个URL同时出现类似状态，就不应该让Agent逐个分析8,000次，而应该按page_type、template、directory、canonical_pattern、robots_pattern、status_pattern、content_similarity和index_status聚类。
如果92%的受影响URL都来自同一个product variant template，那么问题对象应该从8,000 URLs升级为1 Template Issue。
二十五、Indexing Agent还应该计算“商业优先级”
不是所有未索引URL都值得修。20,000个Filter URL不索引可能完全不用管；5个核心解决方案页面不索引则可能需要立即处理。
最终Priority至少应该结合page_type、business_value、organic_potential、conversion_role、internal_importance和indexing_issue_confidence形成P0-P3。
P0通常是首页、核心产品或核心Category因Noindex、Robots或Canonical错误退出索引；P1是高价值Landing Page批量异常；P2是普通内容页选择性索引问题；P3则是低价值或本来不需要索引的URL。
二十六、GEO时代为什么Indexing Diagnosis仍然重要
进入AI Search以后，GEO不能简单等同于传统SEO排名，但可抓取、可解析、Canonical稳定、主体内容清晰、实体关系明确与机器稳定访问依然是重要基础设施。
未来更完整的体系可以理解为：DISCOVERABILITY → CRAWLABILITY → INDEXABILITY → SEARCH VISIBILITY → AI RETRIEVABILITY → AI CITATION → BUSINESS OUTCOME。
这也是SEO与GEO真正能够进入同一个Monitoring体系的地方。
二十七、项目原创判断：未来最有价值的不是“索引检查工具”，而是Indexing Evidence Graph
传统工具告诉你“URL A = Not Indexed”。更成熟的系统应该知道：URL A属于什么模板；Sitemap是否存在；Internal Links有多少；Robots是否允许；HTTP是否为200；是否允许索引；Declared Canonical是谁；Google Canonical是谁；内容相似度是多少；Googlebot最后什么时候抓；是否曾经索引；最近有没有模板变更。
到了这一步，“为什么不收录”就不再是一道模糊的SEO经验题，而开始变成Evidence Graph上的诊断问题。
AI Agent真正擅长发挥作用的地方，不是替人猜原因，而是把分散证据组织起来，按照规则逐层排除，最终给出可验证的诊断。
所以SEO索引自动化真正的终点，不应该是自动提交更多URL，而应该是：让每一个重要URL为什么被发现、为什么被抓取、为什么被选择、为什么退出索引，都尽可能有证据可以解释。
这才是Indexing Intelligence。
下一篇
《SEO / GEO 工作自动化部署与实践规范（七）：GSC + GA4自动分析——怎样让Agent从“流量下降”自动定位到Query、Page、Device、Country与转化问题》
第七篇将正式进入Measurement Layer，把GSC的Clicks、Impressions、CTR、Average Position、Query、Page、Country、Device、Search Appearance，与GA4的Organic Sessions、Landing Pages、Engagement、Key Events和Leads接到同一个诊断框架。