リンクチェックで403・429が出たら｜閲覧結果と取得条件を分ける確認手順

リンクチェックの結果がエラーでも、そのURLをすぐ削除・転送しないでください。まずリンク元、調べたURL、日時、エラーの内容と、通常の閲覧で起きることを揃えます。自動取得の失敗と、必要な人が本文を読めない問題は、同じとは限りません。

この記事は、企業サイトを更新する担当者と、点検結果を報告する制作会社向けです。自動ツールのエラーを、人が直すべき案内と未確認事項へ分ける手順を扱います。アクセス制限の回避や、サーバー設定を一律に緩める方法は案内しません。

1．エラーの出たリンクと確認条件を控える

リンク元と実際の取得先を分ける

エラーが出たページだけでなく、どの本文・画像・ボタンから、そのURLを案内しているかを残します。リンク文字と保存されているURLを照合し、転送がある場合は最初のURLと最終的な行き先を区別します。似た別ページを開いて確認済みにしないようにします。

表示文字では正しい資料名に見えても、リンク先が旧版のままという場合があります。反対に、ツールで取得できなくても、正式な公開資料の案内自体が続いている場合があります。応答と内容の正しさを別の確認欄にしてください。

ツールと日時も記録する

利用したツール、確認した日時、結果のコードやエラー文、分かる範囲の取得方法を控えます。タイムアウトや名前解決の失敗では、HTTP応答のコードを受け取れていないこともあります。エラー一覧の全行を、404という一つの分類へまとめません。

共有する記録からは、認証用の一時情報や不要な個人情報を除きます。結果の全文を公開することと、担当者間の調査資料として保管することは用途が違います。

2．応答コードで分かることを限定する

拒否と不存在を同じにしない

HTTPの公式仕様RFC 9110の403は、要求を理解したが処理を拒否する応答です。コードだけで「そのページは削除された」「必ずWAFが原因」とは判断できません。404や、ログインが必要な状態とは区別して調べます。

405は、その対象で要求したメソッドが認められない応答です。ツールの取得方法と通常の閲覧方法が違う場合は、その違いを担当者が調べます。特定のコードから、すぐサーバー設定を変更する手順へ進めないでください。

429では繰り返す前に条件を確認する

RFC 6585の429は、一定時間に多すぎる要求を送ったことを示します。再試行までの目安を表すRetry-Afterが付く場合があります。必ず付くとは限らず、再試行すれば必ず読めるという保証でもありません。

短時間に何度も取得して判定を変えようとせず、ツールの頻度・同時取得数、応答の説明、管理者の案内を確認します。自動チェックが正常に動いたかと、相手の利用条件に沿っているかも別に確認してください。

3．正規の閲覧で同じURLを確認する

リンク元の公開ページから実際に操作し、同じURLへ進むか、本文やファイルを読めるかを確認します。管理者としてログインした状態だけでなく、案内の対象者が使う条件も確認してください。会員向けなら正規の権限、一般公開ならログインしていない状態で区別します。

開けた場合も、目的の資料か、受付が続いているか、内容が古くないかを読みます。200の応答や画面の表示だけでは、読者の疑問に合う行き先と確認したことにはなりません。エラー案内を正常な本文と取り違えないようにします。

開けない場合は、その状態と確認日時を残します。端末やネットワークの違いを調べる場合も、許可された環境で条件を明確にします。制限を避けるために他人の認証情報を借りたり、自動取得の身元を偽装して再試行したりしません。

4．取得方法の違いと、原因の仮説を分ける

制作担当は、ツールの要求方法、転送の追跡、Cookieやログインの有無、取得頻度、応答内容を比較します。通常のページ取得に使うGETと、本文を受け取らず応答情報を確認するHEADでは、結果が同じと決めつけず、利用した方法を記録します。両者の意味はRFC 9110のメソッド説明を参照できます。

自社管理のサイトなら、管理者が同じ日時のアクセスログや制限の記録を照合できる場合があります。外部サイトなら、その管理者でなければ分からないこともあります。取得条件の差があることから、原因や担当システムを確定したと扱わないでください。

記事のリンク点検のために、WAF、認証、索引設定、公開範囲を一括変更する必要はありません。修正が必要と分かった場合は、その対象、影響、戻し方と承認を別の仕事として整理します。

5．修正する・経過を見る・未確認を分ける

リンクが不要かどうかは、その記事で果たす役割も見て判断します。重要な一次資料が取得失敗したからといって、同じ題名の別サイトを正本として置き換えないでください。別資料を使うなら、発行元、版、適用条件まで確認します。

内部リンク全体の配置を調べる場合は、企業サイトの内部リンク点検も参照してください。本稿は、取得エラーが出た一件の判断を中心に扱います。

6．変更前を残し、必要な案内だけ直す

本文のリンクを修正する場合は、リンク元と位置、変更前後のURLと文言、理由、確認担当を残します。共通の案内、転送、公開状態、アクセス制限などが関係する場合は、本文の一語修正とは別に影響を確認します。

反映前には現在の原稿を保存し、別の人が更新していないかを照合します。取得エラーの一覧から、すべてのリンクを一括削除する処理を行わないようにします。変えないリンクや資料も対象外として記録してください。

結果が分からないときは同じ処理を再送せず、現在の保存値を読み直します。戻す場合も、後続の正しい編集を消さないよう、当該箇所と原本を比較して限定します。

7．公開後に、リンクの操作と内容を読み戻す

編集画面でURLを保存できても、公開ページへ反映されたかは別の確認です。ログインしていない公開側でリンク文字、行き先、転送先の本文やファイルを確認します。PCとスマートフォンで必要な情報へ進めるかも見ます。

点検結果には、元の取得結果、通常閲覧の結果、実施した修正、未確認、次の担当と日付を残します。自動チェックのエラーが減ったことを、すべてのリンク先の意味確認が終わったことや、検索順位・相談が増えたことへ置き換えません。

再チェックは公開後の確認や、次に決めた観察時期など、目的がある場合に行います。同じ結果を何度も取得するより、未確認の条件と確認先を明らかにする方が、次の判断へつながります。

8．相談には結果と条件、直したい案内を渡す

自社で確認できる最初の仕事は、リンク元、リンク先、日時、ツールの結果、正規の閲覧結果を一組にすることです。原因を特定できなくても、この材料があれば調査の対象を絞れます。

Acquaへは、リンクの現行確認、点検票の整理、WordPressの本文や案内の修正、公開前後の検収など、必要な工程を相談できます。企業向けWeb支援と制作会社向け実装・保守で担当範囲を確認し、環境と必要な調査を見て対応可否を決めます。外部サイトの制限解除や復旧を一律に約束しません。

相談窓口には、対象URL、確認した結果、困る人と操作、希望する状態を伝えてください。認証情報や機密ログを初回から貼る必要はありません。支援後は、正しい案内へ進めること、取得できない範囲が区別されること、変更と次の確認を担当者が引き継げる状態を目指します。