作成: IILL Editorial
最終更新: 2026年8月26日
先に結論を言うと、価値のある旧URLをすべて残します。URLを維持するか、 最も近い新ページへサーバー側の恒久リダイレクトを設定し、canonical、 hreflang、内部リンク、XMLサイトマップも新URLにそろえます。 公開後は インデックス、404、問い合わせ受信を確認し、リダイレクトは最低1年間 維持します。
ホームページのリニューアルは、古いドメインに新しい画面が表示された だけでは完了しません。既存の検索URL、外部リンク、DNSとメールの設定、 問い合わせフォーム、分析、運用権限も安全に移す必要があります。
最も重要な成果物はビジュアルのモックアップではありません。すべての 旧URLと新しい移行先を1対1で対応させた表です。この表がなければ、 見た目が改善しても検索訪問を404へ送り、送信された問い合わせが担当者 に届かないサイトになりかねません。
ホームページのリニューアルが必要な兆候
次の問題が複数回起きているなら、部分改善と全面リニューアルを比較します。
- モバイルでナビゲーション、表、フォームが使いにくい
- サービスやチーム情報が実際の組織と一致しない
- ドメイン、ホスティング、ソースリポジトリの管理者が分からない
- 複数ページでタイトルと説明が重複し、検索流入も見えない
- 問い合わせが計測されない、または信頼できない経路で届く
- 文言修正のたびに外部会社へ依存し、変更履歴が残らない
- 古いプラグインと管理者アカウントがセキュリティ更新を難しくする
見た目だけが古いなら、デザインシステムと主要ページの改善で十分かも しれません。URL、コンテンツ、権限、コンバージョン導線が絡み合っている なら、初日から移行計画をリニューアル範囲に入れます。
リニューアル前に必ず保存するもの
1. 既存URLと検索流入
現在のサイトをクロールし、正常ページ、リダイレクト、エラーを一覧に します。Search Consoleの表示回数、外部リンク、自然検索訪問、完了した 問い合わせがあるページを示します。新しいナビゲーションにないという 理由だけで削除せず、役割を維持するか、統合するか、本当に終了するかを 決めます。
2. ドメイン、DNS、業務メール
ドメイン登録者、支払いアカウント、DNS管理者、更新日を記録します。 DNSはWebサイトだけでなく、業務メールや外部サービスの認証も制御します。 公開時にゾーン全体を置き換えると、サイトは動いていてもメールだけが 止まる場合があります。
3. 原稿、画像、ライセンス
原稿、元画像、ロゴ、文書、記事をバックアップします。フォント、素材 画像、テーマ、プラグインのライセンスが新サイトでの利用を許可しているか 確認します。ファイルを持っていることと、再公開する権利があることは別です。
4. 問い合わせと分析の基準値
公開前4〜8週間の問い合わせ、重要なランディングページ、CTAクリック、 フォーム完了を記録します。電話、メール、メッセージ、予約、ダウンロード を分け、新旧サイトを一つの合算クリックではなく実際の成果で比較します。
URL対応表の作り方
少なくとも次の項目を持つ表を作ります。
| 旧URL | 現在の価値 | 新URL | 処理 | 検証 |
|---|---|---|---|---|
/old-service |
自然検索訪問 | /services/core |
301リダイレクト | 検索意図が一致するか |
/team/kim |
現職プロフィール | /experts/kim |
301リダイレクト | プロフィールと内部リンク |
/event-2021 |
終了済み | なし | 410または案内 | 外部リンクと代替先 |
/contact |
コンバージョンページ | /contact |
維持 | フォーム、メール、分析 |
Googleのサイト移行ガイドは、旧URLから新URLへの対応、恒久的な サーバー側リダイレクト、canonicalとサイトマップの同時更新を案内して います。すべての旧URLを新しいトップページへ送ると、利用者と検索 エンジンが必要とする関係が失われます。
URL対応表と次の七つを一致させます。
- リダイレクト：変更したURLを、不要な中継を挟まず最も近い最終 ページへサーバー側で恒久転送します。
- canonical：新ページは廃止したURLではなく、自分自身の正規URLを 指定します。
- 内部リンク：ナビゲーション、本文、フッターを新URLへ直接 書き換えます。
- hreflang：言語別ページがある場合は、各言語の新URLを相互に参照 させます。
- サイトマップ：インデックス可能な新URLを送信します。移行中は旧URL の一覧も、リダイレクトの確認に利用できます。
- 監視：必要な旧・新Search Consoleプロパティを確認し、インデックス、 リダイレクトエラー、以前流入していた検索語を追います。
- 維持期間：再クロールが遅いURLや外部リンクにも対応できるよう、 リダイレクトを最低1年間維持します。
公開前リニューアルチェックリスト
- すべての旧URLに確認済みの移行先または終了判断がある。
- 重要ページに明確なタイトル、H1、説明、目的が残っている。
- 変更URLは最も近い関連ページへ恒久リダイレクトする。
- canonical、hreflang、robots、サイトマップが新構造と一致する。
- DNS変更後も業務メールと認証レコードを維持する。
- モバイルメニュー、入力エラー、完了状態、キーボード操作が動く。
- テスト問い合わせが実際の担当者へ届き、必要な返信も送られる。
- 分析と広告のコンバージョンが一度だけ、有用なラベル付きで発火する。
- リポジトリ、デプロイ、ドメイン、分析の所有者を文書化した。
- ロールバック手段と公開責任者がいる。
公開後1日、1週間、4週間に確認すること
1日目はステータスコード、リダイレクト、TLS、フォーム配信、分析、業務 メールを確認します。最初の1週間は404ログ、Search Consoleのインデックス、 モバイルユーザビリティ、Core Web Vitalsを確認します。4週間後は自然検索 の入口ページ、完了した問い合わせ、重要ページの離脱を事前基準と比べます。
公開後に順位が動くことはあります。日付だけを変えたり、ほぼ同じキーワード ページを大量に作ったりせず、欠けたリダイレクト、失われたコンテンツ、 クロール問題から直します。
公開前に、別の担当者でもサイトを引き継げるか確認してください。Webサイト 引き継ぎチェックリストは ドメイン、デプロイ、計測の管理権限を、バックアップ復元 テストはロールバックの実効性を扱います。
次にすること：デザインを承認する前に旧URL一覧を作ります。現在のURLを 出力し、検索表示、外部リンク、完了した問い合わせがあるページに印を付け、 その一枚を初回会議に持参してください。第三者の確認が必要なら IILLへの相談窓口から現在の構成を共有できます。
Webサイト制作、何から決めるべきか迷っていませんか？
現在の状況と必要な成果を伺い、制作範囲と次のステップを先に整理します。