从 Wayback Machine 下载整站

从 Wayback Machine 保存一个页面只需两分钟。保存整站则完全是另一回事, 如果毫无准备就动手，很可能搭上一整个周末。存档并不会把你的网站打包成一个整洁的文件，而是保存了成千上万次独立的抓取记录，每次都定格在各自的爬取时间。要把它们拼回一个连贯的网站，大多数人都会卡在这一步。本指南梳理了那些真正会导致整站下载失败的陷阱，以及自动化何时不再是可选项。

为什么从 Wayback Machine 下载整站比下载单页难得多

一个页面就是一次抓取。一个网站则是爬虫曾经发现的每个 URL，各自按不同的时间表归档。你的首页可能有 9,000 次抓取记录，而退换货页面可能只有三次，最新一次还是 2017 年的。从 Wayback Machine 下载整站，等于在用从未设计成能拼在一起的碎片拼一幅马赛克。

资源文件让情况更糟。Logo 是一次抓取，样式表是另一次，可能还来自不同年份。存档在提供这些文件时会重写 URL，且只在 web.archive.org 内部才能解析，所以简单复制下来的网站在本地打开时立刻就会出问题。一个页面还能容忍这些毛病，五百个页面就会把问题放大无数倍。

下载之前先摸清网站全貌

别一上来就用 wget。先用 CDX API 把存档实际拥有的完整清单拉出来：

web.archive.org/cdx/search/cdx?url=example.com/*&matchType=prefix&output=json&collapse=urlkey&filter=statuscode:200

这一个请求就能告诉你有多少个唯一 URL、爬虫覆盖了哪些板块、缺口在哪里。最近处理一个 2009 年的 phpBB 论坛时，清单显示有 22,000 个唯一 URL，其中大概只有 1,400 个是真正的内容，其余全是会话 ID、打印视图重复页和从没人看过的日历页面。

像承包商一样审读清单

• 按目录统计 URL。一个庞大的 /images 目录说明资源还在；一个稀疏的目录意味着后面要吃苦头。
• 检查各板块的日期跨度。如果博客在 2016 年就断了，但首页一直更新到 2023 年，说明博客是被取消链接或被屏蔽了，而不是被删除了。
• 尽早识别垃圾模式：会话参数、回复表单、排序参数。它们会虚增数量和下载时间。
• 留意 MIME 类型。大量 text/html 却没有图片条目，说明存档只留了骨架、丢了皮肤。

如果你不想自己写请求就能拿到清单，Restorix 的免费估算功能会在你花一分钱之前就显示某个域名下已归档文件的精确数量和总大小。这个数字会改变你的计划。三百个文件是一个下午的手工活，三万个就不是了。

导致整站下载失败的陷阱

以下每一条都至少坑过我一次。在你下载了三个小时、输出结果完全看不懂之前，没有一条是显而易见的。

• robots.txt 的历史。多年来，存档一直拒绝抓取或提供被 robots.txt 屏蔽的页面。如果前任站长配置有误，整个目录在存档中根本不存在，任何工具都无能为力。
• 主机名分散。www.example.com、example.com、blog.example.com 和旧 CDN 主机是不同的抓取集合。对其中一个主机做前缀查询会静默地漏掉其余的，爬虫脚本也一样。
• http 与 https。同一页面在两种协议下各被归档一次，有时资源还不同。选覆盖更全的那个版本，而不是你记忆中的那个。
• JavaScript 渲染页面。爬虫只存了它在抓取时能执行的内容。一个 2019 年的 React 站可能回来时只剩一堆空 div 的壳，实际内容全没了。
• 时间戳漂移。把 2014、2017 和 2021 年抓取的文件拼成一个网站，会导致布局错乱和导航不匹配。所有内容都应锚定到一个目标日期。
• Wayback 的外壳。正常提供的快照包含存档工具栏和重写后的链接。在时间戳后加 id_ 后缀来获取原始内容，否则就得从每个保存的文件中手动剥离这些外壳。

查询字符串、分页及其他 URL 陷阱

查询字符串是整站下载悄悄失败的地方。对存档来说，/shop?cat=shoes 和 /shop?cat=hats 是不同的 URL，各有不同的抓取记录。?page=2 和?page=200 也是如此。我处理过的一个客户的 WooCommerce 商店有 4,000 个归档 URL，但实际只有 90 个产品，其余全是筛选组合、排序参数和跟踪参数。

策略很机械：拉取 CDX 列表，按问号前的路径分组，然后判断哪些参数承载内容。产品 ID 和分页：保留。会话 ID、UTM 标签和筛选排列：丢弃。一个方向搞错会丢失真实页面，另一个方向搞错则会下载十倍的垃圾并为此付出时间代价。

当你的整站下载回来满是缺口时

缺失资源是常态，不是例外。预期会出现以下缺口：

• 爬虫从未触发的懒加载和 JavaScript 注入的图片
• 在样式表内部引用的 CSS 背景图和 Web 字体
• 视频和音频文件，存档对它们的捕获充其量是不稳定的
• 通过需要实时 API 密钥的第三方工具包加载的字体和图标
• 任何来自第三方域名、广告网络或登录后才能访问的内容

对于每个缺口，你的选择有限：尝试相邻的时间戳，尝试 www 和非 www 或 http 和 https 变体，或者接受损失并重新生成资源。这正是文件清单发挥作用的地方。Restorix 在每次恢复时都会附带 JSON 或 SQLite 文件清单，所以排查哪些文件缺失变成了一次筛选查询，而不是花一下午逐页点击。

何时停止写脚本，转向自动化

算笔实在账。为一个杂乱网站写一个靠谱的下载脚本需要一个周末来构建和调试，外加 archive.org 在第 8,000 个文件处限速后的大量重跑时间。然后第二个项目才刚开始：剥离 Wayback 重写、修复内部链接、选择规范主机名、部署和测试。

当网站需要重新上线运行而不仅仅存在于你的硬盘上时，自动化就有了意义。Restorix 在一个任务中完成下载、清理和部署：按恢复文件数付费，首个文件免费，价格在估算时锁定，任何失败都会自动退款到你的余额。对于小型网站、研究用途和真正享受解谜乐趣的人来说，手工方案仍然合理。两种路线我都走过无数次，盈亏平衡点来得比人们预想的快，通常在第二次重跑左右。

从下载的文件到可运行的网站

1. 剥离 Wayback 工具栏，将每个 archive.org URL 改回相对路径。
2. 选定一个规范主机名，www 或非 www，另一个做重定向。
3. 在任何现代环境部署之前，将内部链接转换为 HTTPS。
4. 移除失效的第三方脚本：旧版分析代码、广告标签和社交挂件。
5. 部署后，打开浏览器网络面板逐一点击前 50 个页面，捕获仍返回 404 的内容。

这个阶段总有两样东西会出问题：联系表单和搜索。两者都依赖存档从未捕获的服务端代码。用托管表单服务或纯 mailto 链接替换表单，用静态索引或搜索引擎限定搜索框替换站内搜索。

Restorix 将以上所有内容整合到恢复选项中：相对内部链接、HTTPS 转换、分析代码剥离、一键部署到 SSH、FTP 或 S3，以及一个内置的轻量 CMS 让恢复后的网站保持可编辑。手动做或交给服务来做都行，清单是一样的，只是花费的时间不同。