こんにちは。バナナデスクです。
リンク切れの点検で「正常」と出たURLを開いたら、肝心の資料ではなくログイン画面だった。こうしたリンクは、数字だけでは見逃します。反対に、一時的なエラーが出たからといって、すぐに資料が削除されたと決めるのも早すぎます。
ブログのリンク切れは、HTTPの応答、最後に着いたURL、そこで読める内容を合わせて確認します。この記事では6種類の状態を用意して実際に応答と画面を確認し、残す・直す・再確認する判断を整理しました。
最初に、リンク先とリンクがある記事を一緒に記録する
不具合のあるURLだけを一覧にすると、後でどの記事を直すか探し直すことになります。点検表には、リンク元記事、リンクの文言、現在のURL、確認日時、応答、最後のURL、読めた内容、次の対応を残します。
最初は、よく読まれている記事や、申込条件・料金・手順の根拠として紹介しているリンクから確認すると、読者の判断に関わる不備を見つけやすくなります。記事の中の本文リンクだけでなく、ボタンや参考資料一覧にも目を通してください。
大量のリンクを調べるツールは候補の発見に使えますが、ツールが使うアクセス方法と、読者がブラウザーで開く条件は同じとは限りません。検出したURLは、何が問題なのかを次の段階で確かめます。
6種類のリンクで、応答と画面を確認した例
2026年10月1日、パソコン内の127.0.0.1だけで動くPython製の検証サーバーを使いました。実在の外部サイトへ負荷を掛けた調査ではありません。6つの架空URLへGETでアクセスし、転送の途中の応答とブラウザーの最終画面を照合しました。
| 検証用パス | 確認したHTTP応答 | 画面の内容 | ブログ側で考える対応 |
|---|---|---|---|
| /course | 200 | 講座案内が表示 | 紹介している内容と一致すれば維持 |
| /missing | 404 | 記事が見つからない画面 | 綴りと移転を調べ、代替がなければ参照文も修正 |
| /old-course | 301 → /course → 200 | 新しい講座案内 | 内容が同じ移転ならリンクを新URLへ更新 |
| /temporary | 503・Retry-After: 120 | 一時的に利用できない画面 | 時間を置いて再確認し、恒久削除と決めない |
| /private | 302 → /login → 200 | ログインが必要な画面 | 一般読者向けに使える資料か確認 |
| /blocked | 403 | この条件でアクセス不可 | 手動表示や相手の案内を確認し、遮断を回避しない |
この検証では、リンク切れ点検プラグインは使用していません。プラグインの速度、サーバー負荷、全件の検出率を測った結果ではありません。各状態の違いを、応答と表示の両方から読むための実例です。
最後の200だけで正常と決めない
検証用の/privateは、302で/loginへ転送され、最後の画面は200を返しました。200は応答が成功したことを示しますが、目的の資料が一般読者に読める証拠ではありません。ここで「資料を読む」とリンクしていたら、ログインが必要だと説明するか、公開資料へ差し替える判断になります。
エラーメッセージが出ているのに200を返すページもあり得ます。GoogleのHTTPステータスの説明も、2xx応答だけでは検索への登録は保証されず、内容がエラーを示す場合はsoft 404になり得ると説明しています。ブログの点検でも、数字と内容の両方を見る理由になります。
404なら、URLの誤りと移転を先に調べる
404を見つけたら、まずURLの入力ミス、大文字と小文字、末尾の記号、コピー時に混ざった文字を確認します。自分の記事の変更履歴があるなら、タイトルを変えただけか、URLも変えたかを照合します。
外部の資料は、同じ発行元のサイト内検索や資料一覧から新しい掲載先を探します。見つけたページが同じ主張を裏付けるなら差し替え、内容が変わっているなら引用や説明も直します。近いテーマのページがあるというだけで、以前と同じ根拠になるとは限りません。
代替資料がない場合は、読めないリンクだけを残して説明の根拠にしないようにします。別の根拠を探す、確認できない主張を狭める、不要になった参照文を削る、といった対応を選びます。リンクを消した後も「こちらをご覧ください」だけが残らないか読み直してください。
転送先が正しいなら、本文のリンクも新URLへ直す
今回の/old-courseは301で/courseへ移り、講座案内を表示しました。移転先の内容まで一致していることを確認できれば、ブログ本文のリンクを新URLへ変更する候補になります。
転送された先がトップページや無関係な商品ページなら、「ページは開いた」だけで完了にはしません。読者がリンク文言から期待した情報に到達できるかを確認します。複数回の転送がある場合も、最終URLだけでなく途中の経路を記録しておくと、元サイトの管理者へ具体的な状況を説明できます。
503や403は、すぐに恒久的な削除と解釈しない
503の例にはRetry-After: 120という応答も付けました。これは今回のサーバーが再試行までの目安を示すために設定した値で、120秒後の復旧を観測したわけではありません。現実の点検では、記録した時刻から間隔を置いて再確認し、継続する場合は公開されている障害案内なども調べます。
403の例は、その条件のアクセスを許可しない設定です。外部サイトで同じ応答が出ても、ページの削除、会員限定、自動アクセスの制限など、原因は数字だけでは確定しません。通常の手動アクセスで読めるか、公開対象が変わったかを調べ、制限を回避する目的でアクセスを繰り返さないようにします。
修正後は、保存された記事からもう一度開く
- リンク先だけでなく、リンク文言と前後の説明を確認して修正します。
- 記事を保存した後のページを開き、修正したリンクをクリックします。
- 最終URLと資料の内容が意図どおりか確認します。会員向けの資料なら、その条件も読者へ分かるようにします。
- 点検表へ修正日と理由を残します。一時的な問題で保留したものは、再確認の対象として区別します。
新しい点検プラグインを導入する場合は、取得間隔や対象件数、サーバーの制約を確認して小さく試します。全記事を短時間で何度も調べることより、検出結果を適切に直せることを優先してください。
リンク切れを直す目的は、読者が必要な説明や根拠へ到達できる状態にすることです。エラー件数が0になっただけで検索順位の改善が確定するわけではありません。応答と実際の行き先を照合し、文章も一緒に整えると、点検の結果を読者の使いやすさにつなげられます。