サイト移転（URLの変更を伴う）

01 何が起きたか — 「サイト移転」は1つではなく4パターンある

Google公式が定義する「サイト移転」の範囲

WEBサイトのリニューアルやドメイン変更を検討するとき、「サイト移転」という言葉が指す作業は1種類ではない。Google Search Centralの公式ガイドは、対象とする移転を次のように列挙している。HTTPからHTTPSへの移行、ドメイン名の変更（example.comからexample.netへの変更や、複数ドメインの統合を含む）、そしてURLパス構造の変更（example.com/page.php?id=1からexample.com/widgetへの変更のような、パラメータ付きURLから読みやすいURLへの変更など）である。プロトコル・サブドメイン・パスの組み合わせが変わるケースにも、このガイドは対応する。一方で、URL自体が変わらないインフラ変更（サーバーの引っ越しやCDNの導入だけを行う場合）は、このガイドの対象外として別の資料が案内されている。

4パターンの何が違うのか

この4パターンは、見た目は似ていても、必要な対応がまったく違う。HTTPからHTTPSへの移行や、同一ドメイン内でのwww・非wwwの切り替え、URLパス構造だけの変更は、Search Console側の特別な申請なしで進められる。これに対して、ドメイン名そのものの変更やサブドメインの変更は、Search Consoleの「アドレス変更ツール」を使う対象になる。この区別を最初に押さえておかないと、「移転したのにSearch Consoleで何を報告すればいいのか分からない」という状態のまま作業を進めることになる。本記事は、この4パターンを型として整理し、WEBディレクターが自分の案件がどの型に当たるかを最初に判定できる形にまとめる。

02 なぜ・背景 — 移転作業の速度は、URLの数とサーバー速度で決まる

Googleが移転を認識するまでの時間は、事前準備の質に左右される

Google公式ガイドは、移転後にGoogleが新しいURLを認識し、検索結果に反映するまでの速度について「Googlebotと当社のシステムが移転されたURLを発見・処理する速度は、URLの数とサーバーの応答速度に大きく左右される」と説明している。つまり、移転の反映速度は運任せの数字ではなく、事前にどれだけ丁寧にURLマッピングを作り、リダイレクトを整備したかによって変わる、という前提が公式に示されている。中規模サイトでも「数週間以上」、大規模サイトでは「さらに長く」かかるとされており、移転を実施した当日に検索結果が切り替わることは想定されていない。

移転前に準備しておくべき3つの作業

公式ガイドが移転前の準備として挙げている作業は、大きく3つに整理できる。第一に新サイト側の準備で、CMSの設定・コンテンツの移行・画像やPDFなどのファイル転送に加えて、HTTPS移行であればTLS証明書の取得と設定、robots.txtの正確な設定、削除するコンテンツへの404・410応答の準備が含まれる。第二にURLマッピングの作成で、旧URLから新URLへの1対1の対応表を、サイトマップ・サーバーのアクセスログ・Search Consoleのリンクレポートから抽出したURL一覧をもとに作る。第三に新サイト側のメタデータ更新で、各ページに自分自身を指すrel="canonical"タグを設定し、多言語サイトであればhreflangの注釈も新URLで更新し、内部リンクをすべて新URLに張り替える。

移転規模と進め方の使い分け

小〜中規模のサイトについて、公式ガイドは「1セクションずつではなく、サイト内の全URLを同時に移転することを推奨する」と述べている。段階的に移転すると、ユーザーが新旧どちらの形のサイトを見ているのか分かりにくくなり、Googleのアルゴリズムがサイト移転そのものを検知しにくくなるためである。大規模サイトについては、テスト区間を設けて段階的に移転する対応も許容されている。また、可能であればトラフィックが少ない時期に合わせて移転を実施することも推奨事項に含まれている。

03 この記事で出てくる用語

「リダイレクトすれば評価は消える」という誤解

移転にともなって順位が一時的に変動すると、「リダイレクトによってページの評価が失われたのではないか」という不安が生まれやすい。しかし公式ガイドは「301やその他の恒久的リダイレクトは、PageRankの損失を引き起こさない」と明記している。順位の変動自体は、リダイレクトが評価を失わせているからではなく、「サイトに大きな変更を加えると、Googleが再クロール・再インデックスを行う間、順位の変動を経験することがある」という、移転作業そのものに付随する一時的な現象として説明されている。この違いを取り違えると、順位が下がった原因を誤って診断してしまう。

移転後のトラフィック変動を、どう切り分けるか

移転後に検索トラフィックが崩れたように見えたとき、原因を切り分ける視点も公式に案内されている。検索トラフィック低下の原因を調べるガイドは、コアアップデートなどのアルゴリズム変動・robots.txtやサーバーエラーなどの技術的問題・セキュリティ上の警告・スパムポリシー違反による手動対策・季節要因による需要の変化、という複数のカテゴリを挙げたうえで、移転についても直接触れている。「サイト内の既存ページのURLを変更した場合、Googleが再クロール・再インデックスを行う間、順位の変動を経験することがある」という記述は、02章で見た移転そのものの一時的な変動とも重なる。移転を実施した直後にトラフィックの数字だけを見て慌てないためには、Search Consoleのパフォーマンスレポート・クロール統計情報レポート・ページのインデックス登録レポートの3つを並べて確認し、崩れているのが検索順位なのか、クロールの状況なのか、インデックス登録の状況なのかを、まず切り分ける必要がある。

04 型別 — 適用範囲・この記事が測っていないこと・手順

🅰 適用範囲 — どの移転が、どのツールを必要とするか

4パターンのうち、アドレス変更ツールを使うのはドメイン名の変更とサブドメインの変更の2つだけである。HTTPからHTTPSへの移行、www・非wwwの切り替え、同一ドメイン内でのURLパス構造の変更には、このツールを使う必要がない。かわりに、301リダイレクトの実装・新しいサイトマップの送信・canonicalタグの更新という、共通の作業で対応する。制作会社や代理店のようにクライアントサイトの移転を複数扱う立場では、着手前に「この案件はどの型に当たるか」を最初に判定し、アドレス変更ツールの申請が必要かどうかをチェックリストの1項目として明示しておくと、申請漏れを防ぎやすい。

🅱 この記事が測っていないこと・分からないこと

公式ガイドを確認しても、明確にされていない点がいくつかある。第一に、リダイレクトを解除して問題ない具体的な日数は示されていない。ガイドは「できるだけ長く、一般的には最低1年間はリダイレクトを維持する」としているが、1年を超えたら安全という断定ではなく、「ユーザーの視点からは、リダイレクトを無期限に維持することも検討してよい」という、より慎重な表現も併記されている。第二に、移転後に新URLが検索結果に表示され始めるまでの正確な日数は、サイトごとのURL数とサーバー速度に依存するため、一律の数字としては示されていない。第三に、段階的移転を選んだ場合に、どの区切り方が最も安全かという基準も明文化されていない。「何日で終わるか」「いつリダイレクトを外してよいか」を一律の数字で語ることはできない。

🅲 手順 — 自分の案件で確認する流れ

実際の移転作業は、次の4段階で進める。第一にURLマッピングと新サイトの準備として、旧URLと新URLの1対1対応表を作成し、新サイト側にrobots.txt・404/410応答・canonicalタグを設定する。第二に301リダイレクトの実装として、マッピング表に基づいた個別リダイレクトルール、またはドメイン変更であればワイルドカードによる一括リダイレクトを設定する。このとき、公式ガイドが注意を促す「リダイレクトチェーンを避ける」を守り、最終的なリダイレクト先に直接つなげる。第三に新サイトマップの送信とcanonicalの確認として、新URLを収録したサイトマップをSearch Consoleに送信し、新サイト側のcanonicalタグがすべて新URLの自己参照になっていることを確認する。第四にSearch Consoleでの移行後の監視として、インデックス登録レポートで旧サイトの登録数が減り、新サイトの登録数が増えていく推移を追う。

URLマッピングは、HTMLページだけを対象にしない

URLマッピングの作成というと、記事ページや商品ページのURLだけを思い浮かべがちだが、公式ガイドが挙げる移転前の準備には、画像・PDF・CSS・JavaScriptといった非HTMLリソースの転送も含まれている。これらのファイルのURLが変わる場合、記事本文やCSSファイル内の参照パスもあわせて新しいパスへ張り替える必要がある。また、多言語サイトを運用している場合は、hreflangの注釈も新URLで更新する対象に含まれる。hreflangは言語・地域ごとの対応関係を示す注釈であり、旧URLを指したまま残っていると、Googleがどの言語版のページを、どの検索結果に出すべきか正しく判断できなくなる。移転作業のチェック項目を「記事ページのURL」だけに絞ると、こうした周辺リソースの張り替え漏れが見落とされやすい。

05 明日、自分の案件で確認できることチェックリスト

まず何を数えるか

ここまでの内容を、実際に手を動かせる作業に翻訳した。観点は、事前準備（URLマッピングとメタデータ）、リダイレクトの実装、Search Console側の申請と送信、移転後の監視、の4つに分かれる。着手前にどの型（4パターンのうちどれ）に当たるかを判定してから、該当する項目を上から順に進める。

• 今回の移転が4パターンのうちどれに当たるかを判定し、アドレス変更ツールの申請が必要かを確認する
• 旧URLの一覧を、サイトマップ・アクセスログ・Search Consoleのリンクレポートの3箇所から抽出する
• 抽出した旧URLと、対応する新URLの1対1マッピング表を作成する
• マッピング表のうち、上位10件のページについて旧URLと新URLの内容が一致しているか目視で確認する
• 新サイト側のrobots.txtを開き、開発中に設定した全面ブロックの記述が残っていないか確認する
• 新サイト側の主要ページを5件選び、canonicalタグが新URLの自己参照になっているか確認する
• 301リダイレクトの実装後、マッピング表のうち5件をブラウザで実際に開き、意図した新URLに到達するか確認する
• リダイレクトのホップ数を3件のURLで確認し、3ホップを超えるチェーンがないか確認する
• 削除して統合しないページについて、多数の旧URLが1つの無関係なページ（トップページなど）へ集約されていないか確認する
• 新URLを収録したサイトマップを作成し、Search Consoleに送信する
• 移転から1週間後、Search Consoleの「ページのインデックス登録」レポートで、旧URLの登録数が減り新URLの登録数が増えているかを確認する
• 移転から1週間後、Search Consoleのパフォーマンスレポートで、クリック数・表示回数が旧サイトの水準と比べて大きく崩れていないか確認する
• サーバーのエラーログを確認し、リダイレクト先で404や5xxエラーが急増していないか確認する
• 外部サイトからの主要な被リンク元を3件選び、リンク元に新URLへの更新を依頼できないか検討する
• リダイレクトを解除する予定日をカレンダーに入れる（目安は最低1年後）

15項目の内訳と、かかる時間の目安

15項目は4つの観点に対応している。それぞれにどの項目が入り、目安としてどれくらいの時間がかかるかを、以下の表にまとめた。

事前準備を除く実作業の目安は1回あたり30〜40分程度である（移転後の監視は、データの反映を待ちながら複数回に分けて実施する）。すべてのページを一度に確認する必要はなく、まず主要なページから優先して進めるとよい。

06 代替・他の選択肢（表で）

4パターンごとの、ツールの要否と注意点

これまで見た4パターンについて、それぞれ何が必要で何が不要かを、以下の表にまとめた。

「今すぐ切り替えたい」場合に、301リダイレクトだけでは足りないこと

301リダイレクトは恒久的な移転の手段として推奨されているが、即効性のある手段ではない。移転後にGoogleが新URLを認識し検索結果を切り替えるまでには、公式ガイドが示すとおり数週間以上を要する。「今日中に旧URLを検索結果から消したい」という要望には、301リダイレクトだけでは応えられない。この場合の考え方は、noindexやrobots.txtによる恒久的な非表示化とも異なり、別の判断軸になる。検索結果への出方を制御する設定そのものについては、noindex・nofollow・robots.txtの役割分担を整理した回で、3つの設定を混同したときに起きる失敗パターンを扱っている(noindex・nofollow・robots.txtは、それぞれ何を止めているのか)。また、削除したページに404・410・ソフト404のどれを返すべきかという判断は、移転で使わなくなった旧URLの後始末にもそのまま当てはまる(削除したページに何を返すか ── 404・410・ソフト404の使い分け)。

ページを統合する場合と、統合してはいけない場合

移転にあわせて複数の旧ページを1つの新ページに統合したくなる場面もあるが、公式ガイドはここに明確な線を引いている。「多数の旧URLを、無関係な単一のURL（新サイトのトップページなど）へリダイレクトしないでほしい」とされ、この形は利用者を混乱させ、ソフト404として扱われる可能性があると説明されている。ただし例外もあり、「複数のページを1つのページに統合する場合はこの限りではない」とも明記されている。つまり判断の基準は「統合先のページに、旧ページの内容が実際に引き継がれているか」であり、内容が引き継がれていない旧URLを、内容の異なる新ページへまとめて向けることは避ける必要がある。

07 自社サイトで確認したこと — sitemap・canonical・URL表記の一貫性

移転がなくても、同じ確認項目でつまずくことがある

当サイトが公開しているブログでは、サイト移転を実施したわけではないが、サイト移転の確認項目とまったく同じ性質の食い違いが記録されている。サイトマップに記載したURLの末尾スラッシュの有無が、実際に配信されているURLと一致しておらず、Googleからそのページが見えていなかった、という事例である(archives/38)。この事例をきっかけに、sitemap・canonical・内部リンク・末尾スラッシュの4層が同じ形式で揃っているかを、コマンドを使って数分で確認する手順が整理されている(archives/39)。

この4層の確認は、移転作業でこそ効く

サイト移転では、新URLのsitemap・canonicalタグ・内部リンク・末尾スラッシュの表記が、すべて同じ形式で揃っているかどうかが、そのままGoogleが新URLを正しく認識できるかに直結する。ここでどれか1層だけ古い表記のまま残っていると、canonicalが指すURLとsitemapに記載したURLが微妙に食い違い、Googleがどちらを正規URLとして扱うべきか迷う状態になりかねない。移転作業がない平常時に見つかった食い違いのパターンは、移転作業のときにこそ再現しやすいため、上記の2つの記録は、本記事05章のチェックリスト5〜6番目（canonicalタグの確認）を実施する際の具体的な確認方法としてそのまま使える。

08 このテーマの、これまで

「リンクは生きているが、飛び先が正しくない」という食い違い

移転作業では、301リダイレクトを設定しても、内部リンクの張り替え自体を見落とすことがある。当サイトのブログでは、リンク切れ（404）が0件であることを確認した後にさらに詳しく調べたところ、リンクは正常に機能しているのに、内部リンクの59.2%がnoindexを設定した記事への導線になっていた、という事例が記録されている(archives/134)。移転作業でも同じ形の食い違いが起こりうる。リダイレクトが正しく機能しているかどうかと、内部リンクの飛び先が意図した新URLになっているかどうかは、別々に確認する必要がある項目である。

大量のURLを一度に扱った経験から

当サイトでは、1,000件規模のページのnoindex設定を6日間で一括して見直した記録がある(archives/105)。移転作業でURLマッピングを1件ずつ手作業で確認するのは、記事数やページ数が増えるほど現実的でなくなる。この記録は移転そのものを扱ったものではないが、大量のURLを扱うときほど、機械的に突き合わせる仕組みを先に用意しておく必要があるという点で、本記事05章のチェックリストの考え方と共通している。