古いサイトから移行するときに、SEO・URL・問い合わせを守る方法
新しいサイトへ移るとき、デザインや原稿だけを引き継いでも十分ではありません。検索から読まれているURL、営業資料に載ったアドレス、フォームの通知先、計測の設定など、見えにくい経路も一緒に確認する必要があります。
「守る」とは、変化を起こさないという意味ではありません
ページを統合し、URLを整理し、フォームを作り直すことはあります。重要なのは、変更の理由と対応関係を把握し、公開前後に動作を確認できる状態にすることです。
1. 現在のサイトを棚卸しする
主要なページ、PDFや外部サイトから参照されるURL、検索から訪問されている入口、問い合わせにつながるページを一覧にします。アクセスが多いことだけで優先順位は決まりません。営業やサポートで使われる説明、契約中の顧客が参照する案内、採用候補者が確認するページも確認します。
2. URLの対応表をつくる
旧URLごとに、新しいページ、統合先、終了理由を記録します。内容が新しい場所へ移る場合は恒久的なリダイレクトを検討し、移らないページは利用者が次に取れる行動を考えます。トップページへの一律転送では、読者にも検索エンジンにも内容の関係が伝わりにくくなります。
| 旧URLごとの項目 | 記録する内容 |
|---|---|
| 移行判断 | 維持、書き直し、統合、終了 |
| 新しい行き先 | 内容が最も対応する一つのURL |
| 検索シグナル | title、H1、canonical、index方針、サイトマップ、内部リンク |
| 多言語関係 | 日本語・英語の対応ページ、言語切替、hreflang |
| 参照元 | メニュー、本文、PDF、広告、外部サイト、QRコード |
| 確認担当 | 設定者、公開前確認者、公開後監視者 |
3. 問い合わせと計測を、公開前に実地で確認する
フォームは送信画面を見るだけでなく、実際に通知が届くか、返信先や同意文が意図どおりか、迷惑メール対策が機能するかを確認します。電話リンク、予約、決済、外部連携も同様です。Search Console とアクセス解析は役割が異なるため、検索での入口とサイト内での行動を同じ数字として扱わないようにします。
4. 画像・PDF・構造化データ・外部連携も移行対象にする
HTMLページ以外にも、検索や営業で使われるPDF、参照される画像URL、フォームの送信先、タグ管理、SNS共有画像、構造化データ、フィード、APIがあります。新しいサイトで使わないものも含め、所有者と影響を確認します。すべてを移すのではなく、必要な資産を意図的に残し、不要な公開物や古い設定を意図的に終了します。
5. 公開判定と戻し方を決める
公開手順には、実施時刻、担当、DNSやキャッシュの影響、変更を止める条件、旧環境を残す期間、バックアップ、復旧判断を含めます。すべての移行で同じロールバック方法を使えるわけではありません。データ更新や問い合わせ受付が始まった後に単純に旧環境へ戻せない場合もあるため、対象構成に合う方法を技術担当者と合意します。
6. 公開後は、確認の責任者と期間を決める
公開直後には、重要URL、リダイレクト、canonical、サイトマップ、フォーム、計測、言語切り替え、モバイル表示を確認します。その後も、クロールや再評価の過程で変動が起こり得ることを前提に、検索・アクセス・問い合わせを個別に見ます。異常に気づいたときに誰が確認し、どこへ連絡するかを事前に決めておくと、対応が落ち着きます。
次のステップ：公開後30・60・90日の確認へ
移行直後の動作確認が終わったら、検索での入口、サイト内の利用、問い合わせ、運用上の負担を別々に見て、次の改善を一つ選びます。
PLAN THE MOVE
移行前に、守るべき経路と確認手順を整理しませんか。
現サイト、URL、フォーム、技術的な条件が分かる範囲から、現実的な移行計画を考えます。
確認日・参考情報
2026年8月17日確認。URL変更を伴う移行は Google Search Central のサイト移転ガイド、検索とサイト内行動の確認はGoogle Analytics と Search Console の比較を参照しています。
