面向 AI 搜索的 GEO 技术 SEO 审计指南以 geo-seo-claude 的 geo-technical 智能体为实战框架【免费下载链接】geo-seo-claudeGEO-first SEO skill for Claude Code. Comprehensive AI search optimization for any website — citability scoring, AI crawler analysis, brand authority, schema markup, platform-specific optimization, and PDF reports. If you want learn how to sell this to real businesses, check out the skool community项目地址: https://gitcode.com/gh_mirrors/ge/geo-seo-claude导读本文基于 geo-seo-claude 仓库中的 geo-technical 智能体规范 及其配套的 geo-technical 技能、页面抓取脚本 与测试用例系统讲解一套完整的、同时服务传统搜索引擎与 AI 爬虫GPTBot、ClaudeBot、PerplexityBot 等的技术 SEO 审计方法。读完本文你将掌握从响应头抓取、robots.txt 与 sitemap 校验、Meta 标签审计、安全头检查、URL 结构评分、移动端优化、Core Web Vitals 风险评估、服务端渲染SSR判定到 RFC 8288 服务发现与 Markdown 内容协商等 11 步审计流程并理解每一项检查背后的源码级实现与扣分规则能够直接复现出一份可交付的 Technical Score 报告。为什么技术 SEO 是 GEO 的地基在 geo-seo-claude 的评分体系见 docs/scoring-methodology.md中Technical Foundations 占总 GEO 分的15%由geo-technical智能体独立评估。它的核心理念非常直白一个技术上无法被爬取、索引、引用的网站内容写得再好也无法被任何平台引用。更关键的一点是 GEO 与传统 SEO 的差异AI 爬虫通常不执行 JavaScript。GPTBot、ClaudeBot、PerplexityBot 抓取的是原始 HTML 并直接解析如果你的正文依赖客户端渲染AI 爬虫看到的就是一个空页面。因此服务端渲染SSR分析被 agents/geo-technical.md 列为最高优先级检查在总分中独占25% 权重是整个审计中影响最大的单一维度。| Category | Weight | Max Points | |---|---|---| | Server-Side Rendering / JS Dependency | 25% | 25 | | Meta Tags Indexability | 15% | 15 | | Crawlability (robots.txt, sitemap) | 15% | 15 | | Security Headers | 10% | 10 | | Core Web Vitals Risk | 10% | 10 | | Mobile Optimization | 10% | 10 | | URL Structure | 5% | 5 | | Response Headers Status | 5% | 5 | | Additional Checks | 5% | 5 |在完整审计流程中/geo audit会并行启动 5 个子智能体见 geo/SKILL.md 的 Orchestration Logic其中geo-technical专门负责技术维度/geo technical url命令则可单独运行一次纯技术审计输出GEO-TECHNICAL-AUDIT.md。以下是这套审计的完整执行步骤。第 1 步抓取页面 HTML 与响应头审计的第一步是用 WebFetch 抓取目标 URL 的原始 HTML并完整记录 HTTP 响应头。以下响应头字段每一项都有具体的技术含义响应头字段关注点Status Code200 / 301 / 302 / 404 等状态码判断可达性与重定向Content-Type确认返回的是 HTML 文档Cache-Control / ETag缓存策略与内容校验X-Robots-Tag可覆盖meta robots优先级更高Server识别底层技术栈如 nginx、CloudflareContent-Encoding压缩方式gzip、brLink:头完整捕获所有值供第 10 步 RFC 8288 服务发现分析使用仓库里的 scripts/fetch_page.py 提供了这套抓取的脚本化实现fetch_page()会记录status_code、redirect_chain通过response.history追踪每一跳、完整响应头并单独提取 6 个安全头到security_headers字段。其命令行用法为python scripts/fetch_page.py url page python scripts/fetch_page.py url full # 一次性输出 page robots llms sitemap第 2 步robots.txt 与 XML SitemapRobots.txt 检查清单默认规则User-agent: *是否存在是否有针对特定爬虫Googlebot、Bingbot 及各类 AI 爬虫的规则Disallow模式是否误伤重要内容Crawl-delay指令可能拖慢索引速度是否引用 Sitemap语法错误或格式问题AI 爬虫访问GEO 关键项skills/geo-technical/SKILL.md 专门列出了 10 个需要重点检查的 AI 爬虫及其对应平台CrawlerUser-AgentPlatformGPTBotGPTBotChatGPT / OpenAIGoogle-ExtendedGoogle-ExtendedGemini / Google AI trainingGooglebotGooglebotGoogle Search AI OverviewsBingbotbingbotBing Copilot ChatGPT (via Bing)PerplexityBotPerplexityBotPerplexity AIClaudeBotClaudeBotAnthropic ClaudeAmazonbotAmazonbotAlexa / Amazon AICCBotCCBotCommon Crawl大量 AI 模型的数据源FacebookBotFacebookExternalHitMeta AIBytespiderBytespiderTikTok / ByteDance AI一个必须强调的细节屏蔽 Google-Extended 并不会屏蔽 Googlebot。Google-Extended 只控制 AI 训练数据的使用不影响搜索索引但屏蔽它可能降低网站在 AI Overviews 中的出现率。除非有明确的数据授权顾虑规范建议放行 Google-Extended。在源码层面scripts/fetch_page.py 的fetch_robots_txt()内置了更完整的 14 个爬虫清单额外包含 OAI-SearchBot、ChatGPT-User、anthropic-ai、cohere-ai、GoogleOther 等并实现了一套状态判定逻辑Disallow: /→BLOCKED部分Disallow→PARTIALLY_BLOCKED有规则但未屏蔽 →ALLOWED无专属规则但有User-agent: *且未屏蔽 →ALLOWED_BY_DEFAULT无任何规则 →NOT_MENTIONEDrobots.txt 不存在404→NO_ROBOTS_TXTfetch_robots_txt还会从 robots.txt 中解析Sitemap:声明自动修复 Sitemap:http... 被误切的问题供后续 sitemap 校验使用。XML Sitemap 校验优先读取 robots.txt 中引用的位置否则尝试/sitemap.xml、/sitemap_index.xml校验 XML 格式是否正确检查lastmod是否存在且时间是否准确/新鲜统计 URL 数量与站点实际规模比对过大或过小都要标记目标 URL 是否出现在 sitemap 中大型站点需检查 sitemap index单个 sitemap 上限约 5 万条 URL抽样验证 sitemap 内 URL 是否都返回 200crawl_sitemap()实现了完整的 sitemap 爬取依次尝试/sitemap.xml、/sitemap_index.xml、/sitemap/遇到sitemapindex 会递归抓取子 sitemap最多发现 50 个页面与 geo/SKILL.md 中每次审计最多 50 页的质量门限一致。第 3 步Meta 标签分析从页面 HTML 中提取并评估所有 SEO 相关 meta 标签。以下表格给出了每个标签的检查标准与缺失后果Meta Tag检查点缺失/错误的影响title存在50-60 字符含主关键词缺失 无法控制搜索结果标题meta namedescription存在150-160 字符有吸引力且含关键词缺失 Google 自行生成摘要link relcanonical存在自引用或指向首选版本缺失 潜在的重复内容问题meta namerobots检查 noindex、nofollow、noarchive、nosnippet、max-snippetnoindex 页面被排除在搜索之外meta nameviewport存在且为widthdevice-width, initial-scale1缺失 移动端可用性失败html lang...存在且语言代码正确缺失 语言识别问题Open Graph 标签og:title、og:description、og:image、og:url、og:type缺失 社交/AI 预览效果差Twitter Card 标签twitter:card、twitter:title、twitter:description、twitter:image缺失 X/Twitter 预览效果差link relalternate hreflang...多语言站点必须存在多语言站点缺失 返回错误语言版本注意分析 meta 标签时既要看存在性也要看质量。一个存在但内容是 Home 或 Untitled 的 title 标签实际上等同于缺失。fetch_page.py中对 meta 标签的解析逻辑遍历所有meta标签同时读取name和property属性兼容 Open Graph 的property写法统一小写存入meta_tags字典并单独提取description、canonical、title为独立字段。第 4 步安全响应头安全头对用户和搜索引擎都是信任信号缺失 HTTPS 属于致命问题。检查标准与扣分规则如下Header期望值缺失风险扣分HTTPS站点通过 HTTPS 加载浏览器警告、排名惩罚-30致命Strict-Transport-Security (HSTS)max-age31536000; includeSubDomains易受降级攻击-10Content-Security-Policy (CSP)明确限制资源来源的策略XSS 漏洞风险-10X-Frame-OptionsDENY或SAMEORIGIN点击劫持漏洞-5X-Content-Type-OptionsnosniffMIME 类型嗅探攻击-5Referrer-Policystrict-origin-when-cross-origin或更严格来源数据泄露-5Permissions-Policy限制浏览器功能访问功能滥用风险-3fetch_page.py会从响应头中逐一提取这 6 个安全头HSTS、CSP、X-Frame-Options、X-Content-Type-Options、Referrer-Policy、Permissions-Policy存入security_headers字典为后续扣分计算提供结构化数据。第 5 步URL 结构评估目标 URL 及可观察的站点 URL 模式评分标准干净、可读的 URL无过多参数、session ID 或 hash 片段含相关关键词的描述性 slug反映站点结构的逻辑层级如/category/subcategory/page一致的 URL 格式结尾斜杠、www 与 non-www 统一合理的 URL 长度100 字符以内为佳仅小写无混合大小写用连字符分词不用下划线避免不必要的嵌套深度超过 4 层需要警惕评分区间0-100干净、描述性、有层级80-100小问题长度、轻微不一致60-79明显问题参数、无层级40-59严重问题session ID、过深嵌套、不可读0-39第 6 步移动端优化从 HTML 源码分析移动端优化信号meta nameviewport存在且配置正确响应式设计指标内联/外部样式表中的媒体查询、flexbox/grid/百分比宽度等弹性布局、srcset/sizes/picture响应式图片触控友好指标按钮/链接最小 44x44px 触控目标、不依赖 hover 交互无横向滚动迹象固定宽度元素不超出视口字体大小充足基础字号 ≥ 16px保证移动端可读性skills/geo-technical/SKILL.md 补充了一个关键背景自 2024 年 7 月起 Google 仅用移动版 Googlebot 抓取所有网站不存在桌面抓取。如果站点在移动端不可用就等于对 Google 不可用。第 7 步Core Web Vitals 风险评估重要前提这是基于 HTML 源码的静态风险评估不是真实测量。真实的现场数据field data需要 PageSpeed Insights 或 CrUX。报告输出时必须明确标注这一点。LCPLargest Contentful Paint风险指标大尺寸首屏图片未加loadinglazy或fetchpriorityhighhead中存在阻塞渲染的 CSS/JS无media属性的样式表、无async/defer的脚本Web 字体未设置font-display: swap或font-display: optional缺少关键资源的预加载提示link relpreload首屏大图缺少 width/height 属性或显式尺寸INPInteraction to Next Paint风险指标注意INP 已于 2024 年 3 月取代 FIDFirst Input Delay成为 Core Web Vital不要再引用 FID 作为现行指标。head中的重型 JS bundle 未加defer或async大量同步script标签复杂 DOM 结构嵌套过深、元素数量过多同步加载第三方脚本analytics、广告、widgetHTML 中可见的事件处理器onclick 等暗示沉重的 JS 交互层CLSCumulative Layout Shift风险指标图片无显式width/height属性embed/iframe 无尺寸首屏动态注入内容广告位、banner无font-display属性可能导致文字回流媒体元素缺少aspect-ratioCSS 或尺寸属性每项 Vital 的风险评级Low Risk几乎没有指标Medium Risk存在部分指标High Risk发现多项指标skills/geo-technical/SKILL.md 给出了 2026 年视角下的具体阈值以真实用户数据的75 分位为基准MetricGoodNeeds ImprovementPoorLCP 2.5s2.5s - 4.0s 4.0sINP 200ms200ms - 500ms 500msCLS 0.10.1 - 0.25 0.25第 8 步服务端渲染与 JavaScript 依赖最关键这是 GEO 审计中最重要的检查。GPTBot、ClaudeBot、PerplexityBot 等 AI 爬虫一般不执行 JavaScript依赖 JS 渲染的内容对 AI 搜索完全不可见。客户端渲染CSR迹象body内容为空或极少只有一个根 div如div idroot或div idapp存在客户端框架 bundle 且无 SSR 信号Reactbundle.js/main.js 空 bodyVueapp.jsdiv idappAngularmain.jsapp-rootNext.js/Nuxt检查__NEXT_DATA__或__NUXT__脚本出现这些反而说明 SSR 已启用noscript标签包含后备内容暗示主内容依赖 JS内容通过 API 调用加载内联脚本中的 fetch/XHR 模式服务端渲染SSR迹象初始响应中即有完整 HTML 内容原始 HTML 中可见段落、标题、正文__NEXT_DATA__脚本Next.js SSR/SSG__NUXT__或__NUXT_DATA__Nuxt.js SSR/SSGdata-reactroot或data-server-rendered属性初始 HTML 中渲染完整 meta 标签非 JS 注入脚本执行前body中已有大量正文严重程度分级CRITICAL不执行 JS 时页面 body 基本为空AI 爬虫什么都看不到HIGH主内容存在但导航、侧边栏、相关内容等显著区块依赖 JSMEDIUM核心内容已服务端渲染但交互元素和次要内容依赖 JSLOW完全服务端渲染JS 只是增强而非创造内容源码级的 SSR 判定实现仓库用真实代码实现了上述判定。scripts/fetch_page.py 的fetch_page()中SSR 检测逻辑如下用正则idre.compile(r(app|root|__next|__nuxt), re.I)找到框架式根节点在decompose()破坏 DOM 树之前测量每个根节点内部的文本长度只有当根节点内部文本 50 字符且整页词数 200 时才判定为纯客户端渲染has_ssr_content False并记录错误。这个双重阈值设计是为了修复真实世界中一个非常典型的误报问题tests/test_fetch_page_ssr.py 明确记录了 Issue #19 的场景——大量使用框架式根 dividapp、idroot但实际通过 SSR/预渲染输出完整 HTML 的站点如 WordPress Bricks Builder、LiteSpeed Cache、Prerender.io、Next.js 预渲染过去会被错误标记为纯 CSR。测试用例覆盖了WordPress/Bricks 站点有idapp但内容完整→ 不得误报LiteSpeed Cache 站点有idroot→ 不得误报Next.js 预渲染有id__next→ 不得误报空div idapp/div bundle.js → 必须正确标记为 CSRdiv idrootLoading.../div main.js → 必须正确标记为 CSRSSR 测量必须在decompose()之前进行否则根节点内嵌套的 script/style 会导致字数读成 0这正是把规范变成可验证工程的最佳示例判定标准由测试锁定避免对真实站点产生灾难性误报。第 9 步其他技术检查重复内容信号检查 canonical 缺失、基于参数的 URL 变体、www/non-www 解析重定向链记录目标 URL 是否经过多次跳转才到达查看响应码国际化多语言站点检查 hreflang 标签结构化数据错误检查源码中 JSON-LD 的语法问题畸形 JSON、缺少必填字段资源提示检查link relpreconnect、link reldns-prefetch、link relpreload等性能优化手段fetch_page.py还会提取所有script[typeapplication/ldjson]扁平化graph和顶层数组Next.js 和多数 CMS 输出的是单个{graph:[...]}块让每个实体独立成为一条带type的记录解析失败会记入errorsInvalid JSON-LD detected。另外fetch_page.py同时抓取所有img的 src、alt、width、height、loading 属性——这些正是 LCP/CLS 风险评估的原始素材。第 10 步Agent-Readiness 信号不计分以下检查不影响 Technical Score属于前瞻性的 AI Agent 兼容性信号以 Agent-Readiness Signals 小节单独输出。RFC 8288 Link Headers服务发现直接复用第 1 步捕获的Link:响应头无需额外请求解析所有url; relrelation-type键值对识别高价值 rel 类型api-catalogRFC 9609、describedby、service-doc、mcp-server-card若存在记录发现结果若不存在仅当站点是 API-first导航中有 API 文档、存在/api/或/developers/路径、sitemap 含 OpenAPI时才给出建议普通商业站点直接省略该小节。skills/geo-technical/SKILL.md中的处理矩阵状态处理方式Link:头存在含已知 rel 类型信息性——记录发现Link:头存在rel 类型未知信息性——说明并解释缺失API-first 站点建议——解释并给出实施示例如Link: /.well-known/api-catalog; relapi-catalog缺失普通商业站点省略——不展示Markdown 内容协商向首页发送一个带Accept: text/markdown头的 GET 请求额外一次 HTTP 请求若响应Content-Type为text/markdown或text/markdown; charsetutf-8通过——记为领先能力若响应为标准 HTML给出前瞻性建议——Cloudflare Workers/Pages 站点可用一行配置开启该能力若请求报错或返回非 200跳过并记录错误不扣分。这也与仓库中fetch_page.py的DEFAULT_HEADERS设计相呼应抓取时使用真实的浏览器 User-Agent 与标准 Accept 头确保与 AI 爬虫的实际请求行为可比。第 11 步计算 Technical Score按第 1 步的权重表汇总各类目得分得到 0-100 的 Technical Score。在完整 GEO 审计中该分数乘以 15% 权重汇入总 GEO Score见 docs/scoring-methodology.md 的公式。skills/geo-technical/SKILL.md 同时提供了一套细粒度加点式的替代评分体系满分 100 分适用于需要更精细拆分的场景类目满分说明Crawlability15robots.txt 有效性 3 AI 爬虫放行 5 sitemap 3 3 次点击内可达 2 无误 noindex 2Indexability12canonical 3 无重复内容 3 分页处理 2 hreflang 2 无索引膨胀 2Security10HTTPS 4 HSTS 2 各安全头各 1URL Structure8干净 URL 2 逻辑层级 2 无重定向链 2 参数处理 2Mobile Optimization10viewport 3 响应式布局 3 触控目标 2 字体 2Core Web Vitals15LCP 5 INP 5 CLS 5Server-Side Rendering15正文在原始 HTML 8 meta/结构化数据 4 内部链接 3Page Speed Server15TTFB 3 页面体积 2 图片优化 3 JS bundle 2 压缩 2 缓存 2 CDN 1Total100分数解读90-100Excellent——对传统 SEO 和 GEO 都技术过硬70-89Good——有次要问题但基础扎实50-69Needs Work——显著技术债务影响可见性30-49Poor——重大问题阻碍爬取、索引或 AI 可见性0-29Critical——根本性技术失败需立即处理SSR/JS 依赖之所以权重最高是因为它是决定 AI 爬虫能否访问内容的最大单一因素——这是整套评分体系的基石逻辑。报告输出格式geo-technical智能体最终输出结构化的 Technical Foundations 报告小节标准模板如下## Technical Foundations **Technical Score: [X]/100** [Critical/Poor/Fair/Good/Excellent] ### Score Breakdown | Category | Score | Weight | Weighted | Status | |---|---|---|---|---| | Server-Side Rendering | [X]/100 | 25% | [X] | [Flag] | | Meta Tags Indexability | [X]/100 | 15% | [X] | [Flag] | | Crawlability | [X]/100 | 15% | [X] | [Flag] | | Security Headers | [X]/100 | 10% | [X] | [Flag] | | Core Web Vitals Risk | [X]/100 | 10% | [X] | [Flag] | | Mobile Optimization | [X]/100 | 10% | [X] | [Flag] | | URL Structure | [X]/100 | 5% | [X] | [Flag] | | Response Status | [X]/100 | 5% | [X] | [Flag] | | Additional Checks | [X]/100 | 5% | [X] | [Flag] | ### Server-Side Rendering Assessment **Status:** [CRITICAL/HIGH/MEDIUM/LOW risk] **Rendering Type:** [SSR/SSG/CSR/Hybrid] **Framework Detected:** [Next.js/Nuxt/React SPA/Vue SPA/WordPress/etc.] [关于 AI 爬虫能看到/看不到什么的详细发现] ### Crawlability Indexability **Robots.txt:** [Found/Not Found] — [Key findings] **XML Sitemap:** [Found/Not Found] — [Key findings] **Meta Robots:** [Indexable/Noindex/Other] **Canonical:** [Self-referencing/Cross-domain/Missing] ### Meta Tags Audit | Tag | Status | Value/Issue | |---|---|---| | Title | [Present/Missing] | [Value or issue] | | Description | [Present/Missing] | [Value or issue] | | Canonical | [Present/Missing] | [Value or issue] | | Viewport | [Present/Missing] | [Value or issue] | | Language | [Present/Missing] | [Value or issue] | | Open Graph | [Complete/Partial/Missing] | [Details] | | Twitter Card | [Complete/Partial/Missing] | [Details] | ### Security Headers | Header | Status | Value | |---|---|---| | HTTPS | [Yes/No] | | | HSTS | [Present/Missing] | [Value] | | CSP | [Present/Missing] | [Summary] | | X-Frame-Options | [Present/Missing] | [Value] | | X-Content-Type-Options | [Present/Missing] | [Value] | | Referrer-Policy | [Present/Missing] | [Value] | ### Core Web Vitals Risk Assessment | Vital | Risk Level | Indicators Found | |---|---|---| | LCP | [Low/Medium/High] | [Key indicators] | | INP | [Low/Medium/High] | [Key indicators] | | CLS | [Low/Medium/High] | [Key indicators] | Note: 这是静态 HTML 分析请用 PageSpeed Insights 或 CrUX 数据验证现场测量值。 ### Mobile Optimization **Status:** [Optimized/Partially Optimized/Not Optimized] [Key findings] ### URL Structure **Target URL:** [URL] **Assessment:** [Clean/Minor Issues/Problematic] [Key findings] ### Agent-Readiness Signals (non-scoring) #### RFC 8288 Link Headers (Service Discovery) **Status:** Present / Absent / Not Applicable #### Markdown Content Negotiation **Status:** Supported / Not Supported **Test:** GET [url] with Accept: text/markdown **Response Content-Type:** [value] ### Priority Actions 1. **[CRITICAL]** [Action item — 尤其 SSR/JS 问题] 2. **[HIGH]** [Action item] 3. **[HIGH]** [Action item] 4. **[MEDIUM]** [Action item] 5. **[LOW]** [Action item]独立运行/geo technical时输出的是GEO-TECHNICAL-AUDIT.mdskills/geo-technical/SKILL.md 给出了该文件的完整模板含 8 类目明细表、AI 爬虫访问矩阵表、Critical Issues / Warnings / Recommendations 三段式行动清单以及 Agent-Readiness Signals 小节。实战案例一个典型的技术性致命伤仓库的 examples/electron-srl.com-audit.json 提供了一个绝佳的对照样本意大利教育设备制造商 Electron Srl 的完整审计显示其服务器对所有非浏览器 User-Agent 返回 HTTP 403——GPTBot、ClaudeBot、PerplexityBot 全部被拒之门外。这直接导致该站点对 5 个 AI 平台中的 4 个完全不可见Technical Foundations 仅得 38/100POOR总 GEO 分 28/100CRITICAL。这个案例同时揭示了技术审计的另一个真相爬虫可访问 是一个比 robots.txt 更底层的前提。即使 robots.txt 完全放行Web 应用防火墙Wordfence、Sucuri 等或 Cloudflare 规则层面的 User-Agent 拦截同样会让 AI 爬虫拿不到内容——这正是第 1 步响应头抓取和第 2 步爬虫访问检查必须组合使用的原因。重要注意事项审计执行红线SSR 分析是最高优先级检查。如果页面是无 SSR 的客户端 SPA这是影响整个 GEO 审计的致命发现——此时无论内容优化得多好AI 可见性都无从谈起。Core Web Vitals 的 HTML 静态分析是风险估计不是测量。必须注明真实测量需要现场数据。INP 已于 2024 年 3 月取代 FID任何报告中不得再把 FID 列为现行 Core Web Vital。安全头是用户和搜索引擎的双重信任信号缺失 HTTPS 是致命发现-30 分。分析 meta 标签时同时看存在性与质量Home、Untitled 这类占位标题等同于缺失。AI 爬虫遵守 robots.txt但处理方式可能与传统爬虫不同要留意 Googlebot 规则与 AI 爬虫规则之间的差异。Agent-Readiness 信号不参与计分。RFC 8288 与 Markdown 内容协商均属 IETF 草案或早期采用特性缺失不应被惩罚只输出通过或建议。IndexNow 协议值得关注见 skills/geo-technical/SKILL.md由于 ChatGPT 与 Bing Copilot 都依赖 Bing 索引通过 IndexNow 让 Bing 更快收录内容就能更快在两个主要 AI 平台上获得可见性Google 不支持但会监控该协议。延伸阅读geo-technical 智能体完整规范——本文的规范源头含全部 11 步与扣分细节geo-technical 技能文件——8 大类目加点式评分、AI 爬虫清单、IndexNow 与 Agent-Readiness 完整细则页面抓取脚本——robots.txt 解析、SSR 判定、JSON-LD 扁平化等功能的工程实现SSR 检测测试用例——验证判定启发式对真实站点不误报的测试集评分方法论——Technical Foundations 在总 GEO 分中的权重与计算方式GEO 技能总纲——5 子智能体并行编排与命令路由完整审计示例——真实站点的技术问题对照样本【免费下载链接】geo-seo-claudeGEO-first SEO skill for Claude Code. Comprehensive AI search optimization for any website — citability scoring, AI crawler analysis, brand authority, schema markup, platform-specific optimization, and PDF reports. If you want learn how to sell this to real businesses, check out the skool community项目地址: https://gitcode.com/gh_mirrors/ge/geo-seo-claude创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考