标题与文案批量复制
同一套介绍换个城市名发十几遍，站点之间互相稀释，模型也拿不到区分信息。
换思路模板共用，正文按站点、按业务单独维护。
GEO 官网建设 · 多站点架构
站点可以很多，
站点可以很多，
规则只需要一套
集团官网、城市分站、业务子站、栏目内容页，最怕的不是数量多，而是每站一套地址、每处一段重复文案，最后连 AI 都分不清哪个才是官方说法。这套建站系统把口径、模板与内容治理收在一处，让每个站点既统一、又各自成立。
适用：集团与多品牌、多地域经营、城市分站与业务子站并行的企业。
站点矩阵示意ONE RULE / N SITES
统一规则层
URL · 结构化数据 · 模板 · 安全基线
品牌主站主体信息 / 核心服务
城市分站 A本地案例 / 地域服务
业务子站 B产品线 / 解决方案
内容栏目文章 / 产品 / FAQ
规则共用，内容独立：示意图仅用于说明层级关系。
01 / 先说问题
站群做着做着，最容易踩这三个坑
坑都不在「页面好不好看」，而在结构和管理方式。
各站地址各写一套
分类、栏目、自定义地址没有统一判定，站内链接与 canonical 各说各话，改版时无从对齐。
换思路地址规则集中定义，内链与规范链接共用同一逻辑。
改一处要改 N 遍
一个公共组件出问题，十几个站点逐台登录处理，版本越改越乱，最后没人敢动。
换思路公共产物统一构建分发，按站核对版本再上线。
02 / 架构分层
三层拆开，多站点才管得动
底层越统一，上层越自由；这句话反过来做，就会变成一堆互相牵扯的站点。
L1统一底座
自定义地址、有效分类、停用分类与栏目各有明确判定；文章、产品、案例的地址、站内链接、规范链接和跳转都调用同一套生成逻辑。站点配置、结构化数据输出与安全基线也放在这一层。
- 地址规则集中定义，退化为 ID 的情况有兜底
- 按页面类型输出实体、时间与面包屑
- 预处理查询、输出转义、上传校验、CSRF 与登录凭据统一处理
L2站点矩阵
每站独立域名、独立数据库、独立栏目与内容；公共模板与后台产物由母站统一构建后分发。分发前比对目标站版本，线上更新的文件只做精确块替换，不做整文件覆盖。
- 每个站点保留自己的标题、正文、案例与联系信息
- 模板升级按站核对，避免互相拷错版本
- 推送后校验文件、清理编译缓存并复验页面
L3内容治理
话题检测找出还没被回答的问题，创作队列按站点拆任务，发布规则控制每天篇数、间隔与时段，报表把收录与内容缺口回流成下一轮选题依据。
- 按站点拆分选题，减少跨站重复
- 发布时段与间隔可配置，时间不出现未来值
- 站点说明文件与站点地图随栏目变化重建
03 / 地址与内容口径
四类页面，各自该说什么、放哪里
先定层级，再定内容来源，站群才不会长成一团互相重复的页面。
| 页面层级 | 地址口径 | 结构化数据 | 内容来源 |
|---|---|---|---|
| 品牌主站 | 根域名 + 固定单页，全站入口稳定不随活动变动 | 组织信息、站点导航、服务与联系点 | 企业主体信息、核心服务与能力边界 |
| 城市分站 | 独立域名或独立栏目，地域信息写在正文而非只改标题 | 本地服务范围与地域实体属性 | 本地案例、服务说明、区域联系方式 |
| 业务子站 | 按业务线划分栏目，分类启用状态统一判定 | 产品、案例、方案与 FAQ 按页输出 | 产品线资料、参数、交付与常见问题 |
| 栏目内容页 | 自定义地址优先，其次有效分类，无分类回落栏目 | 文章 / 产品实体、发布时间、面包屑 | 话题缺口、创作队列与人工审核内容 |
表里是规则口径，不等于上线后立刻获得收录或引用；效果受站点历史、内容质量与检索环境影响。
04 / 内容治理
四步走完，下一轮选题就有依据
重点不是一次发多少篇，而是每站都补自己的缺口。
- 01
口径统一
先固定地址规则、栏目层级与页面结构，各站不再自由发挥。
- 02
模板分发
公共产物构建后按站核对版本，推送、清理缓存、复验页面。
- 03
分站差异化
按站点拆选题与正文，地域、业务、案例各写各的，不做批量替换。
- 04
报表回流
收录、引用与内容缺口回到后台，成为下一轮任务的输入。
05 / 交付边界
系统里有什么，一次说清
切换查看三类清单，避免「上线之后才发现少一块」。
- 站点矩阵与地址规则表（含老地址对应关系）
- 按站配置的栏目、模板、页面文案与结构化数据
- 站点地图、文本地图、llms 说明与 AI 知识文件
- 可视化后台、完整源代码、部署环境与域名权限
- 发布规则配置、探活与日志核对方法
- 文章、产品、案例、单页、菜单、轮播与询盘自助维护
- AI 发布规则：每日篇数、发布间隔、时段与目标栏目
- 话题检测、创作队列、发布报表与内容缺口回看
- SEO 单页配置、FAQ 问答库与站点说明内容维护
- 静态页、模板编译缓存与站点配置缓存的清理入口
- 数据库预处理与参数绑定，标识参数强制整型转换
- 模板输出统一转义，双提交 Cookie 的 CSRF 校验
- 上传仅限图片类型并校验 MIME，压缩后限制体积与尺寸
- 密码哈希存储，会话 Cookie HttpOnly + SameSite=Lax
- 敏感配置加密存储、掩码回显，备份文件不放在可下载目录
多个站点用同一套系统，会不会被判成重复内容？
重复往往来自「同一篇文案换城市名发一遍」，不是来自共用程序。我们的做法是模板与规则共用、内容与数据分开：每个站点独立数据库，栏目、标题、正文、案例与联系信息按站点维护，地址口径统一但页面内容不复制。
老站已经有一批收录链接，升级时要不要全部换成新 URL？
不建议。先导出老地址与收录情况，能保留的保留；必须调整的先建立老地址到新地址的对应关系，再分批处理。存量链接不做映射就整体重指向，最容易把已有权重一次清掉。
每个站点都要单独配一套后台吗？
站点的数据与域名各自独立，但后台能力是一套：文章、产品、案例、单页、菜单、轮播、询盘、发布规则都在可视化界面维护。母站负责构建与分发公共产物，各站的业务数据不混在一起。
模板改一处，所有站点都会立刻一起变吗？
公共模板统一构建后按站分发，但分发前会先确认目标站的版本，线上比本地新的文件不做整文件覆盖，只做精确块替换；推送后核对文件校验值、清理模板编译缓存并复验页面，避免「升级一次、全站一起坏」。
多站点项目的交付包含哪些内容？
包含站点矩阵与地址规则表、按站配置的栏目与模板、可视化后台、完整源码与部署环境，以及结构化数据、站点说明文件、内容发布规则和报表口径。域名、服务器与后台权限归企业所有，不绑定服务商平台。
先把站点矩阵画清楚，再决定建几个站
提供现有域名、业务线与地域范围，我们按上面的层级给出地址口径、内容分工和分阶段实施清单。