AIOツールで引用先のリンク切れを見つけたら？404・転送・内容変更を確認する手順

AIOツールで引用先のリンク切れを見つけたら、引用された回答の保存、現在の到達先の確認、本文の内容照合の順に調べます。URLを開けるようにすることと、そのページが回答の根拠として使えることは別の確認事項です。404、転送、アクセス制限、内容変更を分けると、修正対象と担当者を決めやすくなります。

この記事では、AIの回答に添えられたURLを点検するための台帳と手順を紹介します。事例の件数、URL名、製品条件は説明用の架空例です。特定のAIがリンク切れを検知する仕組みや、修正後に必ず再引用されることを示すものではありません。

最初に分けるのは「回答時点」と「確認時点」

先週取得したAI回答の引用先が、今日開くと404になっている場合、今日の状態だけで先週も存在しなかったとは判断できません。公開終了、サイト移行、一時的な障害など、取得後に状態が変わった可能性があります。回答を取得した日時と、リンクを確認した日時を別の列に残します。

反対に、現在はページが存在していても、回答の説明を裏付けているとは限りません。引用時は旧プランの料金表だったURLが、今は新製品の紹介に変わっていることがあります。到達可否だけのチェックでは、このような意味の変化を見落とします。

まず保存するのは、質問、回答原文、引用が付いている箇所、元のURL、エンジン、取得日時です。後からリンクを置き換える場合でも、元のURLは上書きせずに残します。AIが提示した証拠と、自社が確認のために選んだ代替資料を区別できる状態にするためです。

HTTPの状態とページの内容を分けて読む

Googleの説明では、200応答だけでインデックス登録が保証されるわけではありません。エラーページや実質的に空の内容を200で返すと、soft 404として扱われることがあります。404などの4xx、429や5xxはそれぞれ処理が異なります。ここでは検索エンジンの挙動を一括りにせず、点検の入口として使います。GoogleのHTTPステータスに関する公式説明

この表は運用の仕分け例です。ブラウザで見た状態と、ツールが取得したHTTPステータスが違う場合は、どちらかを消さず、取得方法と日時を併記します。ログイン状態、地域、アクセス元などが違うと、同じURLでも見える内容が変わることがあります。

301と302を見つけただけで、転送を修正すべきとは決められません。Googleは恒久移転には301・308、一時的な移転には302・307を使い分ける考え方を説明しています。恒久か一時的かを運用側に確認し、実態に合う方式を選びます。Googleのリダイレクトの説明

点検台帳に必要な九つの情報

リンクの一覧だけでは、担当者が「どこまで直せば完了か」を判断しにくくなります。最低限、引用された内容、今の状態、所有者、対応、再確認の記録を結び付けます。以下は手作業でも運用できる項目の例です。

元の引用URLを整理して重複を減らす場合も、原本の列は保持します。ページ内の位置を示す文字列や計測用のパラメータを除いた管理用URLを作るなら、別列にします。自動で削った結果、資料の版や対象製品を識別する情報まで消えていないか確認してください。

一つのURLが十回答で引用されていても、修正するページは一つかもしれません。対応作業の件数はURL単位、影響する回答の件数は回答単位で集計すると、担当者の負担と影響範囲を別々に説明できます。この二つを足し合わせた数字を「問題の総数」にしないようにします。

引用先を点検する5ステップ

図：回答を保存、到達先を確認、内容を照合、対応を選ぶ、再確認するの5ステップ。本文でも同じ手順を説明。

1. 回答を保存

質問、回答原文、引用の該当箇所、元のURL、エンジン、取得日時を保存します。現在のページ確認を始める前に、AIが何を根拠として示したかを固定します。

共有用の台帳には、長い回答全体を貼る欄と、確認する主張を短く要約する欄を分けると便利です。たとえば「上位プランでは全件出力が可能」という説明が対象なら、その条件を含めて残します。「出力に関する話」とだけ書くと、後の内容照合が曖昧になります。

2. 到達先を確認

元のURLを確認し、取得できたステータス、転送後のURL、表示結果、確認日時を記録します。アクセス制限や一時障害が疑われる場合は、削除と断定せず再確認の対象にします。

自社ページなら運用担当者に管理画面や設定を照会できます。外部サイトは権限のある範囲で確認し、認証や防御機能を回避しようとしません。ツールで取得できないが通常の閲覧はできる場合も、取得方法の違いとして記録します。

3. 内容を照合

到達できたページで、引用された説明の根拠となる記述を探します。製品、プラン、対象地域、適用日、前提条件が一致するかを確認し、該当箇所と相違点を残します。

見出しが似ているだけでは一致としません。回答が「すべてのプランで利用可能」と説明しているのに、本文では上位プラン限定と書かれているなら、到達可でも内容不一致です。読める資料が複数ある場合は、それぞれの適用範囲を比べます。

4. 対応を選ぶ

自社が管理するページか、第三者のページかを分けて対応を決めます。誤削除の復旧、適切な移転先への転送、本文の修正、代替根拠の提示、意図した削除の維持などから、事実に合うものを選びます。

引用を維持するために古い料金や終了済みの機能を現行情報として復活させる必要はありません。旧情報が必要な場合は履歴として扱い、対象期間を明示します。外部サイトの変更は自社で実施できないため、自社記事の根拠を見直す作業と分けて管理します。

5. 再確認する

対応後に元のURL、最終URL、本文の該当箇所を再確認し、修正結果を保存します。その後のAI回答は別の観測として記録し、ページの修復と再引用の有無を分けて報告します。

「担当者が設定した」と「読者が期待する内容に到達できた」は別の状態です。ページ修正の完了条件を満たしたら作業を閉じ、AI側の表示確認は継続観測に移せます。引用が残らないことだけを理由に、復旧作業を永久に未完了にしないようにします。

自社ページと外部ページでは選べる対応が違う

自社のページが誤って削除された場合は、公開してよい内容かを確認したうえで復旧を検討します。旧ページを新ページに統合した場合は、読者の目的を満たす移転先を選びます。単に同じサイトだからという理由で、すべての旧URLをトップページへ集める判断は避け、内容の対応関係を確かめます。

意図的に終了したページに同等の後継情報がなければ、削除状態を維持する判断もあり得ます。その場合、現在の公式案内に終了時期や問い合わせ先を記載するなど、利用者が状況を理解できる導線を考えます。旧URLを無条件に復活させることを、LLMO対策の必須作業にしないでください。

外部サイトでは、まず自社側の引用や紹介記事を確認します。自社記事がその外部資料を根拠にしているなら、主張を裏付ける現行の一次資料を探し、確認できない部分は表現の修正を検討します。AI回答が直接外部サイトを引用している場合は、その回答の記録を保ち、自社で改変できるようには扱いません。

修正依頼を検討するときは、URL、確認日時、問題のある箇所、期待する確認内容をまとめます。連絡先の調査や送信は、社内の担当者と権限を決めて行います。到達先の所有者が分からないまま、類似ドメインの相手に資料や社内情報を送らないようにします。

架空例：同じ「リンク異常」でも三通りに分かれる

架空の業務サービスで、三つの引用先を点検する場面を考えます。いずれもAIOツールの回答一覧から見つけたものですが、修正方法は異なります。以下の判断は説明用であり、各サイトの状況に応じて担当者が確定します。

一つ目は、読者が必要な説明に到達できない問題です。二つ目は、到達はできるものの、適用条件の確認が必要な問題です。三つ目はHTTP上の障害ではありません。三つをまとめて「リンクを直した」と報告すると、どの根拠が回復したのかが分からなくなります。

優先度は、異常の種類だけで決めず、読者の判断に与える影響と自社で対応できる範囲を併せて考えます。契約条件の誤認につながるページや、重要な導入手順の欠落は先に確認する候補です。ただし、影響する読者数が分からない段階で、実際の損失額や離脱人数を推定値として断定しないようにします。

定期点検は重要な引用先から始める

大量のURLを毎日すべて確認するより、重要な質問で引用された自社ページ、変更予定のページ、直前に異常を検出したページを先に追います。点検の頻度は、更新頻度と利用者への影響に応じて決めます。料金や仕様の変更時には、通常の巡回とは別に対象ページの確認を組み込みます。

新しい観測を追加するときは、前回の状態を消さず、履歴として残します。同じURLが「正常→一時障害→正常」と変わったことと、「正常→内容変更」の違いが見えるようになります。担当者が交代しても、同じリンクを何度も初めから調べる手間を減らせます。

対応結果の報告では、点検したユニークURL数、影響回答数、未確認件数、修正済み件数を分けます。たとえば架空の10URLのうち、2URLを修正し、その2URLが6回答に使われていても「6URL修正」ではありません。分母の考え方はAIOツールの指標と分母の解説で整理できます。

AIOツールで追う結果と、サイト側で直す作業をつなぐ

LLMOチェキの公式ページでは、回答全文と引用元の確認が案内されています。本記事のリンク点検台帳は運用の提案であり、すべてのHTTP確認や外部サイトの修復が製品内で自動実行されるという説明ではありません。利用できる画面や出力と、サイト運用担当者の確認結果をつないで使います。

最初の一件では、回答の証拠を保存し、現状を確かめ、対応後の読者体験まで確認してください。そこまで記録できれば、次の異常も同じ形式で扱えます。月次の共有では、引用数の変化とは別に「根拠へ到達できる状態を何件確認したか」を月次レポートへ添えると、実施した作業と観測結果が対応します。

対応の終了条件をページの役割ごとに決める

料金の根拠ページなら、元の引用先から現行の料金と適用条件に到達できることが確認項目になります。操作手順のページなら、手順が途中で欠けず、対象バージョンが分かることを確認します。ページの役割が違うため、「200を返した」という一項目だけを全件共通の完了条件にしないほうが実務に合います。

点検を依頼するときは、期待する到達先を担当者が確認できる形で書きます。「リンク修正をお願いします」だけでは、転送先をトップページへ変えて終わるかもしれません。「旧手順を参照した人が、現行機能の設定方法と制約を読めること」と書けば、本文の移行も必要か判断できます。対象の説明が終了した場合には、終了の案内へ到達できることを完了条件にする案もあります。

確認した人と修正した人を台帳に残しておくと、後から同じURLで問題が再発したときに経緯を追えます。大きな承認工程を作る必要はありません。小規模なサイトなら一人で両方を担当しても、修正日時と閲覧確認日時を分けて記録するだけで、未確認の作業を見つけやすくなります。

影響件数を誤って大きくしないための数え方

架空の点検で、同じ引用URLが回答一覧に12行出ていても、12件の異なる回答とは限りません。一つの回答が複数の引用を持ち、表の出力形式によって行が増えている可能性があります。回答IDで重複を除いた件数と、URLごとの件数を別々に集計します。回答IDを確認できないときは、確定した回答数として報告せず、その制約を添えます。

同じURLが復旧した後に別の障害を起こした場合は、過去の案件を無言で書き換えるより、新しい点検記録を作って前の案件と関連付けると分かりやすくなります。障害の回数、問題があったユニークURL数、影響回答数はそれぞれ別の値です。報告する前に一つのURLを例にたどり、原文、到達結果、修正記録がつながるかを確かめてください。