给公众号搭一个 GEO 实体页：JSON-LD、三副本一致性与两次线上踩坑

1. 起因：货架变成了 1–3 张卡

有行业调研转述的数据显示，2026 双11 期间约 79.4% 的消费者购物前会先问 AI，AI 对消费决策的影响力约 43.7%；对话式购物转化率约 12.3%，关键词搜索约 3.1%。

先把口径讲清楚：这几个数字来自不同平台、不同场景的转述，我没有见到原始报告，只能当方向性参考，不宜当成精确结论引用。同样，流传的「德化某白瓷品牌靠 AI 推荐月订单涨 10 倍、成交额同比约 677%」是单点个案，不能照搬成规律。

但方向本身值得动手。搜索时代给用户一整页货架，对话时代往往只给 1–3 张卡。要争的不再是「排在结果页第几」，而是「有没有资格被拼进那段答案」。

我把这件事拆成三层，做成了一个可部署的实体页：

实体层   → 你是谁（机器可读的身份声明）
内容层   → 你说了什么（可被抽取的正文结构）
一致性层 → 各处说法是否一致（避免互相打架）

三层都做完，才算一个能被答案引擎正常读取的实体页。

---

2. 实体层：先让机器知道「这是一个谁」

公众号有个天然缺陷：它没有一个公开、可抓取、可自定义的权威实体页。文章散落在 mp.weixin.qq.com/s/...，但没有一处集中声明「这个账号是谁、作者是谁、写过什么」。

我的做法是单独建一个静态页（Cloudflare Pages），在 <head> 里放一段 NewsMediaOrganization：

{
  "@context": "https://schema.org",
  "@type": "NewsMediaOrganization",
  "name": "《AI的哥德巴赫猜想》",
  "url": "https://mp.weixin.qq.com/mp/profile_ext?action=home&__biz=Mzk2ODAwNjU1MQ==",
  "description": "聚焦 AI ×（变现 / 副业 / 投资 / 算力经济 / AI 安全 / 落地应用）的微信公众号，作者为 Slash AI。",
  "founder": {
    "@type": "Person",
    "name": "Slash AI",
    "jobTitle": "公众号作者 / AI 商业观察者"
  },
  "keywords": ["AI商业化", "AI产业落地", "GEO生成式引擎优化" ],
  "sameAs": [
    "https://mp.weixin.qq.com/mp/profile_ext?action=home&__biz=Mzk2ODAwNjU1MQ==",
    "https://slashai.online"
  ],
  "hasPart": [
    {
      "@type": "Article",
      "headline": "文章标题",
      "author": { "@type": "Person", "name": "Slash AI" },
      "datePublished": "2026-11-04",
      "url": "https://mp.weixin.qq.com/s/xxxx",
      "description": "一句话摘要",
      "article:section": "AI产业落地"
    }
  ]
}

几个容易忽略的点：

• founder 要单独声明作者 Person。只写组织不写人，作者 IP 就建不起来。答案引擎问「谁写的」时缺一个明确锚点。
• url 指向权威实体页，不是随便一个落地页。这个账号没有独立官网，所以我用公众号主页（__biz 参数那个）作为权威页，静态站作为事实枢纽。
• sameAs 用来消歧：把主页、自定义域名、代表性文章链接都列进去，让机器知道这些是同一个实体的不同出口。
• hasPart 是内容证据：每篇文章一条 Article，带 headline / author / datePublished / url / description。它比「我们写过很多好文章」这种自述有用得多。

线上目前的实际规模：sameAs 6 条、hasPart 13 条、keywords 76 个，页面可见文章卡片 13 张——可见区和结构化数据里的条数必须一致，这点后面会讲怎么校验。

---

3. 内容层：写给人看，也要写给抽取器看

结构化数据解决的是「你是谁」，正文解决的是「你能回答什么问题」。我给每篇文章固定了几个约束：

约束	做法	为什么
开篇直接答案句	第一段就把结论说完，不铺垫	抽取器常取首段作为答案候选
唯一 h1	全文只有一个主标题	避免主题信号被稀释
来源标注	每个数字后面写清来源与口径	降低被判定为不可核验内容的概率
对比表	关键差异用表格而非长段	表格是天然的结构化片段
文末 FAQ	2–4 个用户真会问的问题	对齐问答式检索意图
实体首定义	首次出现的术语给一句定义	让「GEO 是什么」有可引用的答案句

这里有个反直觉的经验：会讲故事的写法，在 AI 回答里未必占优。有监测转述提到，若干品类中社媒侧声量高的头部品牌，在 AI 回答里的出现占比明显偏低（社媒侧约 34.5%、AI 侧约 5.6%）。这个数据同样是转述、不宜当精确值，但它指向一个可操作的判断：模型更容易引用参数、条款、检测报告这类「证据语言」，而不是体感、身份、场景这类「种草语言」。

---

4. 一致性层：三副本 + 一处改动要动五个地方

这是最容易翻车的部分。我维护了三份内容：

1. index.html — 可见页面 + <head> 里的完整 JSON-LD
2. facthub_jsonld.html — 可单独复制粘贴的 JSON-LD 片段
3. FactHub_*.md — 文档副本，用于人工复核与资料库归档

只要新增一篇文章，必须同步改五处：

• 可见卡片区：新文章置为序号 1，其余整体顺延
• hasPart：追加一条 Article
• sameAs：如有新的权威链接则追加
• meta description / og:description 里的「N 篇代表文章」计数
• 三副本全部对齐，然后重新部署

为什么非要三份？ 因为一旦 hasPart 里有 13 条、可见卡片只有 12 张、描述里还写着「12 篇」，机器拿到的就是互相矛盾的信号。一致性的价值不是整洁，是可信。

部署用的是整目录上传，不是单文件：

npx wrangler pages deploy . --project-name=slashai

token 走环境变量注入，不要写进脚本或提交进仓库。

---

5. 验证：别只看 HTTP 200

我上线后会跑两类校验。第一类是计数：

curl -s https://slashai.online | grep -c 'class="article"'

第二类是把页面里的 JSON-LD 真正解析出来，而不是 grep 到字符串就算过：

import json, re
html = open("index.html", encoding="utf-8").read()
m = re.search(r'<script type="application/ld+json">(.*?)</script>', html, re.S)
d = json.loads(m.group(1))
print(d["@type"], len(d["sameAs"]), len(d["hasPart"]))

这一步能抓到「JSON 少了个逗号」「引号没转义」这类 grep 发现不了的问题。结构化数据的正确性要按解析结果判定，不按肉眼判定。

---

6. 两个真实的坑

坑一：未核验的第三方脚本被自动化部署顺带推上线

排查访问量时，我在 <head> 里临时插过一段第三方统计 beacon，token 是没核验过的占位值，插完没来得及验证。

结果当天 10:00 的定时任务执行「部署整个目录」时，把这段还没验证的脚本一起发了上去。发现后我把它从 index.html 删掉、重新部署，线上复验残留为 0。

教训有两条：

• 整目录部署会带上目录里所有未提交意图的改动，临时试验不要写进会被自动化部署的生产目录。
• 任何第三方脚本上线前先验证凭据有效性，占位 token 既收不到数据，还多一个外部请求。

坑二：想要「按域名精确统计」，实际拿不到

我原本想看这个站点的单域名精确访问量。查下来：Pages 项目的 web_analytics_tag / web_analytics_token 都是 null，Web Analytics 没启用；Pages REST Analytics 端点也不可用。

能用的只剩 Cloudflare GraphQL 的 httpRequests1dGroups，它给 pageViews 和 requests，但是账户级日聚合，而且这个账户的 Zone 数是 0、Pages 项目只有 slashai 一个，GraphQL 又不支持 host 维度过滤。所以结论是：账户级数据可以近似当本站流量看，但它不是域名级精确值。

另外它按 UTC 自然日切分，与北京时间差 8 小时；requests 含静态资源、爬虫和接口探测，看访客要优先看 pageViews。

我最后选择把这几条限制直接写进日报里，而不是造一个看起来更漂亮的数字。测不准就标明测不准，比伪造精度有用。

---

7. 效果与边界（不吹的部分）

目前能确认的只有两件事：结构化数据在线上可被正常解析；13 篇文章、6 条 sameAs、76 个关键词与可见区一致。

我没有可靠数据证明「被 AI 引用的次数提升了」——站点级引用数据现在拿不到，账户级流量统计也只是近似。所以这篇不写「涨了多少」的结论，只写可复现的做法和可验证的状态。

如果你也在做类似的事，我的建议是按这个顺序来：先把实体声明补齐，再统一正文结构，最后解决一致性。跳过前两步直接铺关键词，收益很有限。

---

作者：Slash AI · AI 商业观察

本文是《AI的哥德巴赫猜想》实体页建设的一份公开实验记录。

参考资料 / 实验样本

• schema.org — NewsMediaOrganization / Article 类型定义：https://schema.org/NewsMediaOrganization
• 「实验样本页（可查看源码中的 JSON-LD）」：slashai.online
• 文中双11 与转化率数据为行业调研转述，未见原始报告；德化品牌为单点个案，均仅作方向性参考。