結論から
移行後も順位を維持できるのは、アクセスやリンクを集めているすべてのURLが公開後も応答する場合です。つまり、同じアドレスに同じコンテンツがあるか、最も近い対応先へサーバー側の恒久リダイレクトが設定されている状態です。移行トラブルの多くは、リストに載せ忘れたURLが原因です。
GoogleのURL変更を伴うサイト移転のガイドが基本方針を示しています。古いURLをすべて新しいURLに対応付け、301や308などのサーバー側の恒久リダイレクトを使い、「原則として少なくとも1年間」維持すること。そして「移転中はサイトの順位が一時的に変動することを想定」することです。
同じガイドでは、一度に変えるのは1つだけにするよう勧めています。先に新しいドメインへ移り、レイアウトの変更は後にします。Googleのアドレス変更ツールのドキュメントはさらに率直です。移転とあわせてコンテンツやURL構造のリニューアルも行うと、Googleが各ページを再評価する間、「おそらくトラフィックが減少する」とされています。両方が必要な場合は、リニューアルを別のフェーズとして計画しましょう。
移行の3つのタイプ
| 移行タイプ | 変わるもの | リダイレクト | Search Console |
|---|---|---|---|
| ホスティングのみ | サーバーまたはCDN。URLはすべて同じ | 不要 | クロールとインデックスを監視 |
| プラットフォーム(WixからWordPress、WordPressからAstroなど) | CMS、テンプレート、たいていは一部のURLパターン | パスが変わるすべてのURL | 新しいサイトマップを送信し、その後は監視 |
| ドメインまたはサブドメイン | すべてのURL | すべて | 確認済みの全バリエーションでアドレス変更 |
ホスティングのみの移行については、Googleのホスティングガイドが、DNSのTTLを「移行の少なくとも1週間前に」短くし、旧サーバーはアクセスがゼロになるまで稼働させ続けるよう案内しています。公開後にクロール頻度が一時的に下がるのは正常です。
移行前:URLを持つものをすべて洗い出す
リダイレクトマップの精度は、その元となる旧URLのリストの精度次第です。しかも、どの情報源にも漏れがあります。
公開中のサイトをクロールする
現在のサイトをクロールし、全URLをステータスコード、タイトル、メタディスクリプション、canonicalタグ、hreflangタグとともにエクスポートします。そこにXMLサイトマップ内のURLもすべて加えます。Googleは、最近少なくとも1回アクセスのあったURLをサーバーログで確認することも勧めています。
Search Consoleとアナリティクスからランディングページを取得する
Search Consoleの検索パフォーマンスレポートで、最長の期間を指定して「ページ」タブをエクスポートします。アナリティクスでも、オーガニック検索のランディングページを同様に出力します。これらのページはアクセスや問い合わせをもたらしているため、公開時にひとつずつ手作業で確認します。
リンク元を調べる
リンクレポートでは被リンクの多いページを確認できますが、表は「1,000行までに制限」されており、Google自身も網羅的なリストではないとしています。お使いの被リンク調査ツールと組み合わせましょう。
フォーム、連携ツール、メディアを一覧にする
すべてのフォームとその送信先、埋め込んでいるツール(予約、チャット、地図、決済)、直接リンクされているすべてのファイルを書き出します。Googleのガイドは、計画に「動画、画像、JavaScript、CSSファイル」も含めるよう述べています。これらのURLも他のコンテンツと同じように移動するためです。
リダイレクトマップを作る
旧URL1つにつき1行。旧URL、新URL、ステータスコード、メモ、テスト済みの欄を設けます。ルールは4つです。
- 各旧URLを、最も近い対応先に割り当てます。多数の旧URLをトップページのような無関係な1つの移動先にまとめてリダイレクトすると、「ソフト404エラーとして扱われる可能性」があります。
- 複数の旧ページを1つに統合した場合は、そのすべてを統合先へリダイレクトします。
- 対応するページがない場合は、リダイレクトではなく404または410を返します。
- 新しいプラットフォームで可能な限り、パスは変えずに維持します。
構築中:リダイレクトと、それに伴って引き継ぐもの
1対1のサーバー側301または308リダイレクトを使う
Googleのリダイレクトに関するドキュメントによると、301と308は「リダイレクト先が正規URLであるべき」ことを示し、「可能な限りサーバー側の恒久リダイレクト」が推奨されています。一時的なコード(302、303、307)にはその効果がなく、JavaScriptによるリダイレクトは最後の手段です。
最終的なURLへ直接リダイレクトしてください。Googleのクローラーは最大10回のリダイレクトホップまでたどりますが、サイト移転ガイドは「最終的な移動先に直接リダイレクトする」ことを勧めています。過去の移行で残ったリダイレクトがある場合も、新しい最終URLへ向け直しましょう。
リダイレクトを処理する環境のデフォルトのステータスコードを確認してください。Dardoが制作したサイトをホスティングしているCloudflare Workersでは、_redirectsファイルは各行に301と書かない限り302になります。上限は静的リダイレクト2,000件、動的リダイレクト100件で、クエリパラメータは照合できません。そのため、WordPressのプレーンなパーマリンク(/?p=123)には、Workerのコード内にリダイレクト処理が必要です。
代わりに404または410を返すべき場合
内容の薄いページ、終了したオファー、重複ページは残す必要がありません。Googleのガイドは、移行しないコンテンツは「HTTP 404または410を正しく返す」べきだとしており、Googleのクローラーは429を除くすべての4xxコードを同じ扱いにします。つまり、そのURLはインデックスから外れます。
メタデータ、canonical、hreflangを引き継ぐ
- タイトルとメタディスクリプション。新しいテンプレートに自動生成させず、フィールドごとに移行します。
- canonical。新しい各ページには、新URLを指す自己参照のcanonicalを設定します。Googleの正規化ガイドはcanonicalを「ルールではなくヒント」と位置づけているため、canonical、リダイレクト、サイトマップの内容は一致させる必要があります。
- hreflang。Googleのローカライズ版ガイドによれば、各言語版は「自身と他のすべての言語版を記載しなければならず」、「2つのページが互いを指していなければ、タグは無視されます」。すべてのアノテーションを新しいURLに更新してください。
構造化データ、内部リンク、画像URL
- 構造化データ。Organization、Breadcrumb、Article、Productのマークアップを新しいテンプレートで作り直し、リッチリザルトテストで検証します。Googleの移転ガイドには記載がないため、見落としやすい項目です。
- 内部リンク。リダイレクトではなく、新しいURLを直接指すようにします。
- 画像とファイル。わかりやすいファイル名と代替テキスト(alt)は維持し、リンクや画像検索からのアクセスがある旧画像・PDFのURLはリダイレクトしてください。
アクセス解析と同意取得
アクセス解析、コンバージョンイベント、広告ピクセルを再設定し、ステージング環境でテストします。旧サイトでCookieの同意を求めていた場合は、新サイトでもこれらのタグが作動する前に同じ方法で同意を取得する必要があります。
プラットフォーム別に見る、よくあるトラブル
以下は2026年10月時点の各プラットフォームの公式ドキュメントに基づくメモです。各プラットフォームの仕様を説明するもので、不具合ではありません。
| プラットフォーム | マッピングが必要なURLパターン | エクスポートとリダイレクトの制限 |
|---|---|---|
| WordPress | パーマリンクは基本(/?p=N)、日付ベース、投稿名のいずれかです。カテゴリーやタグのアーカイブには、/category/のようなベースが必ず付きます。 | WordPress 6.4以降、新規インストールでは添付ファイルページが無効ですが、アップグレードしたサイトでは有効のままです。そのため、古いサイトではアップロードしたファイルごとにURLが存在することがあります。 |
| Webflow | CMSアイテムはコレクションページにあります。 | コードエクスポートにはCMSコンテンツ、Eコマース、ユーザーアカウント、フォーム処理、サイト内検索、ローカライズされたページは含まれず、Workspaceプランが必要です。コレクションはCSVで別途エクスポートします。 |
| Wix | ブログ記事は/post/プレフィックスの下にあり、名前の変更はできますが削除はできません。WordPressでは、カスタムパーマリンク構造に/post/%postname%/を指定すれば同じURLを保てます。 | Wixのサイトは「Wixのサーバー上で稼働する必要がある」ため、移行する場合はページを作り直すことになります。 |
| Framer | サブパスを変更しても既存のリダイレクトルールは更新されないため、古いルールが存在しないパスを指したままになることがあります。 | サイトは標準的なHTML、CSS、JavaScriptとして公開されます。CMSコンテンツはプラグインを使ってCSVまたはJSONでエクスポートできます。 |
| Squarespace | URLマッピングでは、/blog/[name] -> /posts/[name] 301のように、コレクション全体に対して[name]変数を使えます。 | エクスポートはWordPress XML形式で、ブログページ1つ、レイアウトページ、ギャラリーは含まれますが、ストアページ、商品・動画・音声ブロック、カスタムCSSは含まれません。URLマッピングでは画像やファイルのURLをリダイレクトできず、上限は約2,500行です。 |
| Shopify | ストアフロントのURLは/products/、/collections/、/pages/、/blogs/<blog>/などのパスの下にあります。Shopifyは/productsと/collectionsを固定としています。 | リダイレクトは、もうページを読み込まないURLからのみ設定でき、ストアあたりの上限は100,000件です(Plusは20,000,000件)。 |
Wixから移行する場合は全ページを作り直すことになり、Squarespaceから移行する場合はエクスポートに含まれる内容をインポートし、残りを作り直すことになります。Shopifyへの移行では通常、商品URLが変わるため、マップはすべての商品を網羅する必要があります。
公開当日
- DNS。ホスティングやDNSを変更する場合は、少なくとも1週間前にTTLを短くしておきます。
- クロールのブロック。ステージング用の
noindexタグとrobots.txtのブロックを削除します。Googleは、開発中にnoindexを使ったURLをすべて控えておくことを推奨しています。 - リダイレクト。新サイトと同じリリースで公開します。
- リダイレクトのテスト。マップ全体をスクリプトで確認します。すべての旧URLが1回の転送で正しい最終URLに301または308で転送され、そのURLが200を返すことが条件です。
- Search Console。新サイトの所有権を確認し、新しいサイトマップと、再クロールを促すための旧URLのサイトマップを送信します。これらのURLがリダイレクトされるという警告が出るのは想定どおりです。
- アドレス変更ツール。ドメインを変更する場合は、新旧両方のプロパティを所有している同じGoogleアカウントから、wwwありとなしを含む旧ドメインのすべてのバリエーションについて送信します。
- 収益に関わる導線。実際にフォームを送信し、テスト決済を行い、アクセス解析のイベントが届くことを確認します。
- 自社のリンク。SNSのプロフィール、広告、ディレクトリ掲載を更新します。
公開後30日・60日・90日
1〜30日目:変動を想定する
順位は「Googleがサイトを再クロールして再インデックスしている間」は変動することがあり、「中小規模のサイトでは、ほとんどのページが動くまでに数週間かかり、大規模なサイトはさらに時間がかかります」。次の点を確認します。
- インデックスとサイトマップのレポート。旧サイトのインデックス済みURLは減り、新サイトでは増えます。
- ページ別のパフォーマンス。新しいURLで表示回数とクリック数が出始めます。
- サーバーログと404。想定外の404は、マップに抜けている行があるということです。2週間は毎日確認してください。
31〜60日目:ベースラインと比較する
上位のランディングページを新しいURLと比較します。クリックが減ったページについては、次の順に確認します。リダイレクトは1回の転送で正しいページに届いているか、コンテンツやタイトルは変わっていないか、内部リンクは今もそのページを指しているか、サイトマップに含まれているか。そのうえで、価値の高い被リンク元のサイトに更新を依頼します。
90日目以降:リダイレクトは残す
Googleのガイドでは、リダイレクトは「原則として少なくとも1年」維持し、ユーザーの視点からは「リダイレクトを無期限に維持することを検討」するよう勧めています。ドメイン移転の場合、アドレス変更ツールのページでは最低180日と定められており、それを過ぎても旧サイトがクロール可能な状態だと、Googleは旧サイトを無関係なものとして扱います。また、他の人に取得されないよう、旧ドメインの料金を「少なくとも1年間」支払い続けることも推奨しています。
チェックリスト
| フェーズ | タスク | 完了の目安 |
|---|---|---|
| 事前 | サイト、サイトマップ、サーバーログをクロールする | すべての旧URLとステータスコードを1つのリストにまとめている |
| 事前 | ランディングページと被リンクの多いページをエクスポートする | 上位ページと被リンク先がマップ上で目印付けされている |
| 事前 | フォーム、連携、スクリプト、ファイルを洗い出す | それぞれに担当者と新サイトでの対応方針がある |
| 事前 | リダイレクトマップを作成する | すべての旧URLに転送先があるか、404/410にするという判断が済んでいる |
| 構築 | サーバーサイドの301または308リダイレクト | 1回の転送で完結し、チェーンやホームページへの一括リダイレクトがない |
| 構築 | タイトル、ディスクリプション、canonical、hreflang | 旧ページと一致している。canonicalとhreflangは新URLを使用している |
| 構築 | 構造化データ、内部リンク、画像URL | リッチリザルトテストに合格し、リダイレクトを経由する内部リンクがない |
| 構築 | アクセス解析、コンバージョン、同意取得 | ステージングでイベントが作動し、同意が必要な場合は同意後にのみ作動する |
| 公開 | noindexとrobots.txtのブロックを削除する | 新URLがクロール可能になっている |
| 公開 | リダイレクトマップをテストする | すべての行が想定どおりのコードと転送先を返す |
| 公開 | Search Console:所有権の確認、サイトマップ、アドレス変更 | 重大なエラーなく送信できている |
| 公開後 | インデックス状況、404、パフォーマンスを監視する | 旧URLは減り、新URLで表示回数が増えている |
| 移行後 | リダイレクトと旧ドメインを維持する | 最低1年間 |
サイト移行のサポート
Dardo は、Cloudflare Workers 上のカスタム Astro 構成へサイトを移行します。リダイレクトマップは、公開前にテストしたうえでサイトとともに納品する成果物のひとつです。サイト移行のページをご覧ください。移行に合わせてデザインも一新する場合は、サイトリニューアルもご確認ください。移行をご検討中の方は、お気軽にご相談ください。
