环形山技术栈：四个自研插件解决出海站的什么问题
一、出海站的四条断裂
在给客户做站点审计时，反复出现的不是”缺少某个功能”，而是同一件事的信息分散在三四个地方，彼此不同步。四条最典型的断裂：
| 断裂 | 表现 | 真实代价 |
|---|---|---|
| 语言断裂 | 翻译插件只管翻译，不管 hreflang 与多语言 URL | 翻译做了，但在目标语言里搜不到 |
| 线索断裂 | 表单插件、统计工具、CRM 各自为政 | 有询盘但不知道从哪来，无法优化 |
| 安全断裂 | 要么裸奔，要么安全插件一刀切拦截 | AI 爬虫被误挡，GEO 通道直接失效 |
| 内容断裂 | 内容资产（技术文档、案例）无法批量进入站点 | 内容团队的成本花在”手工搬运”上 |
这四条断裂的共同特征：单独看每个环节都没问题，连在一起就出问题。
比如”语言断裂”：翻译功能本身很好用，但它不与 SEO 层联动，所以生成了德语页面却没有对应的 hreflang 和德语 URL——页面存在，但搜索引擎不知道它的存在。
所以技术栈的设计思路不是”堆功能”，而是让每条链路端到端打通。
二、环语 LinguaSEO：语言层
解决的断裂： 翻译与 SEO 分离。
核心能力
| 能力 | 具体内容 | 解决什么 |
|---|---|---|
| 自动翻译 | 内容翻译 + 语言切换 | 让客户能看懂 |
| 多语言 URL | 每种语言独立 URL 结构 | 让页面能被目标语言搜索到 |
| hreflang 自动生成 | 自动输出双向互引 + x-default | 解决”多语言站被判定重复内容” |
| 多语言站点地图 | 每种语言的 sitemap 独立输出 | 让搜索引擎完整发现各语言页面 |
| 翻译状态管理 | 标记未翻译 / 已翻译 / 待更新 | 避免”参数更新了但德语页还是旧的” |
| 后台菜单控制 | 后台左侧菜单的隐藏与排序 | 给客户精简后台界面 |
设计取向
“翻译即 SEO”——翻译与 SEO 不是两步，是同一个动作的两个输出。每翻译一个页面，同时产出：目标语言内容、独立 URL、hreflang 标签、站点地图条目。四样东西必须由同一次操作生成，否则一定会出现某一项漏掉。
能力边界（不做什么）
| 不做 | 原因 |
|---|---|
| 不做人工翻译服务 | 插件负责工程链路，翻译质量由译者/客户决定 |
| 不改写产品参数 | 参数是事实，插件不生成、不修改事实 |
| 不做术语库强制替换 | 术语一致性靠译者按术语表执行，不靠自动替换（自动替换会误伤） |
三、环迹 LeadPulse：线索层
解决的断裂： 表单、追踪、归因三套系统各自为政。
三大模块
| 模块 | 功能 | 关键设计 |
|---|---|---|
| 表单转化 | 22 种字段类型，含国际电话区号、IM 联系方式、多币种 | 条件显示、宽度分栏、字段级校验 |
| 按钮转化 | 曝光 / 点击 / 转化率统计 + 点击明细 | 不限于表单，任何 CTA 都可追踪 |
| 访问统计 | 每日 UV/PV、7/14/30 天趋势、核心页面 Top 100 | 人与爬虫分开统计 |
三个值得说明的设计
① 每条转化携带 26 项来源与设备数据。
包含渠道、访问环境、国家/地区、设备类型、Click ID 等。目的很明确：让”这条询盘值不值得跟”有判断依据，而不只是”收到一条询盘”。
② AI 爬虫识别（50+ 爬虫，分 5 类）。
爬虫不执行 JavaScript，所以走服务端钩子采集，与人类访客分开统计。其中 AI 爬虫（GPTBot、ClaudeBot、PerplexityBot 等）的活跃度，是 GEO 的前置信号——正如我们在另一篇文章里讨论的，被读是前提，被引用是结果。
③ 归因口径遵循”可比较”原则。
- First Touch 只在真带回来源时写入（直接访问不占首触位）
- Last Touch 每次覆盖，默认口径为 last_non_direct
- 12 种 Click ID 独立存储，保留 90 天
- 同域 referrer 剔除
- 微信作为”访问环境”维度，与”渠道”正交存储
能力边界
| 不做 | 原因 |
|---|---|
| 不做邮件通知服务 | 通知与 SMTP 配置由客户或第三方承担（避免与客户既有系统冲突） |
| 不替客户判断线索价值 | 只提供数据，判断与跟进由客户业务团队做主 |
| 不做访客级别的个人画像 | 只做统计与归因，不构建个人画像（合规考虑） |
四、环盾 CraterGuard：安全层
解决的断裂： 安全策略与业务通道互相冲突。
核心能力
| 能力 | 内容 |
|---|---|
| 安全基线加固 | 登录保护、文件权限、常见漏洞面收口 |
| REST 接口管理 | 默认锁定（返回 401 cg_rest_locked），需要时按需放行 |
| 异常访问防护 | 高频请求、异常 UA、扫描行为识别 |
| 安全审计与修复 | 提供扫描与修复流程，支持域名 + 凭证的极简调用 |
一个关键取向：不要”一刀切拦截”
安全插件最常见的副作用是把 AI 爬虫和搜索引擎爬虫一起挡掉。这在 GEO 语境下是致命问题：站点的 GEO 通道被自己的安全策略关闭，而且没人知道。
所以环盾的设计原则是分级放行：
| 类型 | 策略 |
|---|---|
| 搜索引擎爬虫（Googlebot / Bingbot） | 放行（并校验真伪） |
| AI 检索型爬虫 | 放行（GEO 通道） |
| AI 训练型爬虫 | 可放行（按策略） |
| 扫描 / 攻击行为 | 拦截 |
与 robots.txt 的分工：robots.txt 是”声明”（告诉爬虫不要来），环盾是”执行”（在应用层真的拦或不拦）。两者必须一致——如果 robots.txt 放行了 GPTBot 但环盾在应用层拦掉了，那就是白放行。这是审计中最常发现的配置矛盾之一。
五、环汇 CraterInflux：内容进站层
解决的断裂： 内容资产无法安全、批量地进入站点。
三段式设计
| 阶段 | 做什么 | 为什么这样设计 |
|---|---|---|
| ① 预演 | 解析包，给出数字（将新增 / 更新 / 跳过 / 冲突） | 不落库，先看清楚会发生什么 |
| ② 预览 | 轻预览（不落库，只验正文渲染） / 全预览（落临时草稿，30 分钟自动清理） | 让作者在发布前真的看到页面 |
| ③ 发布 | 落库，输出 URL 清单（可复制纯链接 / Markdown / CSV） | 发布后可核对、可分发 |
包格式与幂等
| 项 | 设计 |
|---|---|
| 包结构 | manifest.json（根目录）+ content/*.html + media/ |
| 正文格式 | HTML 片段（无 front-matter） |
| 幂等键 | pack_id + external_id（不按标题或 slug 推断） |
| 分类与标签 | 不存在时自动创建，或按配置忽略 |
| 媒体 | 位图进媒体库；SVG 默认内嵌（embed），零上传风险 |
为什么幂等键不能用标题或 slug？因为标题改一个字、slug 手工调一次，靠猜就会新建出重复内容，而且事后极难清理。用”来源侧稳定不变”的标识作为键，才能保证重复导入是安全的。
安全默认（都不可配置）
| 默认 | 说明 |
|---|---|
| 默认状态为草稿 | 导入不等于发布 |
| 包内禁止可执行文件 | .php / .js / .phar 等直接拒绝整包 |
| 体积闸 | 单文件 2 MB / 整包解压 50 MB / 单条目正文 500 KB |
| 防 zip 炸弹 | 解压前先读中央目录，超限直接拒绝 |
| SVG 消毒白名单 | 剥离 script / 事件属性 / 外部引用（用 DOM 解析，不用正则） |
六、环枢 CraterHub：授权与分发层
四个业务插件之上，还有一个管理层的组件：环枢负责授权、分发与在线更新。
| 角色 | 部署位置 | 职责 |
|---|---|---|
| 主控端（master） | 服务方（域名锁定） | 管理授权项、生成授权 |
| 被控端（agent） | 客户站 | 校验授权、上报状态 |
| 版本仓库 | 分发服务器 | 提供包清单与文件 |
授权项是集中注册的：目前共 6 项，分别对应主题与各插件。这套设计的意义是让”授权到期后怎么办”变成一个有明确规则的事，而不是等到期那天再临时处理：
| 档位 | 语义 |
|---|---|
| A | 只停新增（存量与前台不变，停更不停修） |
| B | 存量保留，增量停 |
| C | 分级撤回（安全基线永久保留） |
一条重要的设计原则：未安装环枢时，各插件退化为”放行/静默”，行为与安装前逐字节等价。这保证了插件可以独立使用，不会因为”忘装管理端”而整体失效。
一个例外值得说明：环汇在未装环枢时是”只读降级”——能解析、能预演、能预览，但不能发布。原因是”批量写入站点”属于高影响动作，默认保守。
七、为什么自研而不是拼装
公开的 WordPress 插件生态很丰富，大多数功能都能找到现成方案。选择自研的理由不是”自己做得更好”，而是三个具体问题：
| 问题 | 拼装方案的状况 | 自研方案的处理 |
|---|---|---|
| 口径不统一 | 每个插件有自己的一套归因/SEO 口径，数据无法合并 | 全系列共享同一套数据口径与字段定义 |
| 链路不打通 | 翻译与 SEO、表单与归因之间需要写胶水代码 | 链路在设计时就是端到端打通的 |
| 安全与合规不可控 | 第三方插件的代码质量与数据处理方式无法审计 | 代码自持，可审计、可修改、可向客户说明 |
还有一个实际原因：客户站的长期可维护性。拼装方案的问题往往在两年后爆发——某个插件停止更新、某个更新引入了不兼容、某处数据口径变了导致历史数据不可比。自研的代价是初期投入，收益是可预测的长期维护。
一个明确的边界
这套技术栈不替代客户业务系统：
| 不替代 | 说明 |
|---|---|
| ERP / CRM | 插件输出线索数据，可对接；不承担客户关系管理 |
| 邮件营销平台 | 通知与序列邮件由专业平台承担 |
| 设计系统 | 提供结构与组件规范，视觉由主题决定 |
定位是”出海站的工程底座”——把站点本身的语言、线索、安全、内容四条链路做扎实，让上层业务系统接入时不需要再处理这些底层问题。
FAQ 常见问题
| 场景 | 建议组合 |
|---|---|
| 单语言出海站，重线索 | 环迹 + 环盾 |
| 多语言出海站 | 环语 + 环迹 + 环盾 |
| 内容量大、需要批量进站 | 加环汇 |
| 需要统一授权与在线更新 | 加环枢 |
| 维度 | 常见拼装方案 | 环形山技术栈 |
|---|---|---|
| 数据口径 | 各插件独立定义 | 全系列统一（渠道、环境、来源字段一致） |
| 安全与 AI 通道 | 安全插件默认拦截非人类流量 | 分级放行，明确保留 AI 检索通道 |
| 批量写入 | 直接落库，先写后看 | 预演 → 预览 → 发布，默认草稿 |
| 幂等策略 | 多按 slug 或标题判断 | pack_id + external_id，来源侧稳定标识 |
| 层面 | 做法 |
|---|---|
| 资源加载 | 前台资源按需加载，管理端样式不进入前台 |
| 查询 | 数据表带索引，统计类查询做聚合缓存 |
| 外部请求 | 访客归属默认走”轻量模式”（读 CDN 头 + 时区推断），不做逐请求的 IP 查询 |
写在最后
出海站的技术工作，容易陷入”装插件、配功能”的状态——每装一个就解决一个具体问题，但整体上仍然支离破碎。
真正需要先回答的问题是：我的站点上，有哪几条链路是断的？
语言层断了吗（翻译与 SEO 是否联动）？线索层断了吗（询盘能不能追溯到来源）？安全层断了吗（AI 爬虫是否被误挡）？内容层断了吗（内容能不能高效进站）？
四条链路各自打通，站点才算有了可用的底座；底座稳了，SEO、GEO、投放、内容这些上层动作才有复利。这也是这套技术栈存在的理由——不是为了让站点”功能更多”，而是为了让每条链路不再断在半路。