如何查找网站上的所有页面（包括已删除的页面）

我们的网站有多少个页面？这个问题听起来似乎背后有个数据库。其实很少有。去年一位客户坚称他们的网站大约有 400 个页面。站点地图显示 1,900 个。爬虫找到 3,400 个。Wayback Machine 的索引列出了该网站曾经提供过的 11,000 个 URL，其中一半早已被删除。四个来源，四个答案, 但四个答案各自描述了不同的情况，都是正确的。

以下是我用来查找网站上所有页面的四种方法，每种方法实际涵盖的内容，以及如何将它们合并成一份可操作的干净清单。

为什么查找网站上的所有页面很难

除非 CMS 恰好保留了一份主清单，否则就没有主清单, 而且即便有，它也只知道自己。真实的网站会积累超出任何单一清单范围的页面：没有任何菜单链接的孤立页面、过去迁移留下的旧版块、某次邮件营销中引用过的上传文件、即时生成的分面 URL，以及 2016 年有人搭建然后就被遗忘的整个子域。

每种发现方法看到的只是这片混乱中的不同片段。站点地图是 CMS 的自报。爬虫描绘的是链接图谱。Wayback Machine 的 CDX 索引保留了历史记录。Search Console 报告的是 Google 实际向用户提供的内容。单独看任何一种都不完整；合在一起则接近完整。

在构建清单之前，先想清楚这份清单的用途。迁移清单、SEO 审计和已下线网站的恢复工作需要相同的原始材料，但清理方式不同。

站点地图：查找网站上所有页面的最快方法

从 /sitemap.xml 开始。如果返回 404，请检查 robots.txt 中是否有 Sitemap: 指令, 很多网站把这个文件放在一个奇怪的路径下。WordPress 核心自 5.5 版本起就提供 /wp-sitemap.xml；Yoast 和 Rank Math 生成的是 /sitemap_index.xml，后者按文章类型展开为多个子级站点地图。抓取索引文件，然后抓取每个子级文件。

该协议规定每个站点地图文件最多包含 50,000 个 URL，解压后不超过 50 MB，因此大型网站总是使用索引文件, 不要在找到的第一个文件后就停下来。

接下来是注意事项，因为站点地图会通过省略来"说谎"。站点地图只列出 CMS 知道的内容：没有孤立的媒体上传、没有多年前删除的页面、没有运行在 CMS 之外的遗留版块，也没有 /old-tools/ 下自定义脚本生成的内容。而在手工编写或过时的站点地图中，即便是已知清单也是虚构的。用你最近更新的页面去抽查 lastmod 日期；如果对不上，就什么都不要相信。

像 Googlebot 一样爬取网站

爬虫从首页开始，沿着它能看到的所有链接前进，这和搜索引擎的工作方式相同。Screaming Frog 是业界默认工具，500 个 URL 以内免费；Sitebulb 更适合审计用途；如果想要完全的控制力，一段用 requests 和 BeautifulSoup 写的小型 Python 脚本, 或者 wget 的爬虫模式, 也无需任何费用。

爬虫能发现站点地图遗漏的内容：无人添加到站点地图的分页存档、标签和分类页面、指向仍然存在但已损坏页面的链接、以及消耗爬取预算的重定向链。

它的盲区恰好是站点地图盲区的镜像。如果没有链接指向某个页面，爬虫就永远找不到它。JavaScript 渲染的菜单需要无头浏览器，否则爬取就会停在首页。分面导航（筛选器、日历、排序方式）可以把一个 500 个页面的店铺膨胀成 50 万个 URL 的爬取陷阱；在开始之前就要设置好排除规则，而不是之后。对于不属于你的网站，请保持较低的并发，并遵守 robots.txt。

Wayback CDX API：查找网站过去与现在的所有页面

这是几乎没人使用、但能发现最多内容的方法。Internet Archive 的 CDX 服务器会列出它为某个主机捕获过的每一个 URL, 包括十年前已删除的页面，这是任何在线方法都无法看到的。

一条 curl 命令即可获得完整清单：

curl "https://web.archive.org/cdx/search/cdx?url=example.com/*&output=text&fl=timestamp,original,statuscode&filter=statuscode:200&collapse=urlkey&from=2010&to=2020"

重要的参数：collapse=urlkey 对同一 URL 的重复抓取进行去重；filter=statuscode:200 过滤掉 404 和重定向；matchType=domain 将范围扩大到子域；from 和 to 用于限定年份。对于已下线的网站，这段时间窗口正是宝藏所在。

数量会很大。一个运营时间很长的论坛或店铺可能返回数百万行，而查询字符串的噪声（会话 ID、跟踪参数）会让清单进一步膨胀。API 是免费的，但有速率限制，因此面对大型域名要保持耐心，并把大规模抓取按年份分批进行。

如果你想要答案却不想动手写查询，Restorix 在免费估算中就使用了这个索引, 粘贴一个域名，它会在几秒内报告准确的归档文件数量和总体积，无需任何查询。

Google Search Console：查找你的网站向 Google 展示的所有页面

对于你拥有的网站，Search Console 提供了一份独有的数据集：Google 实际收录并提供过的内容。验证所有权后，重点关注两份报告。

• 效果报告的"网页"标签页：列出每一个获得过展示的 URL，可以导出。Web 界面每次导出最多 1,000 行；Search Analytics API 则可翻页到远超这个数字的量级，而批量导出到 BigQuery 则每天提供完整数据集。
• "网页索引编制"中的"网页"报告：分为已编入索引和已抓取但目前未编入索引，并附带示例 URL, 可以快速了解 Google 究竟愿意保留网站的多少内容。

它的独特价值在于展示数据：真实用户访问过的页面，包括没有任何链接的孤立页面。如果一个被遗忘的着陆页每月仍能带来三十次点击，它就应当被列入"保留"清单。如果必应流量对你重要，Bing 网站管理员工具也提供同样的报告。

合并、去重并清理清单

四个来源，四种格式, 合并的环节正是价值所在。把所有内容倒入一个 CSV，然后在去重之前先做规范化处理，否则同一个页面会以六种不同面貌出现六次。

这些"伪装"并非假设。同一张真实的产品页可能以以下形式出现：https://www.example.com/page/?utm_source=newsletter、http://example.com/page、example.com/page/#comments、example.com/page?fbclid=abc123、www.example.com/page/index.html，以及 EXAMPLE.com/page, 六行记录，同一个文档。大小写、协议、www、参数、片段和默认文件名都必须先归并为单一的标准形式，之后的去重操作才有意义。跳过这一步，你那 11,000 条 URL 的清单实际上只是 6,000 个换了"装扮"的 URL。

• 将主机名小写；完全去除片段（#section）。
• 删除跟踪参数：utm_*、fbclid、gclid、ref。对保留的查询参数进行排序。
• 选择一种末尾斜杠约定并强制执行。
• 将协议和 www 变体归并为你的标准形式。

去重后，对每个 URL 进行分类：当前返回 200、正在重定向、当前 404 但已被归档，或已完全消失。第三类（已删除但存在于 CDX 数据中）正是迁移工作中最容易遗忘、事后又最令人后悔的部分。对于大多数网站，一个二十行的 Python 脚本就能处理所有这些工作；电子表格可以应付几千个 URL。

四种来源的快速对比：

你已经找到了所有页面, 接下来呢

对于迁移工作，这份清单就是你的重定向地图：每一个在 Search Console 中有展示、或在 CDX 数据中有抓取记录的 URL，都会被 301 重定向到最接近的现代等价页面。对于 SEO 审计，爬取和索引列能够暴露薄弱版块和爬取陷阱。两者都是几个下午认真工作就能完成的事。

如果这份清单是为了恢复一个已下线的网站，那就跳过手动重建吧。我们的恢复服务 可以从 Wayback Machine 恢复整个网站：免费估算会显示准确的文件数量、总体积和固定价格，你按恢复的文件数计费，第一个文件免费，清理选项可以去除旧的统计代码、将链接转为相对路径、并压缩资源文件。最终结果可一键部署到你的主机，或导出为 XML、CSV 或 JSON（附带完整文件清单），如果你想要原始资料的话。无论哪种方式，你刚才所做的清点工作已经准确地告诉你一次高质量的恢复应该包含哪些内容。