サイトリニューアルのSEO：URLの転送で検索への影響を抑える手順とAI検索で確かめること

サイトリニューアルでURLが変わるときは、古いURLから新しいURLへの転送（リダイレクト）が、検索での評価を新しいURLへ引き継ぐ土台になります。Googleは、古いURLと新しいURLの対応表を作り、サーバー側の永続的なリダイレクト（301など）で、対応する新しいURLへつなぐことを勧めています。デザインやドメイン、URLの形を一度に全部変えず、変更を分けることも、影響を抑えるための大事な考え方です。ただし、正しく転送しても、移転中は順位が一時的に変動することがあるとGoogleは書いています。

この記事では、次のことがわかります。

• リニューアルで検索の評価が落ちやすい理由と、URLが変わらないときとの違い
• Googleがサイトの移転について公式に勧めていること
• 古いURLと新しいURLの対応表の作り方と、転送の決め方（消すページ・まとめるページを含む）
• AIによる概要・AIモードや、ChatGPTの検索での見え方で確かめること
• 公開前と公開後に確かめること（チェックリスト）

リニューアルで評価が落ちやすい理由：URLが変わるかどうかで変わる

Googleの検索結果に出ているのは、ページの「URL」です。リニューアルでURLが変わると、Googleは新しいURLを見つけて、改めてクロール（読みに来ること）とインデックス登録をし直す必要があります。古いURLに、外部のサイトからのリンクや、お気に入り、名刺・パンフレットのQRコードなどが向いていることもあります。転送がないと、そうした訪問はエラーのページで止まってしまいます。

Googleは、URLが変わる移転の例として、次の3つを挙げています。

• HTTPからHTTPSへの変更
• ドメイン名の変更（例：example.comからexample.netへ）や、複数のドメインの統合
• URLのパスの変更（例：/page.php?id=1から/widgetへ）

一方で、サーバーやホスティングの会社を変えるだけで、URLが変わらない場合は、手順が違います。Googleは別の文書で、DNSのTTL（設定が行き渡るまでの保存時間）を移転の少なくとも1週間前に下げることを検討する、作業中に入れたクロールの禁止を外す、といった点を挙げています。また、ホスティングを変えた直後にGooglebotのクロールの頻度が一時的に下がるのは通常の動作だとしています。

リニューアルでは、デザインだけ変えてURLは同じ、ということもあります。まず、今回のリニューアルでURLが変わるのか（ドメイン・HTTPS・パスのどれか）を、制作会社と一緒に確かめることが出発点です。

Googleの公式の説明：対応表と、永続的なリダイレクト

Googleの「サイトを移転する方法」は、URLが変わる移転の流れを、新しいサイトを準備して十分にテストする、古いURLから新しいURLへの対応表を作る、サーバーでリダイレクトを設定して移転を始める、新旧両方のURLのトラフィックを見る、の順に説明しています。対応表について、Googleは「元のサイトの URL から新しいサイトの URL へのマッピングは重要な項目です。」と書いています。

リダイレクトの種類については、技術的にできるならサーバー側の永続的なリダイレクトを使い、301や308を勧めています。永続的なリダイレクトは、Googleにとって、転送先が正規の（代表の）URLだという合図になり、検索結果に転送先が出ます。一時的なリダイレクト（302・307など）では、Googleは転送先を正規のURLとする合図には使わず、検索結果に元のURLが残りやすくなります。元に戻す予定がない転送には、永続的なリダイレクトを使います。

評価の引き継ぎについて、Googleは次のように書いています。

301 や その他の永続的なリダイレクト によって PageRank の損失が生じることはありません。

ただし、これは「転送すれば順位がまったく変わらない」という意味ではありません。Googleは、移転中は掲載順位が一時的に変動することがあり、通常のことで、時間とともに安定するとしています。小規模から中規模のサイトで大半のページの移転が反映されるのに数週間かかり、大規模なサイトではそれより長くかかる、という目安も示しています。

変更は一度に1つずつ

Googleは、サイトの変更を1つずつ順に行い、すべてを同時に変えないよう計画することを勧めています。ドメインを変える移転について、Search Consoleのヘルプには次の注意があります。

サイトの移転と、新しい場所でのサイトのコンテンツや URL 構造の再設計を組み合わせると、Google が個々のページを再学習し再評価する必要があるため、トラフィック損失が発生する可能性があります。

リニューアルでは「ドメインも、CMSも、デザインも、URLも、文章も一度に新しく」となりがちです。予算や日程の都合で一度に行うこともありますが、その場合は、検索からの訪問が一時的に動く可能性を、関係者で前もって共有しておくのが現実的です。なお、小規模・中規模のサイトでURLを変えるときは、区分ごとに分けるより、すべてのURLを一度に移すことをGoogleは勧めています（大規模なサイトは区分ごとの移転も勧めています）。「変更の種類を分ける」と「URLを少しずつ移す」は別の話です。

古いURLと新しいURLの対応表を作る

対応表は、古いURLの一覧の右に、転送先の新しいURLを書いたものです。ドメインだけを変えて、パスがまったく同じなら、まとめて転送するルール（ワイルドカード）で済むこともあります。この場合も、下層のページをトップページへ集めるのではなく、古いドメインの /service/ は新しいドメインの /service/ へ、というように、同じパスの新しいURLへ転送されるかを確かめます。パスが変わるときは、1ページずつ対応を決めます。

古いURLを集める

Googleは、古いURLを集める方法として、次のものを挙げています。

• 今のサイトマップ（重要なURLが入っている可能性が高い）
• サーバーのログやアクセス解析で、訪問の多いURL
• Search Consoleの「リンク」で、内部・外部からリンクされているページ
• CMSのページの一覧
• 画像・動画・PDFなどのファイルのURL（これらもほかのページと同じように移す）

会社のサイトでは、サービスの紹介、事例、採用、問い合わせのページに加えて、営業資料や会社案内のPDF、ニュースの古い記事のURLも、忘れずに一覧に入れます。

転送先の決め方

Googleは、多数の古いURLを、関係の薄い1つのURL（新しいサイトのトップページなど）へ転送するのは避けるよう書いています。「このようなリダイレクトはユーザーに混乱をきたし、 soft 404 エラー とみなされる場合もあります。」とし、soft 404は、ページがないのに正常なページのように応答している状態を指します。ただし、以前は複数のページにあった内容を1つのページにまとめた場合は、元の複数のURLをまとめた先に転送してよいとしています。

消すページは、404か410を返すようにします。Googleは、すでにインデックスに登録されているURLが404などを返すと、そのURLをインデックスから削除するとしています。

転送の連なり（チェーン）を避ける

古いURL→途中のURL→新しいURL、のように転送が続くことを「チェーン」と言います。Googlebotは最大10回までの転送をたどれますが、Googleは最終的な転送先に直接転送することを勧めています。直接できないときも、チェーンの転送の数は5回未満（理想は3回以下）に抑えるよう書いています。転送が続くと、利用者にとって表示が遅くなり、長いチェーンに対応していないブラウザーなどもあります。

リニューアルを何度か重ねたサイトでは、前回のリニューアルの転送の先に、今回の転送がつながってしまうことがあります。前回の転送ルールも、今回の新しいURLへ直接向けるよう書き直します。

新しいサイトで準備すること

転送のほかに、新しいサイトの側で準備することがあります。Googleの文書から、会社のサイトで関わりやすいものを挙げます。

• 正規URLの指定：新しいURLのそれぞれに、自分自身を指す rel="canonical" を入れます。古いURLを指したままにしないよう、公開後にも確かめます。
• 内部リンク：サイトの中のリンクを、古いURLから新しいURLに書き換えます。転送があっても、転送を通るぶん表示が遅くなるためです。
• 作業中のブロックを外す：公開前の確認用のサイトで、robots.txtでクロールを止めたり、noindex（検索に載せない指定）を入れたりすることがあります。Googleは、移転のためだけに入れたnoindexやrobots.txtのブロックは必ず外すよう書いています。外し忘れは、よくある誤りとして挙げられています。
• サイトマップ：新しいURLを載せたサイトマップを用意し、移転を始めたらSearch Consoleで送信します。
• Search Console：新旧両方のサイトを、Search Consoleで確認（所有者として登録）しておきます。HTMLファイルやmetaタグで所有者の確認をしているときは、新しいサイトにも同じものを入れます。
• サーバーの処理能力：移転のあと、Googleは一時的に、新しいサイトを通常より多くクロールします。

ドメインを変えるときだけ：アドレス変更ツール

Search Consoleの「アドレス変更ツール」は、ドメインやサブドメインを変えるとき（example.comからexample.netへ、a.example.comからb.example.comへなど）にだけ使います。HTTPからHTTPSへの移転、同じドメインの中でのwwwのありとなしの切り替え、同じドメインの中でのパスの移転には必要ありません。リダイレクトを設定したあとに、古いサイトのプロパティから送信します。

使うときの条件は、次のとおりです。

• 新旧両方のプロパティの所有者で、両方を同じGoogleアカウントで管理している
• 古いサイトの、パスを含まないドメイン単位のプロパティ（example.com など）から使う。http://example.com/petstore/ のようなパス単位のプロパティでは使えない
• ツールは、指定したドメインより下のサブドメイン（wwwを含む）を移さない。Googleは、古いドメインのすべてのサブドメインのバリエーション（wwwのあり・なし、en. など）について、使っていないものも含めて、所有権を確認したうえでツールを使うよう書いている
• HTTPとHTTPSは別々に申請しなくてよい（ツールは、指定したプロパティのすべてのプロトコルを移す）

リダイレクトはいつまで残すか

Googleの「サイトを移転する方法」は、リダイレクトをできるだけ長く残すこと、一般的には1年以上を勧めています。その間に、Googleは古いURLを指すほかのサイトのリンクなどを処理し直し、新しいURLへシグナルを移せるとしています。利用者のためには、リダイレクトを無期限に残すことも検討するよう書いています。

ドメインを変えてアドレス変更ツールを使う移転について、ヘルプには、少なくとも180日間リダイレクトを残し、Google検索からのトラフィックがまだある場合はさらに残す、と書かれています。180日たつと、Googleは古いサイトと新しいサイトの関係を認識しなくなります。また、古いドメインがほかの人に買われて悪用されないよう、少なくとも1年間は古いドメインの料金を払い続けることを勧めています。

2つの文書で日数の書き方は違いますが、どちらも「短くて済ませる」ものではありません。会社のサイトでは、古いドメインの契約と転送の設定を、少なくとも1年は残す前提で、サーバーやドメインの契約の更新日を管理しておくのが安全です。あとでサーバーを乗り換えるときに、リダイレクトの設定を移し忘れないよう、乗り換えの作業の一覧にも入れておきます。

AIによる概要・AIモードと、ChatGPTの検索で確かめること

リニューアルのために、AI向けの特別な作業が増えるわけではありません。Googleは、AIによる概要やAIモードにサポートリンク（根拠のリンク）としてページが出るための条件を、インデックスに登録されている、Google検索でスニペットが表示される、検索の技術的要件を満たす、とし、「これ以外に追加の技術要件はありません。」と書いています。あわせて、Search Consoleの「検索の生成 AI 設定」で、サイトが生成AI機能に含まれている必要があります。条件を満たしても、表示が保証されるわけではありません。

つまり、Googleの生成AI機能での見え方も、ふだんの検索と同じく、新しいURLがインデックスに登録されているかが土台です。リニューアルでは、次の点を確かめます。

• 新しいURLがインデックスに登録されているか（転送やnoindexの外し忘れがないか）
• 新しいサイトで、スニペットを止める指定（nosnippetなど）を意図せず入れていないか
• ドメインを変えて、新しいSearch Consoleのプロパティを作ったときは、「検索の生成 AI 設定」が意図どおりか（初期設定は「含める」。親のプロパティがあるときは「親から設定を継承する」なので、継承元の設定を確かめる）

ChatGPTの検索は、OpenAIのクローラー「OAI-SearchBot」がサイトを読みます。OpenAIは、ChatGPTの検索の結果に出るように、robots.txtでOAI-SearchBotを許可し、公開しているIPアドレスの範囲からのアクセスを許可することを勧めています。robots.txtを変えてから検索の結果に反映されるまで、24時間ほどかかることがある、としています。新しいサーバーやCDN・WAF（不正なアクセスを止める仕組み）に乗り換えたときは、AIのクローラーを止める設定が入っていないかも見ておきます。クローラーごとの確かめ方は「ChatGPT・Claudeに自社が出てこない？ AIのクローラーが読めているかの確かめ方」にまとめています。

公開前と公開後のチェックリスト

Laugh Mind では、URLが変わるリニューアルで確かめることを、次のように整理しています（Googleの公式のチェックリストではありません）。

公開前

• 今回のリニューアルで、URLが変わるか（ドメイン・HTTPS・パス）を制作会社と確かめた
• ドメイン・CMS・デザイン・URLの変更を、分けられるものは分けた。一度に行うときは、検索からの訪問が一時的に動く可能性を関係者で共有した
• 古いURLの一覧（サイトマップ・アクセス解析・Search Consoleのリンク・CMS・PDFや画像）を作った
• 古いURLごとに、転送先の新しいURL、まとめ先、または「消す（404・410）」を決めた。トップページへのまとめての転送はしていない
• 前回のリニューアルの転送も、今回の新しいURLへ直接向けた
• 新しいURLの rel="canonical"・内部リンク・サイトマップを、新しいURLにした
• 新旧両方のサイトをSearch Consoleで確認した

公開した日

• 作業用に入れたrobots.txtのブロックとnoindexを外した
• 転送すると決めた古いURLの応答を、ブラウザーの開発者ツールやコマンドなどで見て、対応表どおりの新しいURLへ、301（または308）で直接（1回で）転送され、転送先のページが正常に表示されることを確かめた（ページを開いて表示されるだけでは、転送の種類や回数はわからない。多いときはツールやスクリプトでまとめて確かめる）
• 消すと決めた古いURLが、404か410を返すことを確かめた（トップページなどへ転送されていない）
• 新しいサイトマップをSearch Consoleで送信した
• ドメインやサブドメインを変える移転のときだけ、条件（同じGoogleアカウントで新旧両方の所有者・パスを含まないプロパティ・サブドメインごとの申請）を確かめて、古いサイトのプロパティからアドレス変更ツールで送信した（HTTPS化だけ・wwwのあり・なしだけ・同じドメインの中のパスの変更には使わない）
• 新しいサイトのrobots.txtで、Googlebotや、OAI-SearchBotなどのAIの検索のクローラーを意図せず止めていないかを確かめた

公開後の数週間

• Search Consoleのページのインデックス登録のレポートで、新しいURLの登録が増えているかを見た。404などのエラーは対応表と照らし、消すと決めた古いURLの404・410（予定どおり）と、残すページや転送先に出た想定外のエラーを分けて確かめた
• URL 検査ツールに主なページの新しいURLを直接入れて、インデックス登録の結果で、Googleが認識している状態を見た（古いURLを入れても、結果は古いURLのもので、転送先の登録状況ではない）
• サーバーのログやアクセス解析で、古いURLへの訪問が新しいURLに移っているか、予期しないエラーがないかを見た
• 外部のサイト・SNSのプロフィール・広告・名刺などのリンクを、新しいURLに更新した（訪問の多いリンクから）
• リダイレクトと古いドメインの契約を、少なくとも1年は残す予定にした

URL 検査ツールでは、見ているものを分けて考えます。Search Consoleのヘルプによると、インデックス登録の結果は、入力したURLそのもののインデックスでの状態で、転送されるURLを入れても転送先の結果は出ません。一方、［公開 URL をテスト］（ライブテスト）は、今のページを取得できるかを調べるもので、インデックスに登録されていることの確認とは別です。ライブテストは転送をたどって転送先をテストしますが、転送があったことや、最終的にテストしたURLは表示されません。そのため、古いURLのライブテストが成功しても、転送の種類や行き先、回数はわかりません。転送の確かめは、開発者ツールやコマンドで応答を見て行い、新しいURLの登録状況は、新しいURLを直接入れて確かめます。

私たちLaugh Mindの経験：入り口のURLを1つにまとめた

私たちLaugh Mindも、自社の会社サイトで、入り口のURLをそろえました。http・https、wwwのあり・なしのURLを、https://laugh-mind.co.jp/ で始まる正規のURLへ、1回の転送でまとめました。トップページだけでなく、下層のページも、それぞれ同じページの正規のURLへ転送されます（たとえば、http://laugh-mind.co.jp/company/ は https://laugh-mind.co.jp/company/ へ）。

一般に、転送が途中の入り口を経由する形（たとえば、httpからhttpsへ、さらにwwwなしへ、と2回に分かれる形）になっていると、上で書いた転送のチェーンになります。リニューアルでドメインやURLを変えるときも、古いURLのすべての入り口（http・https・wwwのあり・なし）から、新しいURLへ1回で届くかを確かめるとよいでしょう。下層のページは、トップページへ集めず、それぞれ対応する新しいURLへ転送されるかを確かめます。

まとめ

• リニューアルで検索への影響を抑える土台は、URLが変わるかを確かめ、古いURLと新しいURLの対応表を作り、サーバー側の永続的なリダイレクト（301・308）で、対応する新しいURLへつなぐこと。
• 消すページは404か410を返す。多数の古いURLを関係の薄いトップページへまとめて転送するのは避ける（soft 404とみなされる場合がある）。内容を1つのページにまとめたときは、まとめた先へ転送してよい。
• 変更は一度に1つずつが基本。ドメインの移転とURL構造・内容の作り直しを同時に行うと、トラフィックが落ちる可能性があるとGoogleは書いている。移転中は順位が一時的に変動することがあり、小規模・中規模のサイトで大半のページの反映に数週間かかる。
• リダイレクトは、Googleの文書では一般的に1年以上（アドレス変更ツールのヘルプでは少なくとも180日、トラフィックがあればさらに）。古いドメインも少なくとも1年は契約を続ける。
• AIによる概要・AIモードでの見え方も、新しいURLのインデックス登録が土台。ドメインを変えたときは「検索の生成 AI 設定」（親からの継承を含む）を、ChatGPTの検索にはrobots.txtでOAI-SearchBotを止めていないかを確かめる。

リニューアルの前に、今のサイトが検索やAIでどう見えているかを確かめておくと、公開後に比べる基準になります。数字の見方は「AI検索からの表示と訪問の測り方：Search Console・GA4・Bingで見る数字」にまとめています。サイトが検索やAIに伝わる状態かをまとめて確かめたいときは、AIO・LLMOソリューションの無料の初回診断（AIO SCORE 100）もご利用いただけます。