Webサイトのリニューアルで検索流入を落とさないためには、新しいデザインだけでなく、旧URLから新URLへの対応表、リダイレクト、重要ページの本文、公開後の計測を公開前に決める必要があります。URLを変えずにデザインだけを変更する場合と、ドメインやURL構造まで変える場合では、SEO上の確認点が異なります。
検索順位を維持できると保証する方法はありません。Googleは、大きなサイト変更後には再クロール・再インデックスの間に検索表示が一時的に変動し得ると説明しています。だからこそ、変更前の実績を保存し、旧ページと新ページを対応づけ、公開後に落ちたページを特定できる状態を作ることが重要です。
まず「何を変えるリニューアルか」を分ける
最初に変更範囲を一覧化します。デザイン、CMS、サーバー、ドメイン、URL構造、本文、見出し、内部リンク、フォーム、計測タグは、それぞれ影響が違います。複数を同時に変えるほど、不具合が出たときに原因を切り分けにくくなります。
- URLを維持する：本文やナビゲーション、モバイル表示、速度、タグの出力を重点確認する。
- URLを変更する：旧URLと新URLの対応表、恒久リダイレクト、canonical、内部リンクを確認する。
- ドメインも変更する：上記に加え、旧・新プロパティ、DNS、証明書、サイトマップ、Search Consoleの扱いを確認する。
「全面リニューアル」と言っても、全ページのURLを変える必要はありません。成果の出ているURLを維持できるなら、その選択も検討します。一方、統合・削除が必要なページには、検索意図に合う移行先を決めます。
公開前に保存すべき検索実績とページ一覧
Search Consoleでページごとの表示回数、クリック、CTR、平均掲載順位、主なクエリを保存します。GA4では自然検索のセッション、主要ページ、問い合わせなどの成果を保存します。期間は季節変動を考慮し、直近28日だけでなく数か月単位も見ます。数値が取れない場合は「取得不能」と記録し、PVの別ツール値を同じ指標として混ぜないでください。
サイトマップ、主要なランディングページ、被リンクの多いページ、問い合わせを生んでいるページを優先リストにします。単にアクセスの少ないページを削除すると、特定の商談クエリや内部リンクの入口を失う場合があります。ページの役割と残す理由を確認してから、維持・統合・削除を判断します。
URL変更時は1対1の対応表を作る
旧URLごとに、内容が最も近い新URLを決めます。Googleのサイト移行ガイドは、旧URL一覧の作成、対応表、サーバー側の恒久リダイレクト、内部リンクとcanonicalの更新を案内しています。大量の旧ページを無関係なトップページへ一括転送すると、利用者も検索エンジンも目的の情報に到達できません。
旧URL→新URL→別URLという長い転送の連鎖も避けます。最終URLへ直接到達できるようにし、転送先がHTTP 200で表示されることを確認します。URLを統合する場合は、新ページに旧ページの重要な情報が実際に引き継がれているか確認してください。リダイレクトだけでは検索意図のずれは解決しません。
対応表の記入例とテスト方法
架空の企業サイトを例に、旧ページが「/services/system/」、新ページが「/service/system-development/」へ変わるとします。単に転送設定を置くだけでなく、旧URLで探されていた対応範囲、費用の考え方、問い合わせ先が新ページに残っているかを確認します。別テーマのサービスTOPへまとめて送ると、読者の期待に合わない場合があります。
| 旧URL | 新URL | 確認する検索意図 | 公開後の確認 |
|---|---|---|---|
| /services/system/ | /service/system-development/ | システム開発の対応範囲 | 旧URLは301、新URLは200、canonicalは新URL |
| /blog/old-guide/ | /blog/new-guide/ | 同じ手順・回答が読めるか | 本文、内部リンク、画像、CTAを確認 |
URL対応表には転送先だけでなく、旧ページの主要クエリ、直近のクリック、所有担当、検証結果、未対応理由を残します。公開前に数件を手動で追い、公開後は全URLを機械的に確認します。なお、これは入力例であり、実際のクラウドシード案件や移行実績ではありません。
本文・見出し・内部リンクを引き継ぐ
デザイン刷新の際に、検索流入を得ていた説明やFAQを大幅に削ると、対象クエリへの回答が弱くなる可能性があります。すべての文章を固定する必要はありませんが、旧ページで読者が探していた要点、独自の事例、サービスへの自然な導線は意識して引き継ぎます。
新しいナビゲーションや関連記事から、重要ページへたどり着けるかも確認します。内部リンクは旧URLを経由せず新URLへ直接向け、アンカーテキストでリンク先の内容が分かるようにします。一般的なSEOの基本は既存サイトで始めるSEO対策で整理しています。
公開前の技術確認
ステージングやプレビューで、PCとスマートフォンの表示、ナビゲーション、フォーム、主要ページのHTTP状態を確認します。開発中に設定したnoindexやrobotsの制限が本番にも残っていないか、canonicalが公開するURLを指すか、OGP画像が適切かを点検します。構造化データを使っている場合は、ページの実内容と一致しているか確認します。
計測タグも対象です。GA4のpage_viewが重複しないか、問い合わせ完了が正しい成功条件で記録されるか、旧サイトと新サイトで比較できるかを確認します。フォームの実送信テストが必要な場合は、関係者の承認とテストデータの取り扱いを決めてから実施します。
公開後はページ単位で変化を追う
公開直後は、旧URLの転送、主要新URLのHTTP 200、canonical、サイトマップを確認します。その後はSearch Consoleのページ・クエリ別データとGA4の自然検索を見て、流入が減ったページを特定します。検索結果の反映には時間がかかるため、公開翌日の順位だけで成否を決めないことも大切です。
問い合わせが減った場合、検索流入の減少だけが原因とは限りません。記事やサービスページからのCTA、フォームへの到達、送信成功まで分けて確認します。新サイトの検索流入が増えても問い合わせが減るなら、導線や入力負担に問題がある可能性があります。AI検索を含む流入計測も、通常の検索計測とは分けて検討できます。
公開後の数字が落ちたときの切り分け
例えば公開後7日で特定ページの自然検索セッションが減った場合、最初に旧URLの転送、最終ページの200、noindexの有無、canonical、新サイトマップへの掲載を確認します。これらが正常なら、Search Consoleで同じクエリの表示回数・順位・CTRを更新前後で比較します。表示回数だけ減ったのか、順位が落ちたのか、クリック率が落ちたのかで次の対策は異なります。
日次の小さな増減で即座に旧サイトへ戻すのではなく、技術的な障害と検索評価の反映待ちを分けて判断します。Googleはサイト移行ガイドで、再クロール中に表示が一時変動し得ると説明しています。
制作会社へ相談する前の整理
旧URL一覧、残すページ、優先する検索クエリ、GA4・Search Consoleの閲覧権限、CMSとサーバーの情報、フォームと既存の問い合わせ件数を用意すると、移行範囲を具体化しやすくなります。URLや本文をどこまで変えるか未確定でも、現行の成果と事業上の重要ページを共有するところから始められます。
クラウドシードは公開中のサービス案内で既存WebサイトのリニューアルやWebマーケティング支援を案内しています。個別の対応範囲や費用は現状確認後の判断となります。Webサイトのリニューアルと検索流入の引継ぎを相談する
