サイト移転のAIO対策｜GoogleのAI検索に備える公開前後の確認手順

サイト移転のAIO対策では、旧URLから必要な情報へたどり着けることと、新URLがGoogleの検索対象になれることを公開前後で確かめます。

ドメインやページの住所を変えるときは、転送設定に加え、本文、検索向けの設定、移転前の記録も引き継ぎます。

GoogleのAIによる概要（AI Overviews）とAIモード（AI Mode）は、回答に関連するウェブページへのリンクを表示する検索機能です。[1]

本稿では、この二つを対象に、Web担当者と制作会社が移転の確認表を作る手順を説明します。

記述は2026年10月13日に確認したGoogleの公式資料に基づき、確認表や担当者の分担は運用上の提案として示します。

実際のサイト移転やSearch Consoleの実アカウントで検証した成功事例ではありません。

移転で必要なAIO対策の範囲を決める

移転時のAIO対策は、Googleがページを読み取り、検索やAI回答のリンク候補として扱える状態を引き継ぐ作業から始めます。

AIO対策は、AIを使った検索で情報を見つけてもらうための取り組みを指します。

ただしGoogleは、AIによる概要やAIモードへの掲載に、通常の検索とは別の特別な最適化は必要ないと説明しています。[1]

そこで最初に、ドメイン、ページのURL、本文、配信サーバーのどこを変えるかを書き出します。

URLは同じでも、公開先で本文が欠けたり、検索を拒む設定が残ったりすれば点検が必要です。

移転を予定していないサイトの全体点検は、AIO対策のチェックリストで確認できます。

本稿の確認表では、移転するURLと変更する設定を一組にして管理します。

GoogleのAI検索に載る条件と移転時の確認点

GoogleのAI検索で関連リンクとして表示されるには、ページがインデックス登録され、スニペット付きで検索結果に表示できる必要があります。[1]

インデックス登録は、Googleが検索に使う情報としてページを登録することです。

スニペットは、検索結果でページ名に添えられる短い説明を指します。

移転先を開けるだけでは、この二つを確認したことにはなりません。

新URLへアクセスできるか、必要な本文を読めるか、意図しない検索除外や表示制限がないかを順に調べます。

例えば会社のサービス紹介を移すなら、サービス名だけでなく、対象者や利用条件まで新ページに残っているかを読みます。

これは説明用の例で、特定企業の実績ではありません。

公開後はSearch ConsoleというGoogleのサイト管理ツールで、新URLの登録情報を確認します。

そのうえで、AI検索の表示は別の記録として追います。

Googleは要件を満たした場合でも、クロール、登録、検索表示を保証していません。[1]

設定確認の合格を「移転後も必ず引用される」という約束に変えないことが必要です。

URLを変える移転と変えないリニューアルを分ける

URLが変わる移転では旧新URLの対応と転送を用意し、変わらない場合は配信先や表示内容の確認を中心に進めます。[2][10]

リニューアルという呼び名だけでは、必要な作業を決められません。

実際に利用者が開く住所を比べると、作業の違いが分かります。

変更するもの	URLへの影響	主に確認すること
ドメイン	サイトの住所が変わる	旧新の対応、転送、所有権
ページのパス	同じドメイン内でも住所が変わる	ページごとの対応と内部リンク
配信サーバー	同じURLを使う場合がある	新しい配信先の接続、本文、画像
デザイン	設計により異なる	URL変更の有無と本文の表示

例えばデザイン変更でも、記事URLの末尾が変わればURL移転として扱います。

反対に、配信サーバーを替えるだけなら、存在しないURL変更のための転送を追加する必要はありません。

URL不変の移転では、新しい配信先でページやダウンロードが動くかを試し、切り替え後の旧新サーバーへのアクセスを確認します。[10]

対応表の最初の列に「URL変更あり・なし」を置き、設定担当との認識をそろえます。

ドメイン・CMS・デザインの変更を分けて進める

ドメイン移転、CMS変更、デザイン変更は、可能なら一つずつ進めます。

CMSは、記事や商品ページを管理する仕組みです。

Googleは、複数の変更を同時にまとめず、順番に実施することを勧めています。[2]

例えばドメインだけ先に移し、その後に見た目を変える順序を検討します。

一度に本文まで大きく書き換えると、公開後に問題が起きた際、URLの切り替えと内容変更を切り分けにくくなります。

大規模なサイトでは、技術的に可能なら一部を先に移す方法も案内されています。[2]

先行する範囲は、更新が少なく、突発的な出来事の影響を受けにくい部分が候補です。

ただし、一部で問題がなかったことを、サイト全体の移転が安全という証明にはできません。

工程表には、変更範囲、設定担当、確認担当、切り替え時刻、復旧を判断する人を記載します。

これは当社の運用提案です。

同日に実施する必要がある変更も、作業記録は分けて残します。

不具合を見つけたときに、どの設定を誰へ確認すればよいかまで決めておきます。

移転前に旧URLとAIO対策の基準値を保存する

移転前に残すのは、旧URLの一覧と、その時点で取得できる検索・AI表示の記録です。

新サイトの公開後に集め始めると、以前の本文や設定と比べる材料が足りなくなります。

まず移転対象の一覧を作り、元の取得データを変更せずに保存します。

次に、作業用の表へ新URL、引き継ぐ内容、確認結果を追加します。

検索での表示回数と、実際のサイト訪問は別の数字として扱います。

Googleの生成AIレポートは、AI検索でリンクが表示された回数を確認するための資料です。[11][12]

レポートを取得できない場合は、その理由と確認日を残し、空欄をゼロへ置き換えません。

保存先は担当者が共通で参照できる場所に決め、対象サイト、期間、取得日が分かる名前にします。

過去の状態を残すことと、移転後の成果を証明することを分けて準備します。

CMS・サイトマップ・ログから旧URLを集める

旧URLはCMSの一覧だけでなく、サイトマップ、アクセス記録、リンク情報を突き合わせて集めます。[2]

サイトマップは、検索エンジンへページの所在を伝えるファイルです。[7]

CMSの現行一覧から消えていても、外部からリンクされ、利用者が開くURLは残る可能性があります。

次の順で取得元をそろえると、一覧の抜けを調べやすくなります。

1. CMSから公開ページのURLを取り出します。
2. 現行サイトマップに載るURLと照合します。
3. 配信サーバーのアクセス記録や解析ツールで、使われているURLを追加します。
4. Search Consoleのリンク情報から、内部・外部リンクのあるページを確認します。
5. 画像、動画、PDFなどの参照先も移転対象へ含めます。

取得方法はCMSや配信環境によって異なるため、担当者へ一覧の書き出しを依頼します。

その際は、対象期間と、非公開ページを含むかも明記します。

アクセス記録の対象期間は、サイトの季節変動を考慮して選びます。[2]

短い期間にアクセスがなかったという理由だけで、ページを廃止候補にしません。

一覧には取得元も残し、何を調べた範囲のURLなのかを追えるようにします。

生成AIレポートと手動確認を移転前に残す

移転前のAI表示は、Search Consoleの生成AIレポートと、質問して確認した結果を分けて保存します。

Googleは生成AIレポートで、AIによる概要とAIモードの表示回数を確認できると説明しています。[11][12]

公式ヘルプのレポート入口から、権限のある対象サイトを開きます。

期間を選び、ページ、国、端末など、比較に使う区切りを確認します。

次にエクスポート機能でグラフと表のデータを保存し、選んだ条件も別途記録します。[12]

ダウンロードでは、画面の「~」「-」がゼロになるため、利用できない値だったことも残します。[12]

手動確認では、質問文、AI機能、日時、表示されたリンク、実際に開いたURLを記録します。

例えば移転対象のサービスを探す質問を選び、後日も同じ質問で確認します。

一回の回答は、その時点の観測として扱います。

レポートの表示回数も手動で見つけたリンクも、訪問数や成約数ではありません。

レポートが出ない場合は、表示回数が十分でない可能性などを公式ヘルプで確認し、「表示なし」と記録します。[12]

旧URL・新URL・引き継ぐ内容を対応表にする

URL対応表には、転送先だけでなく、新ページへ残す説明と未確認項目を記載します。

Googleの移転ガイドも旧URLと新URLの対応を準備する手順を示しています。[2]

次の表は、その作業を担当者間で進めるための記入項目の提案です。

項目	記入する内容
旧URL・新URL	省略しない完全な住所
ページの扱い	維持、統合、廃止のいずれか
引き継ぐ説明	読者の問い、対象者、利用条件、根拠
設定予定	転送方法と公開時の制限変更
実測結果	応答、最終URL、本文の確認結果
担当・確認日	作業者、確認者、確認した日時
未解決項目	未定の内容と次に確認する人

例えばサービス説明を統合する場合は、「統合」とだけ書かず、旧ページの利用条件を新ページのどこで読めるかを記します。

これは記入方法の例で、実施済みの移転記録ではありません。

新URLが未定なら「未定」、応答を測っていなければ「未検査」とします。

設定予定の欄に301と書いてあっても、実際の応答を確認するまでは完了にしません。

表の一行から、公開予定と確認できた事実の両方をたどれる状態にします。

新URLへ引き継ぐ本文と参照先を点検する

新ページでは、旧ページが答えていた問いと、その答えに必要な条件・根拠を読める状態にします。

同じタイトルのページがあっても、説明が抜けていれば内容の引き継ぎは終わっていません。

GoogleはAI検索でも、重要な情報を文字で提供し、利用者に役立つ内容を用意することを案内しています。[1]

比較するときは、旧新ページを並べて、対象者、サービスの範囲、利用条件、参照資料を読みます。

文章を一字ずつ一致させることや、見出し数を維持することが、AI引用を保つ条件という意味ではありません。

古くなった説明は、現在の根拠に合わせて更新します。

対応表には、残した内容、更新した内容、廃止した理由を短く記します。

ページの所在を変える作業と、説明の正しさを確かめる作業の両方を終えてから、本文の確認欄を埋めます。

旧ページの問い・条件・根拠が新ページに残るか

本文の比較では、読者が判断に使う情報を項目ごとに確認します。

例えばサービス紹介なら、「誰が使えるか」「何を頼めるか」「どの条件で料金が変わるか」を新ページでも説明できるかを見ます。

この例は確認方法を示すもので、特定の料金や成果を仮定していません。

旧ページの見出しだけでなく、注記、表、参照リンクも比較の対象です。

新デザインで表を削った結果、対象外の条件まで消えていないかを確かめます。

数値を残す場合は、その出典と対象期間が新ページにも対応している必要があります。

更新日を表示する場合も、実際に確認した内容と一致させます。

重要情報を文字で提供するというGoogleの案内を踏まえ、図だけに残った説明は本文にも置きます。[1]

設定担当には、単に「本文移行済み」ではなく、比較した項目と差分を渡します。

内容を更新する人と表示を確認する人が別なら、どちらが未完了かを記録します。

新しい本文を読んでも利用条件を判断できない箇所は、元資料へ戻って補います。

移転のために、古い説明をそのまま正しいものとして再公開しないようにします。

ページ統合と廃止で転送先の判断を変える

統合した内容に対応する新ページがあれば転送先にし、対応する内容がなければ適切な削除応答を検討します。[2]

リダイレクトは、旧URLへのアクセスを別のURLへ転送する仕組みです。

複数の旧ページを一つへまとめる場合も、新ページで元の問いに答えられるかを読んでから設定します。

例えば二つのサービス説明を統合するなら、それぞれの対象者や提供条件が統合先で区別できるかを確認します。

無関係な旧URLをすべてトップページへ送る方法は避けます。

Googleの移転ガイドも、関連しない多数の旧URLを一つの移転先へ転送しないよう案内しています。[2]

廃止したページに代わる内容がない場合は、ページがないことを示す404や、削除済みを示す410などの応答を設定担当と確認します。[2][9]

エラー表示の文面を作るだけでなく、サーバーの実際の応答も確かめます。

対応表には、統合先と内容の対応、または廃止理由を残します。

既にリンク切れが発生している場合の調べ方は、AI経由のリンク切れを直す確認手順で補足しています。

画像・PDF・ダウンロード先も移転対象に含める

本文から開く画像やPDFも、旧URLの一覧と新しい参照先の確認に含めます。

Googleの移転ガイドは、画像やダウンロード資料の移行も準備事項に挙げています。[2]

本文だけ新サイトへ移しても、資料のリンクが旧サーバーに残る場合があります。

旧環境を終了する前に、ページ内の画像、資料へのリンク、ダウンロード後のファイルを開きます。

確認するのは、ファイルを取得できることと、中身が意図した版であることです。

同じファイル名であっても、古い内容や別の言語の資料を配信していないかを読みます。

外部サービスで配信する資料なら、本文のURLと公開範囲も担当者に確認します。

ログインが必要な資料を、移転の都合だけで公開へ変更する必要はありません。

公開する予定の情報と、制限を残す情報を対応表で分けます。

料金や対象条件など、ページを読むために重要な説明は文字でも提供します。[1]

画像があることだけで説明を引き継いだとせず、代替テキストや本文の説明も確認します。

最後に、新ページから必要な資料へ実際に進めることを確認し、ファイルの担当者と確認日を残します。

公開前のAIO対策でクロールとURL指定を確かめる

公開前には、新ページを読めるか、検索を拒む設定が残っていないか、正規URLの指定が新しい住所にそろっているかを確かめます。

クロールは、Googleなどの仕組みがページへアクセスして情報を取得することです。

開発中のサイトでは、公開前の情報を守るため、認証や検索除外を設定している場合があります。

公開時に外す設定と、そのまま残す制限を一覧にします。[2]

すべての拒否設定を一括で解除するのではなく、一般公開するページを対象に切り替えます。

新サイトのテンプレートや配信設定は、複数のページへ同じ影響を与えます。

トップページだけでなく、記事、商品、サービス説明など、実際に使う種類ごとに確認対象を選びます。

設定の確認は準備環境で終わりにせず、切り替え後の本番URLでも同じ項目を確かめる予定にします。

開発中の認証・robots.txt・noindexを確認する

開発中の制限は、認証、配信側の拒否、robots.txt、noindexを別々に確認します。

robots.txtは、クローラーへアクセスしてよい範囲を伝えるファイルです。

noindexは、対応する検索エンジンにページを検索結果へ登録しないよう伝える設定です。[8]

名前が似た目的で使われても、確認する場所と働きが異なります。

確認する場所	公開対象で調べること
開発用の認証	閲覧時に不要なログインを求めないか
配信・防御の設定	Googleのアクセスを意図せず拒まないか
robots.txt	公開するURLを遮断していないか
ページのHTML	noindexが残っていないか
HTTP応答ヘッダー	X-Robots-Tagにnoindexが残っていないか

HTMLはページを構成する記述、HTTP応答ヘッダーはサーバーが本文とともに返す情報です。

Googleがnoindexを読むには、そのページへアクセスできる必要があります。[8]

robots.txtで遮断したままでは、ページ内のnoindexを読み取れません。

公開するURLと残す制限を設定担当へ渡し、変更後の実際の応答とページ内容を確認します。

本文の文字情報とスニペット制限を点検する

新しい見た目でも重要な説明を文字で読めるか、検索表示の制限が意図どおりかを確認します。

Googleは、重要な内容のテキスト提供と、構造化データが表示本文に合うことを案内しています。[1]

構造化データは、商品や記事などの情報を検索エンジンへ伝えるための記述です。

デザインの変更で説明を画像にまとめた場合も、利用条件や判断に必要な情報は本文に残します。

Search ConsoleのURL検査では、取得されたHTMLや、ライブテストで描画されたページを確認できます。[5]

画面で見える本文と、取得された内容の両方を比べます。

スニペットの制限には、nosnippet、data-nosnippet、max-snippetなどがあります。[1]

設定担当には、新テンプレートでこれらを追加・変更していないかを確認します。

以前から意図して制限していた情報を、掲載を増やす目的だけで勝手に解除しません。

GoogleのAI検索向けに、専用のAIテキストファイルや特別な構造化データを新しく用意する必要はありません。[1]

追加ファイルの有無より先に、現在の本文と表示制限が公開方針に一致しているかを確かめます。

canonical・内部リンク・サイトマップを新URLにそろえる

新ページのcanonical、内部リンク、サイトマップは、公開する新URLへそろえます。[2][4]

canonicalは、内容が重複するページの中で、代表として扱ってほしいURLを伝える指定です。

新URL自身を指定する自己参照canonicalも確認します。

例えばページは新ドメインで開けても、テンプレートに旧ドメインの指定が残ると、住所の案内が食い違います。

次の項目をURL対応表と照らし合わせます。

1. canonicalが意図した新URLになっているか。
2. 本文やメニューの内部リンクが新URLを指すか。
3. サイトマップに検索へ出したい新URLを載せているか。
4. hreflangを使っている場合、各言語・地域の対応先も更新したか。

hreflangは、別言語や別地域向けのページを伝える指定です。[2]

canonicalは希望を伝えるもので、Googleが実際に選択するURLとは分けて確認します。[4][5]

検索から外すnoindexを、代表URLを選ぶ代わりに使いません。[4]

重複ページの詳しい整理は、商品ページの正規URLをそろえる方法も参照できます。

URL移転の転送設定を検査する

転送設定は、旧URLを開いた結果が対応表どおりになるかを、実際の応答と移転先の本文で検査します。

リダイレクトは、旧URLへのアクセスを別のURLへ案内する仕組みです。

設定ファイルを保存しただけでは、公開環境で正しく動くかは分かりません。

Googleは、URLの対応を用意し、転送を実装してからテストする手順を示しています。[2]

検査では、旧URLが返す状態、途中で通るURL、最後に開くページを一組で残します。

最後のページが開けても、必要なサービス説明や資料がなければ内容の確認は未完了です。

また、新URLを直接開いた結果だけでは、旧リンクからの移動を確かめたことになりません。

転送の経路は設定担当、本文の引き継ぎは編集担当が確認し、両方の結果を同じ対応表に記録する運用を提案します。

恒久移転は301・308で対応先へ直接つなぐ

恒久的にURLを移す場合は、サーバー側の恒久リダイレクトを使い、301または308の応答で対応先へつなぎます。[2][3]

301と308は、ページが恒久的に移転したことを示すHTTPステータスコードです。

HTTPステータスコードは、ページの要求に対してサーバーが返す処理結果を表します。

Googleは、これらを新しいURLを正規のページとして扱う強いシグナルとして使います。[3]

ただし設定した瞬間に、検索上のURLがすべて更新されるという意味ではありません。

旧記事を新記事へ移す場合は、その新記事へ直接転送する設定を確認します。

過去の転送先を経由して新サイトへ向かう形が残っていれば、最終的な対応先へ更新します。

Googleは、転送の連鎖を避け、可能な限り最終目的地へ直接転送することを勧めています。[2]

一時的な移動には302や307など別の扱いがあるため、移転の目的と応答を一致させます。[3]

サーバーやCMSごとに設定方法は異なるので、管理画面の項目名よりも実際に返る応答で確認します。

誤った転送先・連鎖・ループを一覧で調べる

転送の検査では、誤った行き先、複数段階の転送、同じURLへ戻るループを分けて記録します。

Googleの移転ガイドは転送のテストを求め、HTTP応答の資料では過剰な連鎖やループによるエラーを説明しています。[2][9]

一つの代表ページだけが動いていても、他のURLの設定まで正しいとは判断できません。

対応表にある旧URLを対象に、検査ツールやサーバーの確認方法で実測します。

次の表は、結果を整理するための記入様式の提案です。

確認欄	記録する内容	修正を検討する状態
最初の応答	実際のステータスコード	恒久移転なのに意図と違う応答
転送経路	途中で通るURL	不要な経由先や同じURLへの戻り
最終URL	最後に開いた住所	対応表と異なるページ
最終応答	移転先の応答結果	エラーや利用できないページ

空欄は未確認として扱い、予定している値を実測欄に入れません。

修正後は同じ旧URLから再検査し、結果と確認日時を更新します。

通常のページだけでなく、画像やPDFの移転も対応表に含めて調べます。[2]

転送経路と移転先の本文を別々に確認する

転送経路の検査が通ったら、最終ページをブラウザーで開き、本文と資料へのリンクを読みます。

HTTPの200応答は取得の成功を示しますが、Googleでの登録や、そのページが求める情報を含むことまでは保証しません。[9]

例えば料金説明の旧URLから新ページへ移動できても、適用条件が落ちていれば編集上の修正が必要です。

これは確認方法を示す仮の例であり、実際の移転結果ではありません。

対応表に残した問い、対象者、条件、根拠を新ページと突き合わせます。

Search ConsoleのURL検査では、新URLを直接指定して現在の取得状態や登録情報を調べます。[5]

URL検査の結果だけを、旧URLからの全転送経路を確認した証拠にはしません。

転送経路はHTTP応答で、本文は画面と取得内容で、それぞれ確認した手段を残します。

AIの回答に載ったリンクがすでに開けない場合の切り分けは、AI流入先のリンク切れ確認も参照できます。

移転前の準備では、既存の不具合を直す作業と新しい転送の検査を別欄にすると、未解決の対象を追いやすくなります。

移転当日の作業と公開判断をそろえる

移転当日は、新サイトを利用できる状態にしたうえで転送を検査し、該当するSearch Consoleの手続きを進めます。

所有権の確認や転送先の決定を当日初めて始めると、公開の判断に必要な材料が不足します。

公開前の確認表を当日の工程表へ移し、作業順と結果を残せるようにします。

Googleの移転ガイドは、新サイトの準備、URL対応、転送、監視という流れを示しています。[2]

ここでは、その流れに担当者、確認時刻、未解決事項、判断者の欄を加える運用を提案します。

作業済みという連絡と、実際のURLで確かめた結果は分けて記録します。

重要なページが開かない場合は、検索表示の変化を待つ前に対応が必要です。

一方、公開直後に検索の登録情報が古いだけで、移転全体を失敗と決めることは避けます。

旧サイトと新サイトの所有権・接続を確認する

Search Consoleで旧サイトと新サイトの所有権を確認し、移転後も検証に必要な設定を保ちます。[2]

所有権の確認は、そのサイトを管理できることをGoogleへ示す手続きです。

検証用のファイルやタグを使っている場合、CMSの入れ替えで消えていないかを調べます。

Googleは、両サイトの確認に加え、必要に応じてHTTP・HTTPSやwwwの有無などのバリエーションも考慮するよう案内しています。[2]

アドレス変更ツールを使う場合は、旧新両方のプロパティで、同じGoogleアカウントが確認済みの所有者である必要があります。[6]

権限があるはずという認識で済ませず、担当者が対象を開けることを実際のアカウントで確認します。

接続については、旧URLからの転送と新URLのHTTPS接続が利用できるかを調べます。

旧ドメインや証明書の管理担当も工程表に残します。

本稿は公式手順の解説であり、特定サイトの所有権や接続を確認済みと報告するものではありません。

実施するサイトでは、確認したプロパティ名、担当者、日時を記入し、未確認の権限を完了扱いしません。

転送・新サイトマップ・アドレス変更の適用順を確認する

新サイトを準備して転送を有効にしたら、旧URLから対応先へ到達できるかを確かめます。[2]

その後、対象となる移転でアドレス変更ツールを使い、新URLを載せたサイトマップを送信します。[2][6]

サイトマップは、検索エンジンへページの所在を知らせるファイルです。

送信だけで、すべてのURLのクロールや登録が保証されるわけではありません。[7]

アドレス変更は、サイトの住所が変わったことをGoogleへ伝える手続きです。

適用の要否は、次の区別に沿って確認します。[6]

移転の内容	アドレス変更ツール
別ドメインへの移転	対象となる条件を確認して使う
サブドメインの移転	対象となる条件を確認して使う
HTTPからHTTPSへの変更	使わない
wwwあり・なしの切り替え	使わない
同じドメイン内のパス変更	使わない
URLを変えない配信先変更	使わない

対象の移転でも、この手続きは転送設定の代わりにはなりません。

事前条件を満たしてから実行し、提出内容と処理結果を工程表へ残します。

ツールを使わない移転も、新URLや配信先の確認を省略してよいわけではありません。

未解決項目があるときの公開延期・修正判断を決める

公開の判断は、予定した時刻だけでなく、重要なページを利用できるかで決めます。

ここで示す判断表は編集上の提案であり、Googleが定めた公開承認の制度ではありません。

例えば、問い合わせへ進む主要ページが開かない場合は、影響範囲を確認し、修正または公開延期を判断します。

解除する予定のnoindexが残る、旧URLの対応先が決まらない、重要な説明が欠ける場合も、未解決事項に残します。

Googleは、移転前に新サイトを準備し、開発時の制限などを確認するよう案内しています。[2]

次の項目を一つの記録にまとめます。

1. 影響するURLと、利用できない情報。
2. 公開を待つか、修正して再検査するかの判断。
3. 対応する担当者と、結果を確認する担当者。
4. 次に確認する時刻と、判断の根拠。

サーバーのエラーは、応答内容と影響範囲を調べて対応します。[9]

移転中は検索順位が一時的に変動し得るため、順位の動きだけで自動的に旧サイトへ戻す基準にはしません。[2]

公開を進める場合も、残った課題を消さず、後続の確認表へ引き継ぎます。

移転後のAIO対策を技術状態とAI表示で確認する

公開後は、現在のページ、Googleの登録情報、生成AIレポート、手動で見たAI回答を別々に記録します。

四つの情報は確認できる対象が違い、一つの結果ですべてを判断できません。

例えば現在のページを修正しても、Googleの登録情報には前回取得した内容が残っている場合があります。[5]

また、生成AIレポートで表示回数を確認できても、特定の質問に毎回同じ回答が出ることを意味しません。[1][12]

対応表には、観測した事実、確認した日時、比較条件、次の作業を残します。

移転と同時に本文や商品構成を変えた場合は、その変更も別欄に書きます。

表示回数の増減だけから、移転の効果や失敗を断定しないためです。

設定上の不具合を直す作業と、検索側の変化を継続して観測する作業を、同じ記録で追える形にします。

公開URLの状態とGoogleの登録情報を比べる

新URLの現在の状態はライブテストで、Googleが持つ登録情報はURL検査の通常の結果で確認します。[5]

通常の結果は、Googleが最後に取得した版に基づくため、現在の画面と同じとは限りません。

次の項目を別々の欄で残します。

記録する項目	確かめること
ライブテスト	現在のURLを取得できるか
前回のクロール	Googleがいつ取得したか
インデックス登録	Googleの登録情報での状態
Googleが選択した正規URL	どのURLが代表として扱われているか

ライブテストの成功だけで、登録済みや正規URLの確定とは判断しません。[5]

ページを修正した場合は、必要に応じてインデックス登録をリクエストします。

ただし、依頼は登録完了や掲載時期を保証するものではありません。[5]

多くの新URLを知らせる場合は、サイトマップも利用できます。[7]

旧URLと新URLのどちらを検査したかを明記すると、転送元の情報と移転先の登録状態を混同せずに済みます。

結果が更新されていない場合も、推測で確認済みに変えず、観測した内容と次の確認予定を残します。

生成AIレポートは新旧URLと同じ条件で比較する

生成AIレポートを比較するときは、旧新URLの対応に加え、国、端末、期間をそろえます。[12]

ページ別の表示回数は転送後の最終URLに割り当てられ、多くの場合は正規URLが集計先になります。[12]

旧URLの数値だけを見ると、新URL側へ移った記録を見落とす可能性があります。

ページ統合がある場合は、対応表で複数の旧ページと新しい一つのページの関係を確認します。

日付は太平洋時間を基準に扱われるため、日本時間の切り替え時刻と混同しません。[12]

直近のデータには暫定値が含まれることがあり、比較時点も残します。[12]

グラフと表ではプロパティ単位・ページ単位など集計方法が異なる場合があるため、合計を無条件に一致させようとしません。[12]

表示回数が十分でないサイトではレポート自体が表示されないこともあり、その状態を表示回数ゼロと記録しません。[12]

移転前に保存できなかった値は「基準値なし」として扱います。

このレポートの表示回数は、訪問数や問い合わせ数を表すものではありません。[11][12]

エラーと本文欠落を先に直し、AI表示は継続確認する

AI検索での表示が減った場合も、まず旧URLの応答と新ページの本文を確認します。

利用者が開けないページや欠けた説明があれば、表示回数の解釈より先に修正対象を特定できます。

旧URLの転送先、移転先の内容、検索を制限する設定、Googleのクロール情報という順で照合する方法を提案します。

設定や本文を直したあとは、同じURLを再検査し、修正前後の結果を残します。

Googleの移転ガイドも、旧新サイトのトラフィックとクロールの監視を案内しています。[2]

手動でAI回答を調べる場合は、移転前の記録と同じ質問を用い、機能名、日時、回答内のリンク先を記録します。

AIによる概要やAIモードでは使う仕組みが異なり、回答やリンクも変わり得ます。[1]

一度の手動確認で見つからないことを、全利用者に表示されなくなった証拠にはしません。

期間や条件をそろえたレポートと手動記録を併せて見ても、季節性や他の変更が混じる場合は原因を確定できません。

確認表には「移転が原因」と推測を書き込む前に、観測できた事実と未確認の点を分けて残します。

サイト移転のAIO対策でよくある質問

移転後も、旧URLを支える運用と、検索やAI回答の変化を確かめる運用が続きます。

公開当日の作業が終わっても、旧ドメインや転送を直ちに終了する判断にはつながりません。

Googleは、移転の処理に必要な期間と、利用者が古いリンクを使う場合の両方を考慮して転送を維持するよう案内しています。[2]

また、AI回答に旧URLが見えることと、そのリンクから情報へ到達できないことは、分けて調べる必要があります。

最後に、旧ドメインの維持、古いリンクの扱い、Google以外への適用範囲を整理します。

これらの判断も、担当者と次回確認日を対応表に残すと、公開後の作業を引き継げます。

確認済みの範囲を明記し、別サービスの表示や将来の掲載まで保証する表現は避けます。

旧ドメインとリダイレクトはいつまで残すか

Googleのサイト移転ガイドでは、リダイレクトをできるだけ長く、一般に少なくとも一年は維持することを勧めています。[2]

利用者のためには、より長期間、あるいは無期限に残すことも検討するよう案内されています。[2]

古い資料や外部サイトのリンクからアクセスする人がいる可能性を、契約や設定の維持判断に含めます。

アドレス変更ツールの案内には百八十日という期間がありますが、これを全転送の終了期限として扱いません。[6]

ツールの手続きと、旧URLから利用者を案内する転送は別の役割を持ちます。

旧ドメインを維持する担当者、契約更新、HTTPS接続、転送の動作を確認表に残す運用を提案します。

サーバー構成を整理する場合も、旧URLから新URLへの案内が残るかを先に確かめます。

アクセスが少ないことだけで、過去のリンクが不要になったとは判断しません。

終了を検討する際は、その時点の公式資料と利用状況を確認し、残るリンクへの対応を含めて判断します。

一年が過ぎればすべてのサイトで安全に転送を消せる、という保証はありません。

AIの回答に旧URLが残っていたら移転失敗か

AI回答に旧URLが残っているという観測だけで、移転全体の失敗とは判断できません。

まず、そのリンクから新しい適切なページへ到達できるかを確認します。

次に、新ページの本文、検索制限、Googleの登録情報を調べます。[1][2]

恒久リダイレクトは新URLを正規として扱う強いシグナルですが、表示がその場ですべて切り替わる保証ではありません。[3]

手動確認の記録には、質問、AI機能、日時、表示されたURL、実際の到達先を残します。

到達できない場合は転送やページの不具合として扱い、到達できる場合はリンク表示の観測として分けます。

この区別があれば、修正担当へ渡す内容も具体的になります。

ただしリンクが開けるだけで、AI検索の表示が以前と同じと確認できたことにはなりません。

GoogleはAI検索への掲載を保証していないため、旧URLが何日で消えるかや、表示がいつ回復するかを本稿では断言しません。[1]

設定を変える場合は観測記録と照合し、理由のない転送先変更を繰り返さない運用を提案します。

Google向けの移転確認でChatGPTなども確認済みになるか

Google向けの確認だけで、ChatGPTなど他のAIサービスまで確認済みにはできません。

本稿で一次出典により裏付けた対象は、GoogleのAIによる概要とAIモードです。[1]

旧リンクからページを開けるかという利用者側の確認はできますが、各サービスが情報を発見し、回答にリンクを載せる条件は別に調べる必要があります。

他のサービスの確認欄は、実際に調べるまで未確認のままにします。

Googleの表示回数を、別のAIサービスでの引用回数へ読み替えることもできません。

サービスごとの調べ方を整理する際は、AIO対策のチェックリストで確認範囲を見直せます。

移転の運用では、対象サービス、調べた質問、日時、見つかったリンクを分けて残します。

全AIでの引用維持を一括して約束せず、確認できた事実から次の修正を決めます。

まずは旧新URLの対応表に、本文、転送、登録情報、AI表示の確認欄を用意し、担当者と未確認項目をそろえるところから進めます。