WordPressのリンク切れ監査で大量のエラーが出ると、見つかったURLをすぐ削除・置換したくなります。しかし、404と503を同じ「リンク切れ」として扱うと、正常なリンクを一時障害の最中に書き換え、関連性の弱い代替先へ読者を送ることがあります。
結論：404は内容確認、503は再確認キューへ分ける
監査結果は、最初から「修正するリンク一覧」ではなく「再確認する候補一覧」として扱います。404はURL変更、削除、入力ミスを確認して後継先を探します。503はサーバーが一時的に処理できない状態を表すため、取得時刻、再試行条件、Retry-After、同一ホストの他URLを記録し、時間を空けて再確認します。
404と503は修正判断が違う
404 Not Foundは、サーバーが要求されたリソースを見つけられない時の応答です。URLのタイプミス、記事の削除、スラッグ変更、カテゴリ構造の変更などが候補になります。一方、503 Service Unavailableは、保守、過負荷、接続数制限などで、その時点では要求を処理できない一時状態に使われます。
HTTPの定義でも、503は一時的な状態に使う応答とされ、可能なら復旧見込みをRetry-Afterで示します。したがって一度の503だけでリンク先が消えたと断定せず、再取得して恒久障害か一時障害かを分ける必要があります。
| 状態 | 意味の目安 | 最初の判断 |
|---|---|---|
| 200 | 取得成功 | リンク先本文と意図を確認 |
| 301 / 308 | 恒久リダイレクト | 最終URLとループを確認 |
| 302 / 307 | 一時リダイレクト | 認証や保守画面への転送を確認 |
| 404 / 410 | 未発見 / 消失 | 後継URLまたは削除を検討 |
| 429 / 503 | 制限 / 一時利用不可 | 待機して再確認 |
実測で分かった、一括修正が危険な理由
ある週次監査では49件の異常応答が検出されました。公開URLを個別に再確認すると、恒久的な404は6件で、残る43件は同じ時間帯に集中した503でした。その後、子sitemapを取り直すとすべて200へ戻りました。最初の結果だけで49件を置換していれば、正常な43リンクまで不要に変更していたことになります。
件数の増減をそのまま品質指標にしない
前回589ページを取得できた監査が、次回107ページしか取得できなかった場合、リンク切れ49件という数字だけを前月13件と比べても改善・悪化は判断できません。監査対象数、ホスト別エラー、時刻、再試行結果をそろえて比較します。
安全なリンク切れ監査の7ステップ
- 公開sitemapや記事台帳から、監査対象URLを確定する
- 参照元URL、リンク先URL、アンカーテキスト、HTTP状態、取得時刻を保存する
- 301・302は最終到達先とリダイレクト回数を確認する
- 404・410は公開ブラウザ、sitemap、サイト内検索で後継先を探す
- 429・500・502・503・504はホスト別にまとめ、待機して再取得する
- 置換候補はURLが200だけでなく、元リンクの検索意図と文脈に一致するか確認する
- 変更前本文とハッシュを保存し、少数ずつ更新して公開DOMを再確認する
JavaScriptで描画されるSPAでは、静的HTMLだけを監査すると存在するリンクを見落とす場合があります。その場合は静的HTMLと描画後DOMを分ける内部リンク監査も併用してください。
503を再確認する時の記録項目
- 最初に503を取得した日時とタイムゾーン
- レスポンスヘッダーの
Retry-After、キャッシュ、CDN情報 - 同一ホスト内で200、404、503になったURL数
- HEADとGETの差、リダイレクト後の最終状態
- 1回目、待機後、別時間帯の再取得結果
- ブラウザ表示と機械取得で応答が違うか
Retry-Afterヘッダーには、再試行までの秒数または日時が入ります。ヘッダーがない場合も、同一サイトへ短時間に大量の再試行を重ねず、指数的に待機時間を伸ばし、上限回数を決めます。
404の置換先は「200なら何でもよい」ではない
恒久404と確認できても、トップページやカテゴリ一覧へ機械的に差し替えると、アンカーテキストと到達先が一致しなくなります。たとえば特定プラグインの設定手順へのリンクを製品一覧へ置き換えると、読者が探している操作手順へ正面回答できません。
- 同じ記事の新URLがあるなら、そのURLを最優先する
- 統合記事があるなら、該当見出しへ到達できるか確認する
- 同じ検索意図の後継がなければ、リンクと周辺文を削除・書き換える
- 販売終了や配布停止なら、現行の入手先を確認してから案内を変える
- 価格、返金、ライセンス条件は推測で転記しない
内部リンクの目的は数を増やすことではなく、孤立記事を減らし、次に読むべき情報へつなぐことです。基本設計は内部リンクと孤立記事の基礎、製品を使った運用はACS Internal Linksで孤立記事を見つける方法も参考になります。
WordPress更新前後の安全確認
本番更新では、対象投稿IDと公開URLを確定し、更新直前のcontent.raw、更新日時、SHA-256を保存します。監査から更新までに別の編集が入った場合は、古い本文へ上書きせず中止します。更新は上限件数を決め、1サイト全件を一度に変えない方が復旧と原因追跡が容易です。
置換処理には対象URLと新URLの組を識別する一意マーカーを持たせます。同じ日次処理が再実行されてもリンクや関連記事ブロックを二重追加せず、すでに変更済みなら検証だけを行う設計にすると安全です。
- 公開元と新しいリンク先がHTTP 200か
- 公開DOMに新しいアンカーが1回だけ出るか
- 置換前URLが対象箇所から消えたか
- PCと390pxで横はみ出しやボタン崩れがないか
- ブラウザconsoleに新しいエラーや警告がないか
よくある質問
Q. 503が1回出たリンクは削除した方がよいですか？
A. すぐには削除しません。503は一時的な保守や過負荷で返ることがあります。取得時刻とRetry-Afterを記録し、待機後と別時間帯に再確認してから判断します。
Q. 404なら必ず別URLへ置換しますか？
A. いいえ。同じ検索意図の後継先がない場合、無関係なトップや一覧へ替えるより、リンクと周辺文を削除・書き換える方が自然です。
Q. HEADが200ならリンクは正常ですか？
A. 本文取得、リダイレクト、認証、JavaScript描画で結果が変わるため、重要リンクはGETと公開ブラウザでも確認します。200でも本文が保守画面や空ページなら正常とは限りません。
Q. 監査ツールのリンク切れ件数を前月と比較できますか？
A. 監査対象数、取得成功率、同一ホストの一時エラー、実行時刻が同等な時に比較します。取得ページ数が大きく違う結果を単純比較しないでください。
まとめ
WordPressのリンク切れ監査では、404と503を同じ修正キューへ入れません。404は後継先と文脈を確認し、503は取得時刻、ホスト、Retry-After、再試行結果を残します。変更前の本文とハッシュを保存し、少数ずつ更新して公開DOMまで確認すれば、正常リンクの誤修正を減らせます。
孤立記事と関連記事を継続的に整える場合はACS Internal Links、サイトの状況から次の改善先を選ぶ場合はACSサービス選択診断をご覧ください。
この記事は役に立ちましたか？
ありがとうございます！
