WordPress の公開記事からリンク切れ候補を探して修正する

記事のリンクは移転や削除だけでなく認証設定の変更でも読者から見えなくなる．一度取得できなかっただけでリンク切れと決めると実際にはログイン後に読めるページや一時的な障害を誤って直すことになる．

WordPress 用 MCP サーバープラグインで記事の本文を読み取りリンク先の HTTP 応答は別の調査として扱う．移転先が正しいと人が確認した URL だけを記事の流れを壊さない範囲で修正する．

リンク切れ候補を探す

公開中の記事をページごとに調べ本文と抜粋に含まれる URL，アンカーテキスト，リンクの前後の文章を拾う．記事一覧には本文が含まれないため候補の記事は個別に読み直す．タイトル，URL 名，保存状態，カテゴリーとタグ，アイキャッチ画像も一緒に確認してどの記事のリンクかを取り違えない．

HTTP 応答は候補を分類するための材料である．401 は認証を求めている状態，403 は権限や WAF に拒否された状態の可能性がある．429 は回数制限，5xx は一時障害かもしれない．これらをリンク切れと断定せず確認できた条件をそのまま記録する．

Codex へ渡す指示

公開記事のリンク切れ候補を探して原因と確認方法を見せてください．

候補の一覧を受け取ってから移転先や修正の要否を人が決める．外部サイトへの問い合わせや認証情報の入力を AI に任せず確認できない URL は未確認のまま残す．

応答だけでリンク切れと決めない

サイト内リンクが 301 や 302 で移転している場合は最終 URL の内容とサイト内で使う正規の URL 名を確かめる．外部リンクの移転先が広告や別サービスになっているなら単純に追従しない．404 も一時的な設定や URL の表記違いがあり得るため確認日時を残して再調査する余地を示す．

HTTP 200 でも別の内容へ変わっていることがある．反対に 403 でも読者の通常の環境では表示されることがある．応答，認証の有無，ページの内容を分けて判断する．

新しい URL を人が選ぶ

修正候補には旧 URL，記事内のアンカー，想定する新 URL，置換する文章を並べる．新 URL は所有者の案内や公式の移転情報で確かめる．架空の「旧資料ページ」から「新資料ページ」へ移す例は手順の説明であり実際の移転を確認したものではない．

認証が必要なページを削除候補にしない．リンク先の運営者，記事の目的，読者が次に必要とする情報が揃って初めて置換案を承認する．

一箇所を直してから再確認する

承認した記事を直前に読み直し本文が読み取り時から変わっていないかをプラグイン側で照合する．旧 URL が一度だけ現れることを確かめその文字列だけを本文内で置換する．保存前に本文が変わっていれば競合として止め古い内容で上書きしない．複数箇所を同じ URL に変える場合も記事ごとに位置と目的を確認する．

保存後は記事を読み直し新 URL，アンカー，置換箇所が意図どおりであることを確認する．タイトル，抜粋，URL 名，保存状態，カテゴリーとタグ，アイキャッチ画像に余分な変更がないことも見る．

公開ページで確認する

保存された本文と読者向け HTML は別の確認である．必要なら公開 URL をクライアント側で開きリダイレクト，認証要求，キャッシュの影響を確かめる．401 や 403 の結果だけでリンク切れと報告しない．

リンク切れを人が確認して修正するのは大変な作業

リンク監査は記事の文脈を読み HTTP 応答と閲覧条件を分けて候補化する作業である．移転先を人が承認してから一箇所ずつ直し保存後の本文と公開ページを別に確認することで誤った削除や一括置換を避けられる．
AI に任せるとかなり負担が減る作業である．