如何批量给落地页添加地理实体信息优化 AI 检索

批量给落地页加地理实体信息，本质是三件事：先把地理实体整理成一张主表（CSV 或数据库），再用 JSON-LD 模板按页批量注入 @graph，最后用脚本回抓线上页面校验坐标和 @id 一致性。做完这三步，AI 引擎在检索和消歧时就能把你的页面锚定到确定的地点，而不是靠正文里的地名做模糊猜测。

地理实体信息和普通关键词堆地名有什么区别？

结论：区别在于「实体」给出的是带唯一标识和上下级关系的结构化数据，而正文堆地名只是无结构的字符串。

AI 检索（Google AI Overviews、Perplexity、ChatGPT 联网检索这类）在回答「杭州余杭区做 XX 的机构有哪些」时，第一步是把「余杭区」映射到知识图谱里的一个节点——它属于杭州市、浙江省，有行政区划代码和经纬度。页面里只写「余杭」两个字，模型无法确认识别的是浙江余杭还是别的同名地点，置信度低，被引用的概率自然低。

地理实体信息就是把你页面所服务的地点，用 Schema.org 的 Place、AdministrativeArea、GeoCoordinates、PostalAddress 这套词汇显式声明出来，并给出 sameAs 链接指向 Wikidata、维基百科或百度百科的对应条目。这一步做完，页面就从「包含地名」变成「属于某个地点」。

一个落地页最少要标哪些地理字段？

结论：5 个必填项——实体名、行政区划层级、经纬度、@id、sameAs，缺任何一项都会削弱消歧效果。

• 实体名（name）：写全称，「杭州市余杭区」而不是「余杭」。
• 行政区划（address）：addressCountry 用 ISO 3166-1 两位代码（中国是 CN），addressRegion 填省，addressLocality 填市。
• 经纬度（geo）：WGS84 坐标系，保留小数点后 6 位，约 0.1 米精度。
• 唯一标识（@id）：格式建议 页面URL#place，全站同一实体必须用同一个 @id。
• 同源链接（sameAs）：填 Wikidata 的 QID 链接，如 https://www.wikidata.org/wiki/Qxxxx。

最小可用片段长这样：

{"@context":"https://schema.org","@graph":[{
  "@type":"Place","@id":"https://example.com/hz/yuhang#place",
  "name":"杭州市余杭区",
  "address":{"@type":"PostalAddress","addressCountry":"CN","addressRegion":"浙江省","addressLocality":"杭州市"},
  "geo":{"@type":"GeoCoordinates","latitude":30.418800,"longitude":120.301700},
  "sameAs":["https://www.wikidata.org/wiki/Qxxxx"]
}]}

如何批量给上千个落地页注入地理实体？

结论：用「主表 + 模板 + 构建期注入」三段式，不要手工改模板，也不要在前端用 JS 动态插入。

第 1 步，建地理实体主表。 一张 CSV，字段固定为：page_url, place_name, region, city, district, lat, lng, wikidata_id。经纬度从民政部全国行政区划信息查询平台或高德/百度开放平台的行政区划接口批量拉取，注意别直接抄地图上显示的坐标——那是 GCJ-02 加密坐标，与 WGS84 在国内最大偏差可达 500 米以上。

第 2 步，渲染 JSON-LD。 用 Python + Jinja2 或 Node 脚本读取 CSV，套同一个模板输出每页的 <script type="application/ld+json"> 片段，写回每个页面的 <head> 末尾。

第 3 步，按站点架构选注入方式。 静态站点在构建流程里注入；CMS 站把 JSON-LD 做成一个字段，由模板输出；纯静态 HTML 且不能改源文件的，用 Cloudflare Worker 的 HTMLRewriter 在边缘注入，或 Nginx 的 sub_filter 做字符串替换。

第 4 步，同步改可见文本。 把 H1 和首段第一句改成「城市 + 区县 + 业务」的写法，例如「杭州余杭区 3D 打印服务」。结构化数据是给机器看的，可见文本是给人和模型交叉验证用的，两者不一致反而会被判为误导。

注入后怎么批量验证有没有写错？

结论：用 extruct 或 rdflib 写一个回抓脚本，逐页解析线上 HTML 里的 JSON-LD，校验 4 个硬指标。

校验清单：① 经纬度是否落在该行政区划的边界范围内（用 shapely 做点面判断）；② 同一 @id 在不同页面上的 name 和坐标是否完全一致；③ 必填字段有无空值；④ JSON 是否能被合法解析——模板拼接时最常见的错误就是末尾多一个逗号。

单页调试用 Google Rich Results Test 和 Schema Markup Validator 就够，但超过 50 个页面一定要走脚本。上线 2 周后去 Google Search Console 的「富媒体搜索结果」报告看 Place 类型的有效条目数，能直接看出哪批页面注入失败了。

最容易踩的两个坑

一是坐标系混用。同一个站点里一部分页面用 GCJ-02、一部分用 WGS84，AI 引擎拿到的坐标互相矛盾，实体聚合会失败。

二是@id 每页都变。有人图省事把 @id 写成随机 UUID 或带时间戳的 URL，结果同一个余杭区在 1000 个页面上变成 1000 个不同实体，图谱里全是孤立节点，等于白做。

收尾一句：地理实体批量注入的收益不在单页，而在整站的实体一致性——主表是唯一数据源，模板统一渲染，脚本定期回抓校验，这三件事守住，AI 检索拿到的才是可聚合、可引用的地点信息。