Last updated: 2026-06-30

Last verified: 2026-06-30 against the current OnlyPat repository structure, local deployment registry, build scripts, sitemap routes, and public-site validation rules. This is a project case study, not official Cloudflare documentation. Cloudflare Pages limits, pricing, dashboard wording, Google AdSense policies, and search rules should still be checked against official sources before making current platform claims.

OnlyPat 建站指南 is an independent guide-site project. This article describes a real local portfolio split and does not imply affiliation with Cloudflare, Google, Aliyun, DNSPod, or other service providers.

先说结论

我一开始想做的只是一个 Cloudflare 建站指南站。

但做着做着，内容开始变多：一边有建站、域名、AdSense、内容规划这些文章；一边又想做浏览器里能直接用的小工具；后来还把伊莫攻略工作台迁进来。继续把所有东西塞进一个站，短期看省事，长期会越来越乱。

最后我把 OnlyPat 拆成了三个站：

站点 域名 作用
建站指南 guide.onlypat.com 讲 Cloudflare Pages、低成本建站、内容规划、信任页和变现准备
工具站 tool.onlypat.com 放 JSON、时间戳、Base64、Cron、QR Code 等浏览器工具
伊莫攻略工作台 yimoo.onlypat.com 放一个独立的伊莫 / Aniimo 攻略工作台

仓库根目录不再当成网站本身，而是变成 portfolio 控制面：放规则、部署登记、共享脚本、决策记录和验证说明。

这个拆分的价值不是“看起来更专业”，而是让每个站都有清楚的读者、域名、sitemap、robots、AdSense 边界、Cloudflare Pages 项目和验证命令。以后我想改工具站，不会误伤建站指南；想更新伊莫数据，也不会污染建站文章。

适合 / 不适合

判断项 适合拆成多个子站 不适合急着拆站
读者意图 建站读者、工具用户、游戏玩家明显不同 所有页面服务同一类读者
页面形态 长文指南、可操作工具、单页工作台差异很大 都是同一种文章或同一种产品页
部署风险 某个站改坏不应该影响其他站 一个站点结构仍然足够清楚
sitemap 和 canonical 主题和域名身份需要分开 一个 sitemap 能自然解释全部内容

30 分钟开工版

如果你也在犹豫要不要拆站，先不用改 DNS，也不要急着新建 Cloudflare Pages 项目。

  1. 写下每类页面的读者是谁。
  2. 标出每类页面的主要动作：阅读、复制工具输出、查游戏路线，还是别的。
  3. 列出现有 sitemap 里主题最不相关的 5 个 URL。
  4. 判断这些页面是否应该共享同一个 canonical 域名。
  5. 写出如果某一类页面改坏，会不会影响另一类页面。
  6. 只要答案还不清楚，就先不要拆；先用目录、分类或导航解决。

详细判断

OnlyPat 的拆分不是从“想多做几个站”开始，而是从读者意图、页面形态、部署边界、sitemap/canonical、广告信任边界和验证链开始。下面的复盘按这些决策点展开。

为什么不继续做一个大站

单站最大的诱惑是简单。

一个仓库，一个首页，一个域名，一个部署。刚开始当然舒服。但内容一旦变复杂，问题会很快出现。

第一个问题是读者意图混在一起。

来读建站指南的人，关心的是“我怎么从 0 到 1 做一个低成本网站”。来工具站的人，可能只是想马上格式化一段 JSON，或者生成一个 QR Code。来伊莫攻略工作台的人，关心的是游戏里的能力、路线和配置。三类人不是同一种需求。

如果都放在一个导航里，首页会变得很难讲清楚：到底这是教程站、工具箱，还是游戏攻略站？

第二个问题是 SEO 和站点地图会混乱。

建站文章、开发工具、游戏攻略都可以被搜索引擎收录，但它们不应该共享同一种页面结构、同一批结构化数据和同一个内容策略。指南文章需要文章页、面包屑和读者路径；工具页需要 WebApplication 结构化数据和可直接使用的输入输出；游戏工作台需要静态 fallback 和数据边界。

第三个问题是部署风险变大。

如果仓库根目录就是网站，一次误部署可能把根文档、脚本、草稿、迁移记录一起送上去。拆成 sites/guide/、sites/tool/、sites/yimoo-guide/ 后，每个站只从自己的目录或构建产物部署，风险低很多。

第四个问题是广告和信任边界会变模糊。

建站指南可以讲 AdSense readiness、affiliate 披露、隐私政策和内容信任。工具站可以保留广告脚本，但页面上不能暗示用户点击广告。游戏攻略工作台也要保留 ads.txt 和公开边界。它们可以共享一个 portfolio 规则，但不应该混成一个页面逻辑。

拆分前先定三个角色

拆站不是先搬文件，而是先定角色。

我给三个站定了不同任务。

guide.onlypat.com 是信任入口。

它负责解释为什么要这样建站，怎么判断 Cloudflare Pages 是否适合，什么时候不要急着申请 AdSense，怎么准备隐私页、披露页、内容规划和 90 天路线。这个站可以有案例、教程和实战复盘，但核心仍然是“帮人把低成本建站想清楚”。

tool.onlypat.com 是直接使用入口。

用户来到工具站，不一定想读长文。他可能只是想把 JSON 格式化一下，转换时间戳，生成 Base64，解析 JWT，做 Cron 表达式，或者生成 QR Code。所以工具站应该更像开发者工作台：搜索、分类、输入、输出、复制、清空、示例。

yimoo.onlypat.com 是独立内容资产。

它不是建站教程，也不是开发工具，而是伊莫攻略工作台。它需要自己的 sitemap、robots、静态 fallback、数据脚本和验证脚本。继续把它放在建站指南下面，会让两个方向都变得不清楚。

这一步定完后，后面的技术决策就简单了：不是“这些东西怎么塞进一个站”，而是“每个站应该如何独立上线”。

仓库结构怎么拆

现在仓库结构大致是这样：

cloudflare-guide-site/
  docs/
  scripts/
  sites/
    guide/
    tool/
    yimoo-guide/

根目录只做控制面，不做公开网站。

根目录的 docs/ 放 portfolio 规则、项目地图、完成定义、部署登记、域名登记、长期记忆和决策记录。根目录的 scripts/ 放共享构建和部署脚本。这样未来任何一个新会话打开仓库，都能先知道这个项目不是一个单站，而是三个独立站点组成的小 portfolio。

sites/guide/ 放 Astro 建站指南。

它有自己的 src/、public/、文章草稿、实战笔记、布局、sitemap 路由、ads.txt 和 robots.txt。建站类内容放在 docs/drafts/，日常工具工作流放在 docs/notes/，但它们仍然属于 guide 站的内容体系。

sites/tool/ 放 Astro 工具站。

它有自己的工具目录、工具数据源、动态工具页、工具布局、sitemap、ads.txt 和 robots.txt。新增工具时，应该只碰工具站的数据、页面和样式，不应该去改建站文章。

sites/yimoo-guide/ 放 dependency-free 静态工作台。

它不是 Astro 站，而是单 HTML 加资源脚本的静态应用。这样它可以独立部署，也可以用自己的 PowerShell 验证脚本检查数据和页面边界。

部署边界怎么定

我给自己定了一条硬规则：

不要部署仓库根目录。

每个站都有自己的 Cloudflare Pages 项目和部署源：

Site ID 目录 Pages 项目 部署源
guide sites/guide/ onlypat-guide sites/guide/dist/
tool sites/tool/ onlypat-tool sites/tool/dist/
yimoo-guide sites/yimoo-guide/ yimoo-guide 明确打包的静态 public bundle

这条规则解决了一个很实际的问题：根目录里有很多不是公开页面的东西，比如项目规则、部署记录、脚本、handoff、决策日志。如果把根目录当 Pages 项目上传，迟早会出现不该公开的东西被带出去的风险。

拆开以后，每次部署都问三个问题：

  1. 目标站点是谁？
  2. 部署源是不是这个站自己的构建产物？
  3. 部署后有没有检查 /、/ads.txt、/robots.txt、/sitemap.xml？

只要这三个问题能回答清楚，部署就不会变成拍脑袋。

sitemap 和 canonical 不要混

多站点最容易犯的错，是 sitemap 混在一起。

guide.onlypat.com/sitemap.xml 只应该放建站指南和实战笔记的 URL。
tool.onlypat.com/sitemap.xml 只应该放工具站 URL。
yimoo.onlypat.com/sitemap.xml 只应该放伊莫工作台自己的 URL。

canonical 也是一样。

一个指南文章页面的 canonical 应该指向 guide.onlypat.com。一个工具页面的 canonical 应该指向 tool.onlypat.com。不要因为它们在同一个仓库里，就共享同一个站点身份。

这样做有三个好处：

  • 搜索引擎更容易理解每个站的主题；
  • Search Console 里看问题时更清楚；
  • 后续某个站改版，不会误伤其他站的索引结构。

AdSense 要保留，但不要让广告定义网站

这个项目的公共站点默认保留 AdSense 脚本和 ads.txt。

但这不等于每个页面都围绕广告设计，更不等于可以写任何鼓励点击广告的文字。我的规则是：

  • 公共站点保留共享广告脚本；
  • ads.txt 必须在 public bundle 里；
  • 隐私和披露页面要和实际广告设置一致；
  • 不承诺 AdSense 通过、展示、点击率、访问量或收入；
  • 页面文案不暗示用户点击广告支持网站。

这也是为什么我更愿意把广告当作站点的基础设施，而不是产品方向。真正决定一个站能不能长期维护的，不是广告代码有没有放进去，而是它有没有足够明确的读者和内容价值。

验证链怎么做

拆成三个站后，我不想每次都靠记忆。

所以根目录有统一脚本：

pwsh -ExecutionPolicy Bypass -File .\scripts\build-site.ps1 -Site guide
pwsh -ExecutionPolicy Bypass -File .\scripts\build-site.ps1 -Site tool
pwsh -ExecutionPolicy Bypass -File .\scripts\build-site.ps1 -Site yimoo-guide

改 guide，就跑 guide。
改 tool，就跑 tool。
改 yimoo，就跑 yimoo。
改根控制文档，再跑 workspace audit 或 handoff 校验。

这比“每次都全量检查”更实用。小站 portfolio 的维护重点不是把流程搞重，而是让每次改动都能用最短路径证明没有破坏目标站点。

部署后再做线上检查：

  • 首页是否 200；
  • /ads.txt 是否存在；
  • /robots.txt 是否存在；
  • /sitemap.xml 是否存在；
  • 新增页面是否能打开；
  • sitemap 是否包含新增 URL。

这套检查不保证 SEO、流量或收入，但能证明基本发布链路是通的。

这次拆分里最重要的取舍

第一个取舍：根域名暂时不急着做品牌首页。

onlypat.com 可以成为未来品牌根站，但当前更重要的是让三个子站先稳定。根域名如果临时承担 AdSense 验证或过渡用途，就把它写清楚，不要误以为那是永久信息架构。

第二个取舍：工具站不做复杂后端。

工具站第一阶段只做浏览器端工具。只要 JSON、时间戳、Base64、Hash、QR Code 这些能在浏览器本地完成，就不要急着加账号、数据库、后端 API。工具站的价值是快、轻、可用。

第三个取舍：伊莫站保持独立。

伊莫攻略工作台有自己的读者和数据结构，不应该因为同在 onlypat.com 下就强行套建站指南的文章系统。它只需要在 portfolio 层面接受统一部署和广告规则。

第四个取舍：控制面要比记忆可靠。

如果只靠聊天记录记住“不要部署根目录”“每个站独立 sitemap”“AdSense 要保留”，下一次维护很容易忘。写进 AGENTS.md、docs/project-map.md、docs/done-definition.md 和部署登记，后续每次打开项目都能恢复上下文。

常见误区

误区 为什么会出问题
子域名越多越专业 没有清楚角色的子站只会增加维护成本
同仓库就可以共用 sitemap sitemap 和 canonical 跟公开站点身份有关，不跟仓库结构绑定
拆站后就不用统一规则 多站更需要统一部署、广告、robots、验证和决策记录
根目录可以顺手部署 根目录包含控制文档和脚本，不应该当 public bundle

OnlyPat 实操备注

当前仓库的硬边界是：根目录只做 portfolio 控制面，sites/guide/、sites/tool/、sites/yimoo-guide/ 分别构建和部署。每次改动都必须选择目标站点，跑对应验证，再用中文提交并推送。

什么时候你也应该拆站

不是每个小项目都应该拆。

如果你只有一个主题、一个读者、一种页面类型，继续做一个站就够了。拆站会增加域名、sitemap、部署、导航和维护成本。

但如果出现下面几种情况，就应该认真考虑拆分：

信号 说明
读者明显不同 教程读者、工具用户、游戏玩家不是同一类访问者
页面形态不同 文章、工具、单页工作台需要不同结构
部署节奏不同 工具频繁迭代，指南低频更新，游戏数据单独校验
SEO 主题不同 一个 sitemap 里混太多主题，会削弱站点身份
风险边界不同 某个站改坏时，不应该影响其他站
变现和披露不同 广告、affiliate、工具隐私、游戏资料来源需要不同说明

判断标准不是“我有几个页面”，而是“这些页面是不是应该共享同一个站点身份”。

如果从头再做，我会按这个顺序

  1. 先写清楚每个站点的角色，不先搬代码。
  2. 给每个站定 canonical 域名和 Pages 项目名。
  3. 把根目录定位为控制面，而不是 public 目录。
  4. 为每个站准备独立 ads.txt、robots.txt 和 sitemap。
  5. 先保证一个站能独立构建，再迁第二个站。
  6. 写统一的 build-site.ps1，不要靠手记命令。
  7. 把部署源写进 deployment registry。
  8. 上线后检查 /、/ads.txt、/robots.txt、/sitemap.xml。
  9. 再考虑 Search Console、AdSense、内容扩展和工具批量新增。

这个顺序比较慢，但它能减少返工。

给读者的简化版方案

如果你也有一个内容站，后来想加工具、案例、资料库或小游戏，不要第一反应就拆成很多站。

先问自己四个问题：

  1. 这些内容是不是服务同一类读者？
  2. 它们是不是需要同一种页面结构？
  3. 它们是不是应该共享一个 sitemap 和 canonical 域名？
  4. 其中一个部分改坏，会不会影响其他部分？

如果答案大多是“是同一类”，继续放在一个站里，用分类、标签、导航解决。

如果答案开始变成“不是同一类”，就可以像 OnlyPat 这样拆：

根目录：portfolio 控制面
sites/guide：文章和案例
sites/tool：可直接使用的工具
sites/special-project：独立主题或工作台

拆站不是为了显得复杂，而是为了让每个站更简单。

官方来源

  • Cloudflare Pages docs: https://developers.cloudflare.com/pages/
  • Google Search Central AI optimization: https://developers.google.com/search/docs/fundamentals/ai-optimization-guide
  • Google Search spam policies: https://developers.google.com/search/docs/essentials/spam-policies

下一步

OnlyPat 现在的重点不是继续拆更多站，而是让三个已存在的站各自变得更有用。

建站指南继续沉淀真实案例和低成本建站路径。
工具站继续增加能马上使用的浏览器工具。
伊莫攻略工作台继续保持数据和玩法边界清楚。

只要每个站都能回答“谁会来、来做什么、我怎么验证它还正常”，这个 portfolio 就不会变成混乱的网站农场。