HOME > 技術ドキュメント > Webサイトのリンク切れ調査と運用フロー入門
Webサイトのリンク切れ調査と運用フロー入門
執筆:株式会社エスロジカル(Webシステム受託開発・インフラ構築・運用改善)
運用年数が長いサイトほど、リンク切れ(404 Not Found・5xx・タイムアウト)は気付かないうちに溜まっていきます。
外部リンク先のサイト消滅、自社内の URL 変更、記事削除、タイポ──原因はさまざまです。
放置すると SEO 評価の低下・ユーザーの離脱・問い合わせ機会のロス につながります。
本記事では、リンク切れの原因・影響の整理と、実務で使える調査・運用フローを解説します。
1. リンク切れが起きる主な原因
| 原因 | 典型例と対策 |
|---|---|
| 外部サイトの消滅・記事削除 | 参照元の企業・個人サイトが閉鎖された/記事がアーカイブされた。外部リンクは特に「定期巡回」でしか発見できない |
| 自社内の URL 変更 | CMS リニューアル・カテゴリ統合で URL が変わった。301 リダイレクトの設定漏れが典型。リダイレクト設計とセットで管理する |
| 記事の削除・非公開化 | 古い記事を消したあと、サイト内の他記事からのリンクが孤立。削除前に内部リンク元を確認する運用が必要 |
| HTTPS 化・ドメイン変更 | http:// のままハードコードされている、旧ドメインのままの参照が残っている |
| タイポ・コピペミス | 新規記事公開時に貼ったリンクが間違っているケース。公開前の curl -I 確認が一番効く |
| 一時的な障害 | リンク先が一時的に 5xx・タイムアウト。1回だけの判定で「リンク切れ」と決めず、リトライ前提で運用する |
2. リンク切れが事業に与える影響
- SEO 評価の低下:大量の 404 が放置されたサイトはクロールバジェットを浪費し、サイト全体の信頼度評価にも影響します。
- ユーザー離脱:記事中のリンクが切れていると「このサイトはメンテされていない」という印象を与え、直帰率が上がります。
- 問い合わせ機会のロス:サービスページ・問い合わせフォームへのリンクが切れていると、コンバージョンに直接効きます。
- 過去資産の死蔵:古い記事の中に存在しないページへの内部リンクが残っていると、関連記事・回遊が機能しなくなります。
3. リンク切れの調査手順
規模・更新頻度に応じて、調査手法を組み合わせます。
| 手法 | 向くケース | 特徴 |
|---|---|---|
| 手動 + ブラウザ | 小規模・公開直前の確認 | ページ数が少なければ最も確実。デベロッパーツールの「Network」タブで 4xx/5xx を可視化できる |
curl -I |
個別 URL の精査 | レスポンスコードだけを取得して即時確認。curl -IL でリダイレクト追跡まで行える |
| WordPress プラグイン | 個人ブログ・小〜中規模 WP | 「Broken Link Checker」等。サイト内常駐型はサーバー負荷に注意 |
| SaaS / 外部巡回サービス | 中〜大規模・定期運用 | サーバー側に負担をかけず、定期巡回・通知が可能。複数サイト一括管理に向く |
| Google Search Console | SEO 観点の確認 | Google が検出した 404 を「ページ > 未登録」で確認できる。気付きの起点になる |
curl で個別確認する例:
|
# ステータスコードだけ確認 curl -o /dev/null -s -w "%{http_code}\n" https://example.com/some-page # ヘッダー表示(HEAD リクエスト) curl -I https://example.com/some-page # リダイレクトを最後まで追跡してチェーン全体を確認 curl -IL https://example.com/some-page |
4. リンク切れ自動巡回の運用設計
サイト規模が大きくなると、定期巡回と通知の仕組みが必要になります。
- 巡回間隔:更新頻度の高いサイトは週次、コーポレートサイト規模なら月次でも実用十分。
- 通知先:メール・Slack・Chatwork など、運用チームが日常的に見ている場所に送る。差分(前回からの新規・解消)だけ通知すると運用が回りやすい。
- 除外設定:外部 SNS のシェアボタン URL、認証必須ページ、レートリミットがあるサイトは事前に除外。
- リトライ:5xx・タイムアウトは一時障害の可能性が高いため、最低でも 2回のリトライで「真のリンク切れ」を判定する。
- クロール速度:巡回元のリクエストが集中すると相手サイトに迷惑がかかる。同時実行数・リクエスト間隔を制御する。
弊社運営の リンク切れチェック(dead-link-checker.com) は無料版に加えて、 大規模サイト・定期巡回・チーム共有に対応した有料プランをご提供しています。
5. リンク切れを減らすコンテンツ運用ルール
- 記事削除より「410 Gone」または 301 リダイレクト:404 にせず明示的に意図を返す。サイト統合時の判断は 301/302 リダイレクト設計のベストプラクティス を参照。
- 外部リンクは出典として残す:引用元の元 URL を残し、必要なら Web Archive(archive.org)のスナップショット URL を併記する。
- 記事公開前のチェックリストに「全リンクのステータス確認」を入れる:編集フローに組み込むのが最も効果的。
- URL は変更しない設計:カテゴリ階層を URL に含めない、日付を含めないなど、後で変えなくて済むパーマリンク設計を最初から選ぶ。
6. よくある質問
- Q. 外部リンクの切れは放置でいいですか?
- A. 数が少なければ実害は限定的ですが、参照元として信頼性に関わるので、出典の重要度に応じて Web Archive 等で差し替えを推奨します。問い合わせ・購入導線に絡む外部リンクは即対応すべきです。
- Q. 301 でリダイレクトすれば SEO は無傷ですか?
- A. 多くの場合はほぼ無傷ですが、リダイレクトチェーン(3回以上の連続リダイレクト)はクロールバジェットを消費し、ユーザー体験も低下します。中継せず直接最終 URL に張り替えるのが理想です。詳細
- Q. canonical を設定していれば 404 にしてもいい?
- A. canonical は「重複コンテンツの正規版」を示すヒントで、404 を打ち消す効果はありません。削除する記事は 301 か 410 を返すのが原則です。
- Q. リンク切れチェックツールは自前で書くべき?SaaS を使うべき?
- A. 自社の本業に近いなら自前、それ以外は SaaS が割に合います。クロール礼節(robots.txt 順守・レート制御)と通知基盤を自前で作る労力は侮れません。
チェックリスト
- □ サイト内に死んだ内部リンクが何件あるか把握している
- □ 公開前のチェックフローに全リンクのステータス確認が含まれている
- □ 削除した記事は 404 ではなく 410 か 301 を返している
- □ 外部リンクの定期巡回(週次〜月次)の仕組みがある
- □ Google Search Console の「ページ > 未登録」を定期的に確認している
- □ 5xx・タイムアウトは 1回の検知で即「切れ」と判定していない(リトライ前提)
リンク切れチェックサービス(弊社運営)
dead-link-checker.com は、Web サイトのリンク切れ(404・5xx・タイムアウト等)を自動巡回・通知する SaaS サービスです。
無料版に加えて、大規模サイト・定期巡回・チーム共有に対応した有料プランを提供しています。
関連:HTTPステータスコード実務ガイド / 301/302 リダイレクト設計のベストプラクティス / SSL証明書
dead-link-checker.com は、Web サイトのリンク切れ(404・5xx・タイムアウト等)を自動巡回・通知する SaaS サービスです。
無料版に加えて、大規模サイト・定期巡回・チーム共有に対応した有料プランを提供しています。
関連:HTTPステータスコード実務ガイド / 301/302 リダイレクト設計のベストプラクティス / SSL証明書
