リンク切れ

公開済みサイトで 404 を返すURLを見つけ、提案されたリダイレクトで修正できます

Broken links はベータ版で、Ultimate サイトプランで利用できます。

Broken links は、訪問者がアクセスしているものの、もはや存在しない公開済みサイト上の URL を見つけ出します。各リンク切れ URL について、GitBook は訪問者が最も探していた可能性が高いページを特定し、1 回のクリックで有効化できるリダイレクトを提案するので、訪問者が 404 ページに着地し続けることがなくなります。

サイトのサイドバーで、次へ移動します 改善 → Broken links.

仕組み

GitBook は、Broken links を含むプラン上の公開済みサイトを定期的に監査します。各監査では次の手順が実行されます。

1. サイトへの過去30日間のトラフィックを確認し、404 を返した URL を収集します。URL は少なくとも3回アクセスされている必要があり、次のようなボットやスキャナーによるノイズは除外されます。 /wp-admin または .php ファイルへのリクエストは無視されます。
2. 類似した URL をまとめ、既存のライブリダイレクトでカバーされているものや、そのパスにページが存在するため再び解決されるものを除外し、残りを訪問数順に並べます。最も訪問数の多い60件のリンク切れ URL が次へ進みます。
3. 公開済みコンテンツを読み取り、各訪問者が最も探していた可能性が高いページを見つけます。セクション全体が移動している場合、GitBook はリンク切れ URL を次のような 1 つのワイルドカード提案の下にまとめます。 /v1/*。該当するページがない場合は、GitBook がその旨を示し、その URL を30日後に再確認します。
4. 明確に一致するリンク切れ URL ごとに、提案されたリダイレクトを作成し、そのページが選ばれた理由の短い説明と、URL が受けるトラフィック量に基づく重大度を付けます。

サイトの監査は 1 日に最大 1 回です。各監査は現在のトラフィックからやり直され、解決済みの URL は除外されるため、60 件を超えるリンク切れ URL があるサイトでも、監査を重ねることで訪問数の多いものから順に処理されます。GitBook がどのページにも一致させられなかったリンク切れ URL も、理由と検討したページを含めて検出項目として保持されるため、リダイレクトではなく新しいページが必要かどうかを判断できます。

Broken links は サイトのリダイレクトの上に成り立っています。リダイレクトに慣れていない場合は、先にそれを読んでください。

2つのビュー

Broken links には 2 つのビューがあり、ヘッダーのタブから切り替えられます。

• 検出項目 GitBook が見つけたリンク切れ URL と、確認用に提案されたリダイレクトを一覧表示します。
• 分析 サイトの分析から得られた完全なリンク切れ URL レポートを表示します。まだ提案がない URL も含まれます。

検出項目の確認

この 検出項目 ビューは過去30日間の要約から始まります。

カード	表示内容
リンク切れの訪問	サイトが返した 404 応答の数。
影響を受けた訪問者	404 に到達した一意の訪問者数。
提案されたリダイレクト	レビュー待ちの未処理提案の数。

リストには、各検出項目のステータス、重大度、そしてリンク切れ URL と、GitBook が見つけた場合は遷移先のページを説明するタイトルが表示されます。修正案のある検出項目が最初に一覧表示されます。

重大度

重大度は、サイト内の他のリンク切れ URL と比べて、そのリンク切れ URL が受けるトラフィック量を反映します。

重大度には3つのレベルがあります。

• 高：過去30日間に少なくとも20回の訪問があり、サイト内で訪問数の多いリンク切れ URL 上位5件のうちの1つ。
• 中：安定したトラフィックのある URL。
• 低：過去30日間に数回しかアクセスされていない URL。

検索、フィルタリング、並べ替え

検索ボックスに URL、またはその一部を入力して、特定の検出項目を見つけます。フィルターバーを使って、検出項目を次で絞り込めます。 ステータス または 重大度。既定では一覧は 未対応 検出項目のみを、重大度順に表示します。並べ替えを 最近更新された順 に切り替えると、最新の変更が最初に表示されます。検出項目を開いて戻っても、検索、フィルター、並べ替えは保持されます。

リンク切れ URL を修正する

1. 一覧で検出項目を選択して、詳細を開きます。
2. 次を読みます 背景 セクション。GitBook がリンク切れ URL に一致させたページと、その理由が説明されています。 関連ページ リストには関係するページへのリンクが表示されます。
3. クリック リダイレクトを作成.
4. この リダイレクトを追加 ダイアログが ソースパス と 転送先 を、提案内容からすでに入力済みの状態で開きます。必要に応じて変更してください。たとえば 恒久的リダイレクト を選択すると、古い URL が二度と戻らない場合に適しています。
5. クリック リダイレクトを有効化 をクリックすると、すぐに有効化されます。 下書きとして保存 をクリックすると、サイトのリダイレクト設定から後で公開できます。

ソースが未処理の検出項目と一致するリダイレクトを有効化すると、その検出項目は自動的に 解決済みとしてマークされます。リダイレクトを下書きとして保存すると、リダイレクトが公開されるまで検出項目は未処理のままです。

リダイレクトはサイトのリダイレクトに追加されます。 設定 → リダイレクトから、または画面上部の リダイレクトを管理 をクリックして、いつでも編集または削除できます。

リダイレクトの作成にはサイトでの管理者権限が必要で、検出項目のステータス変更には編集権限が必要です。使用できない操作は無効化され、説明が表示されます。

ワイルドカード提案

複数のリンク切れ URL が同じ接頭辞を共有し、すべて同じ移動したセクションに属している場合、GitBook は URL ごとに 1 つずつリダイレクトする代わりに、次のような単一のワイルドカードリダイレクトを提案します。 /v1/* 代わりに。あらかじめ入力されたリダイレクトダイアログでは ワイルドカードを一致したテキストに置き換える が有効になっているので、 /v1/installation は新しい宛先の一致するパスに送られます。ワイルドカードリダイレクトの動作については、 サイトのリダイレクト を参照してください。

検出項目を無視する

提案が適切でない場合、またはリンク切れ URL にリダイレクトが不要な場合は、検出項目を開いて 無視をクリックします。 却下 に移動し、既定の一覧から消えます。 ステータスでフィルタリングすると再度見つけられ、 アーカイブ解除.

ステータスメニューを使って、一覧または詳細ページから直接検出項目のステータスを変更することもできます。

ステータス	意味
未対応	検出項目はレビュー待ちです。
解決済み	リダイレクトが作成されたか、URL が再び解決されるようになりました。
却下	検出項目を無視するよう選択しました。

次回の監査でリンク切れ URL が再び解決されると、検出項目は自動的に解決済みになります。これは、そのパスにページが再び存在するようになった場合（翻訳ページを含む）、またはライブリダイレクトでカバーされる場合です。

リンク切れ URL の分析

この 分析 ビューには、選択した期間に 404 を返したすべての URL が表示されます。GitBook に提案があるかどうかは関係ありません。これらは、入力ミスの URL、リダイレクトのない古いリンク、またはスパムリンクの可能性があります。リダイレクトではなく新しいページが必要なリンク切れ URL を見つけたり、リンク切れトラフィックの発生源を確認したりするために使用できます。

レポートには次のカードが含まれます。

• リンク切れ URL のヒット数, 影響を受けた訪問者、そして 固有 URL 選択した期間について、時間経過に伴う傾向付きで表示されます。
• 主なリンク切れ URL、ヒット数順に並べられます。
• ディメンション別のリンク切れ URL、これによりリンク切れトラフィックを次の項目でグループ化できます。 参照元ドメイン, リンク切れ URL, 完全な参照元, 国、また デバイス。参照元ドメインでグループ化すると、古い URL へリンクしている外部サイトを最も早く見つけられ、実際の古いリンクとクローラーノイズを見分けられます。
• アダプティブコンテンツによって発生した 404、サイトでアダプティブコンテンツを使用している場合。これらは、存在するページに到達したものの、条件によって閲覧できなかった訪問者です。リダイレクトでは役に立たないため、検出項目から除外されます。

レポートは、ほかの サイト分析と同じフィルターで絞り込めます。セクション、言語、国、デバイス、参照元などが含まれます。