リニューアルで最も多い失敗は、公開後に検索からの流入が落ちることです。原因のほとんどは、移行の設計を省いたことにあります。この記事では、手順と確認項目を整理します。
リニューアルを判断する基準
目的があるかを先に確認します。 「古くなったから」だけでは、作り直しても結果は変わりません。
成果が出ていない：問い合わせが来ない、来訪後すぐ離脱する。ただし、原因が構造にあるのか内容にあるのかを先に切り分けます。
更新できない：自社で直せない構成のため、小さな修正にも費用と時間がかかる。
スマートフォンで使いにくい：実機で確認して問題がある場合。
事業内容が変わった：載せている情報が実態と合っていない。
安全上の問題がある：使っている仕組みの更新が止まっている。
内容の問題であれば、作り直さずに直せます。 全面的な作り替えは、費用と期間、そして移行の危険を伴います。
準備1：現状を記録する
作り替える前に、今の数値を残します。 比較できないと、リニューアルの効果を判断できません。
流入の数値：表示回数、クリック数、平均掲載順位。検索の管理ツールで確認します。
主要なページ：流入が多いページ、成果につながっているページの一覧。
外部からのリンク：どこからリンクされているか。
成果件数：問い合わせ、電話、資料請求。
期間を決めて記録します。 直前の1か月だけでなく、季節の変動が分かる期間を残します。
準備2：URLが変わるかを決める
ここが最も重要な分岐です。
Google 検索セントラルでは、URLを変更する移転と、ホスティングの変更などURLを変更しない場合とで、参照するドキュメントが分かれています。
URLを変更する移転の例として挙げられているのは、HTTPからHTTPSへのURLの変更、ドメイン名の変更、または複数のドメインやホスト名の統合、URLパスの変更です。
URLを変えずに済むなら、変えないほうが安全です。 デザインと内容だけを変える場合、移行の危険は大きく下がります。
準備3：URLの対応表を作る
URLが変わる場合、公式ドキュメントでは現在のURLから対応する新しい形式へのURLマッピングを準備することが手順として示されています。
すべてのURLを一覧にします。 抜けたページは、公開後に見つからない状態になります。
対応先を決めます。 同じ内容のページがあるならそこへ、なくなるページは近い内容のページへ。
なくすページを決めます。 流入も成果もないページは、無理に残さない判断もあります。ただし、外部からリンクされているページは慎重に扱います。
準備4：一度に変えることを減らす
公式ドキュメントには、一度に行う変更を1つのみにすることが示されています。サイトに対する変更を1つずつ順に行い、すべてを同時に変更しないよう計画することが案内されています。例として、CMSの変更、レイアウトの変更、ドメインの移転を、一度に1つずつ行うことが挙げられています。
また、サイトの規模が大きく技術的に可能な場合は、最初にサイトの一部を移転してトラフィックと検索のインデックス登録への影響をテストすることが推奨されています。最初にテストする部分は、あまり頻繁に変更されない部分、よく起きる状況や予測できない出来事によって大きな影響を受けない部分を選ぶよう案内されています。
同時に全部を変えると、問題が起きたときに原因が特定できません。
移行の実施
公式ドキュメントで示されている手順は次のとおりです。新しいサイトを準備して十分にテストする、URLマッピングを準備する、元のURLから新しいURLにリダイレクトするようサーバーを設定して移転を開始する、元のURLと新しいURL両方のトラフィックを観察する。
実施の時期についても案内があります。 トラフィックが周期的に変動する場合や特定の曜日に少なくなる場合は、トラフィックが多くないときにタイミングを合わせて移転するのが得策とされています。問題が発生しても影響を受けるユーザーを最小限にとどめられ、クロールのためにより多くのサーバー リソースを割けると説明されています。
リダイレクトについて：公式ドキュメントには、301やその他の永続的なリダイレクトによってPageRankの損失が生じることはないと明記されています。
順位の変動を前提にする
公式ドキュメントには、移転中、サイトのランキングが一時的に変動することを想定するよう示されています。
大幅な変更があった場合、Googleがサイトを再クロールしてインデックスに登録し直す間にランキングが変動することがあると説明されています。そして、原則として、中規模のサイトでほとんどのページの移転がインデックスに反映されるのに数週間かかり、より大規模なサイトであればそれより長くかかるとされています。
処理の速度は主にURLの数とサーバーの速度によって異なるとされ、サイトマップを送信すると検出プロセスの時間を短縮できると案内されています。
公開直後の数値で判断しないようにします。 社内にもこの前提を共有しておきます。
公開後の観察
公式ドキュメントでは、Search Console を使用すること、各プロパティのデータを個別に確認することが案内されています。
インデックス ステータス レポートで概要を確認する。
サイトマップ レポートで、サイトマップで送信されたURLのうちインデックス登録されたURLの数を確認する。
あわせて確認するのは次の点です。リダイレクトが正しく動いているか、見つからないページが出ていないか、問い合わせが届いているか、主要なページの流入がどう推移しているか。
問い合わせの動作確認は必ず行います。 リニューアル後に届かなくなる事故が起きやすい箇所です。
ホスティングだけを変える場合
URLを変えずにサーバーだけを変える場合は、公式ドキュメントの別のガイドが用意されています。URLが変わらないため、移転の設計は簡単になります。
ただし、切り替えの前後で表示が止まらないこと、証明書が正しく設定されていることは確認します。
リニューアルでよくある失敗
移行の設計を見積もりに含めない：公開後に流入が落ちてから、追加費用が発生します。
URLの一覧を作らない：抜けたページが見つからない状態になります。
同時に全部を変える：問題の原因を特定できません。
現状の数値を残さない：効果を判断できません。
公開直後に判断する：反映には時間がかかると公式に説明されています。
問い合わせの動作を確認しない：その間の機会を失います。
この記事のまとめ
リニューアルは、目的を確認し、現状の数値を記録し、URLが変わるかを決めるところから始めます。URLを変えずに済むなら、そのほうが安全です。
URLが変わる場合は、対応表を作り、リダイレクトを設定し、新旧両方のトラフィックを観察します。公式ドキュメントでは、一度に行う変更を1つにすること、トラフィックの少ない時間帯に行うこと、ランキングの一時的な変動を想定することが示されています。
反映には数週間以上かかる場合があると説明されています。公開直後の数値で判断しないようにします。
出典と注記
移転の手順、対応表の準備、変更を1つずつ行うこと、時間帯の選び方、ランキングの変動と反映までの期間、リダイレクトの扱い、Search Console での確認は Google 検索セントラル「サイトを移転する方法」に基づきます。URLを変更しない場合の扱いは同「ウェブ ホスティングの変更と SEO」に基づきます（いずれも確認日 2026年8月20日時点）。公式ドキュメントは更新されるため、実務では最新の記載を確認してください。 判断の基準とよくある失敗は当社が支援の現場で用いている整理です。成果を保証するものではありません。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。