サイトリニューアルでSEO評価を落とさない移行方法｜URL・301・計測・公開手順

監修: 菊地 将（リブランディング株式会社）

サイトリニューアルでは、デザインやCMSが完成していても、URLの引き継ぎ、301リダイレクト、canonical、サイトマップ、計測設定が欠けると、公開後に検索流入を失う原因になります。重要なのは、問題が起きてから診断するのではなく、公開前に「何を引き継ぐか」「何を正常と判定するか」「異常時にどう戻すか」まで決めておくことです。この記事では、SEO・Web担当者が制作会社や開発会社と共有できるよう、移行設計を6つの工程に分けて整理します。

結論：公開前に「URL・転送・正規化・計測・公開判定・戻し方」の6点を固定する

サイトリニューアルのSEO移行は、公開日に301リダイレクトを設定するだけでは不十分です。Googleは、URL変更を伴うサイト移転について、新サイトの十分なテスト、旧URLから新URLへのURLマッピング、リダイレクト、移転後のトラフィック監視までを一連の工程として案内しています。

公開前に最低限、次の6点を1枚の移行計画へまとめておくと、担当者ごとの認識差を減らせます。

特に重要なのがURL対応表です。Googleは、複雑なサイト移転では旧URLの一覧を作り、各URLを新しい移転先へマッピングするよう案内しています。検索流入の多いURL、被リンクがあるURL、主要な成果ページから優先して確認します。

なぜサイトリニューアルでSEO評価が落ちるのか

検索順位が下がる原因を「デザインを変えたから」と考えると、移行時に見るべき場所を外します。大きなリスクは、旧サイトで積み上がっていたURL単位の情報や評価を、新サイトへ正しく引き継げないことです。

移行時のURL設計だけでなく、クロール・インデックス・正規化など技術要件を広く確認したい場合は、テクニカルSEOの実務チェックリストも確認してください。

URL変更で旧ページと新ページの関係が切れる

URLが変わる場合、検索エンジンとユーザーに移転先を示す必要があります。HTTPの仕様上、301は対象リソースに新しい恒久的なURIが割り当てられたことを示すステータスです。Googleも、URL変更を伴うサイト移転では、可能なら301や308などのサーバーサイドの永続的リダイレクトを推奨しています。

一方、旧URLをすべて新サイトのトップページへ転送するような設計は避けるべきです。Googleは、関連性の低い1つのURLへ多数の旧URLを転送すると、ユーザーを混乱させ、soft 404として扱われる場合があると説明しています。

canonical・内部リンク・サイトマップが旧URLのまま残る

301だけ新URLへ向いていても、canonical、内部リンク、XMLサイトマップが旧URLのままだと、サイト内で異なるシグナルを送る状態になります。

Googleは、移転先URLに自己参照canonicalを設定し、内部リンクを新URLへ更新し、新URLを含むサイトマップを準備するよう案内しています。

一時的な順位変動と移行事故を混同する

適切に移行しても、検索結果はすぐに完全には切り替わりません。Googleによると、小規模から中規模のサイトでは、大半のURLの移転が反映されるまで数週間かかる場合があります。

公開数日後の順位変動だけで「移行失敗」と判断せず、リダイレクト、インデックス、エラー、計測値を分けて確認することが重要です。

STEP1｜旧サイトのSEO資産を棚卸しする

移行設計は、新サイトを見る前に旧サイトの棚卸しから始めます。最低限、サイトマップ、CMSのURL一覧、Search Console、アクセス解析を突き合わせ、検索流入やリンクを持つURLが漏れないようにします。

Googleは、重要URLを特定する方法として、サイトマップ、サーバーログや解析ソフトウェアの高トラフィックURL、Search Consoleで確認できるリンクを挙げています。

URLを削除・統合する場合も、単純に「新URLなし」で終わらせません。同等の移転先がないなら404または410、複数ページを1ページへ統合するなら内容的に最も近い統合先へ転送する、という判断をURL単位で残します。

STEP2｜旧URLと新URLの対応表を作る

URL対応表では、旧URLごとに「維持・変更・統合・削除」を分類します。新旧サイトのディレクトリ構造だけで一括変換すると、コンテンツの統廃合と対応しないことがあるためです。

旧URLごとに役割を判断し、維持・変更・統合・削除の結果に応じて処理を決めます。

対応表には、旧URL、新URL、対応区分、リダイレクト有無、canonical、公開後の期待ステータス、確認担当者まで入れると、そのまま受入テスト表として使えます。

また、リダイレクトチェーンはできるだけ作らない設計にします。Googlebotは複数のリダイレクトをたどれますが、Googleは最終URLへ直接転送することを推奨し、直接転送できない場合もチェーンを5個未満、理想的には3個以下に抑えるよう案内しています。

STEP3｜301・canonical・内部リンク・サイトマップを同じ新URLへそろえる

URL変更があるページでは、転送と正規化の向きをそろえることが重要です。公開前に、旧URLから新URLへの301または308、新ページの自己参照canonical、内部リンク、新サイトマップが同じ新URLを示すことを確認します。

301だけでなく、canonical・内部リンク・サイトマップまで同じ新URLを示す状態にそろえます。

Googleは、サイトマップには検索結果に表示したいcanonical URLを含めるよう案内しています。サイトマップは1ファイルあたり非圧縮50MBまたは50,000URLが上限で、それを超える場合は分割できます。

公開前のチェックでは、次も忘れないようにします。

• 開発環境で付けたnoindexが本番に残っていないか
• robots.txtが本番で必要なページをブロックしていないか
• canonicalが開発URLや旧URLを指していないか
• 内部リンクが旧URL経由になっていないか
• hreflangを使うサイトでは新URLへ更新されているか
• 新旧のSearch Consoleプロパティを確認できるか

Googleも、開発中に使用したnoindexを移転開始時に削除すること、Search Consoleの所有権確認が新サイトでも継続することを事前に確認するよう案内しています。

ドメインまたはサブドメインを変更する場合は、リダイレクト設定後にSearch Consoleのアドレス変更ツールを利用します。HTTPからHTTPSへの変更や、同一ドメイン内のパス変更ではアドレス変更ツールを使わないため、移行種類を先に分類しておくと誤操作を防げます。

STEP4｜公開前に計測の「基準線」と受入テストを決める

公開後に「流入が落ちた」と気づいても、公開前の基準値がなければ異常かどうかを判断しにくくなります。そこで、公開前に主要指標の基準線を保存します。

実務上は、季節性やキャンペーンの影響を避けながら、直近の通常期間を使って次を保存しておくと比較しやすくなります。

• Search Console：検索クリック、表示回数、主要クエリ、主要ページ
• GA4：自然検索セッション、主要ランディングページ、問い合わせ等のキーイベント
• クロール：200、3xx、404/410、5xxの件数
• URL対応：旧URLから新URLへの到達結果
• 計測タグ：主要ページとフォームでイベントが取得できるか

Google Analyticsでは、通常レポートの処理に24〜48時間かかる場合がありますが、リアルタイムレポートとDebugViewを使えば、公開直後にデータ収集の成否を確認できます。

したがって、公開判定では「翌日のレポートを見る」だけではなく、公開直後にリアルタイム計測まで確認するのが実務的です。

見込み客側から見ると、移行事故はSEO指標だけの問題ではありません。検索結果から来たユーザーが404へ到達する、問い合わせフォームが動かない、旧ページのブックマークから目的ページへ移れない、といった状態はそのまま機会損失になります。

SEO移行では、検索エンジン向けの設定と、ユーザーが目的ページへ到達して行動できるかを同じ受入テストで確認します。

STEP5｜公開は「作業順」ではなく「公開ゲート」で管理する

公開作業は、担当者が順番にタスクを消化するだけでなく、「この条件を満たしたら公開してよい」というゲートで管理します。

サイト公開は作業完了ではなく、移行設計・技術・計測・承認の4条件を通過した時点で判断します。

公開前の判断軸は、次の4段階に分けると整理しやすくなります。

公開直前には、コンテンツ・CMS・ドメイン・デザインなど複数の大変更を同時に重ねすぎないことも重要です。

Googleも、サイト移転では可能な限り変更を1つずつ行うことを推奨しています。ドメイン変更、CMS変更、大幅な情報設計変更を同時に行うと、問題が起きた際に原因を切り分けにくくなります。

STEP6｜ロールバックは「戻せる状態」と「戻す条件」を先に決める

ロールバックは、SEO順位が少し下がったら旧サイトへ戻すという意味ではありません。検索順位は移転中に一時変動することがあるため、順位だけを切り戻し条件にすると、かえってURL状態を何度も変えることになります。

公開前には、少なくとも次をバックアップ対象として決めます。

• 旧サイトのファイルとデータベース
• DNSやCDNの変更前設定
• リダイレクト設定
• robots.txt、canonical、サイトマップ
• GA4やタグ管理の公開前設定
• フォームや外部連携の設定
• 新旧URL対応表と公開時の設定値

切り戻し条件は、重大度で決めると判断しやすくなります。

一時的な順位変動だけでは切り戻さず、技術設定を確認します。重大障害は事前に定めた条件に従って修正・切り戻しを判断します。

たとえば「主要ページが広範囲に5xxになる」「旧URLの大半が誤ったURLへ転送される」「本番サイトにnoindexが残る」「問い合わせ機能が停止する」といった事象は、即時修正または切り戻しを検討する重大障害です。

一方、順位の一時変動だけであれば、まず技術設定とインデックス状況を確認します。

URL変更を伴う移転で旧環境へ戻す場合は、サイト本体だけを戻してリダイレクトやcanonicalを新URLのまま残す、といった混在状態を避けなければなりません。

どの設定を同時に復元するかを公開前に手順化し、実行責任者を決めておくことが重要です。

公開後の詳細診断は「サイト移行後のSEO監査」と分ける

この記事で扱うのは、公開前の移行設計と、公開直後に「予定どおり移行できたか」を確認する受入テストまでです。

公開後に行う検索順位の継続監視、インデックス診断、クロールエラーの原因切り分け、検索流入減少ページの分析は、事後監査の領域です。

公開前の移行計画に事後診断まで詰め込むと、「今何を決めるべきか」がぼやけます。

なお、Googleは301などの永続的リダイレクトをできるだけ長く、一般には1年以上保持するよう案内しています。公開後すぐに旧ドメインや転送設定を撤去しないことも、移行計画に含めておきましょう。

公開後のリダイレクト、canonical、サイトマップ、順位変動の確認手順は、サイト移行後のSEO監査方法で詳しく整理しています。

公開前チェックリスト

最後に、公開前の確認項目をまとめます。

• 旧URLを一覧化し、重要URLを特定した
• 旧URLごとに維持・変更・統合・削除を決めた
• 旧URLと新URLの対応表を作った
• 301/308が関連する新URLへ直接向いている
• canonicalが新URLの自己参照になっている
• 内部リンクを新URLへ更新した
• 新URLを含むサイトマップを準備した
• noindexとrobots.txtの本番設定を確認した
• Search Consoleの所有権を新旧で確認した
• GA4のページビュー・主要イベントをテストした
• 公開前の検索流入・主要ページ・成果基準値を保存した
• バックアップを取得した
• 重大障害時の修正・切り戻し条件を決めた
• 公開責任者と技術責任者を決めた
• 公開後の監査担当へ引き継ぐ項目を決めた

移行計画表やURL対応表をゼロから作る場合は、無料ダウンロードページで資料を確認できます。本文の手順を実案件のタスクへ落とし込む際に活用してください。

まとめ

サイトリニューアルでSEO評価を守るには、公開後の監視より前に、公開前の移行設計を固めることが重要です。

中心になるのは、旧URLと新URLの対応表、301/308、canonical・内部リンク・サイトマップの統一、Search ConsoleとGA4の計測基準、公開ゲート、バックアップとロールバック条件です。

特に、URL変更を「制作会社の実装作業」として任せきりにせず、SEO・Web担当者が対応表と完了条件を持つと、公開前に漏れを発見しやすくなります。

公開後は受入確認を終えたうえで、順位・インデックス・流入の継続監査へ引き継ぎましょう。

参考文献・データ元

‹ 親記事: テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト