【免费下载链接】claude-seoUniversal SEO skill for Claude Code. 26 sub-skills 19 sub-agents covering technical SEO, E-E-A-T, schema, GEO/AEO, agent readiness (Lighthouse Agentic Browsing, WebMCP, llms.txt), backlinks, local SEO, e-commerce, international SEO, Google APIs, and PDF/Excel reporting. 9 optional extensions for live SEO data.项目地址https://gitcode.com/GitHub_Trending/cl/claude-seo点击查看免费下载导读本文围绕 claude-seo 项目中用于生成 URL 索引状态报告的官方模板skills/seo-google/assets/templates/indexation-status-report.md展开说明该模板如何承接 Search Console URL Inspection API 的实时数据将URL 是否被 Google 索引这一核心事实结构化为可读、可交接、可归档的报告。读完本文你将掌握从批量 URL 检查gsc_inspect.py到索引报告生成google_report.py --type indexation的完整调用链理解 PASS/FAIL/NEUTRAL 判定、canonical 冲突、常见索引问题等字段的业务含义并能直接套用模板产出标准化的索引审计报告。一、模板定位把索引事实变成可交付报告在 SEO 工作流中某个 URL 到底有没有被 Google 索引是一个必须由 Google 官方数据回答的问题。claude-seo 的 seo-google 技能用 Search Console URL Inspection API 获取这一事实而本模板则负责把 API 返回的原始 JSON 转译为人类可读的 Markdown 报告。模板的核心数据流是通过scripts/gsc_inspect.py对单条或批量 URL 发起 URL Inspection 请求拿到包含verdictPASS/FAIL/NEUTRAL 等、coverage state、canonical、rich results 的结构化结果按本模板的六个区块Summary、Detailed Results、Canonical Mismatches、Common Issues、Rich Results Detected组织输出可选地交给scripts/google_report.py --type indexation生成带环形图donut chart的 PDF 报告。技能文档在 skills/seo-google/SKILL.md 中明确了一个重要原则Sitemaps 只能告诉你提交了多少 URLURL Inspection API 才是索引状态的事实来源indexation truth。本模板正是这一原则在交付层的落地——它记录的不是我们提交了多少而是Google 实际收录了多少。二、模板骨架逐节解析模板全文共 42 行结构紧凑共六个数据区块外加页脚。下面逐节说明其业务含义与填写方式。1. 头部元信息**Property:** {property} **URLs Inspected:** {total_urls}Property被检查的 Search Console 资源格式为sc-domain:example.com或https://www.example.com/。gsc_inspect.py在未显式传--site-url时会从配置文件~/.config/claude-seo/google-api.json的default_property字段读取见 scripts/gsc_inspect.py。URLs Inspected本批次实际检查的 URL 总数。需要特别注意批量上限gsc_inspect.py中定义了DAILY_LIMIT 2000超过该数量的批次会被截断并给出警告见 scripts/gsc_inspect.py。2. Summary 汇总表StatusCountPercentageIndexed (PASS){pass_count}{pass_pct}%Not Indexed (FAIL){fail_count}{fail_pct}%Neutral{neutral_count}{neutral_pct}%Errors{error_count}{error_pct}%这四类统计与gsc_inspect.py中batch_inspect()的 summary 逻辑一一对应见 scripts/gsc_inspect.pyIndexed (PASS)API 返回的verdict PASS即该 URL 已被 Google 索引Not Indexed (FAIL)verdict FAIL未被索引需在 Detailed Results 中定位原因Neutralverdict为NEUTRAL或其他非 PASS/FAIL 值如VERDICT_UNSPECIFIED、PARTIALErrors请求本身失败权限不足、限流、URL 不属于该资源等此时inspection.get(error)非空。Percentage 建议按count / total_urls * 100计算并保留一位小数。在 PDF 生成端google_report.py还会额外给出索引率Index Rate并按阈值着色≥90% 显示为 success-box绿色70%–90% 为 highlight低于 70% 为 critical-box红色实现一眼判断健康度见 scripts/google_report.py。3. Detailed Results 明细表URLVerdictCoverage StateFetch StateGoogle CanonicalLast Crawl这是全报告信息密度最高的表。每一行对应gsc_inspect.py中inspect_url()返回的一个结果对象其字段直接映射到 URL Inspection API 的indexStatusResult参见 skills/seo-google/references/search-console-api.md模板列API 字段典型取值说明VerdictverdictPASS/FAIL/NEUTRAL/PARTIAL/VERDICT_UNSPECIFIED整体索引判定Coverage StatecoverageState人类可读的覆盖状态描述如 Submitted and indexed / Crawled - currently not indexed 等Fetch StatepageFetchStateSUCCESSFUL/SOFT_404/NOT_FOUND/BLOCKED_ROBOTS_TXT/ACCESS_DENIED/SERVER_ERROR/REDIRECT_ERROR/BLOCKED_4XX等抓取阶段失败原因Google CanonicalgoogleCanonicalURL 字符串Google 实际选定的 canonicalLast CrawllastCrawlTimeISO 8601 时间戳最近一次抓取时间gsc_inspect.py还会解析robotsTxtStateALLOWED/DISALLOWED、indexingStateINDEXING_ALLOWED/BLOCKED_BY_META_TAG/BLOCKED_BY_HTTP_HEADER、crawledAsDESKTOP/MOBILE与referringUrls这些字段在排查 FAIL 时可作为辅助证据见 scripts/gsc_inspect.py。4. Canonical Mismatches 冲突清单URLUser CanonicalGoogle Canonical此区块专门列出用户声明的 canonical 与 Google 选定的 canonical 不一致的 URL。判定逻辑在gsc_inspect.py中实现match googleCanonical userCanonical当两边都非空且不相等时即为冲突见 scripts/gsc_inspect.py。Canonical 冲突通常是以下原因之一页面声明的 canonical 指向 301 重定向链路的中间跳两个页面互相声明对方为 canonical循环引用站点未声明 canonicalGoogle 自行推断此时 userCanonical 可能为空需在报告中标注为 N/A 并人工核对参数化 URL 处理不当导致 Google 合并了不同的 URL 变体。冲突列表应单独成表因为它在优先级上高于一般的 FAIL 明细——即使一个 URL 已通过 PASScanonical 错误也可能导致流量和排名信号流向错误的页面。5. Common Issues 问题聚合表IssueCountPriorityAction该表把 Detailed Results 中的 FAIL 按根因聚合。建议从以下维度归类与 URL Inspection API 返回的状态字段对应Issue 归类对应 API 信号建议 Actionrobots.txt 屏蔽robotsTxtState DISALLOWED或pageFetchState BLOCKED_ROBOTS_TXT检查 robots.txt 规则是否误伤如需收录则放行noindex 屏蔽indexingState BLOCKED_BY_META_TAG/BLOCKED_BY_HTTP_HEADER移除 noindex 标签或 X-Robots-Tag 响应头软 404pageFetchState SOFT_404返回真正的 404/410 或补全内容抓取失败pageFetchState SERVER_ERROR/REDIRECT_ERROR检查服务器可用性与重定向配置权限问题pageFetchState ACCESS_DENIED/ACCESS_FORBIDDEN检查鉴权、防火墙、验证码发现但未收录coverageState Crawled - currently not indexed提升页面质量与内链权重配合 Indexing API限 JobPosting/VideoObject 等类型Priority 字段建议使用 High / Medium / Low 三级能直接解释大量 FAIL 的根因如全站 noindex为 High偶发的抓取错误为 Medium单一页面问题为 Low。6. Rich Results Detected 富结果清单URLRich Result TypeStatus此区块来自 API 的richResultsResult对象。gsc_inspect.py会解析detectedItems输出每个检测到的富结果类型如 FAQPage、HowTo、Product 等及其包含的条目与问题列表见 scripts/gsc_inspect.py。这可以帮助你判断结构化数据是否真正被 Google 识别而不仅是验证通过。7. 页脚数据边界与时效*URL Inspection API: 2,000 inspections/day per site, 600/min.* *Generated {timestamp} via Google Search Console URL Inspection API.*页脚是报告严谨性的体现明确数据来源为 GSC URL Inspection API提示配额边界每站点每天 2,000 次、每分钟 600 次。更完整的配额表见 skills/seo-google/references/rate-limits-quotas.md项目级上限为 10,000,000 QPD / 15,000 QPM可在多个站点间共享记录生成时间戳方便日后对比多轮审计结果观察索引状态随时间的变化。三、数据生产链路从命令到模板的完整调用链模板不是手工填写的而是由命令链自动产出的。完整的链路如下步骤 1单条检查用于快速验证python3 scripts/gsc_inspect.py https://example.com/page --json不带--site-url时会读取配置中的default_property。单条模式的终端输出会展示 Verdict、Coverage、Robots.txt、Indexing、Page Fetch、Last Crawl、Canonical 及 Rich Results 等信息见 scripts/gsc_inspect.py。步骤 2批量检查用于生成报告python3 scripts/gsc_inspect.py --batch urls.txt --site-url sc-domain:example.com --json inspect-data.json批量模式要求urls.txt每行一个 URL。脚本内置两层保护日配额截断超过 2,000 个 URL 时自动截断并告警节流延迟默认每次请求间隔delay1.0秒可用--delay调整把请求速率压到 600 QPM 限值以内见 scripts/gsc_inspect.py。批量结果 JSON 中的summary字段结构为{pass, fail, neutral, error}四个计数正是模板 Summary 表的数据来源。步骤 3生成 PDF 报告可选增强python3 scripts/google_report.py --type indexation --data inspect-data.json --domain example.comgoogle_report.py的indexation报告类型会渲染一个Indexation Status章节见 scripts/google_report.py包括由chart_index_status()生成的索引状态环形图四象限配色绿Indexed、红Not Indexed、灰Neutral、暗Error中心标注 URL 总数见 scripts/google_report.pyIndexed / Not Indexed 两张指标卡metric card索引率及分级着色提示逐 URL 结果表URL、Verdict、Coverage State、Last Crawl。技能层面对应命令为/seo google inspect-batch file与/seo google report indexation完整工作流参见 skills/seo-google/SKILL.md 的 Reports 一节。四、判定口径与字段语义为什么不能只看 Verdict报告的价值在于可解释的失败而不仅是失败的个数。模板的 Detailed Results 表保留 Coverage State 与 Fetch State 两列正是为了区分以下常见场景FAIL Blocked by robots.txt不是内容问题是抓取策略问题FAIL Soft 404页面存在但返回 200内容不足以被识别为有效页面FAIL Crawled - currently not indexedGoogle 已抓取但认为质量/权重不足需要内容与外链层面提升FAIL Server error纯技术故障修复服务器即可NEUTRAL判定未明确如刚提交或正在处理不应等同于失败。这些区分直接决定 Common Issues 表中 Action 列的写法。只有把 Verdict 与 Coverage State / Fetch State 组合阅读报告才能指导下一步具体操作而不是停留于有 N 个 URL 没被收录。另一个容易误读的点CrUX 的 404 与 URL Inspection 的 404 语义不同。URL Inspection 的NOT_FOUND表示 URL 本身返回 404而 CrUX API 的 404 表示流量不足、无数据——两者不要混用参见 skills/seo-google/SKILL.md 的 Technical Notes。五、配额、认证与错误处理保证审计跑得完、跑得准认证前置条件URL Inspection API 需要服务账号Service Account而非仅 API Key对应 seo-google 技能的 Tier 1。认证步骤见 skills/seo-google/references/auth-setup.md创建 GCP 项目 → 启用 Google Search Console API → 创建服务账号 → 在 GSC 的设置 用户和权限中添加服务账号的client_email读权限设为 Full 即可使用 Indexing API 才需要 Owner。配额约束速查维度限额每站点每日QPD2,000 次每站点每分钟QPM600 次每项目每日QPD10,000,000 次每项目每分钟QPM15,000 次Per site 与 Per project 的差别很关键2,000/天是按 GSC 资源维度计算10M/天是按 GCP 项目维度共享。如果你的 GCP 项目下有多个 GSC 资源总额度是 10M但每个站点单独受 2,000/天约束见 skills/seo-google/references/rate-limits-quotas.md。常见错误与处理gsc_inspect.py对三类高频错误做了内建识别见 scripts/gsc_inspect.pyHTTP场景处理400URL 不属于该资源核对 URL 与 property 是否匹配403服务账号无权限在 GSC 设置 用户和权限中添加client_email429超过 600 QPM / 2,000 QPD等待后重试参考指数退避策略1s→2s→4s→8s→16s最多 5 次碰到 429 时若响应头带Retry-After则以其值为准批量脚本默认的 1 秒delay已经考虑了 QPM 上限日常 2,000 以内的审计通常不会触雷。六、Sitemaps 与 URL Inspection 的分工避免报告口径错乱模板页脚只引用 URL Inspection API这是有意为之。seo-google 技能和对应测试tests/test_gsc_query.py反复强调一个口径问题Sitemaps API只能返回submitted提交数量、errors、warnings等反映的是提交动作而非收录结果URL Inspection API返回的是 Google 当前的索引判定是唯一的索引事实来源。因此一套严谨的索引审计应该双轨并用先用/seo google sitemaps property查看提交状态与报错再用inspect-batch对关键 URL 逐一核实真实收录情况。报告中不要混用两种口径——Sitemap 的已提交不等于已索引这正是本模板把 Summary 严格限定在 PASS/FAIL/NEUTRAL/Errors 四类的原因。七、实战工作流一套可复用的索引审计 SOP综合模板与源码一套完整的索引审计流程如下准备 URL 清单导出站点的核心页面、新增页面、疑似问题页面写入urls.txt每行一个去重控制在 2,000 个以内确认认证python3 scripts/google_auth.py --check --json验证服务账号可用批量检查python3 scripts/gsc_inspect.py --batch urls.txt --json inspect-data.json按模板整理报告将 JSON 中的summary填入 Summary 表将results展开为 Detailed Results 表从canonical.match False的记录生成 Canonical Mismatches 表按根因聚合 FAIL 生成 Common Issues 表从rich_results.detected_items生成 Rich Results 表生成 PDF可选python3 scripts/google_report.py --type indexation --data inspect-data.json --domain example.com获得带环形图的可交付报告归档与对比按 skills/seo-google/SKILL.md 的约定保存为GOOGLE-API-REPORT-{domain}.md留存时间戳以便与下一轮审计对比。八、模板的扩展方向按页面类型拆分对每个 URL 标注页面类型首页/品类页/文章页在 Summary 之外再输出按类型分组的索引率帮助定位哪类页面未被收录与 CWV 数据联动seo-google 技能同时具备 PageSpeed/CrUX 数据能力可在报告中对已索引但性能差的 URL 附加 Core Web Vitals 状态形成索引 体验复合审计问题自动分类脚本当前 Common Issues 的归类仍以人工/Agent 判断为主可以基于coverageState、pageFetchState、robotsTxtState的组合编写聚合逻辑将模板中的 Issue/Count/Priority/Action 全自动生成。结语indexation-status-report 模板虽短却是 seo-google 技能中索引审计能力的交付骨架上游对接 URL Inspection API 的实时判定下游支撑google_report.py的 PDF 可视化中间以 PASS/FAIL/NEUTRAL/Errors 四分类、canonical 冲突与富结果三个视角组织证据。无论你是用它做一次性批量审计还是把它固化为周期性索引健康度巡检的标准报告都可以直接以本模板为起点配合gsc_inspect.py与google_report.py快速落地一套可追溯、可对比、可交接的索引状态报告体系。赞分享【免费下载链接】claude-seoUniversal SEO skill for Claude Code. 26 sub-skills 19 sub-agents covering technical SEO, E-E-A-T, schema, GEO/AEO, agent readiness (Lighthouse Agentic Browsing, WebMCP, llms.txt), backlinks, local SEO, e-commerce, international SEO, Google APIs, and PDF/Excel reporting. 9 optional extensions for live SEO data.项目地址https://gitcode.com/GitHub_Trending/cl/claude-seo点击查看免费下载相关推荐如何高效自定义LabelImg导出模板专业开发者实战指南如何高效自定义LabelImg导出模板专业开发者实战指南 LabelImg作为一款开源的图像标注工具支持Pascal VOC、YOLO和CreateML等多claude-seo 实战Google Indexing API v3 索引通知全指南claude seo 实战Google Indexing API v3 索引通知全指南 本篇技术指南以 claude seo 仓库中 skills/seo g终极Google索引脚本批量处理指南10万级URL高效索引策略终极Google索引脚本批量处理指南10万级URL高效索引策略 Google索引脚本google indexing script是一款基于TypeScri开发工具上一篇解决PyTorch Geometric中torch.compile与knn_graph的兼容性问题从报错到优化的完整指南下一篇BootstrapBlazor日期范围选择器掌握最大选择范围的终极配置指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考