ECサイト移行時のSEOチェックリスト｜URL変更の影響を抑える手順
目次
ECサイトの移行では、ドメイン、CMS、URL構造、デザイン、商品データが同時に変わりやすく、検索エンジンと利用者の両方へ大きな影響が出ます。SEO上の中心は、旧URLと新URLの対応を保ち、クロール・インデックスの手掛かりを新サイトへ移すことです。
順位や流入の変動を完全になくすことは保証できませんが、変更を分け、URL対応表と検証を準備することで、原因不明の問題を減らせます。
移行の種類を整理する
ドメイン変更、HTTPからHTTPS、URLパス変更はURLが変わる移行です。ホスティングやCDNの変更だけで公開URLが変わらない移行とは確認項目が異なります。
CMS、デザイン、商品分類、URLを一度に変えると、問題が起きた際に原因を分けにくくなります。可能なら変更を段階化し、影響の少ないカテゴリで先に試します。
現状データを保存する
移行前に、公開URL一覧、HTTP応答、canonical、title、robots設定、内部リンク、サイトマップ、構造化データを取得します。Search Consoleの検索流入、インデックス状況、外部リンクも保存します。
売上や流入の多い商品・カテゴリ、新商品、販売終了商品など、優先確認URLを選びます。移行後の比較基準がなければ、欠落を見つけにくくなります。
旧URLと新URLの対応表を作る
旧URLごとに、対応する新URL、転送種別、廃止理由を記録します。商品IDを共通キーにできると、大量ページでも対応を作りやすくなります。
関係のない旧ページをトップへ一括転送しません。統合先があるページは最も近い内容へ、代替がないページは404や410へします。画像やPDFにも流入がある場合は対象に含めます。
新サイトを公開前にクロールする
テスト環境をクロールし、主要ページが200で表示され、title、description、canonical、構造化データが入っているかを確認します。テスト環境のアクセス制限を安全に解除できる範囲で行います。
公開前のnoindexやrobots.txt全体ブロックは、本番公開時に必ず外すチェックを用意します。環境変数や公開フラグで自動的に切り替わる場合も、本番応答を確認します。
リダイレクトを実装する
恒久移行では旧URLから対応する新URLへ301または308を設定します。転送チェーンやループを避け、一回で最終ページへ到達させます。
大規模移行ではURLサンプルだけでなく、対応表全件を自動テストします。旧URLのステータス、最終URL、最終200、ページ内容の関連性を確認します。
内部リンクとcanonicalを新URLへそろえる
新サイトのメニュー、商品カード、パンくず、関連記事、画像リンクを新URLへ更新します。旧URLを内部リンクに残し、毎回転送を通す状態は避けます。
新ページのcanonicalは新URLを指し、自己参照になっていることを確認します。hreflangや構造化データ内のURL、OGPなども必要に応じて更新します。
XMLサイトマップを切り替える
新URLだけを含むサイトマップを生成し、Search Consoleへ送信します。商品、カテゴリ、記事など種別ごとのURL数が移行前の想定と合うか確認します。
移行直後に旧サイトマップを参照用として使う場合も、最終的な削除時期を決めます。日常運用のサイトマップは新しい正規URLへ統一します。
Search Consoleを準備する
旧サイトと新サイトの両方を確認し、所有権が移行後も維持されるようにします。ドメイン変更ではChange of Addressの利用条件を確認します。HTTPからHTTPSだけの移行では扱いが異なります。
ページのインデックス登録、サイトマップ、クロール統計、Core Web Vitals、構造化データを監視します。旧URLの減少と新URLの増加をページ種別ごとに見ます。
公開日の進め方
可能ならアクセスの少ない時期を選び、開発、運用、CS、広告担当の連絡経路を決めます。転送、robots.txt、サイトマップ、計測、カート、決済を順に確認します。
問題が起きた際の切り戻し条件を決めます。ただし、一部だけ旧URLへ戻し転送が循環する状態を作らないよう、判断者と手順を明確にします。
公開後の監視
サーバーログ、404、5xx、転送エラー、Googlebotのアクセスを確認します。検索流入だけでなく、商品閲覧、カート、購入、広告の遷移も監視します。
移行処理にはサイト規模とサーバー状況に応じた時間がかかります。順位の短期変動だけで設定を変更せず、技術エラーとインデックス移行を分けて見ます。
転送を維持する
旧URLへの転送はできるだけ長く、Googleの公式案内では一般に少なくとも一年の維持が推奨されています。利用者や外部リンクのためには、それ以上維持する判断もあります。
内部リンクは新URLへ更新し、転送負荷を減らします。旧ドメインや証明書の更新を忘れると転送自体が動かなくなるため、維持コストを計画します。
よくある間違い
- URL対応表を作らずパターンだけで転送する
- すべての旧URLをトップへ転送する
- 本番公開後もnoindexや全体ブロックが残る
- canonicalと内部リンクが旧URLを指す
- CMS・デザイン・ドメイン変更を同時に行う
移行チェック項目
- 移行前のURLと検索データを保存したか
- 旧URLと新URLの対応表があるか
- 一回の恒久転送で関連ページへ到達するか
- robots、canonical、内部リンク、サイトマップが新URLか
- Search Consoleと計測を準備したか
- 公開後の監視と転送維持期間を決めたか
商品データ移行を検証する
URLが正しくても、商品名、説明、価格、在庫、画像、カテゴリ、レビューが欠ければ検索と購入に影響します。移行前後で商品IDをキーにし、重要項目の値と件数を比較します。
HTMLとして表示される内容だけでなく、title、meta description、構造化データ、画像altも確認します。文字コードや改行変換で説明が崩れる、画像URLが403になるといった移行特有の問題があります。
カテゴリと内部リンクの変化を確認する
新CMSでカテゴリ階層が変わると、商品へ到達するリンク数やパンくずが変わります。主要カテゴリから売れ筋・新商品へたどれるか、孤立商品が増えていないかを比較します。
カテゴリ統合は旧URLの転送だけでなく、新ページの商品集合と説明が旧検索意図を引き継ぐかを確認します。商品数が0になったカテゴリを機械的にトップへ送らないようにします。
障害対応の判断基準
決済不能、全商品404、全体noindex、転送ループなど、即時対応が必要な条件を決めます。軽微な表示ずれと検索インデックスの時間差を同じ障害として扱わないようにします。
切り戻す場合は、DNS、キャッシュ、転送が混在しない手順を用意します。旧環境へ戻した後も、新URLから旧URLへの逆転送を安易に作らず、利用者と検索エンジンの経路を一本化します。
関係者の連絡体制
開発、インフラ、商品、広告、アクセス解析、カスタマーサポートの担当と判断者を明確にします。公開日には、誰が何を確認し、異常をどこへ記録するかを時系列で決めます。
CSへ旧URLや商品検索の変更を共有すると、利用者の問い合わせから技術問題を早く見つけられます。移行はSEO担当だけの作業ではなく、EC運営全体の変更です。
移行後の検証期間を設ける
公開当日は購入機能、ステータス、転送、robots設定を確認し、翌日以降はログとSearch Console、商品データの欠落を見ます。週単位では旧新URLの登録、検索流入、Core Web Vitals、構造化データを比較します。
問題がなければ監視頻度を下げますが、旧ドメインの証明書、転送、Search Console所有権は長期的に維持します。担当プロジェクトが解散しても更新期限が分かるよう、通常運用へ引き継ぎます。
移行完了は、新サイトが表示された日ではありません。旧URLから新URLへの経路が安定し、重要ページが再クロール・登録され、日常の商品公開が新しい仕組みで正常に動くことを確認して判断します。
まとめ
ECサイト移行のSEOでは、旧URLの価値と利用者の導線を新URLへ引き継ぐことが中心です。現状保存、URL対応表、転送、内部リンク、canonical、サイトマップを一つの計画として進めます。
一度に変える範囲を抑え、公開前の全件テストと公開後の監視を行ってください。移行はページ単位で処理されるため、短期変動に慌てず、技術的な矛盾を一つずつ解消することが大切です。
