三个问题，分别回答
域名回答“地址叫什么”，托管回答“内容放在哪里”，访问控制回答“谁能打开”。把这三件事混在一起，很容易以为绑定了自定义域名，就已经完成了迁移。
实际检查时，应分别查看域名记录、部署所在账户和访问规则。地址没有变化，不代表背后的归属也没有变化。
小网站可以保持简单
对于以文字、链接为主的个人站点，静态文件是一种直观的选择。Cloudflare Workers 支持托管 HTML、CSS 和其他静态资源，也可以绑定自定义域名。
简单并不意味着没有设计和交互。搜索、主题切换和阅读目录可以在浏览器里完成；真正需要跨设备同步、多人协作或在线发布时，再引入后台。
保护正式地址，也检查备用入口
Cloudflare Access 的 Worker 级规则可以覆盖对应 Worker 的正式地址、预览地址和自定义域名。只保护一个好记的域名，却留下另一个没有保护的入口，不是完整的私人访问方案。
发布后应做一次未登录检查。需要私密的页面和资源应要求验证，而不是匿名返回内容。搜索引擎的 noindex 设置只是索引提示，不能代替登录保护。
让下一次迁移更容易
保留源文件、部署包和简短的配置说明，记录哪些域名属于哪个服务。清理失效的旧解析时，只处理已经核实的目标。
网站最终应该是可以维护、可以解释、也可以带走的东西。
先为迁移确定一个可验收目标
本篇任务是把个人博客放到自己能维护的托管位置，并用自己的域名访问。准备域名管理入口、源文件和附件、可生成的静态产物，以及旧站点的代表性链接。不要一开始就切 DNS；先明确哪些内容必须保持可访问，哪些私人入口应继续受保护。示例域名为 example.com，文中迁移步骤与结果是演练方案，未创建站点或实际部署。
把“迁移完成”拆成归属、内容、地址和权限四个条件。能看到熟悉页面只证明某个入口可读，不能证明部署项目属于自己的账户；域名归自己也不代表托管源码可以导出。先填写资产表，记录谁管理注册、解析、构建和托管，以及下一次如何恢复源文件。这里不记录密码或密钥本体，账户提示只保留在受控私有清单中，公开版本使用角色名称。
# 个人博客迁移包
正文源文件：content/
附件：assets/
构建说明：<真实命令及工具版本>
源版本：<待填>
产物目录：<待填>
托管项目：<个人项目占位>
正式入口：https://example.com/
预览入口：<自己的受控入口>
域名归属：<已核对/待核对>
DNS及绑定要求：<平台给出的实际要求>
私人内容排除清单：<待核对>
上一份可恢复产物：<明确标识>可复制工作表，示意且未实机验证；填写自己的材料，待测项不代表实际成功。
选托管方式时围绕当前内容选择
以正文和图片为主的博客可以生成静态文件，搜索、主题与目录等交互由浏览器完成。若要跨设备同步草稿、多人协作或在线发布，就需要明确服务端存储与身份流程，不能把浏览器本地保存当成云端功能。选择之前先拿一篇包含图片、中文路径和内部链接的样本确认输出结果，而不是单看平台首页展示。
Cloudflare Workers 静态资源文档说明其托管能力，具体目录、路由与部署配置要按选用工具核对。已有工程应使用现有构建与发布方式，避免另开第二条无人维护的发布链。准备一个独立的待验收产物，查看其中是否只有允许公开的文件，尤其没有草稿、环境文件或私人导航。静态托管不自动筛掉这些内容，构建范围本身就是公开边界的一部分。
在切换地址前完成内容预检
先通过受控预览入口检查首页、文章页、图片和非存在路径，再直接输入深链接刷新。如果站点使用前端路由，需要确认托管层如何处理刷新；客户端点击成功不能代替这项验收。比较旧站代表性链接，记录是保持路径还是需要重定向。尽量先完成内容和路由修正再切换正式域名，减少对公开读者反复暴露半成品的机会。
同时检查源文件和产物是否能关联到一个明确版本。没有版本标识时，至少保存实际构建记录与产物清单，不能用“最新文件夹”作为唯一依据。浏览器缓存可能让两个入口看起来一致，因此应选一项本轮新增的公开内容作为辨识点。本文没有生成真实部署包，模板中的版本、时间与验收结论都应由读者实际执行后填写，不能复制示意结果充当迁移证据。
| 旧路径 | 新路径 | 处理 | 验收 |
| --- | --- | --- | --- |
| / | / | 保留首页 | 待测 |
| /articles/hello | /articles/hello | 保留文章 | 待测 |
| /assets/example.png | /assets/example.png | 保留附件 | 待测 |
| /feed.xml | /feed.xml | 更新公开订阅 | 待测 |
| <私人入口> | <保护目标> | 继续身份验证 | 待测 |
实际旧绑定：<待填>
实际新绑定：<待填>
观察窗口：<待填>
恢复动作与恢复后检查：<待填>可复制工作表，示意且未实机验证；填写自己的材料，待测项不代表实际成功。
完整案例：保留文章地址的托管迁移
假设旧博客有 /articles/hello，准备换托管位置但继续使用 example.com。先让新托管在预览入口提供同一路径与附件，再检查页面内链接是否指回旧平台域名。发现绝对链接仍旧时，修正公开链接生成规则并重新验收；否则切换首页之后读者仍可能被送回旧站，造成一半内容来自新位置、一半来自旧位置的混合状态。
新内容验收通过后，记录旧绑定与记录值，再按平台流程绑定正式域名并检查证书。一次只切换已确认的博客入口，不顺带处理邮箱、私人网络或未知子域名。正式地址返回新内容后，再从文章链接、图片与 RSS 检查实际路径。若任何关键页面失败，可以依据记录恢复旧绑定或旧产物，但缓存可能延缓恢复效果，因此应保留旧站可用到观察窗口结束，而不是切换后立刻删除。
权限和备用入口一起交付
如果只有文章需要公开，私人写作入口应在构建或服务端边界保持独立。检查正式域名、平台默认地址和预览入口是否分别符合预期，不能只保护一个好记的地址。匿名会话打不开写作台，还要继续核对它依赖的草稿接口和附件；正文公开、管理私密是两个同时成立的验收条件。搜索引擎索引设置不会阻止匿名取得内容。
当页面出现登录循环，先查看跳转链及规则匹配，而不是全局关闭保护。证书错误先查绑定名称与证书状态，不使用跳过验证作为完成判据。macOS、GNU/Linux 与 DSM 作为浏览客户端都可按同样矩阵验收；若在其中某平台构建，则额外记录实际工具链和文件路径大小写。不要把静态博客迁移扩展成修改 NAS 系统服务，这不属于本次地址与内容迁移所需步骤。
curl -sS -D - -o /dev/null --connect-timeout 5 --max-time 15 'https://example.com/'
curl -sS -D - -o /dev/null --connect-timeout 5 --max-time 15 'https://example.com/articles/hello'占位示例不能证明你的站点迁移；核对首跳后用浏览器检查正文、附件与深链接。未实机验证。
移交维护材料并延后清理旧资源
交付包应包含正文源文件、附件目录、构建说明、公开路径清单、实际托管目标和恢复步骤。检查源文件在普通编辑器可读、附件可独立打开，才能知道下次迁移不依赖当前平台按钮。构建所需版本写在说明中，缺少的依赖或尚未验证的平台明确列出；一个部署包能在线展示，不代表以后还能从源码重建。
旧记录清理要以用途核实为前提。先观察正式入口与私人边界稳定，再确认没有其他个人服务依赖旧项目，最后按既定保留策略归档或停用。中断、覆盖、删除属于 danger，不能因为迁移大体成功就批量清理陌生记录。完成后的笔记应能回答：新内容在哪里、谁维护、正式地址指向哪里、出错时恢复哪份版本。日期只记录实际核对与修订，不制造长期运营或迁移成功的亲历描述。
填写工作表，把示例变成自己的记录
文中的交付模板先留一个“正式入口”和一个“预览入口”位置，确保它们不会在笔记中混用。源版本填写实际标识，绑定目标填写个人项目名称的私有记录或公开占位，附件目录列可迁移位置。读取检查示例只请求 example.com，实际检查应替换自己的已授权主机和代表性文章。不能因为示例地址返回正常页面，就在个人迁移验收里打勾。
路径对照表尤其适合已有旧文章的站点：一行记录旧路径、新路径以及保留或跳转的决定。新路径相同并不意味着附件也相同，因此另列一项图片检查。恢复记录应指向具体旧部署与旧绑定，而不是“出错再想办法”。观察期间若新内容有修订，重新更新产物版本并复测，避免验收记录指向上一个包。最后将账户归属核实与页面可用分开签记，读者能看到哪些是托管维护问题，哪些是前端内容问题。