リニューアルの打ち合わせは、デザインや機能の話が中心になりがちです。しかし公開の翌月に問い合わせが減り、調べると検索からの流入が半分になっていた、という相談は珍しくありません。原因の多くは、デザインではなく URL の引っ越しの手当てにあります。
URL が変わると、検索エンジンはそれまでの評価をどこに引き継ぐかを、リダイレクト（自動転送）を手がかりに判断します。転送が抜けたり行き先を誤ったりすると、積み上げた評価は新しいページに渡りません。
この記事では、Google の公式ガイドに沿って、リダイレクトマップ（旧 URL と新 URL の対応表）の作り方、ステータスコードの違い、よくある不具合、サーバー別の設定例、揺れの期間、工数の幅を整理します。リニューアルすべきかの判断は「ホームページをリニューアルすべき10のサイン」、費用の全体像は「リニューアルの費用相場と見積もりの読み方」で扱っています。
この記事が主に根拠にした情報
- Google Search Central「URL の変更を伴うサイト移転」「リダイレクトと Google 検索」「HTTP ステータスコード」「重複した URL の統合」
- Search Console ヘルプ「アドレス変更ツール」、IETF の RFC 9110
- Bing Webmaster Blog「Website Migration with Bing」（2020年12月）
- Search Engine Journal の892件のドメイン移転の調査（2025年1月）
| この記事で分かること | 答えの要点 |
|---|---|
| URL を変えると何が起きるか | 評価は転送を手がかりに移る。移転中は一時的に揺れる（第1章） |
| 何から手をつけるか | 旧 URL を全部集め、対応表を作る（第3・4章） |
| どのコードを使うか | 移転は301か308。302・307は一時的な転送だけ（第5章） |
| 何が事故になりやすいか | チェーン、ループ、トップへの一括転送、noindex の持ち越し（第6・12章） |
| どのくらいで落ち着くか | 公式は「数週間以上」。報告事例は幅が大きい（第10章） |
| 費用はどのくらいか | 50 URL 以下で10〜20時間が目安（第11章） |
1. URL を変えると何が起きるか
検索エンジンは「住所」で評価を覚えている
検索エンジンは、被リンクや内部リンク、検索結果でのクリックといった手がかりを、URL ごとに覚えています。URL が変わると、新しい URL は検索エンジンにとって「初めて見るページ」です。
旧 URL から新 URL への恒久的なリダイレクトがあって初めて、検索エンジンは「引っ越した」と理解します。Google はこれを「転送先を正規の URL にすべきだという強いシグナル」と説明しています。
W3C で1998年に公開された「Cool URIs don't change（良い URI は変わらない）」が説くとおり、URL を変えることは、外部のリンクや印刷物の QR コードなど、自社の外にある参照を切ることでもあります。
PageRank は失われないが、揺れは起きる
Google のサイト移転のガイドは、301などの恒久的なリダイレクトで PageRank は失われないと明記しています。一方で、移転中の一時的な順位の変動を想定するよう書いています。
| 公式の記述 | 意味すること |
|---|---|
| 恒久的な転送で PageRank は失われない | 正しく転送すれば評価は引き継げる |
| 移転中は一時的な変動を想定する | 公開直後の減少はある程度避けられない |
| 中規模のサイトで数週間以上かかる | 公開から1か月で結論を出さない |
| 転送は一般に少なくとも1年残す | 早く外すと移転が終わらない |
つまり結果を分けるのは、転送が正しいかどうかと、待つ期間の2つです。
2. 移転の種類で、やることが変わる
移転には5つの型がある
ひとくちにリニューアルと言っても、URL の変わり方はさまざまです。型によって、必要な作業と Search Console での手続きが変わります。
| 移転の型 | 例 | リダイレクト | アドレス変更ツール |
|---|---|---|---|
| URL は変わらない | サーバー・CMS だけ替える | 不要 | 不要 |
| プロトコルの変更 | http から https へ | 全 URL を301 | 不要 |
| ホスト名の変更 | www の有無を揃える | 全 URL を301 | 不要 |
| パスの変更 | /service.html から /services/ へ | 対応表で301 | 不要 |
| ドメインの変更 | example.jp から example.com へ | 対応表で301 | 使う |
URL が変わらない移転では転送は要らず、DNS の TTL を事前に下げ、旧サーバーへのアクセスがなくなるまで止めない、といった別の手順をとります。
一度に1つだけ変える
Google のガイドは、可能なら小さな段階に分けて、一度に1つだけ変えるよう勧めています。アドレス変更ツールのヘルプも、移転とリニューアルを同時に行うと流入を失う原因になり得るとしています。
ドメイン、構成、CMS を同じ日に変えると、流入が落ちたときに原因を切り分けられません。段階を分けられない場合も、変えなくて済む URL は変えないことで影響を小さくできます。設計の段階で「旧 URL をそのまま使えないか」を一度検討してください。
3. Google の公式手順を段階で見る
公開の6〜8週間前から始める
Google のガイドは作業を5段階に分けています。一般的なベストプラクティスの確認、新しいサイトの準備、URL の対応表の準備、移転の開始、流入の監視です。
時期は Google の文書にはなく、DevNJ の目安です。対応表を4週間前までに固めると、テスト環境で転送を試して直す時間がとれます。
| 段階 | 主な作業 | 見落としやすい点 |
|---|---|---|
| 1. 準備 | 新サイトの構築、Search Console で新旧を確認 | 新サイトの robots.txt と noindex |
| 2. 対応表 | 旧 URL の収集、新 URL への対応づけ | 画像・PDF・パラメータつき URL |
| 3. 切り替え | 転送を有効化、サイトマップ送信 | 内部リンクと canonical |
| 4. 監視 | Search Console、ログ、アクセス解析 | 旧サイト側の流入が減っているか |
この表の右の列が、公開後の流入減の原因として最も多いところです。
新しいサイトの準備で確かめること
テスト環境は、robots.txt で巡回を止めたり、全ページに noindex を入れたりして検索から隠します。Google は、開発中だけ必要だった noindex や robots.txt のブロックを公開時に外すよう書いています。外し忘れると、どれほど正しく転送しても新しいページは検索に出ません。
4. リダイレクトマップの作り方
旧 URL を漏れなく集める
対応表は、旧 URL の一覧が完全であることが前提です。CMS の管理画面のページだけを並べると、PDF、キャンペーンページ、パラメータつきの URL、削除したが外部からリンクされている URL が漏れます。
| 出どころ | 拾えるもの | 注意点 |
|---|---|---|
| 現在の XML サイトマップ | CMS が把握している公開ページ | 載っていないページが多い |
| クローラーでの巡回 | 内部リンクでたどれる URL | 孤立したページは拾えない |
| Search Console | 検索で表示・クリックされた URL | 直近16か月分まで |
| アクセス解析 | 実際に閲覧されたページ | 計測タグのないページは出ない |
| サーバーのログ | 人とボットが要求した URL | 期間を長めにとる |
| 被リンクの調査ツール | 外部からリンクされた URL | 削除済みのページも見つかる |
この表の下の2つは、「もう存在しないはずなのに、外部から今もリンクされている URL」を拾える数少ない手段です。
列の設計と対応づけのパターン
集めた URL は1行に1つずつ並べ、旧 URL、新 URL、処理（301・410・変更なし）、優先度、根拠、確認結果の列を用意します。根拠を残すと、公開後に行き先の理由をたどれます。
| パターン | 例 | 処理 |
|---|---|---|
| 1対1 | 旧「会社概要」→ 新「会社概要」 | 301で転送 |
| 統合（多対1） | 旧の事例3ページ → 新の事例ページ | 内容を引き継いでいれば301 |
| 廃止（1対0） | 終了したキャンペーン | 404か410を返す |
判断が分かれるのは統合です。Google は、多くの旧 URL を関係のない1つの URL（新しいトップページなど）へまとめて転送しないよう書いています。対応するページがないなら、無理に転送せず404か410を返すほうが素直です。
優先度で確認の手間を配分する
Search Console でクリック数の多いページと被リンクの多いページを優先度 A とし、そこだけは公開前に転送先の内容を1件ずつ目で確かめます。検索の流入は、多くの場合一部のページに集中しています。
5. 301・302・307・308 の違いと Google の扱い
RFC 9110 での定義
HTTP の転送の意味は、IETF の RFC 9110 で定められています。301（Moved Permanently）と308（Permanent Redirect）は「新しい恒久的な URI が割り当てられた」、302（Found）と307（Temporary Redirect）は「一時的に別の URI にある」ことを示します。
違いはフォームの送信方法の扱いです。RFC 9110 は301と302について、歴史的な理由でブラウザなどが次のリクエストで POST を GET に変えてよいと注記し、避けたい場合は308や307を使うよう書いています。308は2014年に RFC 7538 で定義された比較的新しいコードです。
Google はどう扱うか
Google は、301と308を転送先を正規 URL とする強いシグナル、302と307を弱いシグナルとして扱います。そのうえで、意味が違うので状況に合ったコードを使うよう求めています。方式ごとの扱いは次のとおりです。
| 方式 | 恒久か一時か | Google の扱い | 使う場面 |
|---|---|---|---|
| 301 / 308 | 恒久 | 転送先が正規 URL になる | 移転の基本 |
| 302 / 303 / 307 | 一時 | 転送元が正規 URL のまま | メンテナンス中 |
| 0秒の meta refresh | 恒久 | 恒久として扱う | サーバーを触れないとき |
| JavaScript の転送 | 恒久 | 描画に失敗すると認識されない | 最後の手段 |
最も確実に扱われるのはサーバー側の301か308です。meta refresh や JavaScript は、サーバーの設定を変えられない環境のための代替と考えてください。
どれを選ぶか
ページの移転なら301で足ります。ページを開く操作（GET）では POST の問題は起きません。フォームの送信先や API の URL を変えるなら308を選びます。
注意点は2つです。RFC 9110 は301と308を「ヒューリスティックにキャッシュできる」としており、誤った転送を301で出すと、直してもしばらくブラウザに残ることがあります。また、既定値が302のフレームワークもあるので、移転で302を出していないか確かめます（第8章）。
6. チェーン・ループ・ソフト404を防ぐ
チェーン：転送を重ねない
チェーンとは、旧 URL から最終の URL までに転送が何回も重なる状態です。「http の旧 URL → https → www なし → 新しいパス」のような形で、過去の転送を残したまま新しい転送を足すと起きます。
Google のクローラーは最大10回まで転送をたどります。ただし移転のガイドは、最終の行き先に直接送り、無理なら理想的には3回以下、5回未満にとどめるよう勧めています。
チェーンは速度の問題でもあります。Chrome for Developers は、転送はネットワークの往復を増やし、読み込みを数百ミリ秒遅らせることがあるとしています。防ぐには、対応表の新 URL の列に最終の URL だけを書き、http・www・末尾のスラッシュも1回の転送で揃えます。過去の転送の行き先も今回の新 URL に書き換えます。
ループ：転送が元に戻る
ループは、A から B、B から A へと転送が循環する状態です。よくある原因は、サーバーが「末尾にスラッシュを付ける」、アプリケーションが「外す」転送を出してぶつかることです。
ソフト404：転送しすぎも問題になる
ソフト404とは、ページが存在しないのに「成功（200）」を返したり、関係のないページへ転送したりする状態です。Search Console のヘルプは、存在しないページで404を返す代わりにトップページへ転送すると、Google がサイトの構造を理解しにくくなると注意しています。
| 不具合 | 症状 | 確認方法 |
|---|---|---|
| チェーン | 転送が2回以上続く | curl やクローラーで回数を数える |
| ループ | 「リダイレクトが多すぎます」 | ブラウザと Search Console |
| ソフト404 | 無関係な転送か空のページ | Search Console のソフト404 |
| 302のまま | 旧 URL が検索結果に残る | 応答のステータスコード |
| パラメータ落ち | 転送後に条件が消える | ?付きの URL で試す |
チェーンとループは、本番の CDN でしか再現しないことがあるので、公開直後に本番でも確かめます。
7. canonical・hreflang・サイトマップ・内部リンクを揃える
シグナルを同じ方向に向ける
Google の「重複した URL の統合」の文書は、正規の URL を示す方法として、リダイレクト（強いシグナル）、rel="canonical"（強いシグナル）、サイトマップへの掲載（弱いシグナル）を挙げ、組み合わせると効果が重なるとしています。逆に、方法ごとに別の URL を示すと正規の URL が分からなくなります。
| 項目 | 揃え方 | 公式の注意点 |
|---|---|---|
| rel="canonical" | 新 URL が自分自身を指す | 旧 URL を指していないか |
| hreflang | 言語版どうしを新 URL で指し合う | 相互でないと無視される |
| XML サイトマップ | 新 URL だけを送信 | 完全な URL、5万 URL か50MB まで |
| 内部リンク | 本文・メニュー・フッターを書き換え | 正規の URL に一貫してリンク |
| robots.txt | 止めたいものだけ止める | 正規化に使わない |
内部リンクが旧 URL のままだと、サイト内を移動するたびに転送が起き、チェーンの原因にもなります。
旧 URL を robots.txt でブロックしない
Google は、正規化に robots.txt を使わないよう明記しています。また、同じサイトの中で正規の URL を選ばせる目的で noindex を使うことも勧めていません。
旧 URL が検索結果に残っているからとブロックするのは逆効果で、クローラーが転送を読めなくなり、評価の移転が止まります。旧 URL は巡回できる状態のまま、301を返し続けてください。
hreflang とサイトマップ
Google の文書は、hreflang について2つのページが互いを指していなければ無視されること、URL は https を含む完全な形で書くことを説明しています。言語版が3つあれば、対応表もテストも3倍になるので、対応表に言語の列を足しておくと整理できます。
サイトマップは新しい URL のものを送信し、旧サイトマップは後で外して構いません。lastmod は一貫して正確な場合だけ使われ、priority と changefreq は無視されます。
8. サーバー別の設定例
どこで転送するかを先に決める
転送は、Web サーバー、アプリケーション、CMS のプラグインのどこでも設定できます。検索エンジンから見た結果は同じですが、速さと管理のしやすさが違います。
| 設定場所 | 向いている規模 | 長所 | 注意点 |
|---|---|---|---|
| Apache（.htaccess） | 数百行まで | 共用サーバーでも使える | 行数が多いと処理が重い |
| Nginx（map・return） | 数千行以上 | 速く、大量の対応表に強い | 反映にサーバー権限が要る |
| Laravel のルート | 数十〜数百行 | コードと一緒に管理できる | 既定は302 |
| WordPress のプラグイン | 数百行まで | 管理画面で編集できる | PHP を通るぶん遅い |
対応表が大きいほど、アプリケーションより手前の Web サーバーで処理するほうが有利です。以下は、/service.html を /services/ へ、旧ブログの /blog/2019/post-name.html を /column/post-name/ へ移し、終了したキャンペーンに410を返す例です。
Apache（.htaccess）
mod_rewrite の RewriteRule に R=301 を付けると恒久的な転送になります。mod_alias の Redirect と混ぜると処理の順番で思わぬ結果になることがあるので、どちらかに揃えます。
RewriteEngine On
RewriteRule ^service\.html$ /services/ [R=301,L]
RewriteRule ^blog/[0-9]{4}/([a-z0-9-]+)\.html$ /column/$1/ [R=301,L]
RewriteRule ^campaign-2019/ - [G,L]
[G] は410（Gone）を返す指定です。数千行になる場合は、サーバー設定の RewriteMap を使うと速く処理できます。
Nginx
return 301 を使います。大量の1対1の対応は map に並べると、対応表をそのまま設定に移せます。
map $uri $new_uri {
default "";
/service.html /services/;
}
server {
if ($new_uri) { return 301 $new_uri; }
location ~ ^/blog/[0-9]{4}/([a-z0-9-]+)\.html$ { return 301 /column/$1/; }
location ^~ /campaign-2019/ { return 410; }
}
map は http ブロックに置きます。$uri はクエリ文字列を含まないので、?id=12 のようなパラメータで内容が変わる旧 URL は $args も条件に入れます。
Laravel のルート
公式ドキュメントのとおり、Route::redirect の既定のステータスコードは302です。移転には第3引数で301を指定するか、Route::permanentRedirect を使います。
Route::permanentRedirect('/service.html', '/services/');
Route::get('/blog/{year}/{slug}.html', fn (string $year, string $slug) =>
redirect("/column/{$slug}/", 301))->whereNumber('year');
WordPress のプラグイン
WordPress 本体には、投稿のスラッグを変えたときに旧スラッグから転送する機能があります（wp_old_slug_redirect）。ただし投稿単位の機能で、サイト全体の構造を変えるリニューアルには足りません。
よく使われるのは、2026年10月時点で200万以上のサイトで有効なプラグイン「Redirection」です。正規表現、404の記録、CSV の読み込み、Apache と Nginx の設定への書き出しに対応しています。対応表を CSV で読み込み、規模が大きくなったら Web サーバーの設定に移す、という使い方ができます。
9. Search Console と Bing での手続き
アドレス変更ツールを使う条件
アドレス変更ツールは、ドメインやサブドメインを変える移転だけに使います。HTTP から HTTPS、www の有無、ホスティングや CDN の変更、一部ページの移動には使いません。
| 条件・仕様 | 内容 |
|---|---|
| 使える移転 | ドメイン・サブドメインの変更 |
| 所有者 | 旧・新を同じ Google アカウントで確認済み |
| 事前の作業 | 旧トップから新トップ、主要ページの301 |
| 効果の期間 | 移転の開始から180日 |
| 転送の維持 | 少なくとも180日。流入があればそれ以上 |
| 取り消し | 180日以内なら可能 |
ツールは転送の代わりではなく、正しい転送を前提に、新サイトの評価の移転を優先させるものです。ヘルプは、移転を A から B、B から C と連ねないこと、複数のサイトを同時に1つにまとめないことも勧めています。
Bing のサイト移動ツール
欧州向けのサイトでは Bing の対応も確認します。Bing の Webmaster Blog（2020年12月）は、旧ドメインの転送を少なくとも1〜2年、できればそれ以上残し、所有権を確認したうえでサイト移動ツールで知らせるよう勧めています。URL 送信や IndexNow（更新した URL を検索エンジンに知らせる仕組み）で転送や削除を通知することもできます。
公開後に見る画面
| 画面 | 見るもの | 頻度の目安 |
|---|---|---|
| ページのインデックス登録 | 新 URL の登録数、404・ソフト404・転送のエラー | 最初の1か月は週1回 |
| URL 検査 | 優先度 A のページの登録状態 | 公開直後に1件ずつ |
| 検索パフォーマンス | 旧・新 URL ごとのクリック数 | 週1回、3か月 |
| クロールの統計情報 | 応答の内訳（301・404・5xx） | 週1回 |
Google のガイドは、理想的には旧サイトの流入が下がり、新サイトの流入が上がると書いています。両方が同時に下がっているなら、転送か新サイトの側に問題があります。
10. 移転後の揺れはどのくらい続くか
公式の記述
期間についての Google の記述は多くありません。移転中の一時的な変動を想定すること、中規模のサイトで新しい URL に置き換わるまで数週間以上かかり、大きなサイトではさらに長いこと、の2点です。期間に関わる公式の数字は、ほかにアドレス変更ツールの180日と、転送の維持の目安があります。
報告事例：平均は長いが、幅が大きい
公式以外でよく引かれるのが、Search Engine Journal に掲載された Dan Taylor 氏の調査です（2025年1月更新、データは2024年10月22日集計）。892件のドメイン移転で、新ドメインが旧ドメインと同じ水準の推定の検索流入に戻るまでの日数を数えています。
| 項目 | 2025年の更新版 | 2023年の初版 |
|---|---|---|
| 対象 | 892件のドメイン移転 | 171件 |
| 元の水準に戻るまでの平均 | 523日 | 229日 |
| 1,000日で戻らなかった割合 | 17% | 42% |
| 最も早く戻った例 | 19日・22日・23日・33日 | 記載なし |
この数字は扱いに注意が必要です。第三者のツールによる推定値で、サイト自身の解析の数字ではありません。対象はドメインを変えた移転で、パスだけを変えるリニューアルとは条件が違います。事例の一部は SEO の関係者から集めたもので、市場全体を代表する標本でもありません。それでも、数週間で戻る例もあれば、1年以上戻らない例もあることは読み取れます。
揺れを短くする要因、長くする要因
公式の文書と報告事例から読み取れる傾向を並べます。因果を証明したものではありません。
| 揺れを短くする要因 | 揺れを長くする要因 |
|---|---|
| 1対1の転送、内容も同じ | トップページへの一括転送 |
| 転送1回で最終の URL に届く | チェーン、302のまま |
| URL だけを変え、構造と中身は保つ | ドメイン・構造・中身を同時に変える |
| 内部リンク・canonical を揃える | 旧 URL への内部リンクが残る |
| 公開後に毎週エラーを直す | 公開後に誰も見ていない |
公開直後の減少で慌てて構造を変えると、揺れが長引くことがあります。エラーの修正と、構造の変更は分けて判断してください。
11. 費用と工数の幅
規模別の目安
リダイレクトの作業だけを切り出した公的な相場はありません。以下は制作の現場での整理にもとづく目安で、統計ではありません。オランダの時間単価の調査（フリーランスのWeb開発者€73、制作会社の平均€106、BTW 抜き）を掛け、欧州中央銀行の2026年10月22日の参照レート（1ユーロ＝175.97円）で換算しました。単価の出典は「リニューアルの費用相場と見積もりの読み方」にあります。
| 規模（旧 URL の数） | 工数の目安 | ユーロ換算 | 円換算の目安 |
|---|---|---|---|
| 50以下（企業サイト） | 10〜20時間 | €730〜€2,120 | 約13万〜37万円 |
| 50〜500（事例・ブログあり） | 20〜50時間 | €1,460〜€5,300 | 約26万〜93万円 |
| 500〜5,000（EC・多言語） | 50〜120時間 | €3,650〜€12,720 | 約64万〜224万円 |
工数は、旧 URL の収集から公開後3か月の監視までを含みます。URL が規則で変わるサイトは下限に、ページごとに判断するサイトは上限に近づきます。
見積もりで確かめること
見積もりに「リダイレクト設定」と1行だけの場合は、範囲を確かめます。公開直前に「対応表は発注側で」と言われることもあります。
| 確かめる項目 | 曖昧なときに起きること |
|---|---|
| 旧 URL の収集を誰が行うか | CMS の一覧だけで作られ、PDF や被リンクが漏れる |
| 対応づけの判断を誰が行うか | 内容を知らない人がトップへ送る |
| 公開前のテストの範囲 | 一部だけ、または未実施 |
| canonical・hreflang・内部リンク | 転送だけでシグナルがばらつく |
| 公開後の監視の期間 | 公開日で契約が終わり、エラーが放置される |
この5項目が見積もりにあれば、工数の差を範囲の差として比べられます。
12. よくある失敗例
公開日に起きる失敗
特定の会社の事例ではなく、公式の文書が注意を促している点と、現場でよく見る点をまとめたものです。
| 失敗 | 何が起きるか | 防ぎ方 |
|---|---|---|
| noindex・robots.txt の持ち越し | 新サイトが検索から消える | 公開直後に URL 検査 |
| 全ページをトップへ転送 | ソフト404として扱われる | 1対1の対応表を作る |
| 302で設定した | 旧 URL が正規のまま残る | 応答コードを公開前に確認 |
| 内部リンクが旧 URL のまま | 転送が増えチェーンになる | 本文とメニューを一括置換 |
| hreflang が旧 URL を指す | 言語版の対応が無視される | 対応表に言語の列を足す |
半年後・1年後に起きる失敗
1つ目は、サーバー移行のついでに転送を早く外すことです。外部のリンクは書き換えられないことが多いので、転送は外さない前提で管理します。
2つ目は、旧ドメインの契約を切ることです。転送が消え、第三者に取得されると、旧ドメインへのリンクが他人のサイトに向かいます。
3つ目は、次のリニューアルで転送を重ねることです。対応表を保管し、次回は過去の転送の行き先も書き換えます。
13. 日本と欧州の両方に向けたサイトで増える作業
多言語サイトで変わること
日欧の両方で使うサイトは、言語版ごとに URL があるため作業が増えます。Google の多地域・多言語サイトの文書は、国別ドメイン、サブドメイン、サブディレクトリを選択肢に挙げ、URL のパラメータで言語を切り替える方式は勧めないとしています。
| 項目 | 日本向けだけのサイト | 日本と欧州に向けたサイト |
|---|---|---|
| 対応表の行数 | ページ数 | ページ数 × 言語の数 |
| hreflang の更新 | 不要なことが多い | 全言語版を相互に更新 |
| 確認する検索エンジン | 主に Google | Google と Bing |
| 言語の自動転送 | 問題になりにくい | 避ける |
日本語版を example.jp、英語版を example.com で運用していたサイトを1つにまとめる場合は、2つのサイトを統合する移転です。アドレス変更ツールのヘルプのとおり、一度に1つずつ移すほうが安全です。
言語の自動転送を避ける
ブラウザの言語や IP アドレスで言語版へ自動転送する仕組みは、Google が避けるよう書いているものです。すべての言語版が見られなくなるおそれがあるためで、案内はページ上の切り替えリンクと hreflang で行います。
14. ケースで考える（架空の例）
以下は移転の型が違う3つの架空のケースで、実在の会社ではありません。
ケースA：日本の製造業、CMS の乗り換え
旧 URL は約40。/?page_id=12 が /products/ の形に変わり、ドメインは変えません。流入の8割を占める製品ページ5つと会社概要を優先度 A にし、外部からリンクされた PDF のカタログも個別に転送します。
ケースB：オランダの日系サービス会社、2つのドメインの統合
日本語版の example.jp と英語版の example.nl を、example.com の /ja/ と /en/ にまとめます。旧 URL は2言語で約300。英語版を先に移し、1〜2か月おいて日本語版を移します。hreflang を相互に設定し直し、Bing にも知らせ、旧ドメイン2つは少なくとも2年更新します。
ケースC：EU 向けの通販、商品 URL の規則的な変更
旧 URL は約3,000。/item.php?id=123 が /products/123-name/ に変わります。対応はデータベースの商品 ID から機械的に作れるので、Nginx の map に書き出します。販売終了の商品は後継があれば転送、なければ410です。
| 項目 | ケースA | ケースB | ケースC |
|---|---|---|---|
| 旧 URL の数 | 約40 | 約300（2言語） | 約3,000 |
| 移転の型 | パスの変更 | ドメインの統合 | パスの変更 |
| アドレス変更ツール | 使わない | 使う（1つずつ） | 使わない |
| 対応表の作り方 | 手作業 | 手作業＋言語の列 | データベースから生成 |
| 工数の目安 | 10〜20時間 | 30〜50時間 | 60〜100時間 |
ページ数よりも、移転の型と、対応づけを機械的にできるかで作業の性質が変わります。
15. 公開前後のチェックリスト
公開の4週間前まで
- 旧 URL を6つの出どころから集めた
- すべての旧 URL に「301・410・変更なし」を決めた
- 優先度 A のページの転送先を、内容まで確認した
- トップページへの一括転送をしていない
公開の前日まで
- テスト環境で対応表の全行を自動で確認した
- すべての転送が1回で最終の URL に届く
- 末尾のスラッシュや http・https でループしない
- canonical・hreflang・内部リンクが新 URL を指している
公開日
- 開発用の noindex と robots.txt のブロックを外した
- 本番で301（または308）が返る（302になっていない）
- 新しいサイトマップを Google と Bing に送信した
- ドメインを変えた場合はアドレス変更ツールで知らせた
公開後3か月
- 週1回、404・ソフト404・転送のエラーを確認している
- ログで404になっている旧 URL を拾い、対応表に足している
- 転送を少なくとも1年（Bing を考えると2年）残すことを保守の担当に伝えた
- 旧ドメインの契約を更新し続ける手配をした
まとめ
- URL を変えると、検索の評価はリダイレクトを手がかりに移る。変えずに済むなら変えないのが最も安全
- Google は恒久的な転送で PageRank は失われないとする一方、移転中の一時的な変動を想定するよう案内している
- 対応表は旧 URL を漏れなく集めることが前提。1対1で送り、対応先がなければ404か410
- 移転には301か308。302・307は一時的な転送だけ
- 転送は1回で最終の URL に届くようにし、canonical・hreflang・サイトマップ・内部リンクを揃える
- アドレス変更ツールはドメインを変えるときだけ。転送は Google の目安で少なくとも1年、Bing の目安で1〜2年以上
- 揺れの期間は公式には「数週間以上」。報告事例は幅が大きく、エラーの修正と構造の変更を分けて判断する
参考にした情報源
Google 検索
- Site moves with URL changes — Google Search Central：移転の段階、301・308、チェーン、1年の維持、一時的な変動
- Site moves without URL changes — Google Search Central：URL を変えないサーバー移転
- Redirects and Google Search — Google Search Central：転送の方式ごとの扱い
- How HTTP status codes affect Google's crawlers — Google Search Central：最大10回の転送、シグナルの強さ、ソフト404
- How to specify a canonical URL — Google Search Central：正規化の方法とシグナルの強さ
- Tell Google about localized versions of your page — Google Search Central：hreflang の相互参照
- Managing multi-regional and multilingual sites — Google Search Central：URL の構成、自動転送を避ける
- Build and submit a sitemap — Google Search Central：上限と lastmod
- Change of Address tool — Search Console ヘルプ：使える条件と180日
- 404 (Page Not Found) errors — Search Console ヘルプ：ソフト404
- Page indexing report — Search Console ヘルプ：登録状況とエラー
- URL Inspection tool — Search Console ヘルプ：個別の URL の確認
- Crawl Stats report — Search Console ヘルプ：応答コードの内訳
HTTP の規格・Web の基本
- RFC 9110: HTTP Semantics — IETF：301・302・307・308の定義
- RFC 7538 — IETF：308の最初の定義
- Cool URIs don't change — W3C：URL を変えないことの意義
- Avoid multiple page redirects — Chrome for Developers：転送による遅延
サーバー・CMS
- mod_rewrite による転送 — Apache HTTP Server：RewriteRule と RewriteMap
- mod_alias — Apache HTTP Server：Redirect の書き方
- ngx_http_rewrite_module — nginx：return
- Routing — Laravel 13.x：Route::redirect の既定値302
- wp_old_slug_redirect() — WordPress Developer Resources：スラッグ変更時の転送
- Redirection — WordPress.org：機能と有効インストール数
Bing・報告事例
- Website Migration with Bing — Bing Webmaster Blog：移転の手順と転送の維持期間
- URL Submission — Bing Webmaster Tools：転送・削除の通知
- IndexNow：更新の通知の仕組み
- How Long Should An SEO Migration Take? — Search Engine Journal：892件のドメイン移転の調査
いずれも2026年10月23日に確認したものです。検索エンジンの仕様と画面の名称は変わることがあるため、作業の前に最新の文書を確認してください。図1の時期、第10章の要因、第11章の工数、第14章のケースは DevNJ の整理で、統計にもとづく基準ではありません。
よくある質問
- リニューアルで URL が変わると、検索順位は下がりますか？
- 一時的に揺れることは想定しておく必要があります。Google は URL を変える移転について、移転中の一時的な順位の変動を想定するよう案内しています。旧 URL から内容の対応する新 URL へ301か308で転送し、内部リンクやサイトマップを新 URL に揃えると、評価の引き継ぎを助けられます。
- 301リダイレクトはどのくらいの期間残せばよいですか？
- Google は「できるだけ長く、一般に少なくとも1年」と案内しています。Search Console のアドレス変更ツールを使う場合は、少なくとも180日の維持が条件です。Bing は旧ドメインの転送を少なくとも1〜2年、できればそれ以上残すよう勧めています。旧ドメインの契約も同じ期間は更新してください。
- 301と308、302と307はどう使い分けますか？
- 恒久的な移転には301か308、一時的な転送には302か307を使います。Google は301と308を同じ「強いシグナル」、302と307を「弱いシグナル」として扱います。違いはフォームの送信方法の扱いで、308と307は POST を GET に変えません。ページの移転なら301で足ります。
- 古いページをすべてトップページにリダイレクトしてもよいですか？
- 避けてください。Google は多くの旧 URL を関係のない1つの URL（新しいトップページなど）へまとめて転送しないよう案内しており、そうした転送はソフト404として扱われることがあります。内容が対応するページへ1対1で送り、対応先がないページは404か410を返すのが基本です。
- Search Console のアドレス変更ツールは、どんなときに使いますか？
- ドメインやサブドメインを変えるとき（example.com から example.net へなど）だけ使います。HTTP から HTTPS への変更、www の有無の切り替え、同じドメインの中でパスだけを変えるリニューアルでは使いません。旧サイトと新サイトの両方を、同じ Google アカウントで所有者として確認しておく必要があります。
- リダイレクトの設定にかかる費用はどのくらいですか？
- ページ数と URL の変わり方で変わります。この記事の目安では、50 URL 以下の企業サイトで10〜20時間、50〜500 URL で20〜50時間です。オランダの時間単価（€73〜€106）で計算すると、それぞれ約13万〜37万円、約26万〜93万円です。統計ではなく制作の現場での整理です。
日本と欧州の両方で機能するサイトをお考えですか？
無料で相談する
