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回の検知で即「切れ」と判定していない（リトライ前提）

← 技術ドキュメント一覧へ戻る