サイトリニューアルでAI検索の評価を失わない移行チェックリスト

結論：SEO移行の作法だけでは、AI検索の評価は引き継げない

先に結論です。サイトリニューアルでAI検索の評価を守るために必要なのは、次の3点です。

1. 通常のSEO移行（301リダイレクト・サイトマップ・URLマッピング）を確実に行う。 これはAI検索対策の土台でもあります。Googleは、リダイレクトを「一般的には1年以上」保持することを公式に推奨しています。
2. AI検索特有の資産を移行対象リストに明示的に載せる。 llms.txt、構造化データ、robots.txtのAIクローラー許可設定、定義ブロックやFAQのHTML構造は、通常のリニューアル要件定義から漏れやすい項目です。
3. AIの回答が更新される速度は経路によって違うことを前提に、公開後の観測期間を設ける。 検索インデックス経由の回答は比較的早く追従しますが、モデルの学習データに由来する説明はすぐには変わりません。

AI検索で切り出されても意味が通るよう、定義を一段落でまとめておきます。

サイトリニューアルにおけるAI検索移行対策とは、URL・サイト構成・HTML実装の変更後も、ChatGPT検索・Google AI Overviews・PerplexityなどのAI検索が自社サイトを正しく取得・引用し続けられるように、リダイレクト・クローラー許可設定・構造化データ・llms.txt・定義コンテンツを計画的に引き継ぐ取り組みです。 通常のSEOサイト移行を土台としつつ、AIクローラーのアクセス経路とAI回答の更新速度の違いを考慮する点が異なります。

対象読者は、リニューアルを計画中の企業のWeb担当者・マーケティング責任者です。301リダイレクトやサイトマップといった基本的なSEO移行は把握している前提で、「AI検索・LLM側の評価はどう引き継がれるのか」に焦点を当てます。

AI検索がサイトを「記憶」する3つの経路と、それぞれの更新速度

リニューアルの影響を考えるには、まず「AIはどこから自社の情報を得ているのか」を分解する必要があります。経路は大きく3つあり、更新速度がまったく違います。

このうちリニューアルで直接コントロールできるのは①です。②は「待つ」しかなく、③は広報・外部リンク整理の領域です。つまり、リニューアル時の実務は「①を壊さないこと」に集中し、②③は公開後の観測と別施策で扱うのが正しい優先順位です。

なお、クローラーの役割分担は各社が公式に公開しています。OpenAIはGPTBot（モデル学習用）、OAI-SearchBot（ChatGPT検索のインデックス用）、ChatGPT-User（ユーザー操作起点の取得）を分けて運用しており、公式ドキュメントには「OAI-SearchBotをオプトアウトしたサイトはChatGPT検索の回答に表示されない」と明記されています。PerplexityもPerplexityBot（インデックス用）とPerplexity-User（ユーザー操作起点）を公開しています。GoogleのGoogle-ExtendedはGeminiの学習・グラウンディング利用を制御するトークンで、Google公式ドキュメントに「Google検索での登録やランキングシグナルには影響しない」と明記されています。AI OverviewsはGoogle検索の一部なので、通常のGooglebotとインデックス登録が前提です。

リニューアルで壊れやすい「AI検索資産」チェックリスト

通常のSEO移行では「順位のあるページ」「被リンクのあるページ」を守りますが、AI検索の観点では守るべき資産のリストが少し変わります。次の6つは、リニューアルの要件定義書に明示的に書かれていないと高確率で失われます。

このうちllms.txtについて補足すると、llms.txtはllmstxt.orgで提案されている仕様で、主要なAI検索プラットフォームが公式に採用を表明した事実は現時点で確認できていません。効果は仮説の段階ですが、設置済みであれば「消える」ことにメリットはないため、移行対象に含めておくのが妥当です。

土台はGoogle公式の「サイト移行」ガイダンス

AI検索特有の話に入る前に強調しておきたいのは、Google検索セントラルの「URL の変更を伴うサイト移転」ガイダンスが、AI検索の評価維持にとってもそのまま土台になることです。理由は単純で、AI Overviewsは Google検索インデックスの上に成り立ち、ChatGPT検索やPerplexityも独自クローラーで構築したインデックスを参照するためです。旧URLから新URLへのシグナル引き継ぎに失敗すれば、どのAI検索から見ても「情報源が消えたサイト」になります。

Google公式ガイダンスの要点は次のとおりです。

• リダイレクトはサーバーサイドの恒久的リダイレクト（301または308）を使う。
• リダイレクトは「一般的には1年以上」保持する。 この期間にGoogleは、旧URLを指す外部リンクの再クロール・再割り当てを含むシグナルの転送を行います。さらにGoogleは、ユーザーの観点からリダイレクトを無期限に保持することの検討も推奨しています。「リニューアルから3ヶ月経ったので旧ドメインを解約する」は公式推奨に反します。
• リダイレクトチェーンを避ける。 可能な限り旧URLから新URLへ直接リダイレクトし、やむを得ない場合もチェーンは5回未満に抑えます。
• 移行は段階的に行い、一度に行う変更は1つに絞る。 ドメイン変更・URL構造変更・CMS変更・デザイン刷新を同時に行うと、問題が起きたときに原因を特定できなくなります。

AI検索の観点で1点だけ補足します。OAI-SearchBotやPerplexityBotが301リダイレクトをどう処理するかについて、Googleほど詳細な公式仕様は公開されていません。ただし301はHTTP標準のリダイレクトであり、一般的なクローラーは追従します。「AIクローラーも301を辿って新URLを再インデックスする」ことを前提としつつ、公開後に実際のAI回答で旧URL・新URLのどちらが案内されるかを観測して検証する——これが公式仕様の空白を埋める実務判断です。

フェーズ別チェックリスト：要件定義から公開後まで

AI検索の観点を含めた移行チェックリストを、リニューアルの4フェーズに分けて示します。社内のリニューアル計画書やベンダーへのRFPにそのまま転記できる粒度にしています。

チェックリストの項目数は多く見えますが、大半は「通常のSEO移行手順に、AIクローラーとAI回答の観測を1列追加する」だけです。ゼロから別の移行プロセスを作る必要はありません。

よくある失敗例4つ：どこでAI検索の評価が消えるか

実際のリニューアルで起きやすい失敗を、原因と対策のセットで整理します。

失敗例1：モダンなフロントエンドに刷新した結果、AIクローラーが本文を読めなくなった

リニューアルでクライアントサイドレンダリング中心のフレームワーク構成に変え、初期HTMLがほぼ空になるケースです。GooglebotはJavaScriptをレンダリングしますが、AIクローラー各社は自社ボットのJavaScript実行能力を公式仕様として保証していません。JS実行なしで取得されるHTMLに本文が含まれない構成は、AI検索の情報源から自社を外すリスクを抱えます。対策は、SSRまたは静的生成で主要コンテンツを初期HTMLに含めることを要件定義に明記することです。確認は簡単で、JavaScriptを切ったブラウザで新サイトを開き、定義文・FAQ・会社概要が読めるかを見るだけです。

失敗例2：URL一括変更で、AIの回答が404ページを案内し続ける

ディレクトリ構造を全面変更し、リダイレクトマッピングが不完全なまま公開したケースです。厄介なのは、AI検索の回答には「取得時点のインデックス」が反映されるため、リニューアル後もしばらくAIが旧URLを引用・案内し続けることです。旧URLが404を返すと、AI経由で訪れた見込み顧客がエラーページに着地します。対策は、全ページ分の1対1マッピングと301設定、そして「AIの回答が旧URLを案内する期間がある」前提で旧URLを絶対に404のまま放置しないことです。これはGoogleがリダイレクトを1年以上、できれば無期限に保持するよう推奨している理由とも重なります。

失敗例3：テスト環境のnoindex・Basic認証が本番に残った

古典的ですが、AI検索時代には被害が拡大します。noindexやBasic認証が残ると、Googlebotだけでなく、OAI-SearchBotやPerplexityBotも新サイトを取得できません。検索インデックス経由のAI回答（前述の経路①）が全滅し、復旧後の再クロールにも時間がかかります。対策は、公開手順書に「noindex解除」「認証解除」「robots.txt差し替え」をチェック担当者名付きで入れ、公開直後にHTTPステータスとmetaタグを機械的に検証することです。

失敗例4：新環境のbot対策がAIクローラーを一律ブロックしていた

新サーバーやCDNのセキュリティ設定・WAFが、bot系のUser-Agentを一括で403にしていたケースです。robots.txt上は許可していても、サーバーレベルで拒否していればクローラーはコンテンツを取得できません。GPTBot・OAI-SearchBot・PerplexityBotなどはIPレンジを公式に公開しているため、ログで「どのボットが何のステータスを受け取っているか」を確認できます。対策は、公開後1〜2週間はサーバーログでAIクローラーのUser-Agent別ステータスコードを監視し、403・429の急増がないかを確認することです。

リニューアル後もAIの説明が古いままのときの対処

移行を正しく行っても、AIの回答がすぐに新しい情報へ切り替わるとは限りません。冒頭で整理した3つの経路ごとに、切り分けと対処が変わります。

まず、どの経路の問題かを切り分けます。 ChatGPT検索やPerplexityのように引用元URLを表示するAI検索で自社について質問し、(a)引用URLが旧URLのまま → 経路①（インデックス未更新）、(b)引用がなく古い説明だけが返る → 経路②（学習データ由来）の可能性、(c)引用元が第三者サイトで内容が古い → 経路③（外部言及）、と分類できます。

経路①（インデックス未更新）の場合は、301リダイレクトが正しく機能しているかの再確認、Search Consoleでのサイトマップ送信状況の確認、対象ページの内容更新（更新日と内容の実質的な変更はクロール優先度に影響し得ます）が打ち手です。時間経過で解決することが多い領域です。

経路②（学習データ由来の古い説明）は、サイト側から直接更新する手段がありません。ここで焦って対策サービスに飛びつく必要はなく、現実的な打ち手は「検索インデックス経由の情報で上書きされやすくする」ことです。会社概要・サービス説明などの一次情報ページを最新の内容で明確に保ち、AI検索が回答生成時にリアルタイム取得する情報の質を上げておけば、学習データの古さを検索結果が補正する構図を作れます。モデル自体の知識が更新されるのは次回以降の学習サイクルであり、これは待つしかない、と割り切るのが正確な理解です。

経路③（外部言及の古さ）は、旧URL・旧サービス名を記載している主要な外部サイトへの更新依頼、プレスリリースや公式発表によるリニューアル情報の外部露出が対処になります。

いずれの場合も、「同じ質問セットを定点観測する」仕組みがないと、改善したのか悪化したのかを判断できません。 質問セットの設計と記録方法は<a href="https://uravation.com/llmo/llmo-audit/">LLMO診断の記事</a>で詳しく扱っています。

まとめ：リニューアル計画書に「AI検索」の1章を足す

サイトリニューアルでAI検索の評価を失わないためのポイントを整理します。

• 土台はGoogle公式のサイト移行ガイダンス。301（または308）リダイレクトを全ページ1対1で設計し、1年以上（可能なら無期限）保持する。
• AIがサイトを記憶する経路は「検索インデックス」「学習データ」「外部言及」の3つで、更新速度が違う。リニューアル実務で守るのは検索インデックス経路。
• 定義ブロック・FAQ・会社概要・llms.txt・構造化データ・robots.txtのAIクローラー設定は、要件定義書に明記しないと失われる。
• 公開前はJS無効での本文確認とnoindex/認証解除、公開後はAIクローラーのログ監視と同一質問セットでの定点観測を行う。
• AIの説明が古い場合は経路を切り分ける。学習データ由来の古さは直接消せないが、一次情報ページの鮮度で検索経由の上書きを狙える。

リニューアル前の現状把握として、自社が今AIにどう説明されているかを移行前に記録しておくことは、費用のかからない最初の一歩です。自社での確認には<a href="https://uravation.com/llmo/#diagnosis">AI検索攻略のセルフ診断</a>が使えます。リニューアルの規模が大きく、移行設計の段階から専門的な確認が必要な場合は、<a href="https://uravation.com/contact/?ref=llmo_diagnosis&cta_type=llmo_audit">LLMO診断の相談窓口</a>からご相談ください。

EDITORIAL REVIEW AI検索攻略編集部（株式会社Uravation）

生成AI・AI検索・SEOの公開情報を確認しながら、企業サイトの情報設計として実務で扱える形に整理しています。仕様変更が多い領域のため、公開前後に公式情報と本文の整合性を確認します。