> For the complete documentation index, see [llms.txt](https://gitbook.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gitbook.com/docs/documentation/zh/analytics/broken-links.md).

# 失效链接

查找你已发布网站上返回 404 的 URL，并使用建议的重定向加以修复

{% hint style="info" %}
失效链接处于测试版，并可在 Ultimate 站点方案中使用。
{% endhint %}

失效链接会找出访客正在访问但已不存在的你已发布站点上的 URL。对于每个失效 URL，GitBook 会判断访客最可能想查看的是哪一页，并建议一个你可以一键启用的重定向，这样访客就不会再落到 404 页面。

在你网站的侧边栏中，前往 **改进 → 失效链接**.

## 工作原理

GitBook 会定期审计每个包含失效链接功能的方案中的已发布站点。每次审计都会执行以下步骤：

1. 查看你站点过去 30 天的流量，并收集返回 404 的 URL。一个 URL 至少需要被访问三次才会被纳入考虑，而来自机器人和扫描器的噪声，例如对 `/wp-admin` 或 `.php` 文件的请求，会被忽略。
2. 合并相似的 URL，删除已被现有重定向覆盖的 URL，或因该路径下现在已有页面而再次解析成功的 URL，并按访问量对其余项排序。访问量最高的 60 个失效 URL 会继续处理。
3. 读取你已发布的内容，找出每位访客最可能在寻找的页面。如果整个版块已经迁移，GitBook 会将这些失效 URL 归到一个通配符建议下，例如 `/v1/*`。如果没有页面匹配，GitBook 会明确说明，并在 30 天后再次检查该 URL。
4. 为每个有明确匹配的失效 URL 创建一个建议重定向，并附上简短说明，解释为何选择该页面，以及基于该 URL 所接收流量给出的严重程度。

一个站点最多每天审计一次。每次审计都会从你当前的流量重新开始，已解决的 URL 会被移除，因此如果一个站点有超过 60 个失效 URL，它们会在多次审计中逐步处理，先处理访问量最高的。GitBook 无法匹配到任何页面的失效 URL 也会保留为发现项，并附上原因和它考虑过的页面，这样你就可以判断它们是否需要新页面，而不是重定向。

失效链接建立在 [站点重定向](/docs/documentation/zh/publish/site-redirects.md)之上。如果你不熟悉重定向，请先阅读它。

## 两种视图

失效链接有两种视图，你可以通过页眉中的选项卡在它们之间切换：

* **发现项** 列出 GitBook 找到的失效 URL 以及它建议的重定向，供你审核。
* **分析** 显示来自你站点分析的完整失效 URL 报告，包括尚未有建议的 URL。

## 审核发现项

该 **发现项** 视图会先显示过去 30 天的摘要：

| 卡片         | 显示内容             |
| ---------- | ---------------- |
| **失效访问次数** | 你站点返回的 404 响应数量。 |
| **受影响访客**  | 访问到 404 的唯一访客数量。 |
| **建议重定向**  | 等待审核的未处理建议数量。    |

列表会显示每个发现项的状态、严重程度，以及描述失效 URL 的标题；如果 GitBook 找到了对应页面，也会显示它应跳转到的页面。带有建议修复方案的发现项会排在前面。

### 严重程度

严重程度反映了某个失效 URL 相对于你站点上其他失效 URL 所接收的流量。

严重程度分为三个级别：

* **高**：过去 30 天内至少有 20 次访问，并且是你站点上访问量前五的失效 URL 之一。
* **中**：流量较稳定的 URL。
* **低**：在过去 30 天内只被访问了少数几次的 URL。

### 搜索、筛选和排序

在搜索框中输入一个 URL，或其中的一部分，即可查找特定发现项。使用筛选栏可按以下条件缩小发现项范围： **状态** 或 **严重程度**。默认情况下，列表只显示 **打开** 个发现项，并按严重程度排序。将排序切换为 **最近更新** 即可优先查看最新更改。打开某个发现项再返回，会保留你的搜索、筛选和排序设置。

## 修复失效 URL

1. 在列表中选择一个发现项即可打开其详情。
2. 阅读 **动机** 部分。它会解释 GitBook 将失效 URL 匹配到哪个页面，以及原因。 **相关页面** 列表会链接到所涉及的页面。
3. 点击 **创建重定向**.
4. 该 **添加重定向** 对话框会打开，并已填入 **源路径** 和 **目标** 中的建议内容。你可以调整任何想改的内容，例如选择 **永久重定向** 如果旧 URL 将不再返回。
5. 点击 **启用重定向** 以立即启用它，或者 **保存为草稿** 稍后从你站点的重定向设置中发布它。

当你启用的重定向其源路径与某个未处理发现项匹配时，该发现项会自动标记为 **已解决**。将重定向保存为草稿会让发现项保持打开状态，直到重定向正式生效。

该重定向会添加到你站点的重定向中。你可以随时从 **设置 → 重定向**中进行编辑或删除，或者点击 **管理重定向** 位于屏幕顶部。

{% hint style="info" %}
创建重定向需要站点管理员权限，而更改发现项状态需要编辑权限。你无法使用的操作会显示为禁用状态，并附带说明。
{% endhint %}

### 通配符建议

当多个失效 URL 共享同一个前缀，并且都属于同一个已迁移版块时，GitBook 会建议一个通配符重定向，例如 `/v1/*` ，而不是为每个 URL 创建一个重定向。预填充的重定向对话框已启用 **用匹配文本替换通配符** ，因此 `/v1/installation` 会被发送到新目标下匹配的路径。有关通配符重定向的行为，请参见 [站点重定向](/docs/documentation/zh/publish/site-redirects.md) 。

## 忽略某个发现项

如果建议不正确，或者该失效 URL 不需要重定向，打开该发现项并点击 **忽略**。它会移到 **已拒绝** 并从默认列表中消失。你可以通过筛选 **状态**再次找到它，并通过 **取消归档**.

你也可以使用状态菜单，直接从列表或详情页更改发现项状态：

| 状态      | 含义                      |
| ------- | ----------------------- |
| **打开**  | 该发现项正在等待审核。             |
| **已解决** | 已创建重定向，或者该 URL 已再次解析成功。 |
| **已拒绝** | 你选择忽略了该发现项。             |

当下一次审计发现该失效 URL 现在已能解析成功时，发现项也会自动解决，这可能是因为该路径下又有了页面，包括翻译页面，或者有一个现有重定向覆盖了它。

## 分析失效 URL

该 **分析** 视图会显示在所选时间段内返回 404 的每个 URL，无论 GitBook 是否有对应建议。这些 URL 可能是拼写错误的 URL、没有重定向的过期链接，或垃圾链接。可用它来找出需要新页面而不是重定向的失效 URL，或查看失效流量的来源。

报告包含以下卡片：

* **失效 URL 点击次数**, **受影响访客**，以及 **不同 URL 数量** 在所选时间段内，并显示随时间变化的趋势。
* **失效 URL Top**，按点击次数排序。
* **按维度划分的失效 URL**，可让你按以下维度对失效流量进行分组： **引荐域名**, **失效 URL**, **完整引荐来源**, **国家/地区**返回，或 **设备**。按引荐域名分组是找出链接到过期 URL 的外部网站，以及将真实的过期链接与爬虫噪声区分开来的最快方法。
* **由自适应内容导致的 404**，如果你的站点使用自适应内容。这些访客到达了一个实际存在的页面，但某个条件让他们无法看到该页面。它们会被排除在发现项之外，因为重定向不会有帮助。

你可以使用与你站点其余 [站点分析](/docs/documentation/zh/analytics/insights.md)相同的筛选条件来筛选报告，包括版块、语言、国家/地区、设备和引荐来源。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://gitbook.com/docs/documentation/zh/analytics/broken-links.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.