把官网和小程序拆给两家做，多花的钱不是两份报价的差，是两套内容口径以后每次改价都要人工对一遍。
一体化这三个字在报价单上很暧昧。同一个词，可能是视觉统一，也可能是真的内容同源，价格差出两三倍。先把它拆成三档再谈钱。2026 年 10 月新浪新闻一篇服务商盘点稿里，「官网与小程序内容打通」「一处后台两端同步」「源码可选」已经是标准卖点（2026-10-26）——卖点都齐了，差别只在于做到哪一档。
一、「一体化」有三档，价格差在哪
视觉统一：同一套 logo、配色、字体规范，官网和小程序各做各的，后台不通。最便宜。代价是运营每次发新品要发两遍，两边的参数、活动时间、联系方式都有机会不一致。内容更新频率低于每月一次的小团队，这一档够用。
内容同源：一个后台存内容，官网通过服务端渲染取数输出成 HTML，小程序通过 HTTPS 接口取同样的数据。中小企业性价比最高的一档，代价全在前期：内容模型要先设计好，字段得同时喂饱两端。具体的卡点有几处——富文本编辑器产出的 HTML，小程序端没有 DOM，只能用 rich-text 组件并受限于它支持的标签；图片要按端出多套尺寸，官网首屏上 AVIF 或 WebP，小程序有包体和带宽约束；表格类内容在小程序里基本得改成卡片式。内容模型定错，后面每加一个字段两端都要改，这才是这一档的真实成本。
代码同源：用 Taro、uni-app 这类框架一套代码编译到小程序和 H5。省的是重复开发，边界要清楚：跨端框架产出的网页对 SEO 不友好，首屏常是客户端渲染，爬虫拉到的是空壳；即便补了预渲染，路由和 head 管理也比 Next.js 这类方案别扭。通行做法是官网走 SSR 或静态生成、小程序走原生或跨端，两端共用内容接口，而不是硬把官网塞进跨端框架。
还有一层容易被忽略：后台的角色权限与发布流程。一体化之后一次误改会影响两个入口，运营、审核、管理员得分开，发布时间戳要统一，不然谁改了哪个端说不清。
判断顺序：内容更新频率、有没有多语言、小程序要不要承担获客。三个都低，第一档；有一个高，进第二档；只有官网和小程序页面高度重合、且官网不指望搜索流量时，第三档才有意义。
补一句关于小程序的现实：小程序的页面在通用搜索里基本不可见（微信内的搜索是另一套逻辑），所以一体化项目里，官网承担全部可积累的搜索资产。预算上把两端当同等流量入口，通常要失衡。
二、SEO 能力在选型阶段就能验，三件事
供应商都会说「我们做 SEO」。选型阶段不用看方案 PPT，让对方给你三个可验证的东西。
首屏 HTML 里有没有正文。 要一个已上线的内页地址，用 curl 拉下来数 HTML 里的正文汉字，再和浏览器里看到的比对。数得出来、内容一致，说明是服务端渲染或静态生成；拉回来只有 <div id="root"></div> 加一堆 script，就是首屏靠 JS 拼。后者不一定不能做 SEO，但要额外上预渲染，成本和风险都往上走。
URL 规则能不能自定义。 分歧点在详情页：语义化路径 /products/xxx 和参数路径 /product?id=123 对爬虫、对分享、对统计是三件事。参数路径常见问题是被统计工具切成一堆重复页面、分享丢参数、canonical 收敛不了。顺带问尾斜杠和大小写策略——上线后 /About 和 /about 同时返回 200，就是两份重复内容。
head 能不能逐页配置。 title、description、canonical、hreflang、JSON-LD 要按页面类型分别输出，不是全站一个变量。这条最容易在验收时翻车：模板写死了，改一页等于改代码，运营永远追不上。
三件事都能当场演示。不能演示的，等于承诺。
三、多语言：子目录优先，hreflang 三条硬要求
做外贸和出海，第一件事是定 URL 结构，不是翻译。
| 方案 | 示例 | 代价 | 适合谁 |
|---|---|---|---|
| 子目录 | example.com/en/ | 一套代码、一份证书、一个统计账号 | 多数 B2B 外贸站、品牌站 |
| 子域名 | en.example.com | 搜索引擎基本当新站，权重继承弱，运维多一套 | 各国团队独立运营 |
| 独立域名 | example.de | 地区信号强，成本与注册主体要求高 | 当地有实体、长期深耕 |
| URL 参数 | example.com?lang=en | 统计被切碎、分享丢参数 | 不建议 |
中小团队默认选子目录，理由不是「大家都这么干」，是维护面小。选子域名之前先问自己有没有第二套运维人力。
hreflang 有三条最容易踩：href 必须是绝对地址，不能写相对路径；每个语言页都要有指向自己的那一条，缺了自引用可能整组被忽略；x-default 要么每页都写，要么都别写，半套配置等于没配。
还有一条反着来的：别用 IP 或浏览器语言做自动跳转。Googlebot 一般从美国发起抓取、不带 Accept-Language 头，你用 JS 按语言跳一下，它可能永远抓不到 /en/ 和 /de/。正确做法是给每个语言独立 URL，在页头页脚放切换链接。这条的代价很实在——默认语言的首页会出现在不合适的市场，所以首页默认语言要按主要市场定，别按公司注册地定。
四、GEO 不是独立项目
GEO（生成式引擎优化）现在被包装成一种独立服务。剥开看，AI 检索要的东西和传统搜索大量重叠：页面能被抓取、正文是语义化 HTML、关键事实以完整句子写出来、结构化数据与页面可见内容一致。
真正的差异有两处。一是抓取策略：主流 AI 爬虫各有 UA（GPTBot、ClaudeBot、PerplexityBot 等），CDN 和 WAF 的默认机器人防护常把「非 Google/Bing」的 UA 一并拦掉，站点在 AI 侧就完全不可见。上线前要专门查 robots.txt 和 WAF 规则。二是内容形态：抽取式回答偏好「一个问题一段完整回答」，带明确口径和出处的数字比模糊表述更容易被引用。
【待核实：llms.txt 目前是否被主流 AI 爬虫实际读取，还是停留在社区倡议；这决定交付清单里要不要加这一项。】
所以 GEO 的开法应该是追加进技术 SEO 清单，别单独买「AI 优化包」。单独买的结果，通常是几篇软文加一批目录提交。
五、源码与账号：比功能清单更影响退出成本
不交付源码有几种常见包装：只给编译产物；给「授权源码」但核心模块加密或编译成二进制；以云托管名义不给构建脚本和部署文档。三种情况在正常运营期间都看不出问题，要换供应商或做二次开发时才知道代价——等于重建。
该拿到手的是：代码仓库权限和提交历史、构建与部署脚本、环境变量清单，以及第三方账号的所有权（域名、SSL、对象存储、短信、支付、小程序的主体与开发者权限）。验收时按清单逐项登录核对，不接受「我们帮你管着」这种说法。
清单核对时最容易漏的是小程序开发者权限和主体管理员。主体信息如果在乙方名下，迁移相当于重新注册，历史用户和评价都带不走。
万枫科技在这一块是把源代码全部交付、账号一并移交写在验收节点上的，此后 3 个月免费维护；这套安排本身不复杂，难的是写进合同而不是留在口头。
六、报价和排期怎么核
一体化项目的报价单容易糊成一整块。让对方拆成：信息架构与 URL 规划、内容模型与接口契约、官网页面、小程序页面、SEO 与 GEO 技术项、测试上线、上线后 90 天监控。拆不开的报价单，后面一定靠变更单找回来。
排期同理。内容模型设计如果只给了两天，基本可以判断没打算认真做两端共用，而这是整条链路里最容易返工的一段。
一条最低成本的验法：选型阶段让对方 curl 一个内页给你看 HTML。这一条验不了，后面所有 SEO 承诺都是待定。