网站收录与结构诊断

解决哪些具体问题

把 SEO 问题当成内容问题，是很多站点反复出现“已发现但当前未收录”却修不好的原因。常见场景包括：

• robots.txt 误封 /app/*、Sitemap 里混入 404 或跳转链接，搜索引擎直接拒绝整批 URL。
• 参数化 URL 与静态 URL 互相抢排名，rel=canonical 指向错误，出现大面积“抓取但未收录”。
• 站点层级埋得太深，重要页面从首页超过 3 次点击，内部链接图形成抓取预算黑洞。
• 多区域站点的 hreflang 缺少回指链接，或与 Sitemap 不一致，导致国际流量无法正确分发。
• .htaccess 或框架路由产生多层重定向链甚至循环，链接权重在跳转中被稀释。
• SSR 或 client-side hydration 场景下，Googlebot 看到的内容与浏览器渲染结果不一致。

这个技能如何工作

支持四类输入：本地目录路径、Search Console 导出的 CSV、公开 URL，以及尚未上线的 URL/内链架构草稿。审计按固定阶段推进，不会只罗列症状。

• Phase 1 Indexing System Health：检测 404、Soft 404、Crawled - currently not indexed、noindex 标签，并判断根因属于内容、技术还是结构。
• Phase 2 Crawl Architecture：分析抓取深度、孤立页面与内部链接图，定位抓取预算浪费点。
• Phase 3 Sitemap Architecture Audit：校验 Sitemap 只包含可索引 URL，按页面/文章/商品拆分，核对 canonical 与 hreflang 回指。
• Phase 4 URL Architecture Design：识别重复 URL 与参数堆叠，输出 Clean URL Architecture Model。
• Phase 5 Redirect & Link Flow：找出重定向链/循环，绘制 Clean Redirect Flow Map。
• Phase 6 Content Quality Engine：定位薄内容、重复聚类与自动生成内容，给出合并方案。
• Phase 7 Technical Server Health：检查 5xx、403、API 失败，并验证 Next.js / Nuxt 场景下 Googlebot 能否看到与用户一致的内容。
• Phase 8 Performance & Resource Loading：从结构视角审查 render-blocking JS、CSS 延迟与懒加载错误。
• Phase 9 Internal Linking System Design：把内链图重组为 topical SEO Silo（Hub and Spoke）模型。
• Phase 10 Final Rebuild Plan：产出 Day 1 → Day 30 的清理顺序与 SEO 稳定化路线。

每次审计都会生成统一的主控表，每行包含问题、所属层（SEO/Crawl/Server/Content）、受影响 URL 或模式、根因、技术修复、结构调整、优先级和状态。例如重定向循环会标记为 Server 层，修复动作写 Flatten to 1-hop，结构调整写 Redesign routing，避免只给“优化建议”而没有工程动作。

适用边界与注意点

• 无法直接触发 Google Search Console 的 Request Indexing，只能给出需要人工执行的操作清单。
• 可以识别 render-blocking 资源和架构信号，但深度 DOM 分析依赖你提供文本、代码或报告。
• JS 重渲染站点需要单独检查 Googlebot 抓取到的 HTML 与 hydration 结果是否一致。
• 审计前建议准备好 robots.txt、Sitemap、GSC 索引覆盖报告、访问日志或项目模板，缺少这些输入时结论只能覆盖已提供的数据范围。