サイトリニューアルと移行

第31講 / 全32講読了目安約70分

このページで学ぶこと

リニューアルをデザイン・CMSの入替えだけでなく、既存資産を新環境へ引き継ぐ移行として捉える方法
URL棚卸し、旧新対応表、301リダイレクト、削除・統合の判断
コンテンツ・CMS・インフラ・DNS・計測・Search Consoleの移行
公開前リハーサル、切戻し、旧環境維持、公開後監視
検索流入変動の想定と、問題を切り分ける方法

まず全体像

サイトリニューアルでは、見た目・システムを新しくする一方、既存サイトが持つ資産を引き継ぐ必要があります。

flowchart LR
    O[旧サイト] --> U[URL・検索評価]
    O --> C[コンテンツ・メディア]
    O --> D[データ・CMS]
    O --> A[計測・外部連携]
    O --> I[ドメイン・インフラ]
    U --> N[新サイト]
    C --> N
    D --> N
    A --> N
    I --> N

引き継ぐ資産には次があります。

検索・外部リンク・ブックマークが参照するURL
記事・画像・PDF
公開日・著者・カテゴリ
検索流入
計測の継続性
フォーム・API・業務フロー
ドメイン・DNS・証明書
Search Console・広告・SNS等の設定
利用者の習慣

「新サイトが表示できた」だけでは移行完了ではありません。

移行の種類

URLを変えず、ホスティングだけ変える

サーバー
CDN
CMS基盤
クラウド
DNS接続先

を変更し、利用者から見えるURLは維持します。

検索上の影響を抑えやすい一方、DNS、HTTPS、ステータス、速度、robots、内容差を確認します。

URLパスを変える

例：

/news.php?id=123 → /news/123/
/company/profile.html → /about/profile/

全旧URLと新URLの対応が必要です。

ドメイン・サブドメインを変える

例：

old.example.jp → www.example.jp
example.co.jp → example.com
複数ブランドサイトを統合

DNS、Search Console、外部設定、メール・Cookie・認証等の影響が増えます。

CMS・コンテンツモデルを変える

URLが同じでも、本文、HTML、公開状態、画像URL、カテゴリ、日付が変わります。

複数変更を同時に行う

デザイン、URL、ドメイン、CMS、サーバー、内容を同時に変えると、問題原因を切り分けにくくなります。

事業上可能なら、変更を段階化することも検討します。

移行計画のフェーズ

flowchart LR
    A[棚卸し・要件] --> B[設計・URL対応]
    B --> C[構築・データ移行]
    C --> D[検証・リハーサル]
    D --> E[公開・切替]
    E --> F[監視・修正]
    F --> G[旧環境停止・振り返り]

棚卸し

現行URL
アクセス・検索流入
外部リンク
コンテンツ
機能・フォーム
CMS
インフラ
計測
契約・権限

設計

維持・変更・統合・削除
新URL
リダイレクト
コンテンツモデル
公開方式
責任分界
切戻し

構築・移行

CMSデータ
画像・PDF
HTML変換
API
リダイレクト
サイトマップ
計測

検証

全URLクロール
主要フロー
SEO・アクセシビリティ
性能
差分移行
公開リハーサル

公開・監視

DNS・デプロイ
スモークテスト
Search Console
ログ・404
流入・コンバージョン
外部連携
旧環境

現行URLの棚卸し

URL一覧は、サイトマップだけでは不十分です。

複数の情報源を組み合わせます。

XMLサイトマップ
CMS・DB
Webサーバーログ
GA等のアクセス解析
Search Console
サイトクロール
外部検索
広告・メール・QR
PDF・資料内リンク
手動管理ページ

flowchart TD
    S[サイトマップ] --> L[統合URL台帳]
    C[CMS・DB] --> L
    A[アクセス解析] --> L
    G[Search Console] --> L
    R[サーバーログ] --> L
    X[クロール] --> L

一つの情報源にしかないURLがあります。

アクセスが0でも、法務上必要、外部資料からリンク、将来利用するページかもしれません。

機械的に削除せず、所有部門・内容を確認します。

URLごとの判断

各旧URLを次のいずれかへ分類します。

維持

URLと内容を基本的に維持します。

最も影響を抑えやすい選択です。

変更

内容は継続するがURLを変えます。

最も対応する新URLへ301等で転送します。

統合

複数旧ページを一つの新ページへまとめます。

各旧URLから、統合後の該当ページへ転送します。

新ページが旧内容の主要意図を満たすか確認します。

削除

代替する内容がない場合は、404または410等を返します。

無関係なトップページへ転送しません。

保留・アーカイブ

法務・IR・サポート等で過去情報を維持する場合、アーカイブページとして残します。

更新停止・古い情報であることを明記し、サイト内導線を整理します。

旧新URL対応表

移行の中心となる成果物です。

旧URL	新URL	処理	理由	title/内容	担当	確認
`/old-a`	`/new-a`	301	名称変更	継続	企画	未
`/old-b`	`/new-c`	301	統合	一部統合	広報	済
`/old-c`	なし	410	提供終了	代替なし	法務	済

管理事項

クエリパラメータ
大文字・小文字
末尾スラッシュ
PDF・画像
多言語
ページネーション
モバイル別URL
サブドメイン
http/https
www有無

数千URLでは、ルール変換と個別例外を組み合わせます。

ルールだけに任せず、実際の全URLで結果を検証します。

リダイレクト設計

直接転送

旧URL → 新URLの一段にします。

悪い例：

旧URL → 中間URL → HTTPS化 → 新URL

連鎖は遅延・エラー・管理負荷を増やします。

内容対応

旧ページの目的に最も近い新ページへ転送します。

終了製品 → 後継製品・終了案内
旧店舗 → 移転先・閉店案内
旧ニュース → 同じ記事
統合ページ → 統合後の該当セクション

すべてトップへ転送すると、利用者が目的を達成できず、ソフト404と判断される場合があります。

保持期間

Googleは一般にリダイレクトを長期間、少なくとも1年程度維持することを推奨しています。

ただし、外部リンク・ブックマーク・資料が残るため、可能ならより長く維持します。

旧ドメインの契約・証明書も必要です。

canonicalと内部リンク

新サイト公開後は、

新ページのcanonicalが新URL
内部リンクが新URLへ直接リンク
サイトマップが新URL
hreflangが新URL
構造化データが新URL
OGP・共有URLが新URL

となるようにします。

旧URLから301しながら、新ページのcanonicalが旧URLという矛盾を避けます。

内部リンクが旧URLのままだと、利用者・クローラーが毎回リダイレクトを通ります。

コンテンツ移行

移行対象

タイトル
本文
見出し
公開日・更新日
著者
カテゴリ・タグ
関連
画像
代替テキスト
PDF
動画
URL
メタ情報
公開・非公開
多言語

HTML変換

旧CMSの本文HTMLを新CMSへそのまま入れると、

古いclass・style
不適切な見出し
テーブルレイアウト
絶対URL
文字コード
ショートコード
埋め込み
アクセシビリティ問題

を引き継ぐ場合があります。

自動変換・クリーニング・個別修正の範囲を決めます。

画像・PDF

URL変更
ファイル名
重複
圧縮
代替テキスト
権利
公開期限
PDF内リンク
外部からの直接リンク

を確認します。

旧画像URLへのリダイレクト・継続配信が必要な場合があります。

初回移行と差分移行

移行準備中も現行サイトが更新されるため、一回のコピーでは最新になりません。

flowchart LR
    A[初回移行] --> T[テスト・修正期間]
    T --> D[差分抽出]
    D --> F[最終移行]
    F --> P[公開]

方法

更新停止期間を設ける
更新日時・IDで差分抽出
現旧両方へ二重入力
公開直前に最終エクスポート
更新予約を調整

更新停止の開始・終了・代替受付を関係者へ案内します。

差分移行後に件数・更新日時・内容を照合します。

DNS・ホスティング移行

URLを変えずホスティングだけ変える場合も、移行計画が必要です。

事前準備

新環境へコンテンツ配置
一時ホスト・hosts等で確認
HTTPS証明書
Googlebot等からの到達
IP・WAF・CDN
フォーム・API
ログ
性能
バックアップ

TTL

DNS変更前にTTLを短くすると、切替後の古い情報保持時間を抑えやすくなります。

ただし、変更直前に短くしても、以前の長いTTLが残っている利用者があります。

十分前に計画します。

切替中

旧新の両環境へアクセスが分かれる期間があります。

フォーム・更新・セッション・データが分散しないようにします。

静的サイトは比較的切替しやすい一方、動的書き込みがある場合は同期・停止を計画します。

旧環境停止

すべての利用者・クローラーが新環境へ到達し、ログ・データ・外部連携が正常と確認してから停止します。

公開直後に解約しないようにします。

検証環境のインデックス防止

検証環境が検索結果へ登録されると、

重複
未公開情報
テスト文言
個人情報
誤リンク

の問題になります。

対策

認証
IP制限
noindex
本番と別のAPI・データ
外部リンクを作らない
サイトマップを送らない

noindexだけでは機密性を守れません。

公開時に本番へnoindex・認証・robotsブロックを残さないことも重要です。

robots.txt・サイトマップ・Search Console

公開前

本番robots.txt
検証用制限の除去
新サイトマップ
新URLだけを収録
Search Console所有権
ドメインプロパティ
旧新プロパティ
主要URL検査

公開後

サイトマップ送信
クロール・インデックス状況
404・サーバーエラー
canonical選択
モバイル・構造化データ
検索パフォーマンス
手動対策・セキュリティ通知

ドメイン変更では、Googleの公式手順とSearch Consoleの機能を、当時の最新仕様で確認します。

計測の継続

リニューアル前後を比較するため、計測を公開前に設計します。

確認事項

GA等のプロパティ・データストリーム
タグID
GTM
Cookie同意
イベント名・定義
コンバージョン
クロスドメイン
参照元除外
フォーム・決済
Search Console連携
広告タグ
UTM
BI・BigQuery
データ保持
本番・検証の分離

URL変更でページ分類・レポートが変わります。

旧新URL対応表を分析にも使えるようにします。

リニューアル前後でイベント定義が変わる場合、単純比較できないことを記録します。

外部サービス・設定

URL・ドメイン変更が影響するものを一覧化します。

広告リンク
SNSプロフィール
Google Business Profile
メール・メルマガ
QRコード
アプリ
API許可ドメイン
CORS
OAuthリダイレクトURI
Webhook
決済
reCAPTCHA
地図
Cookie同意
CSP
WAF
監視
外部サイトへの依頼

自社で変更できない外部リンクは、リダイレクトを維持します。

公開リハーサル

公開手順を本番前に通して確認します。

リハーサル内容

最終ビルド
コンテンツ差分
リダイレクト設定
DNS・CDN設定
キャッシュ削除
所要時間
権限
連絡
スモークテスト
切戻し
ログ・監視
Search Console・計測

役割・開始条件・完了条件を読み合わせます。

初回の本番公開で初めて手順を実行しないようにします。

公開当日

flowchart TD
    A[変更凍結・最終差分] --> B[バックアップ]
    B --> C[デプロイ・DNS切替]
    C --> D[キャッシュ更新]
    D --> E[スモークテスト]
    E --> F{重大問題}
    F -->|あり| G[切戻し・緩和]
    F -->|なし| H[監視強化・完了連絡]

確認例

トップ・主要ページ
旧URL→新URL
404
HTTPS
robots・noindex
サイトマップ
title・canonical
フォーム
ログイン・検索
CMS公開
API・外部サービス
計測
Search Console URL検査
ログ・エラー

すべてを一人へ集中させず、役割と確認結果を共有します。

切戻し

切戻しの判断条件を事前に決めます。

切戻し候補

全体表示不能
主要フォーム・決済不能
個人情報・セキュリティ問題
大量の誤リダイレクト
データ不整合
復旧時間を見積もれない

切戻しで戻すもの

Web成果物
DNS・CDN
DB・CMS
API
検索
計測
フォーム送信先
キャッシュ

公開後に新環境で受けたデータ・更新をどう扱うか決めます。

DNSは反映に時間差があるため、即時に全利用者が戻るとは限りません。

公開後監視

最初の数時間・数日

5xx・404
リダイレクト
フォーム・予約
API
ページ速度
WAF
ログ
Search Console
サイトマップ
計測
問い合わせ
旧環境アクセス

数週間

検索クリック・表示
インデックス数
canonical
上位ランディングページ
外部リンク
直帰・コンバージョン
クロール
Core Web Vitals
旧URL利用

Googleの公式資料では、URL変更後にクロール・再インデックスされる間、検索順位・流入が変動する場合があり、中規模サイトでも認識に数週間、大規模サイトではさらに時間がかかる場合があると説明されています。

短期変動だけでリダイレクト・URLを頻繁に変更せず、技術エラーと通常の再処理を切り分けます。

検索流入低下の切り分け

flowchart TD
    A[検索流入が低下] --> B{全体か一部URLか}
    B --> C[Search Consoleでページ・クエリ・国・端末]
    C --> D{クロール・インデックス問題}
    D -->|あり| E[robots・noindex・status・canonical・redirect]
    D -->|なし| F{内容・検索需要・競合}
    E --> G[修正・再検証]
    F --> H[コンテンツ・市場分析]

技術要因

noindex
robots
5xx
誤リダイレクト
canonical
JavaScript
重要リンク消失
内容欠落
サイトマップ
モバイル差
大幅な速度低下

非技術要因

検索需要
季節
競合
コンテンツ変更
ブランド
検索結果表示
検索システム更新

GAだけでなくSearch Console、サーバーログ、クロール、旧新ページ内容を組み合わせます。

旧環境の維持

旧環境は、リダイレクト・データ確認・切戻しのため一定期間維持します。

ただし注意

旧サイトが200で残り重複する
CMSを両方更新して差分が出る
セキュリティ更新を停止
管理者権限が残る
利用者が旧環境へ直接到達
費用・契約が続く

旧URLはリダイレクトし、旧CMS管理画面・データはアクセス制限します。

停止日、バックアップ、削除責任者を決めます。

移行完了の条件

主要URL・旧URL処理が正常
移行件数・内容の照合完了
主要機能・業務フローが正常
計測・Search Consoleが継続
重大エラーがない
検索・アクセスの傾向を監視
旧環境停止の判断
引継ぎ・運用資料
残課題と担当
振り返り

公開日ではなく、安定化と旧環境整理までを移行計画へ含めます。

実案件ではどう考えるか

WordPressからヘッドレスCMS

現行記事・固定ページ
プラグイン機能
フォーム
検索
SEO設定
リダイレクト
公開日
画像・PDF
本文HTML
プレビュー
URL

を分解します。

CMSデータを移しただけでは、WordPressが担っていた機能は移行されません。

同一URLでS3＋CloudFrontへ移行

URL変更がなくても、

DNS
HTTPS
HTTPステータス
404
キャッシュ
フォーム・API
robots
ログ
旧サーバー

を確認します。

Googleの「ホスティング変更」手順に沿い、新環境を事前テストし、切替後に旧新トラフィックを監視します。

多言語サイト統合

各言語URL、canonical、hreflang、翻訳有無、リダイレクトを個別に対応させます。

日本語ページをすべて英語トップへ転送する等、言語・内容が対応しない処理を避けます。

PMチェックリスト

よくある誤解・失敗

「URLは短くきれいに変えた方がSEOに良い」

既存URL変更にはリダイレクト・検索・外部リンク・分析の移行コストがあります。明確な便益がなければ維持も重要な選択です。

「旧URLはすべてトップへ301すればよい」

内容対応がない一括転送は利用者に役立たず、検索エンジンからソフト404として扱われる場合があります。

「公開後すぐ検索流入が下がったので失敗」

URL変更後には再クロール・再インデックスによる変動があり得ます。技術エラーを確認し、規模に応じた期間で監視します。

「同じドメイン・URLならSEO移行作業は不要」

内容、HTML、ステータス、robots、canonical、JavaScript、速度、内部リンクが変われば影響します。

「新サイトが正常なら旧環境をすぐ解約できる」

DNSキャッシュ、切戻し、旧データ、外部リンク、リダイレクト、調査のために一定期間必要です。

理解度チェック

Q1. 現行URL一覧をサイトマップだけから作ってはいけない理由は何ですか。

回答と解説

サイトマップにない古い・孤立URL、検索流入URL、外部リンク先、PDF、パラメータURL等があるため、CMS、解析、Search Console、ログ、クロール等を統合します。

Q2. 削除する旧ページに対応する新ページがない場合、どうしますか。

回答と解説

無関係なトップへ転送せず、原則として404または410等を返します。必要なら利用者向け案内・関連導線を404ページ等へ用意します。

Q3. 初回データ移行だけで公開できない理由は何ですか。

回答と解説

移行準備中も現行サイトが更新されるため、差分移行・更新停止・最終照合が必要です。

Q4. URLを変えずホスティングだけ変更する場合の確認事項を挙げてください。

回答と解説

DNS、TTL、HTTPS、HTTPステータス、robots、フォーム・API、CDN、性能、ログ、旧新環境へのトラフィック、旧環境停止等です。

Q5. 移行後の検索流入低下をどう切り分けますか。

回答と解説

Search Consoleでページ・クエリ別に確認し、robots、noindex、status、redirect、canonical、内容欠落、内部リンク、JavaScript等の技術要因と、需要・競合・内容変化等を分けます。

参考資料

Google Search Central「Move a site with URL changes」
https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
ドメイン・パス等のURL変更を伴う移行の公式手順。
Google Search Central「Changing your hosting」
https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes
URLを変えずホスティング・CDNを変更する場合の公式手順。
Google Search Central「Redirects and Google Search」
https://developers.google.com/search/docs/crawling-indexing/301-redirects
Google Search Central「Get started with Search Console」
https://developers.google.com/search/docs/monitor-debug/search-console-start
Google Search Central「Debugging drops in Google Search traffic」
https://developers.google.com/search/docs/monitor-debug/debugging-search-traffic-drops