TL;DR: 在覆盖 ChatGPT、Perplexity 和 Gemini 的 100 条列表审计中，仅包含描述性文本的列表引用率为 12%，而具有完整结构化地理数据的列表引用率升至 71%。最能提升效果的三项信号分别是经过验证的地理坐标、nearby context 字段，以及跨平台的 NAP 一致性。
2026 年 4 月的前两周，我们对 100 条基于位置的列表进行了一次受控审计，目的是回答一个问题：结构化地理数据究竟能在多大程度上改变 AI 助手引用某条列表的比率。
简短的答案是，最差桶与最佳桶之间大约相差六倍。以下是完整方法论、各桶结果，以及对任何在为 AI 搜索做列表优化的人而言的实际意义。
方法论
列表。 覆盖四个行业的 100 条列表：30 条度假租赁、25 家精品酒店、25 家独立餐厅、20 处本地景点。地域覆盖欧洲 14 个城市，以避免单一市场偏差。所有列表都有活跃、可索引的主页，并且至少在一家第三方目录上有存在。
查询集。 每条列表 15 个发现意图的提示模板，涵盖通用发现（「波尔图安静的精品酒店」）、特性相关发现（「波尔图可步行到地铁的酒店」）和具名召回（「Casa do Vale 是波尔图一家好的民宿吗」）。每个模板都在干净会话中、无对话历史的情况下新发起。
模型。 ChatGPT（GPT-5 级）、Perplexity、Gemini。每条提示在每个模型上发送一次，每条列表 45 条回复，总共 4,500 条回复。
评分。 回复中列表作为链接来源出现、在答案中被明确具名，或两者都满足时，计为一次引用。部分名称匹配由人工复核以排除误报。
分桶。 每条列表按 MapAtlas AEO Checker 在 29 个结构化信号上的得分分组为四个完整度桶。桶的阈值在评分开始之前就已设定。
核心结果
最低桶与最高桶之间的引用率差距比我们预期的要大。
来源：MapAtlas 基准测试，2026 年 4 月，n=100 条列表，4,500 条回复。
最低桶，即只有丰富散文但无结构化数据的列表，引用率为 12%。最高桶，即具有完整 Place schema、验证过的地理坐标、附近上下文字段、FAQ schema 以及跨平台一致的 NAP 的列表，达到 71%。
逐信号拆解
为了弄清是哪些单项信号推动了最高桶的结果，我们做了一次特征消融分析。对六个权重最高的信号，我们在其他变量大致恒定的情况下，比较了拥有该信号的列表与没有该信号的列表之间的引用率。
| 信号 | 含该信号 | 不含该信号 | 提升 |
|---|---|---|---|
带 geo 的完整 Place JSON-LD | 58% | 19% | 3.1x |
| 经过验证的附近 POI 数据 | 62% | 24% | 2.6x |
| 通勤邻近性字段 | 54% | 22% | 2.5x |
| 含位置问题的 FAQ schema | 49% | 26% | 1.9x |
| 跨 3 个及以上平台的 NAP 一致性 | 56% | 21% | 2.7x |
| 外部标识符（Wikidata / Place ID） | 51% | 27% | 1.9x |
来源：MapAtlas 基准测试，2026 年 4 月。
该表有四点值得注意：
- 地理坐标是单一最强的提升项。 不带
geo的 Place 块只比完全没有 schema 稍好一点。 - 附近上下文几乎同样强。 与具名 POI 和交通的邻近性是引用率第二大的预测因素。
- FAQ schema 有帮助，但不如位置相关信号。 回答位置问题的 FAQ（如「最近的地铁有多远」）远优于通用运营类 FAQ。
- 外部标识符的效能超出其直觉权重。 把列表对齐到 Wikidata QID 或 Google Place ID，在消融中几乎让引用率翻倍，可能是因为它让 AI 系统可以在多个来源之间去重。
行业差异
效果大小在各行业中并不一致。起点最弱的度假租赁，从结构化数据中获得的绝对增益最大；训练数据中本已充分代表的地标，增益最小。
| 行业 | 最低桶 | 最高桶 | 差距 |
|---|---|---|---|
| 度假租赁 | 7% | 68% | +61 |
| 精品酒店 | 14% | 74% | +60 |
| 独立餐厅 | 13% | 69% | +56 |
| 本地景点 | 18% | 72% | +54 |
来源：MapAtlas 基准测试，2026 年 4 月。
度假租赁是最明显的赢家。一条一开始隐身的列表，仅通过结构化数据就能成为一个被稳定引用的来源。对于在公众中已具有较强代表性的场所，效果较弱但仍显著。
模型实际在做什么
在对 200 条回复的定性复核中，有一种反复出现的模式。当列表具有完整结构化数据时，助手倾向于引用具体事实：到车站的步行时间、300 米范围内的餐厅数量、街区名称、营业时间。当同一条列表被剥离结构化数据后，助手要么完全省略它，要么用泛泛的措辞来描述。
这与检索增强型模型的行为一致。它们倾向于引用那些以具体、可核实的事实来回答问题的来源。把列表描述为「安静、适合步行」的散文，会输给说明「walk score 92、noise index 18 dB average」的结构化字段。后者更容易提取、更容易与用户查询对比、也更容易归因。
如何把一条列表从第 1 桶带到第 4 桶
根据消融分析，四项变更贡献了大部分的提升：
1. 添加带地理坐标的完整 Place 或 LodgingBusiness JSON-LD 块。 坐标与邮政地址匹配、有规范的外部标识符，并且所有必需的 Schema.org 字段齐全。Google 官方的 本地业务结构化数据指南 列出了权重最高的字段。字段层面的细节见 用于本地业务 AI 引用的 JSON-LD schema。
2. 用经过验证的附近上下文丰富列表。 到最近公交站的步行时间、附近餐厅和咖啡馆的数量、指定半径内的具名 POI。MapAtlas GeoEnrich 可以在规模化场景下从经过验证的来源生成这些数据，从而既可以嵌入 schema 也可以嵌入页面文案。
3. 发布位置相关的 FAQ schema。 问题要与用户表述位置查询的方式直接对应。见 面向 AI 搜索的位置相关 FAQ。
4. 跨平台对齐 NAP。 列表主页、Google Business Profile 以及至少一家第三方目录，应显示相同的名称、地址和电话。机制见 AI 搜索中的 NAP 一致性。
注意事项
本基准具有方向性，而非定论。有三点局限值得指出：
- 样本量。 100 条列表足以看出较大效应，但不足以解析细粒度差异。
- 模型漂移。 AI 助手更新频繁。绝对数值会变动；信号之间的相对排序相对更稳定。
- 查询组合。 我们的模板偏向发现意图。交易型查询（「今晚在波尔图订一个房间」）走的是不同的链路，不在本次研究范围内。
更宏观的要点不在于某一个数字是否精确，而在于结构化与非结构化列表之间的差距是大的、可测量的，并且在列表方自己可控的工作范围内基本上可以缩小。
测量你自己的基线
MapAtlas AEO Checker 使用本基准相同的 29 个信号对列表进行评分。把你表现最好的房源和最弱的房源都跑一次；得分的差距通常与两者在 AI 助手实际回答中被浮现的频率差距相吻合。
对于通过 AI 进行搜索的这一代用户来说，引用率正在成为自然排名的对应物。赢得的列表是那些能给模型可提取内容的，其他一切只是模型会礼貌地忽略的散文。
延伸阅读：
常见问题
什么是 AI 引用率？
AI 引用率指的是在相关用户查询中，AI 助手把某条列表作为已引用来源之一，或在答案中按名称提及该列表的比例。它是 AI 搜索中的自然排名等价物，但衡量的是答案层面而非结果页层面。引用率为 40% 的列表意味着，在被测助手的相关答案中每五条就有两条会出现它。
这个基准是如何进行的？
我们挑选了覆盖四个行业的 100 条列表：度假租赁、精品酒店、独立餐厅和本地景点。每条列表在 ChatGPT、Perplexity 和 Gemini 上使用一套标准发现意图问题模板被查询 15 次。回复按列表是否作为引用来源或具名推荐出现进行评分。随后，列表按 MapAtlas AEO Checker 所测得的结构化数据完整度被分桶。
对引用率影响最大的是什么？
最能影响引用率的三个信号是：带有地理坐标的完整 Place 或 LodgingBusiness JSON-LD 块；经过验证的附近上下文，例如通勤时间和距离具名 POI 的距离；以及 Google Business Profile、列表主页和至少一个第三方目录之间的 NAP 一致性。在这三项上都得分高的列表，引用率大约是三项都得分低的列表的六倍。
单靠散文描述有没有帮助？
帮助有限。包含位置关键词但没有结构化数据的长篇描述，引用率基线约为 12%。加上没有验证过的地理字段的 Schema.org 标记，把它提升到大约 28%。再加上验证过的附近上下文和一致的 NAP 数据，最高分桶达到约 71%。一旦列表被引用，散文质量对用户信任很重要，但对列表最初是否被引用影响有限。
我该如何测量自己的引用率？
把你的列表 URL 输入 mapatlas.eu/ai-seo-checker 的免费 MapAtlas AEO Checker 中。该检查器对本次基准使用的 29 个信号进行评分，并标出缺失项。把得分与周期性的 ChatGPT、Perplexity、Gemini 手动提示结合起来，可以追踪列表随时间在 AI 答案中的出现频率。
