下面按我们在项目里遇到的频率从高到低排。

一、类目与资质：功能和类目对不上

服务类目不是装饰，它决定了你要交什么资质、能不能用支付、能不能卖实物。选错的结果是：审核要你提供一份你根本办不下来的证。

• 做本地生活服务（家政、维修、洗衣），类目却选了「电商平台」，会被要求拿《增值电信业务经营许可证》。
• 卖食品、茶叶、自制糕点，没有《食品经营许可证》，类目选「食品」必然被退。
• 做课程、问诊、招聘，分别涉及教育、医疗、人力资源，各有前置审批。

判断方法很笨但有效：打开类目列表，找和你业务最接近的那一项，先看「需要资质」那一列。写「需要」而你没证的，换一个更轻的类目，把相关功能藏起来，等证办下来再加。

二、审核员进不去：登录、入口、测试账号

审核是在一个全新微信环境里完成的，不是在你手机上。由此有三个高频问题。

测试账号没给或不能用。 需要登录才能看内容的小程序，必须在提审备注里写清账号和操作路径，且账号要有真实数据，不能登进去全是空列表。

验证码收不到。 常见的一种情况：功能都做完了，但短信服务商还在审核，测试号码点了三次都收不到码，审核员只能判定「无法体验完整功能」。

入口藏太深。 首页只有一张海报，真正的功能藏在「我的」二级页面，审核员大概率找不到。首页至少放一个明显入口。

三、细节红线：隐私、诱导分享、强制关注、iOS 虚拟支付

隐私说明缺失。 调用手机号、位置、相册、剪贴板前，必须在用户隐私保护指引里声明用途并弹授权。声明了没实际用、用了却没声明，都算问题。

诱导分享与强制关注。 「分享给 3 位好友解锁」「转发到 5 个群领券」是明确违规；不关注公众号就不让用，同样会被退。可以引导，不能当前置条件。

iOS 虚拟支付。 卖会员、卖课程、卖金币这类虚拟商品，iOS 端不能引导站外支付。做内容付费的，要么 iOS 隐藏购买入口，要么只上安卓。

四、什么情况下先别做小程序

不是所有生意都该把小程序放在第一步。以下几种情况，做了也很难有结果：

• 一次性低频消费（装修、搬家、婚庆）。一年用一次，做完就删，预算不如放在官网内容和口碑上。
• 履约能力还没稳定。 下单变简单了，但接单、排期、售后还是一个人手工记，单量一涨就崩。先跑顺流程，再谈工具。
• 指望它自带流量。 小程序没有自然流量入口，「附近的小程序」那点曝光撑不起生意，流量仍要靠门店、社群、投放去带。
• 核心环节必须线下完成（称重、现场报价、验货）。线上只能做预约和会员，硬套商城模板只会让用户卡住。

五、提审前花十分钟，用干净账号走一遍

1. 拿一个从没用过小程序的微信号（不是管理员、不是开发者），从首页走到下单成功，中途不跳过；把「我的」「设置」里要登录的页面全点开，确认没有空白页和「暂无数据」。
2. 确认测试账号能登录、有数据、有权限，备注写清账号和操作路径。
3. 通读文案，删掉「分享解锁」「关注后使用」「加微信领券」这类句子。
4. 关掉后台测试开关，确认接口指向正式域名——留着测试环境地址，页面直接白屏。
5. 对照类目资质表，把缺证的功能先隐藏，过审后再补。

如果只能做一件事：拿一个干净微信号，从打开小程序到完成一次真实下单，完整走一遍，把走不通的地方截图存下来。 这些截图就是下一轮驳回的理由清单，比事后猜审核员想什么有用得多。

这就是变化本身。搜索没有消失，只是答案被提前生成好了。而 GEO（Generative Engine Optimization，生成式引擎优化）要解决的问题只有一个：让那段答案里有你。

先说清楚 GEO 不是什么

不是发软文、不是买排名、不是给 AI「喂数据」的黑科技。任何告诉你「交钱就能被 AI 优先推荐」的服务，基本可以判定为忽悠——因为主流大模型的检索与排序逻辑并不对外售卖。

GEO 更接近一件笨功夫：把你的信息整理成机器能读懂、愿意引用、并且各处一致的样子。

动作一：先让机器爬得到

再好的内容，抓不到就等于不存在。检查三件事：

• 站点是否有 sitemap.xml，并在百度、必应、谷歌站长平台提交过；
• robots.txt 是否放行了主流爬虫，包括 GPTBot、ClaudeBot、PerplexityBot、Bytespider 这些 AI 抓取器；
• 页面是不是纯前端渲染、首屏要等 JS 才出内容——很多 AI 爬虫不执行 JS。

静态站或服务端渲染的站，在这件事上有天然优势。

动作二：把「你是谁」写成结构化事实

AI 引用一个页面，往往是因为它能快速提取确定的事实。所以你需要结构化数据（Schema.org），至少包含：

• Organization：公司全称、成立时间、地址、电话、服务区域；
• Service：每一项服务是什么、给谁、覆盖哪里；
• FAQPage：客户最常问的问题与答案；
• Article / BlogPosting：文章的作者、发布时间、主题。

写这些的时候你会发现一个副作用：很多说不清的地方，是因为你自己也没想清楚。

动作三：让所有地方的信息一致

AI 判断能不能引用你，会看交叉验证：官网说在盐城，地图标注在盐城，企业信息平台也是盐城——可信。官网写「盐城」，某目录写「南京」，它就会犹豫。

所以做一张清单，把这几处的名称、地址、电话、业务描述统一：

• 官网页脚与「关于我们」
• 地图与本地商户标注
• 企业信息查询平台
• 公众号、视频号、小红书等社交账号简介

这件事一次做完，长期有效，成本极低，但大多数公司没做。

动作四：用「回答完整」的方式写内容

AI 喜欢什么样的页面？能把一个问题讲完整的页面。以本文为例，它需要包含：

1. 定义（GEO 是什么）
2. 适用条件（什么情况下值得做）
3. 具体步骤（五个动作）
4. 成本与周期
5. 常见误区

对比一下常见的企业文章：「我们拥有专业团队，深耕行业多年，为客户提供一站式解决方案」——这句话对人和机器都等于零信息。

一个自检方法：把你写的段落交给一个不了解你行业的人看，如果他看完还是不知道「什么时候该找你、找了你能得到什么」，那就重写。

动作五：每月抽查，用数据说话

GEO 最难的是衡量。一个可行的办法：

• 列出 15–30 个客户真的会问的问题（不是关键词，是完整句子）；
• 每月固定时间，在 4 个 AI 平台各问一遍；
• 记录：是否提及你、排在第几位、引用了哪个来源、提到了哪些竞品。

三个月后你会看到趋势。如果一直是零，说明前面的动作有断点——通常是内容没有被收录，而不是 AI「不喜欢你」。

多久见效，要花多少钱

按我们的经验：技术修复 2–4 周会被重新抓取；内容层面的变化通常 2–3 个月开始显现；AI 平台的提及提升更慢，需要一个季度以上，而且各平台差异很大。

成本上，如果自己有人写内容，主要投入是时间；如果外包，市场上按月服务的价格从几千到几万不等，差别在于是否真的做结构化改造，还是只发文章。

一个提醒

GEO 不是替代 SEO，两者共享同一套内容资产。先把官网做成一个「能回答问题的地方」，两件事就同时推进了。反过来，如果站点本身是个只有轮播图的电子名片，做什么优化都是在沙地上盖楼。

如果你想看看这套东西实际落地长什么样，可以翻一下本站的 llms.txt、sitemap.xml 和任意一篇文章的结构——我们自己的站就是按这套方法做的。

从三千到八万都有人报，差距不在「谁想坑你」，而在于你要的东西根本不是同一个东西。这篇文章把报价拆开，让你能自己判断一份报价单贵在哪、省在哪。

先分清三种「小程序」

第一种：模板/SaaS 版。 服务商提供现成系统，你按年付费，几千块。优点是快，缺点是数据在别人服务器、功能改不了、想搬走很难。适合刚试水、只需要「能下单」的商家。

第二种：基于开源系统二次开发。 拿成熟的开源商城改界面、加字段、对接支付，一两万。性价比最高的一种，前提是服务商真会改，而不是套个模板收定制的钱。

第三种：完全定制。 从原型开始做，两万到十万以上。只有一种情况值得：你的核心业务逻辑和通用商城差异很大（比如预约排班、按米计价、多角色协作）。

报价单应该长什么样

一份能看懂的报价，至少要按模块列，而不是给一个总数。常见模块与工作量大致如下：

如果一份报价只有「商城小程序：30000 元」，你有权要求它拆开。拆不开的报价，后期加功能一定会另收费。

哪些钱可以省

第一，首版不要做营销工具。 拼团、砍价、分销加起来可能占 20% 工作量，但你的第一批客户只有几十个时，这些工具没有任何作用。先让交易跑通。

第二，界面不要追求原创设计。 一套干净的通用版式足够。省下的钱拿去做产品图和文案，转化率提升比设计感更明显。

第三，能买现成组件就买。 富文本编辑器、图表、地图选点，都有成熟方案，没必要从零写。

哪些钱不能省

支付与对账。 微信支付 V3 的证书、回调验签、退款流程，是最容易出事的地方。省这部分，后面会因为一笔对不上的账耗掉更多时间。

权限与数据隔离。 如果有多门店或多角色，权限设计做错，后期改起来等于重做。

测试。 尤其是低端安卓机与弱网环境。很多小程序在开发者手机上流畅，在客户的旧手机上白屏。

一个更实际的问法

不要问「多少钱」，改问这三个：

1. 我这个业务，最少需要哪几个模块就能跑起来？
2. 首版多少钱、多久？第二期加会员和分销大概多少？
3. 源码给不给我？以后换人维护会不会被卡？

第三个问题最容易被忽略，但它决定了你三年后的处境。

关于「包上线」

有些报价写「包上线」，但小程序上线要过微信审核，涉及类目资质、内容合规、支付资质。没有任何服务商能保证一次过审——只能保证按规则整改到过。

所以合同里该写的是：审核被拒时，免费整改几次、多久内完成。而不是「保证上线」。

如果你手上有报价单，不确定贵不贵，可以发给我们看一眼。不给建议卖东西，就说这份单子里哪几项可以砍。

不是客户不配合，也不是开发不用心，而是「语言」不通。客户讲的是业务场景，开发听的是功能点，两边都以为自己懂了。三张图能把这件事对齐。

第一张：流程图（谁在什么情况下做什么）

不要画成「开始 → 处理 → 结束」这种给老师看的图。要画真实的分支：

• 客户下单后，什么情况下要走改价？谁有权改？
• 库存不足时，是拦截、还是允许负库存、还是转预售？
• 售后申请超过 7 天系统怎么处理？

画的时候用泳道图：每个部门一条泳道，横向表示流转。画完你大概率会发现，有三四个环节从来没有明确规则——全靠老员工临场判断。

这些模糊地带，就是后面所有扯皮的来源。

第二张：角色权限表（谁能看到什么、能改什么）

这张表经常被跳过，然后在中后期引发大量返工。至少要回答：

• 有哪几种角色？（老板、店长、销售、仓管、客服、财务）
• 每个角色能看到哪些数据？是全部、本部门、还是只有自己经手的？
• 哪些操作需要审批？金额阈值是多少？
• 谁能导出数据？（这一条最容易被忽略，也最敏感）

把它做成一张表格，横向是角色、纵向是功能，「查看/编辑/审批/导出」四列打勾。开发照着这张表建权限，比口头描述准确十倍。

第三张：状态流转图（一条数据的一生）

订单、工单、合同、报销单，任何有生命周期的东西都需要这张图。

以订单为例：

待付款 → 已付款 → 待发货 → 已发货 → 已完成 　　　↘ 已取消　　↘ 退款中 → 已退款

每个状态要写清三件事：

1. 谁能触发（客户点取消 / 后台操作 / 支付回调）
2. 触发后通知谁（站内、短信、企业微信）
3. 是否可逆（能不能从「已发货」退回「待发货」）

状态机画不清，最后一定出现「这个订单状态怎么不对」的 bug——而且很难查，因为数据本身已经乱了。

顺带说：这三张图不用很专业

不用 Visio，不用 Axure。白板拍照、或者用任意在线表格都行。重要的是内容完整，不是图好不好看。

我们做需求梳理时，通常会用 60–90 分钟跟实际使用者过一遍，边问边画，最后把图发回给客户确认。客户经常在这时候说：「等等，我们好像不是这么走的」——这正是这张图的价值。

一个反面案例

有个客户要「一个简单的报修系统」，听起来三句话能说完。画完三张图之后：

• 流程图里出现了「紧急工单」和「普通工单」两条完全不同的路径；
• 权限表里发现「区域经理只能看自己片区，但要能看到全部统计」；
• 状态图里发现「退回返工」可能循环三次以上。

原本以为两周的活，实际是六周。这不是需求变复杂了，是复杂度本来就在，只是之前没被看见。 早看见，报价和排期就是准的；晚看见，双方都难受。

你可以自己先做的一件事

在找任何团队之前，先写下你公司里最常出错的三个环节，各用五句话描述它现在怎么走。

这五句话，比一份二十页的需求文档更有用。

问题通常不在工具，在这三处。

一、切片粒度错了：整本 PDF 丢进去等于没放

检索增强（RAG）的基本原理是：把文档切成小块，用户提问时找出最相关的几块，再交给大模型组织答案。

如果你把 400 页的手册当成一个整体，检索会失效——它找到的是一整本书，模型只能截取一小段，答案往往答非所问。

正确的做法是按「一个问题一个答案」来切：

• 一条只讲一个故障现象，以及对应的处理步骤；
• 每条独立可读，不依赖上下文（不写「如上所述」）；
• 带上适用条件（型号、版本、地区）。

一页手册可能拆成 5 条，也可能拆成 0 条（纯图）。这件事没法全自动，需要人做一遍——这通常是整个知识库项目里最花时间、也最值钱的部分。

二、入口错了：让员工多开一个网页，就等于不用

知识库最常见的死法是：它在一个独立的网址上。

员工遇到问题时的第一反应是问同事、翻微信记录，而不是打开一个新标签页。所以要把它放到他们已经在的地方：

• 企业微信/钉钉的机器人，直接 @ 就能问；
• 客服系统里的侧边栏，回答客户时顺手查；
• 官网的客服入口（对外的那部分知识）。

多一步跳转，使用率就掉一半。

三、维护错了：没有回流机制，三个月后就过期

知识会过期：产品换代、政策调整、价格变化。如果维护方式是「每季度安排人整理一次」，那它一定会烂掉。

可行的机制是让回答本身成为维护动作：

• 人工回答完一个问题，旁边有一个「存入知识库」的按钮，一键生成条目；
• 每条知识显示最后更新时间与更新人；
• 用户可以对答案点「没用」，连续被点差的条目自动进入待复核队列。

把维护成本压到一次点击，它才可能持续。

顺便说：不要一开始就追求全覆盖

有个客户的计划是「把公司所有文档都录进去」。我们建议先做一块：售后最常见的 50 个问题。

原因很实际：这一块有明确的使用者（售后）、明确的场景（客户在问）、明确的成功标准（自动处理率）。做出来两周就能验证有没有用，再决定要不要扩。

全覆盖项目通常做半年，做完发现没人用，然后归因为「员工不爱学习」。

效果怎么衡量

不要看「上传了多少文档」这种虚荣指标。看三个：

1. 周活跃提问人数——有没有人真的在用；
2. 自动解决率——多少问题不需要转人工；
3. 重复提问率——同一个问题被反复问，说明答案写得不好或找不到。

第二个指标要小心：不是越高越好。把不该自动化的（涉及安全、金额、法律责任）强行自动化，短期数字好看，长期是事故。

一句话总结

知识库不是 IT 项目，是内容项目。工具占两成，剩下八成是把知识写清楚、放对位置、有人维护。

如果这三件事没准备好，买再贵的系统也没用。

一家在盐城开的洗衣店、烧烤店、家政公司，获客成本其实不高——发传单、做活动、老客介绍，都能带来人。真正的问题是：这些人来过一次之后，你还能不能找到他。

所以数字化的顺序，和很多人想的不一样。

第一件：把客户「留下来」

不是加个微信就完了。至少要做到三件事：

• 有记录：谁买过什么、什么时候、花了多少。哪怕先从一个 Excel 开始，但要能查。
• 有触达：能主动联系到他们（微信、短信、公众号），而不是等他想起你。
• 有理由回来：储值、次卡、会员日、到期提醒——机制比折扣有效。

这一步不需要小程序。一张表格加一个微信号就能起步。但没有这一步，后面所有投入都是在漏水的桶里加水。

第二件：让「附近的人」能搜到你

本地搜索的量级不大，但意图极强。有人搜「盐城 洗衣机清洗」，他是真的要下单，不是随便看看。

具体做四件事：

1. 地图标注：高德、百度、腾讯地图，把门店位置、营业时间、电话填全，上传真实照片。
2. 本地平台：美团、大众点评的类目与关键词写准确，别只写「优质服务」这种没人搜的词。
3. 一个能查的页面：哪怕只有一个页面，也要把「服务项目 + 区域 + 价格区间 + 联系方式」写清楚。微信里发链接，比发九张图专业。
4. 信息一致：地图上的电话和页面上的电话必须是同一个。不一致会让人怀疑你是骗子。

这四件事的总成本可能不到一千块，但能持续带来电话。

第三件：再考虑买流量

很多商家的顺序是反的：先投 Dou+、先买推广，客户来了却留不住，于是不断加预算。

合理的节奏是：当你能算出「一个老客一年带来多少钱」，再去买流量才有意义。 否则你只是在为平台打工。

什么时候该上小程序

出现下面这些信号，说明值得投入了：

• 月订单超过 100 单，靠人工记录开始出错；
• 有储值或次卡业务，靠纸质卡管理已经混乱；
• 有多家门店，数据要汇总；
• 想做分销/拼团，需要系统支撑。

如果只是「别人都有我也想有」，那多半做了也不用。

一个真实的对比

两家同样规模的洗衣店：

A 店：做了小程序，功能齐全，但老客户还是习惯打电话，线上下单占比不到 20%。老板觉得「系统没用」。

B 店：先做了客户登记表，第二个月开始发「取件提醒」，第三个月上了一个只有「预约 + 查进度」的小程序。线上下单占比 70%。

差别不在系统，在顺序。B 店先解决了「为什么要线上」，再做工具；A 店先做工具，再找理由。

小结

本地商家的数字化，本质上不是技术问题，是把熟客关系变得可管理。工具只是最后一步。

如果你现在正卡在「要不要做小程序」，先回答一个问题：你的老客户名单，存在哪里？如果答案是「在店员手机里」，那就先解决这个。

坑一：私钥格式不对（最高频）

报错通常是「签名错误」或「私钥格式错误」，但根因是文件格式。

微信支付要求的是 PKCS#8 格式的私钥（-----BEGIN PRIVATE KEY-----），而很多证书工具导出的是 PKCS#1（-----BEGIN RSA PRIVATE KEY-----）。两者内容一样，头尾不同，SDK 直接解析失败。

转换命令：

openssl pkcs8 -topk8 -inform PEM -in apiclient_key.pem -outform PEM -nocrypt -out apiclient_key_pkcs8.pem

判断方法：打开文件看第一行。如果不是 BEGIN PRIVATE KEY，就需要转换。

另外注意：私钥在数据库或配置里存储时，换行符容易在传输过程中丢失，导致「看起来对但用不了」。建议存 base64 或 JSON 转义后的字符串，读取时还原换行。

坑二：签名串拼接错了

V3 的签名串是五行，用 \n 连接，最后一行也要有换行：

HTTP请求方法\n
URL\n
时间戳\n
随机串\n
请求报文主体\n

最常见的三个错误：

• 请求体用了格式化后的 JSON（多了空格和换行），必须用实际发送的那一串；
• GET 请求的 body 是空字符串，但漏了最后的 \n；
• URL 带了 query 参数却只取了 path。

排查技巧：把待签名串打印出来，逐行比对。肉眼看不出问题的时候，用 var_dump 或 console.log 输出成数组更容易发现尾部空格。

坑三：回调验签与解密顺序搞反

支付结果通知是加密的：先验签（确认来自微信），再解密（拿到明文），顺序错了会得到一堆乱码。

需要注意：

• 验签用的是平台证书或微信支付公钥，不是你自己的商户证书；
• 微信支付正在从「平台证书」迁移到「微信支付公钥」模式，新商户直接按公钥模式配置，别照抄旧教程；
• 回调必须返回 {"code":"SUCCESS","message":"成功"}，HTTP 200。返回纯文本 success 会被判定为失败并持续重试。

坑四：金额单位

V3 全部用「分」为单位，整数。1.00 元 要传 100。

这个坑的后果比较严重：传成 1 就是收了一分钱，传成 100.00 会直接报参数错误。建议在业务层就统一用整数分存储，展示时再除以 100，避免浮点数到处飘。

坑五：退款与对账的时间差

• 退款不是实时的，异步结果通过回调通知，别在接口返回成功后就改订单状态；
• 对账单是 T+1 生成，当天查不到；
• 对账文件的金额字段是元（带两位小数），和下单时的「分」不同单位，解析时容易错。

建议做法：订单表单独存「支付金额（分）」，对账时统一换算，别在多处做单位转换。

一个实用的排查顺序

遇到问题，按这个顺序走，能省掉大部分时间：

1. 看错误码：V3 的错误码比 V2 清晰，PARAM_ERROR、SIGN_ERROR、ORDER_NOT_EXIST 含义明确；
2. 打印待签名串：90% 的签名问题在这一步现形；
3. 单独跑一次最小请求：用一个固定参数的查询接口测通，再回到业务代码；
4. 检查服务器时间：时间戳偏差超过 5 分钟会验签失败，这在容器环境里很常见；
5. 确认证书序列号：请求头里的 serial_no 必须和你用的证书匹配，切过证书后容易忘改。

最后一句

支付这块不建议「先跑通再优化」。金额、幂等、回调重试、退款状态，这四个地方一旦设计错，后期修起来比重写还麻烦。

接入前花半天把状态机和幂等键想清楚，能省掉后面两周的救火。

一、每页标题唯一且具体

怎么查：逐页看浏览器标签页标题。

合格标准：每页不同，包含「业务词 + 地域/行业 + 品牌」，长度约 30 个汉字内。

不合格：全站都叫「XX 公司-官方网站」。后果是搜索引擎不知道你哪页讲什么，通常只收录首页。

二、描述不是关键词堆砌

怎么查：查看源码里的 meta name="description"。

合格标准：一句话说清「做什么、给谁、有什么不同」，约 80 字内。

不合格：写满关键词，或者干脆没有。搜索结果的摘要会由引擎自己截取，通常很难看。

三、H1 只有一个

怎么查：搜索源码中 <h1。

合格标准：每页恰好一个，内容与页面主题一致。

不合格：全站用 Logo 图片做 H1，或有五个 H1。层级混乱会让引擎难以判断重点。

四、canonical 正确

怎么查：link rel="canonical"。

合格标准：指向当前页的规范地址，带协议与域名，不带多余参数。

不合格：全站 canonical 都指向首页 —— 这会导致其他页面不被收录，是致命错误。

五、sitemap.xml 存在且已提交

怎么查：访问 /sitemap.xml，再去看百度/必应/谷歌站长后台。

合格标准：包含所有重要页面，有 lastmod，已在站长平台提交。

不合格：文件不存在，或是一年前生成的。

六、robots.txt 没挡住自己

怎么查：访问 /robots.txt。

合格标准：放行需要收录的目录，屏蔽后台与管理接口，包含 sitemap 地址。

不合格：测试环境上线时顺手写了 Disallow: /，然后忘了删——这是「网站不收录」最常见的原因。

七、移动端可用

怎么查：手机打开，看是否需要横向滚动、字号是否过小、按钮是否能点。

合格标准：内容自适应，无需缩放即可阅读。

不合格：PC 版直接缩放。移动端优先收录已经是主流，这一项不合格，其他都白做。

八、首屏加载可接受

怎么查：开发者工具 Network 面板，看「DOMContentLoaded」与总体积。

合格标准：首屏 2 秒内可见内容，首屏资源控制在 1MB 左右。

不合格：首屏要加载 5MB 图片、三个轮播插件、两个字体包。

九、图片有 alt 且尺寸合理

怎么查：源码里看 alt 属性；看图片原始尺寸是否远大于展示尺寸。

合格标准：描述性 alt（不是「图片1」），按展示尺寸压缩，使用 WebP/AVIF。

不合格：4000px 的图缩到 400px 展示——白等几秒钟。

十、内链结构清晰

怎么查：从首页出发，三次点击内能否到达任意重要页面。

合格标准：服务页、案例页、文章页互相链接，有面包屑。

不合格：所有页面只能从导航栏进入，文章之间没有关联。孤岛页面很难被赋予权重。

十一、结构化数据

怎么查：源码搜 application/ld+json，或用搜索引擎的富媒体测试工具。

合格标准：至少有 Organization、WebSite，文章页有 Article，问答页有 FAQPage。

不合格：完全没有。这是 AI 引擎理解你的最低门槛，也是现在最值得补的一项。

十二、404 与重定向正确

怎么查：随便访问一个不存在的地址；再访问一次带 www 和不带 www 的两个版本。

合格标准：不存在的页面返回 404 状态码（不是 200），并且 www 与非 www 只有一个能访问，另一个 301 过去。

不合格：错误页返回 200，导致大量「软 404」；两个域名都能打开，权重被分裂。

查完之后做什么

不用一次全改。按影响排序：

1. 先修「挡路」的：robots、canonical、404 状态码、移动端；
2. 再补「加分」的：标题描述、结构化数据、sitemap；
3. 最后优化「体验」的：加载速度、内链、图片。

改完不要立刻期待流量。搜索引擎重新抓取需要时间，通常 2–4 周看到收录变化，2–3 个月看到流量曲线。

如果你懒得自己查，把这 12 项发给我们，我们出一份带截图的问题清单——免费的。

大多数回答要么是「看预算」，要么是「两个都要」。这两句都等于没说。真正能判断的，是下面三个问题。

问题一：你的客户在哪找你？

在微信里（老客介绍、社群、朋友圈）→ 先做小程序。 这类客户的决策快、路径短，从看到到下单最好不超过三次点击。小程序在微信内可直接打开，转发也方便。

在搜索引擎或 AI 里（搜「XX 厂家」「XX 服务」）→ 先做官网。 这类客户的决策周期长，会反复查证：你是谁、做过什么、有没有资质。官网是唯一能承载这些内容的容器，小程序不方便被外部搜索收录。

两边都有 → 先做官网。 原因很实际：官网可以为小程序导流，反过来不行。而且官网的内容资产（文章、案例）会持续带来免费流量，小程序不会。

问题二：决策周期多长？

一周内能成交的生意（餐饮、零售、家政），工具越轻越好，小程序优先。

一个月以上才成交的生意（设备、工程、企业服务），客户一定会做背景调查。这时候需要的是：能证明你靠谱的页面——案例、资质、团队、过程说明。这是官网的活。

问题三：复购靠什么？

• 靠便利（又来买一次）→ 小程序；
• 靠信任（找同一家放心）→ 官网 + 内容；
• 靠关系（销售跟进）→ 两者都不是核心，CRM 更重要。

想清楚这一条，就不会把预算花错地方。

一个常见的错误组合

「先花两万做官网，上线后没流量，觉得官网没用；再做小程序，没人下单，觉得小程序也没用。」

问题不在工具，在于两个都只做了「壳」：官网没有内容，搜不到；小程序没有运营，没人来。

更合理的做法是：选一个，把它做透。

官网做透 = 20 个能回答具体问题的页面 + 每周更新； 小程序做透 = 一个能跑通的交易闭环 + 前三个月的冷启动运营。

如果预算只够一个

我的建议是：面向本地消费者选小程序，面向企业客户选官网。

因为本地消费者的路径在微信里闭环，而企业客户的信任建立必须发生在能被搜索、能被转发链接的地方。

两个都要的时候，顺序是什么

先官网，后小程序，间隔 1–3 个月。理由：

1. 官网先上线，可以开始积累搜索收录，这是慢变量，越早越好；
2. 官网跑一段时间后，你能看到客户真正关心什么（哪些页面停留久、哪些问题反复出现），这些信息可以直接指导小程序的功能取舍；
3. 小程序上线时，官网已经有了内容可以导流。

反过来（先小程序后官网）也不是不行，但你会浪费掉那几个月的内容积累期。

最后

不要因为「同行都有」而做。先回答上面三个问题，答案通常很清楚。

如果还是不确定，把你的业务用三句话讲给我们听，我们给一个明确建议——包括「现在先别做」这种建议。