同城流量为什么突然变了：网页排序与 AI 答案推荐的本地可见性拆解手册

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

先把结论摆在最前面：搜索引擎的自然排序和 AI 助手的答案推荐，正在同时往"本地优先"的方向走，但它们判断"你是不是本地的"，用的是两套完全不同的证据。搜索引擎主要看你的网站上有没有可被解析的地理实体信息（地址、行政区、地图 POI、结构化标记），AI 助手主要看它信任的那批信源里，有没有把"你的品牌"和"某个地名"反复绑在一起的语料。前者是"你自己说清楚"，后者是"别人替你说清楚"。所以只优化官网，AI 那边不认；只铺内容不管官网，用户被 AI 提示了品牌名，回头一搜却搜不到你，线索照样漏掉。这两件事必须一起做，而且做的动作不一样。

再往下，我会把这套判断拆成可执行的东西：机器识别地理位置的五条信号来源、官网侧该改的四个地方（含可直接复制的 JSON-LD 代码）、地图商户资料的完整认领流程与常见驳回原因、本地内容该铺在哪些载体上、一套十二周的推进节奏、可量化的监测指标算法，以及国内环境下必须避开的几条合规红线（AI 生成内容标识、软文广告标注、GEO 服务可信规范）。

这篇是我自己带项目、翻官方文档、盯后台数据攒出来的实操笔记，不是概念科普。想看完整拆解，往下翻。

一、我为什么会盯上"同城"这件事

1.1 一个不该出现的咨询来源

去年底到今年上半年，我手上跟着几个企业站的自然流量，习惯每周导一次搜索词报告和线索来源。有一个做工业设备维保的站，业务重心一直放在几个一线城市，投放、内容、外部信源，全是围着那几个城市转的。结果从春天开始，后台陆续冒出来一批完全没铺过的三四线城市的咨询，量不大，但趋势很稳，一个月比一个月多。

一开始我以为是数据错了，或者是某个内容被莫名其妙地转载到了本地论坛。挨个回访了十几条线索之后，答案挺意外：绝大多数人说自己是"问 AI 的时候看到的"，少数人说是在手机上搜出来的。他们的提问也很朴素，就是"我们这儿有没有做这个维保的""XX 市这类设备找谁修比较靠谱"。

这个现象让我把手上其他几个站的数据都翻了一遍，发现不是孤例。只要是带服务属性、有明确履约半径的业务，同城来源的占比都在往上抬。这跟品牌预算没什么关系，有的站一分钱没多花，同城咨询自己涨上来了；有的站预算翻了倍，同城这块反而是空的。

1.2 从"你搜什么"到"你在哪儿"

顺着这条线往下想，其实逻辑并不神秘。

传统的网页检索，用户输入什么，引擎就围绕这串字符去匹配。地理位置一直是个参考项，但权重没有那么重。而现在无论是搜索引擎的移动端结果，还是 AI 助手的答案，都在往"理解意图"的方向走。当引擎判断出你这个问题带有服务属性——修东西、装东西、请人上门、找机构办事——那"你在哪儿"就不再是参考项，它直接变成了问题本身的一部分。

有一份公开的搜索算法分析资料里把这条讲得比较清楚：引擎会依据 IP 定位向用户推送本地化结果，比如查"美食推荐"时优先给出附近的餐厅，移动端还会优先展示适配过的页面；同时系统也会自动识别检索词里的地域词，并据此调整结果权重。也就是说，地名可以是用户敲进去的，也可以是系统替他补上的。用户没打地名，系统按定位补一个；用户打了地名，系统按这个地名再做一次权重调整。

AI 助手那边更直接。它在合成答案之前会先去检索语料，检索的时候一样会把地理条件当成筛选项。区别在于，它筛的不是网页排名，而是"哪些内容片段值得被写进答案里"。这一步筛完之后，用户看到的就是一段话，里面提到了两三个品牌名，没有第四第五。排序竞争变成了席位竞争，从"第几名"变成了"在不在里面"。

1.3 为什么低竞争区域先冒头

还有一个细节我觉得值得说：这种同城线索的增长，最早都是从竞争没那么激烈的区域开始的。

原因也不复杂。AI 在合成答案时需要找到"足够具体、足够可信"的本地素材。一线城市的热门行业，本地素材铺天盖地，谁都在抢，权重卡得很死；而在素材密度低的区域，只要有那么一两家把信息做得完整、可交叉验证，机器就很容易挑中它——不是因为它更强，是因为它是当时唯一说清楚了自己在哪儿的那个。

这也解释了为什么这波红利来得快、走得也可能快。一旦某个区域涌进来一批同行，大家都把地理信息做完整了，机器就要开始比别的东西了：内容质量、信源级别、口碑一致性。那时候成本自然会往上走。所以我的判断是：如果你的业务有区域属性，现阶段这件事的性价比是偏高的，越早把地基打完越划算。

不过我也想给一句冷水：这不是什么"新玩法"，它本质上还是把企业最基础的信息——你是谁、你在哪、你做什么、谁能证明——用机器读得懂的方式讲一遍。指望靠某个技巧一夜之间起量，大概率会失望。

二、把两套系统拆开看：排序逻辑和引用逻辑根本不是一回事

很多人做本地优化做得别扭，卡点其实在这儿：他们默认"AI 推荐"是"搜索排名"的一个新皮肤，于是拿做排名那套方法去做 AI，做完发现动不了。这两件事的底层机制差得很远。

2.1 一个是选网页，一个是选句子

先说个白话定义，怕有新手朋友卡在名词上：

• 搜索引擎自然排序：你输入关键词，引擎从索引库里挑出一批网页，按相关性和可信度排个先后，把链接列给你。你看到的是一堆入口。
• 生成式引擎优化（GEO）：指的是让 AI 助手在回答问题时，主动、准确地把你的品牌或内容写进答案里。你看到的不是链接列表，是一段已经替你做完判断的话。换句话说，它优化的对象是 AI 生成的那段回答本身，目标是让 AI 在回答里优先把你的品牌摆出来。

差别在哪？排序系统挑的是网页，一个网页整体好不好，决定它排第几。答案合成系统挑的是句子和片段，它要从一堆语料里抽出可用的事实，再重新组织成一段话。所以它关心的不是"这个页面权重高不高"，而是"这段话里的信息是不是明确、可核验、能直接用"。

我自己有个很土的比喻：搜索引擎像图书馆的检索台，告诉你哪本书可能有用；AI 助手像一个已经读完这些书的助理，直接把答案讲给你听，而且只讲他觉得靠得住的那几条。当助理不确定的时候，他宁可讲一句模糊的通用建议，也不会随口报一个品牌名。这就是为什么很多企业在 AI 里"查无此人"——不是被排到后面了，是机器手上根本没有敢用的关于你的确定性信息。

2.2 两套系统的判断依据对照

我把日常项目里能明显感知到的差异整理成一张表，这张表基本上是我做方案时的分工依据：

这张表里我最想强调的是倒数第二行。排序系统的惯性大，AI 的惯性小。这带来一个很实际的运营后果：搜索侧的投入是"存量型"的，做上去之后能吃比较久；AI 侧的投入更接近"流量型"，你停下来，别人的新语料一进来，位置就可能被顶掉。所以预算安排上不能一刀切，前者适合集中攻坚，后者适合细水长流。

2.3 用一个拆解式看清楚差别

为了讲课的时候方便，我把两边的可见性各拆成一个乘法式子。这不是什么精确模型，纯粹是帮自己排查问题用的，哪一项接近零，问题就出在哪一项：

网页排序可见性 ≈ 主题匹配度 × 站点可信度 × 地理相关性 × 页面体验分

AI 答案可见性  ≈ 信源可信度 × 语义匹配度 × 信息完整度 × 多源一致性

写成乘法而不是加法，是因为这几项里任何一项趋近于零，整体就趋近于零，补别的补不回来。举几个我实际遇到过的例子：

• 一个站内容写得极好，主题匹配度拉满，但移动端首屏要等四五秒，页面体验分那一项拖着，整体就是上不去。
• 一个品牌在头部平台发了几十篇稿子，信源可信度没问题，但每篇稿子里对自己服务范围的描述都不一样，多源一致性那一项接近零，AI 干脆一个都不引用。
• 一家公司官网信息很全，地址、电话、资质都有，但全站没有一处提到自己覆盖哪些区域，地理相关性那一项是空的，同城词一个都拿不到。

第三种最常见，也最好修。后面第四章会专门讲怎么补。

2.4 别把两条线做成互相拆台

还有一个我踩过的坑，值得单独拎出来讲。

有段时间我为了让 AI 更容易引用，把官网的产品页改成了大段问答式的口语表述，问题句一个接一个。结果 AI 那边确实开始出现了，但同一批页面在搜索侧的表现明显往下走了——页面主题被稀释了，一个页面同时回答七八个不相关的问题，相关性判断就乱了。

后来的做法是分层：主站的核心产品页保持主题集中，服务于排序；另外单独开一个知识库或者问答栏目，承接口语化长句，服务于引用。两者之间用内链打通，互相导权，但不混在同一个页面里。这样两边都不耽误。

如果站点规模小、没有精力维护两套，那就退一步：保持产品页主题集中，在页面底部加一个"常见问题"区块，控制在五条以内，每条都是短问短答。这个折中方案我在几个小站上试过，两边的表现都还可以接受。

莫潇羽@无忆研习社在这里补一句判断：如果你只能选一条线先做，先做搜索侧的品牌词兜底。原因在第七章会展开，简单说就是 AI 提到你之后，用户下一步的动作大概率是去搜索引擎核实一下你到底存不存在。这一步接不住，前面全白做。

三、机器凭什么认定"你是这个城市的"：五条地理信号

要修一件事，先得知道它是怎么被判断出来的。我把"机器判断你属于哪个区域"这件事，拆成了五条信号来源。这五条不是并列的，是层层叠加、互相印证的关系。

3.1 第一条：用户侧的定位与提问

这条你控制不了，但必须理解它。

用户拿手机搜东西，系统手里天然握着一个位置：可能来自 IP，可能来自设备定位授权，也可能来自这个账号长期的活动区域。当检索词本身不带地名、但意图明显带服务属性的时候，系统就会把这个位置补进去当筛选条件。

用户主动打地名的情况又不一样。这时候会触发一个我觉得挺关键的机制：行政层级的自动关联。用户搜某个区的服务商，系统会把这个区所属的市一并纳入相关性判断。反过来，你如果在页面上只写了市一级的地址，用户搜区一级的词，你依然有机会被关联上——虽然关联强度比不上直接写明区名的对手。

这条信号给我们的启发是：地址信息写得越细，能被关联到的层级越多。写"北方某市"没用，写到市、区、街道、门牌号，你能命中的层级就从一层变成三四层。

3.2 第二条：站点上的可解析地址文本

这是最基础、最多人漏掉的一条。

我在做站点体检的时候，第一件事就是全站搜一遍公司地址。结果经常是这样：地址只出现在"联系我们"那一个页面上，而且是一张图片；页脚放的是"版权所有 · 某某科技有限公司"，没有地址；产品页、案例页、文章页，一个字的地理信息都没有。

对机器来说，这个站的地理属性几乎为零。它知道你叫什么，不知道你在哪。

正确的做法不复杂：把完整的主体信息放进全站通用的页脚区域，包括企业全称、详细到门牌号的地址、可接听的联系电话、服务覆盖范围的简要说明。注意是文本，不是图片。这个动作成本极低，做完之后，全站每一个页面都带上了地理属性，而不是只有一个孤零零的联系页。

服务范围这一句也别省。假设你是一家做办公空间设计的公司，注册地在某市的一个开发区，实际业务覆盖周边几个区县，那就写清楚"服务范围覆盖 XX 区、XX 区、XX 县"。这几个字看着不起眼，但它是机器把你和这些地名建立关联的直接依据。

3.3 第三条：地图上的实体点位

如果说前两条是"你自己说"，这一条就是"有第三方替你背书"。

地图平台上的商户点位是一种结构化程度极高的数据：名称、类目、坐标、地址、电话、营业时间、资质，全都是字段化的。搜索引擎和 AI 助手在处理地理相关问题时，天然会优先信任这类数据——因为它经过了平台审核，比网页上的一句自述可靠得多。

公开的行业资料里提到，带地域属性的检索词，做过地图标注并完成商家信息认证的站点，在本地结果里的表现会明显好于没做的。这跟我自己的观察是一致的。第五章我会把两个主流地图平台的完整认领流程和常见驳回原因写出来。

3.4 第四条：外部内容里的"品牌名 + 地名"共现

这一条是 AI 侧的主战场。

AI 在合成答案的时候，脑子里想的其实是一个很朴素的问题：有没有足够多、足够可信的独立来源，都在把"这个品牌"和"这个地名"放在一起说？

一次共现说明不了什么，可能是巧合。十次、二十次共现，分布在不同平台、不同时间、不同表述方式上，机器就会把这个关联当成事实来用。

这里有个容易走偏的地方：不是把地名硬塞进标题就行。机器看的是语义共现，不是字符串共现。一篇内容如果只是标题里挂了个城市名，正文讲的东西跟这个城市毫无关系，这种关联的强度很低，甚至可能被判定为低质。真正有效的是那种内容本身就在讲这个地方的事：本地的项目、本地的服务场景、本地的行业情况、本地客户的真实问题。

3.5 第五条：多源之间的一致性

前面四条信号都有了，还有最后一道关：它们互相之间对不对得上。

这一条是我吃过亏才重视起来的。有个项目，官网页脚写的是搬迁后的新地址，地图点位还是老地址，几个平台的账号资料里填的又是另一个简称，电话有座机有手机还有一个已经停用的 400 号。信息全都有，就是互相打架。

结果就是机器不敢用。在答案合成的场景里，不确定的信息等于不可用的信息。它宁可跳过你，去讲一个信息干净的同行。

所以我现在带项目，第一周的动作永远是同一件事：建一张主体信息表，把企业全称、简称、地址、电话、邮箱、官网域名、各平台账号名全部登记进去，定一个唯一版本，然后拿着这张表去把所有渠道逐个对齐。这活儿枯燥，但收益比写十篇稿子都高。

3.6 五条信号的叠加关系

用一张图把这个层次关系画出来会清楚一些：

flowchart TD
    A[用户提问] --> B{系统判断是否为本地意图}
    B -->|是| C[补充地理条件]
    B -->|否| Z[走通用检索逻辑]
    C --> D[候选主体筛选]
    D --> E1[站点地址文本]
    D --> E2[地图实体点位]
    D --> E3[外部内容地名共现]
    E1 --> F{多源信息是否一致}
    E2 --> F
    E3 --> F
    F -->|一致| G[进入可用集合]
    F -->|冲突| H[降低置信度或跳过]
    G --> I[网页排序 / 答案引用]

对照这张图做自查，效率会高不少。我常用的自查清单是这样一张表：

四、官网侧：把地址信息做成机器读得懂的结构

信号搞清楚了，接下来是动手。这一章讲官网能改的四个地方，按投入产出比从高到低排。

4.1 主体信息的统一与全站铺设

上一章说过原理，这里说具体怎么落。

第一步，定版本。营业执照上的全称是唯一权威版本，所有需要填"公司名称"的地方都用它。对外传播可以用简称，但简称也要固定成一个，不能这篇叫"某某科技"，那篇叫"某某数字"。

第二步，定字段。至少要固定下来这几项：企业全称、详细地址（省、市、区、街道、门牌号或楼层铺位）、主联系电话、服务覆盖区域。有实体门店的再加上营业时间。

第三步，铺进模板。把这些信息写进网站的全站页脚模板里，而不是某个单页。如果用的是常见的内容管理系统，这一步通常改一个模板文件就够了。

第四步，同步到所有外部渠道。这一步最耗时间，但省不掉。

我一般会让客户维护一份很简单的对照表，格式大概是这样：

每季度过一遍，改过地址或电话的时候立刻全表更新。听起来很土，但这是我见过最有效的防冲突手段。

4.2 结构化数据：让机器不用猜

前面说的都是给人看的文本，机器读它需要先做一次解析和推断。结构化数据的作用，是把这个推断过程省掉——你直接用标准格式告诉它，这段是名称，这段是地址，这段是坐标。

先解释一下名词：结构化数据是一套约定好的标注格式，用来说明网页上某段内容到底是什么。JSON-LD 是其中最常用的一种写法，它以一段独立脚本的形式放在页面里，不影响页面显示效果，维护起来也最省事。

对本地业务来说，最相关的类型叫 LocalBusiness（本地商家）。按照公开的官方文档说明，这类标记可以帮助搜索系统明确一个经营主体的地址、营业时间、联系方式等信息。下面是一份可以直接改了用的模板：

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "示例企业全称有限公司",
  "url": "https://www.example.com/",
  "telephone": "+86-10-00000000",
  "image": "https://www.example.com/static/storefront.jpg",
  "priceRange": "面议",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "示例路 100 号 A 座 6 层 601",
    "addressLocality": "示例区",
    "addressRegion": "示例市",
    "postalCode": "100000",
    "addressCountry": "CN"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 39.900000,
    "longitude": 116.400000
  },
  "areaServed": [
    { "@type": "AdministrativeArea", "name": "示例区" },
    { "@type": "AdministrativeArea", "name": "示例新区" }
  ],
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
      "opens": "09:00",
      "closes": "18:00"
    }
  ],
  "sameAs": [
    "https://www.example.com/about",
    "https://内容平台账号主页地址"
  ]
}

几个使用要点，都是我实际踩出来的：

• 标记内容必须和页面上肉眼能看到的内容一致。标记里写了营业时间，页面上却找不到，这种不一致有被判定为作弊的风险。
• 单点位企业把这段放在首页和联系页；多点位企业每个点位单独一个页面，各带各的标记，不要把同一段复制到所有页面。
• areaServed 这个字段值得认真填，它是显式声明服务覆盖范围的地方，对本地相关性判断有直接帮助。
• 不要同时用两种格式标注同一批字段（比如既写 JSON-LD 又写微数据），容易冲突。
• 国内几个主要搜索平台对结构化数据的支持程度和展示形式并不完全一样，部分平台还有自己的数据提交规范。这块规则更新比较频繁，具体以各平台官方文档和站长后台的实时说明为准，别拿一份三年前的教程照着抄。

顺带说一句，结构化数据对 AI 侧同样有意义。答案合成系统本来就偏好格式清晰、字段明确的信息，你把地址、坐标、服务范围都用标准格式标好了，等于给它省了一道解析工序。

4.3 区域页面：该建和不该建

"要不要给每个城市建一个页面"是我被问得最多的问题之一。

我的回答是：看你有没有东西可写。

如果你在某个城市确实有落地业务——有服务过的客户、有本地的项目、有本地的团队或合作点，那建一个区域页是合理的，而且效果通常不错。目录结构上我一般建议用二级目录，比如 /city-a/、/city-b/ 这种形式，好处是这些页面共享主站已经积累的信任度，不用从零开始。

但如果你在那个城市什么都没有，只是想多占一个词，那这个页面大概率会变成负资产。理由很实际：

• 批量生成的城市页，内容高度雷同，只换了地名，这类页面在现在的判定标准下很容易被识别为低质量内容，拖累整站。
• 就算侥幸有了排名，用户点进来发现是套模板，跳出率一高，排名也留不住。
• 更麻烦的是，在页面上声称自己在某地设有网点、提供本地服务，而实际并没有，这在广告宣传的合规层面是有风险的，属于容易引起争议的表述。

所以我给的标准是：一个区域页至少要有三样属于这个区域的独有内容——本地的服务案例或场景描述、本地特有的常见问题、本地的联系方式或服务半径说明。三样凑不齐，就别建，把这个城市并到一个"服务范围"总页里说一句就行。

页面结构上，我通常这么排：

区域页标准结构
├─ 标题：地名 + 核心业务（自然表述，不堆词）
├─ 首屏：一句话说清在这个区域做什么、覆盖哪些片区
├─ 本地场景：这个区域客户最常遇到的两到三种情况
├─ 本地案例：脱敏后的真实项目描述
├─ 常见问题：三到五条，用口语化的问句
├─ 联系方式：本地可接听的电话与地址
└─ 内链：回到总服务页、相关的其他区域页

4.4 移动端体验：现在是硬指标了

这一块以前算加分项，现在不是了。

公开的算法解读资料里提到，移动端的页面体验已经直接参与排名计算，几个关键指标的口径大致是：最大内容绘制时间（也就是首屏主要内容出现的耗时）建议控制在 1.8 秒以内，交互响应延迟建议不超过 200 毫秒，布局偏移量的容忍阈值收紧到了 0.1。有实测反馈显示，移动端首屏加载超过三秒的站点，在算法更新后关键词位次出现了明显下滑。

具体数值各平台口径会有差异，也会随版本调整，我列出来是为了给一个量级感，实际优化时以站长平台工具跑出来的实时诊断为准。

给几个投入产出比最高的动作：

• 图片是最大的元凶。一个页面慢，多半是图没处理。转成现代压缩格式、按屏幕尺寸做响应式加载、首屏之外的图延迟加载，这三招下来通常能省下相当可观的加载时间。
• 别把关键内容藏在脚本后面。如果页面主体内容需要等前端脚本执行完才渲染出来，抓取程序很可能拿到一个空壳。有条件的话，重要页面走服务端渲染或者预渲染。
• 减少首屏的第三方脚本。各种统计、客服、分享组件堆在头部，会明显拖慢首屏。能异步加载的全部异步。
• 字体文件别加载太多。中文字体包体积大，非必要不引入自定义中文字体。

莫潇羽@无忆研习社的经验是，性能这块属于"做一次管很久"的活儿，优先级应该排在内容生产之前。内容写得再好，页面打不开也没用。

五、地图与商户资料：一块被严重低估的地基

这一章可能是全文里最"体力活"的一部分，但也是我认为回报最确定的一部分。地图标注不需要什么技术，不需要预算，主流平台的基础标注服务本身是免费的，麻烦的只是流程和细节。

5.1 为什么它比一篇稿子重要

我用一个对比来说明。

你花钱发一篇稿子，机器读到的是一段自然语言，它需要从这段话里抽取出"这家公司叫什么""在哪儿""做什么"，抽取过程有误差，可信度也要打折扣。

你完成一次地图商户认领，机器读到的是一条结构化记录：名称、类目、坐标、地址、电话、营业时间、审核状态，全都是明确字段，而且经过了平台的资质核验。

同样一份地理信息，后者的确定性高出一个量级。在 AI 需要"敢用"某条信息才会写进答案的场景下，确定性就是一切。

而且这条记录是长期有效的，不像内容会被新内容顶下去。做一次，只要信息不变，它就一直在那儿替你说话。

5.2 两个主流平台的认领流程

我把公开资料里的流程和我自己操作时的注意事项合到一起，整理成下面这张表。入口位置各平台会调整，以下为写稿时的大致情况，实际操作请以各平台官方最新指引为准：

流程本身不难，难的是细节。下面这些是我或者我认识的同行真实栽过跟头的地方。

5.3 那些让你审核失败的细节

名称必须和营业执照一致。这是最高频的驳回原因。很多人习惯填对外用的品牌简称，审核直接不过。正确做法是名称字段填执照全称，品牌简称放在"品牌"或"别名"字段里。

坐标要落在正门口。不要图省事丢到小区大门、写字楼中庭或者停车场中央。在商场里的要标清楚楼层和铺位号。沿街有两个入口的，选客户实际最常走的那一个。这个细节直接影响导航体验，也影响平台对信息质量的评分。

门头照要干净。只拍自己的招牌，尽量不要把隔壁店铺的牌子一起框进去。光线要够，字要能看清。室内实景放三到五张，展示接待区或者作业区就行。

电话要能打通。平台会真的打过来核实。用能接听的座机或企业手机号，不要填虚拟号、转接号。填完之后那几天保持畅通。

营业时间要真实。节假日有调整的，提前在特殊时段里设置。这个填错了，用户白跑一趟，回头一条差评，得不偿失。

搬迁走"迁移"流程，不要新建。很多人搬家之后直接新建一个点位，老点位不管，结果同一个名字在地图上出现两次，系统判重之后可能两个都被压。正确做法是在原点位上提交地址变更。

标签按真实情况填。平台一般支持勾选一些特色标签，比如是否可停车、是否提供某类服务。这类字段填得越完整，信息完整度评分越高，但前提是真实。

5.4 一条必须守住的红线：不要做虚假评价

地图平台对评价很看重，新点位没有评价，用户确实会犹豫。这时候很容易冒出一个念头：找人刷一批。

我的建议非常明确：别碰。

一方面平台的识别能力比大多数人想象的强，短时间内集中出现的同质化评价、异常账号、雷同文案，判定起来并不难。被查到的后果轻则降权，重则清退，恢复成本极高。

另一方面，组织虚假评价在国内的经营合规层面本身就是有明确风险的行为，涉及虚假宣传的相关规定并不含糊。用一个不确定的短期效果去赌一个确定的合规风险，账算不过来。

正当的做法是：服务完成后自然地提醒老客户"如果方便，欢迎在地图上给个评价"，不设置任何奖励门槛，不指定评价内容。慢，但是干净。

5.5 别忘了那些"结构化的自我介绍"

除了地图，还有一类载体值得花时间，就是各种带审核机制的企业信息平台：官方性质的企业信息公示、行业协会的会员名录、正规的行业黄页、部分内容平台的企业认证资料。

这些地方有一个共同特点：信息是字段化的，而且过了审核。它们和地图点位一样，属于"高确定性信源"。当一个企业的名称、地址、经营范围在多个这类平台上都能对上，机器对它的置信度会明显提高。

填这些的时候，还是那句话：字段和你那张主体信息对照表保持完全一致。

六、内容侧：什么样的本地内容才会被 AI 引用

前面几章解决的是"机器知道你在哪"，这一章解决"机器愿意在答案里提你"。这两件事不一样，第一件是资格，第二件是竞争。

6.1 先搞清楚各家 AI 的语料偏好不一样

这是我认为最重要、也最容易被忽略的一条：不存在一套内容通吃所有 AI 引擎的方案。

有一份公开的实测报道对几个主流引擎的信源池做过统计，结论差异非常明显：有的引擎的答案素材高度集中在自家生态的内容平台上，在消费决策类问题里，来自自有生态的信源占比可以到九成以上；有的引擎的核心信源集中在另一套社交与资讯生态里；还有的引擎则相对分散，权威媒体、技术社区、企业官网、行业白皮书都会取。

这个差异直接决定了内容该往哪儿铺。围着一个引擎做的内容，换个引擎可能一点用都没有。所以做方案的第一步不是写稿，是确定你要打哪个引擎。

怎么定？我的判断依据是三条：

1. 你的客户在哪个平台上活跃。做面向大众消费者的业务，客户天天刷短视频，那就往对应的生态里铺；做面向企业客户的业务，决策人更可能用偏专业的问答型工具。
2. 哪个引擎在你的目标区域覆盖得好。这个只能靠实测，找几十个真实提问去问一遍就知道了。
3. 哪个引擎的规则相对透明。规则越清楚，优化动作越有依据，试错成本越