一套仓库管理多站点：性能优化与搜索友好全链路指南

一、同仓库多站点：为什么这件事值得做

1.1 场景

假设你正在维护公司官网矩阵：

• 主站：品牌官网（www.example.com）
• A 站：产品能力站（site-a.example.com）
• B 站：行业方案站（site-b.example.com）

初期为了“快”，你把它们拆成 3 个仓库。上线几个月后，问题开始集中爆发：

• 公共组件和样式要重复维护，改一次要同步三遍。
• sitemap.xml、robots.txt、canonical、结构化数据经常配不一致。
• 构建和发布链路分散，CI 时间长，发布时容易漏某个站。
• 对 AI 爬虫的策略没人统一管理，llms.txt 有站点有、有站点没有。

最终你会发现：你不是在做“多站点”，而是在维护三套“近似系统”。

1.2 什么是“同仓库多站点”

一句话：一个仓库管理多个站点入口，复用一套共享能力，通过站点配置实现差异化输出。

可以拆成三层：

1. 站点层：每个站点拥有独立路由入口和域名信息。
2. 共享层：统一复用组件、样式、SEO 工具、内容模型、构建脚本。
3. 构建层：按站点参数构建，产物隔离输出，独立部署。

它不是“把页面放一起”，而是把可复用能力工程化沉淀。

1.3 在应用链路中的位置

1. 内容开发（共享组件 + 站点配置）
    ↓
2. 按站点构建（main / site-a / site-b）
    ↓
3. 生成 SEO 工件（canonical / sitemap / robots / schema）
    ↓
4. 生成 AI 工件（llms.txt / 可读内容索引）
    ↓
5. 分站点部署到 CDN/边缘网络
    ↓
6. 搜索引擎与 AI 爬虫抓取、索引、引用

关键点：SEO 与 AI 友好不能靠“上线前手工检查”，必须在构建链路里自动化完成。

二、为什么这种架构天然更高性能

2.1 开发性能（团队效率）

• 共享模块一次升级，多站点同步收益。
• 统一依赖版本，减少“站点间行为不一致”。
• 可以做“受影响站点增量构建”，避免全量构建浪费。

2.2 运行性能（用户体验）

• 全站统一性能预算（LCP、INP、CLS）和资源策略。
• 静态化优先，配合 CDN 提升首屏速度。
• 共享层统一治理资源体积，避免“某站点偷偷变重”。

2.3 运营性能（可持续迭代）

• SEO 策略一致，降低漏配风险。
• AI 爬虫策略一致，提升内容被模型理解与引用概率。
• 发布流程标准化，新站点接入成本显著降低。

三、实战：构建一个高性能 + SEO + AI 友好的同仓库多站点项目

以下设计兼容 Astro/Next/Nuxt 等静态优先框架，示例以“配置驱动 + 分站点构建”为核心。

3.1 目录结构建议

src/
  pages/
    index.astro                 # 主站入口
    site-a/
      index.astro
      sitemap.xml.ts
      robots.txt.ts
      llms.txt.ts
    site-b/
      index.astro
      sitemap.xml.ts
      robots.txt.ts
      llms.txt.ts
  sites/
    shared/
      site-config.ts            # 站点配置中心
      seo.ts                    # SEO 工具
      content/
        common.ts               # 通用内容模型
scripts/
  build-site.mjs                # 单站/多站构建脚本
doc/
  high-performance-multi-site-seo-ai-friendly-guide.md

原则：共享逻辑集中在 shared，站点差异只在站点入口与配置层表达。

3.2 配置驱动：多站点的核心

建立站点配置中心（site-config.ts）：

• siteKey：站点唯一标识
• baseUrl：用于 canonical、sitemap、OG URL
• brandName：标题模板和品牌文案
• indexable：是否允许索引
• defaultLocale：默认语言（可扩展多语言）

这样新增站点通常只需两步：

1. 增加一份站点配置
2. 增加该站点入口页面与 SEO 工件路由

不需要复制一整套工程文件。

3.3 构建体系：按站点拆分产物

build-site.mjs 建议支持：

• --site=main：仅构建主站
• --site=site-a：仅构建 A 站
• --site=all：全量构建

构建输出建议：

• dist-main/
• dist-site-a/
• dist-site-b/

优势：

• 发布时域名与产物目录一一对应，降低误发风险。
• 回滚可按站点回滚，互不影响。
• CI 可按变更路径决定是否跳过某站构建。

3.4 SEO 友好：从“能收录”到“稳定拿流量”

每站点必备

• 唯一 canonical（禁止跨站点错指）。
• 独立 sitemap.xml，主站提供 sitemap-index.xml 聚合。
• 独立 robots.txt，策略与业务目标一致。
• 结构化数据（Organization、WebSite、BreadcrumbList）。
• 标题与描述模板化，允许站点和页面级覆写。

工程化校验（建议放入 CI）

• 检查 canonical 是否使用本站 baseUrl。
• 检查 sitemap URL 是否全为 200 且不含测试域名。
• 检查 noindex 页面是否未进入 sitemap。
• 检查重复 title/description 比例（超阈值报警）。

3.5 AI 爬虫友好：对模型“可访问 + 可理解 + 可引用”

1）llms.txt 标准化

每站点提供 llms.txt，至少包含：

• 站点定位与受众
• 核心内容入口（文档、FAQ、术语页）
• 推荐引用方式（如优先链接规范页）
• 更新频率与最后更新时间

2）语义化内容结构

• 规范标题层级（h1-h2-h3）。
• 给关键页面增加摘要段与要点列表。
• 避免只用图片传达核心信息（机器可读性差）。

3）抓取策略一致

• robots.txt 中明确允许/禁止路径。
• 敏感路径（后台、私有 API、临时目录）明确 Disallow。
• 避免同一内容在多 URL 可访问（加重去重压力）。

4）机器可读入口

• 为“知识型内容”提供索引页。
• URL 语义化且稳定，减少频繁改路径。
• 发布后自动触发搜索引擎/站长平台更新通知。

3.6 高性能落地：四个关键动作

动作 A：静态优先 + 边缘分发

• 默认 SSG，只有必要页面启用动态能力。
• 静态资源上 CDN，启用长缓存 + 指纹文件名。

动作 B：资源体积治理

• 图片格式优先 WebP/AVIF。
• CSS 拆分关键与非关键路径，减少阻塞渲染。
• JS 默认最小化，按需 hydration。

动作 C：缓存与复用

• 依赖缓存（node_modules/包管理缓存）。
• 构建缓存（按 lockfile + 源码哈希）。
• 站点级缓存键，避免缓存串站。

动作 D：性能预算门禁

在 CI 设置硬性阈值（示例）：

• LCP < 2.5s
• INP < 200ms
• CLS < 0.1
• 首屏 JS gzip < 150KB

超过阈值直接阻断合并，防止性能回退“悄悄上线”。

四、部署与运维：让多站点发布不再脆弱

4.1 推荐发布流程

代码合并
  ↓
受影响分析（哪些站点改了）
  ↓
仅构建受影响站点
  ↓
SEO/AI 工件校验（sitemap/robots/llms/canonical）
  ↓
性能预算校验（Lighthouse/Web Vitals）
  ↓
分站点部署
  ↓
发布后监控与回归检查

4.2 发布后检查清单（最小集）

• 首页、核心落地页返回 200。
• canonical、OG URL、sitemap 域名正确。
• robots.txt、llms.txt 可访问且内容正确。
• 核心页面首屏性能达标。
• 埋点与日志无异常增长（404、5xx、超时）。

五、踩坑与避坑指南

5.1 canonical 指错域名

问题：site-b 的 canonical 指向主站，导致收录错误聚合。   建议：canonical 只能由站点配置自动生成，禁止手写硬编码。

5.2 sitemap 只做了主站

问题：子站页面长期不收录。   建议：每站点独立 sitemap，主站维护 sitemap 索引聚合。

5.3 robots.txt 与 llms.txt 冲突

问题：一个说可抓，一个说不可抓，策略不一致。   建议：同源配置生成两份文件，构建阶段做一致性校验。

5.4 共享模块改动引发全站性能回退

问题：改一个公共组件，三站 LCP 全部恶化。   建议：共享层必须启用性能预算和对比基线。

5.5 产物目录混发

问题：dist-site-a 发布到了 site-b 域名。   建议：在 CI 中增加“域名-目录映射”硬校验，不通过不发布。

六、可直接复用的实施清单（建议收藏）

6.1 架构清单

•  站点配置中心统一管理域名与品牌信息
•  页面入口按站点拆分，避免逻辑耦合
•  共享模块职责清晰（SEO、内容、组件、样式）

6.2 SEO 清单

•  canonical 全站无错链
•  每站点具备 sitemap 与 robots
•  结构化数据覆盖核心页面
•  重复标题/描述有监控

6.3 AI 清单

•  每站点提供 llms.txt
•  文档入口与 FAQ 对机器可读
•  抓取策略与 SEO 策略一致

6.4 性能清单

•  静态优先，动态按需
•  图片现代格式 + 响应式策略
•  JS 体积预算门禁
•  发布后 Web Vitals 持续监控

七、小结

同仓库多站点项目的真正价值，不在“省几个仓库”，而在于：

• 用配置驱动站点差异，降低维护成本；
• 用共享能力保障一致性，避免重复劳动；
• 用构建与 CI 把 SEO/AI 友好变成可执行标准；
• 用性能预算守住用户体验和搜索表现。

当 sitemap、robots、canonical、llms、性能预算都进入自动化流水线，这个多站点体系才算真正“可规模化增长”。