品牌 GEO 可见性诊断

诊断一个品牌在 AI 搜索中的可见性。核心原则：只做可复现的实证勘查，不虚构 AI 平台排名或引用率。

为什么需要这套流程

GEO 问题通常不是"内容不够多"，而是三个结构性故障：

官方信源技术层面不可抓取 → AI 读不到权威事实
品牌实体无法收敛 → 模型判定为低置信度信息
只出现在付费稿件站、缺席中立盘点 → 不在 AI 候选集里

顺序不可颠倒：技术底座 → 实体统一 → 内容建设。顺序错了，内容投入会大幅浪费。

勘查流程（按顺序执行）

第 0 步：先识别建站平台（决定后续建议的可执行性）

抓 HTML 后先看头部特征，判断是 SaaS 建站平台还是自研/自建：

curl -s -L https://<域名> | head -c 2000
curl -s -L https://<域名>/sitemap.xml | grep -o "<loc>[^<]*</loc>"

识别线索：

HTML 里的 siteId / window.__CONFIG__ 等平台标识
script src 指向的 CDN 域名（如 o.alicdn.com/msea-fe/wxz-* → 阿里云万小智）
sitemap 内域名与对外主域不一致，暴露平台二级域名（如 xxx.wanxiaozhi.store）
响应头特征（Server: Tengine / X-Powered-By: Express 等）

为什么要先做这一步：如果判定为 SaaS 建站平台，「改 SSR」「改 sitemap」「改 robots」这类标准建议用户根本执行不了，直接给出去会浪费用户时间。此时必须先做可行性三分，再给方案。

第 1 步：验证官网可抓取性（最高价值，必做）

不要只看浏览器渲染结果。直接抓原始 HTML：

curl -s -L https://<域名> | head -c 2000
curl -s -L https://<域名>/faq | wc -c
curl -sI https://<域名> | grep -i content-length

判定 CSR 空壳站的关键信号：

HTML 小于 2000 字节
存在 <div id="root"></div> 或类似空占位符
<title></title> 为空
多个不同 URL 返回完全相同的 HTML（最致命）

常见建站平台会产出这种空壳站（如阿里云万小智 wanxiaozhi、各类 AI 建站工具）。判定为 CSR 空壳即列为 P0：百度、GPTBot、ClaudeBot、PerplexityBot 基本不执行 JS，抓到的是空白页。

同时检查：

curl -s -L <域名>/sitemap.xml → sitemap 内域名是否与对外主域一致（不一致是高频问题）
页面内是否有 application/ld+json
curl -s -L <域名>/robots.txt → 是否放行 GPTBot / ClaudeBot / PerplexityBot / Google-Extended / Baiduspider

判定为 CSR 空壳站后的修复路径（按性价比排序）：

问建站商开通静态化导出 / SSR 模式 —— 成本最低。先确认平台有没有这个开关，多数 AI 建站工具（如万小智）默认输出 CSR，但部分已提供静态化选项。
CDN / Nginx 层加预渲染中间件 —— 按 User-Agent 判断：识别到爬虫 UA 就返回预渲染好的静态 HTML，真人访问仍走 CSR。不用改动现有站点，是性价比最高的折中方案，可用 Prerender.io 模式或自建 Puppeteer 渲染服务。
迁移到支持 SSR 的框架（Next.js / Nuxt）—— 成本最高，但一劳永逸，且便于部署结构化数据与独立页面。

第 2 步：检索品牌词，做信源构成分析

搜索「品牌名 + 城市」。把所有返回结果分成两组：

| 分组 | 特征 | AI 采信度 | |---|---|---| | 稿件站组 | 企业堂、百业网、中钢网、地方"新闻网"、医美头条等；内容高度同质、明显是通稿 | 低 | | 中立组 | 知乎、小红书、大众点评、腾讯搜一搜、今日头条个人号、垂直媒体盘点 | 高 |

关键判断：如果品牌只出现在稿件站组，说明是"买来的可见性"，不是 AI 真正采信的可见性。

第 3 步：检索品类词 + 城市，检查候选集收录

搜索「品类 + 城市 + 推荐/哪家/多少钱」（如"深圳纹发推荐"）。

逐一检查返回结果中每一篇清单型/对比型/体验型内容，统计品牌是否被提及。

这一步是整套诊断最重要的商业结论来源：AI 回答"XX 哪家靠谱"时优先采信清单型中立内容。品牌若在这类内容中缺席，结论不是"排名靠后"，而是"不在候选集里"——性质完全不同，修复策略也不同。

第 4 步：跨源实体一致性比对

从官网、各篇通稿、第三方平台提取以下字段做交叉比对：

官网域名（常出现多个版本）
客服电话 / 微信
品牌名写法
关键数字（客户数、学员数、年限、门店数、价格、地址）

任何冲突都列出来。模型对跨源冲突数据会降权处理。

第 5 步：内容资产盘点

检查是否存在：结构化价格页、案例详情页、独立门店页（每店一个）、FAQ 结构化标记、行业科普内容、百科词条、地图 POI、点评门店页、知乎/小红书官方原生内容。

SaaS 建站平台（万小智 / 凡科 / 上线了等）的专用处理

绝大多数中小企业官网都跑在这类平台上。 平台约束下必须做可行性三分：

| 类别 | 典型项 | 用户能否自己改 | |---|---|---| | A. 后台可自助 | 页面 TDK（Title/Description/Keywords）、H 标签、robots 文件、站点验证（百度/Bing/谷歌）、Sitemap 提交到站长平台 | ✅ 能，无需联系平台 | | B. 需实测才知 | JSON-LD 结构化数据（走平台「代码嵌入 / 自定义代码」控件） | ⚠️ 平台是 CSR 时，JS 运行时插入的 JSON-LD 爬虫读不到，必须用 curl 验证是否直出 | | C. 平台级 | SSR / 预渲染改造、页面正文直出、sitemap 内域名 | ❌ 不能，只能提工单或走「导出源码自部署」 |

常见误区：<title> 为空不等于平台限制——大多是用户从未在后台设置过 TDK，属于 A 类，今天就能修。先让用户去后台设置，再 curl 复验。

战略调整：分层判断（关键，不要一刀切）

CSR 空壳是平台架构问题，SaaS 厂商几乎不会为年费数百元的客户改渲染架构。工单要提，但不要押注。

但不要武断判定「官网这条路彻底走不通」。必须先做分层验证——head 层和正文层的可抓取性常常不同：

| 层 | 内容 | 通常能否直出 | |---|---|---| | head 层 | title、meta description、站点验证 meta、JSON-LD（若平台提供注入入口） | 多数能直出 | | 正文层 | 页面可见文案、FAQ 答案、产品描述 | CSR 站点一律抓不到 |

如何验证 head 层能否直出（必做）：让用户先在后台完成一次「站点验证」（百度/Bing/谷歌任一），然后 curl 看验证 meta 是否出现在 HTML 源码里。

判定逻辑：验证 meta 能直出 ⇒ 平台具备服务端 head 注入能力 ⇒ title / description / JSON-LD 同样能直出，值得投入。反之若验证 meta 也抓不到，才是真正的「官网彻底走不通」。

这一步同时能顺带确认另一件事：用户是否真的设置了 TDK。<title> 为空在绝大多数情况下是用户没设置，而非平台限制——先让用户设置，再 curl 复验，不要据此劝退。

官网的最终定位

验证完两层之后，官网的定位通常是：

官网 = 实体识别锚点（head 层有用，title/description/JSON-LD 能被 AI 读到）+ 用户转化页 内容型权威信源必须建在平台之外——因为正文层抓不到，靠官网内容被 AI 引用这条路不通。

平台外的优先级（按 ROI）：

百科词条（百度百科 / 搜狗百科）——实体锚点，权重最高
地图 POI + 点评门店页（高德 / 百度 / 腾讯地图 + 大众点评）——本地意图的核心信号
知乎机构号 + 原生回答——AI 高频引用，关键是提供可验证的具体细节
真实客户的一手体验内容——ROI 最高，通稿写不出这类细节

此时「实体一致性统一」的优先级上升到「官网改造」之前，因为官网短期打不通。

向 SaaS 平台提工单的话术原则

能说成「故障」的，绝不说成「需求」 —— 客服接到需求会转产品然后石沉大海；故障必须走处理流程
绝不用技术黑话 —— 不写 SSR / CSR / 预渲染 / JSON-LD，客服看不懂会被错误分类。只说现象 + 影响 + 期望
必须附可复现证据 —— curl 命令，或「浏览器右键 → 查看网页源代码（注意不是『检查』）→ 搜索页面文案 → 搜不到」这类零门槛步骤
引用平台自己的宣传语 —— 如万小智宣传「智能 SEO：自动优化页面元标签、页面结构，适配搜索引擎收录规则」，以此作为付费用户依据，比讲技术原理有效得多
结尾要求明确结论 —— 写明「请勿回复『已反馈产品团队』，请给出明确答复：是否支持 / 是否排期」，防止工单被无限期挂起
走工单系统，不走在线客服 —— 在线客服没有技术处理权限
先提最容易通过的 —— 如「sitemap 域名错误」这类客观 bug，复现成本为零、不涉及架构改动，先建立处理记录，再提架构类诉求

若工单被驳回：转向「申请导出源码 / 开通自定义 head 注入」，平台通常宣传过源码导出能力，以此为据。

复测流程（用户改完后重新验证）

用户改完后跑这一套（一次跑完，别分多次）：

# 1. HTML 大小是否变化（对比首次基线，能快速判断有没有东西生效）
curl -s -L https://<域名> | wc -c

# 2. head 层直出检查（四项一起）
curl -s -L https://<域名> | grep -o "<title>[^<]*</title>"
curl -s -L https://<域名> | grep -o '<meta name="description"[^>]*>'
curl -s -L https://<域名> | grep -c "application/ld+json"
curl -s -L https://<域名> | grep -o '<meta name="baidu-site-verification"[^>]*>'

# 3. 各页面 title 是否互不相同（判断页面级 TDK 是否生效）
for p in "" services training about faq contact; do
  echo -n "/$p -> "; curl -s -L "https://<域名>/$p" | grep -o "<title>[^<]*</title>"
done

# 4. 各页面 HTML 大小是否仍完全相同（相同=正文仍未直出）
for p in "" services training about faq contact; do
  echo -n "/$p -> "; curl -s -L "https://<域名>/$p" | wc -c
done

# 5. robots / sitemap
curl -s -L https://<域名>/robots.txt
curl -s -L https://<域名>/sitemap.xml | grep -o "<loc>[^<]*</loc>"

# 6. 排除缓存误判（Last-Modified 对比当前时间，确认已发布且缓存已刷）
curl -sI https://<域名> | grep -i "last-modified\|date\|age\|x-cache"

排查「改了但没生效」的顺序：① 是否点了「发布」（SaaS 平台改完必须发布）→ ② 看 Last-Modified 时间是否更新 → ③ 看 Age / X-Cache 判断是否命中旧缓存 → ④ 等 5–10 分钟重试 → ⑤ 仍无效才是平台不支持。

注意：截图中的验证码/密钥类字符串（如 codeva-XXXX）容易因图像识别产生个别字符误差，不要直接引用截图内容下判断，让用户自行核对平台端显示的原文。

复测期的高频问题

「sitemap 域名还是平台二级域名」 → 先让用户重新发布一次再复测。实测案例：阿里云万小智的 sitemap 在重新发布后自动改用了绑定的自定义域名，没有提工单就自愈了。不要一上来就走工单。

「TDK 找不到设置入口」 → 若平台是对话式 AI 建站（万小智等），直接让用户用自然语言下指令最快，例如「把首页标题改成：XXX」。比翻菜单效率高得多。菜单路径作为备选告知。

输出结构

按「目标问题 → 证据内容 → 权威页面 → 验证方法」组织：

诊断方法与诚实边界 —— 明确说明未调用 AI 平台引用日志，不提供引用率数据
一句话结论
证据清单（P0/P1/P2 分级，每条附可复现的抓取命令或检索结果）
问题优先级与修复顺序
分批次行动方案 —— 区分「可直接执行 / 需内部决策 / 需外部协同」
目标问题 → 证据内容 → 权威页面 → 验证方法 映射表
验证方法 —— curl 技术验证命令 + 固定问题集的 AI 可见性基线测量方法
合规提示（如适用）

关键交付物模板

JSON-LD LocalBusiness：每家门店一个，用 parentOrganization + subOrganization 关联到统一的 Organization 节点——这是让模型把多门店识别为同一品牌的关键动作。FAQ 页面额外加 FAQPage 标记。

可见性基线测量：固定 10 条用户真实问法的问题集，每月在多个 AI 平台跑一遍，每条重复问 3 次（AI 输出有随机性），记录「是否提及 / 描述是否准确 / 是否附官网链接」。

内容编写要求（决定 AI 是否愿引用）

开头 100 字内给出直接答案
用具体数字，不用模糊修饰词
主动说明局限性与不适用人群 —— 说缺点的页面更受模型信任
标注更新时间与信息出处

合规交叉检查

诊断时顺带扫一遍绝对化/难证表述（「行业首创」「终身」「100%」「第一」）和医疗/疗效暗示用语。这既是《广告法》风险，也是 GEO 问题：模型会降权夸大性表述。

注意事项

绝不虚构 AI 平台排名、引用率、抓取日志
GEO 是长期建设，不承诺即时引用或排名
第三方通稿中的价格、荣誉、资质数据未经官方确认，报告中须标注"待核实"

常见执行困惑（用户拿到方案后的高频追问）

1. 「百度 HTML 标签验证的 meta 代码塞哪里？」

百度站长平台的 HTML 标签验证要求把 <meta name="baidu-site-verification" content="..."> 塞到网站首页 <head> 里。

回答策略：

首选（推荐）：先确认 SaaS 平台是否自带站点验证流程（万小智「管理 → SEO 管理 → 站点验证 → 百度」支持 HTML 标签 / 文件 / CNAME 三种方式，平台自动注入）。这条路根本不用手动塞代码。
次选：导出源码自部署。在项目根目录 index.html 的 <head> 里加。注意 Vite/React 项目的 index.html 在根目录（不是 src/index.html），文件树里和 .gitignore、package.json 平级。

用户认知陷阱：他截图的「代码视图」可能不是 SaaS 平台设计器，而是某个 AI IDE / 代码编辑器。先确认他在哪里看代码——如果是后者，本地修改不会自动发布到平台，必须走平台发布流程。

2. 「代码嵌入控件插的 JSON-LD 为什么 curl 抓不到？」

平台是 CSR 时，自定义代码控件里的 JS 是在客户端运行时执行的，<script type="application/ld+json"> 必须出现在服务端直出的 HTML 里才能被爬虫读取。

回答：让用户改完发布后执行 curl -s -L https://<域名> | grep -o "application/ld+json"。

有输出 → 生效
无输出 → 这条路走不通，改走「平台外权威信源」（百科、地图 POI、点评、知乎）

3. 「软文里能不能把自家品牌排第一？」

不能照做。需主动说明矛盾并给替代方案，不要迎合客户。

为什么：多篇不同作者、不同平台的内容全部把同一品牌排第一，这个模式比夸张用词更易被识别。后果是平台折叠/封号 + AI 整类降权，整批投入归零。客户此前投放的付费通稿往往正是因此失效——这点要直接讲明。

替代方案（效果接近，风险低得多）：

首位提及 —— 让品牌成为文中第一个被说到的具体机构。AI 摘要提取优先抓取「最早出现 + 出现频次最高」的实体，实际效果与排第一接近。
分类施策 —— 品牌词、强相关业务场景可以排第一；行业科普类（讲风险、讲原理、讲失败案例）硬塞第一反而摧毁可信度，应以科普为主、品牌在举例或解决方案处自然带出；竞品盘点类改为写「判断方法 + 区域分组」，不做自排榜单。
真实数据分布 —— 价格、参数如实标注，不做最低也不做最高。真实价格数据是 AI 最爱引用的内容，虚构反而降权。

更有效的路径（优先级高于自发布，务必优先提出）：对「XX 哪家靠谱」这类盘点型问题，最优解是联系已写过同类盘点的第三方创作者，提供真实免费体验名额换取真实测评。一篇真实第三方测评的 AI 采信权重高于十篇自述内容，成本也更低。