UrlEdge
ブログに戻る
2026年5月1日 UrlEdge Editorial2 min read

SEO支援会社向け一括リダイレクト：移行マップを安全に本番反映する方法

URL棚卸し、クライアント承認、CSVインポート、事前検証、公開日のQA、切り戻しまで、サイト移行で使えるリダイレクトマップ運用を整理します。

SEO支援会社がサイト移行前にリダイレクトマップを確認している様子

一括リダイレクトは、単なる実装作業として扱った瞬間に危険になります。SEO支援会社や制作会社がサイト移行を担当する場合、リダイレクトマップはクライアント承認の記録であり、SEOリスクの管理表であり、開発チームへの引き継ぎ資料であり、公開後に切り戻すための保険でもあります。

だからこそ、大量のリダイレクトをスプレッドシート、チャット、CMSプラグイン、Nginx設定、.htaccess の中だけで管理するのは危険です。DNS変更、CDN切り替え、ECプラットフォーム移行、ドメイン変更の前に、マップ自体を本番設定としてレビューする必要があります。

この記事は、EC-CUBE、Shopify、BASE、STORES、WordPress、自社CMS、headless構成、複数ブランドサイトの移行を支援するSEO会社、Web制作会社、技術SEO担当者向けです。LINE公式アカウント、広告LP、メール、アフィリエイト、印刷済みQRコードのURLが残っている案件にも向いています。

代理店向けのワークフロー

安全な進め方は、見た目ほど複雑ではありません。ただし、公開直前に省略すると事故になります。

  1. まだ価値ある流入を送るURLをすべて棚卸しする
  2. URLを事業リスクとSEOリスクで分類する
  3. 担当者、レビュー状態、判断メモ付きのリダイレクトマップを作る
  4. インポート前にマップを検証する
  5. 本番反映前にバッチを取り込み、代表URLをテストする
  6. 公開後の監視と切り戻し手順を用意する

redirect mapをレビューする流れ

単なる表と移行成果物の違いは、責任の所在です。表は行を保存します。移行成果物は、誰が移行先を承認したか、なぜそのHTTPステータスなのか、どのクエリパラメータを残すのか、広すぎるルールが壊れたときにどう戻すのかまで示します。

複数の情報源からURLを棚卸しする

CMSやEC管理画面のエクスポートだけで完了にしないでください。そこに載っていないURLほど、公開日に問題になります。過去の広告、LINE配信、メール、アフィリエイト、外部メディア、QRコード、Search Consoleでまだ表示されている古いランディングページは、プラットフォームの標準エクスポートから漏れがちです。

少なくとも次の情報源を集めます。

情報源重要な理由マップに残すこと
XMLサイトマップ現在の正規URLを把握するURL種別、正規パス、言語・地域
Google Search Console表示やクリックがある自然検索流入を拾うSEO優先度、検索意図、流入価値
アクセス解析・DWH売上、問い合わせ、サポート導線を拾う売上導線、リード導線、サポート導線
クローラー出力status、canonical、内部リンク、階層を確認する200/3xx/4xx、canonical不一致、重複
CMS・ECエクスポート商品、カテゴリ、記事、固定ページを拾う商品・カテゴリ・コンテンツ担当、販売状態
広告・CRM・メール配信リスト自然検索には出ないURLを拾うUTM方針、キャンペーン担当、有効期限
パートナー・アフィリエイト一覧クライアントが直接修正できないURLを拾う連絡先、代替先、計測リスク

小規模サイトなら、レビュー済みCSVひとつで十分なこともあります。大規模ECや複数ブランドの案件では、作業ファイルを情報源ごとに分けても構いません。ただし、本番反映するのは統合済みのリダイレクトマップだけにします。

運用上の質問に答えられるマップにする

代理店のリダイレクトマップは、old_url と new_url だけでは足りません。その2列だけでもリダイレクトは作れますが、クライアント、SEO担当、マーケティング、開発が合意した証拠にはなりません。

次のような列を用意します。

old_url,new_url,status,priority,owner,query_policy,rule_type,review_status,notes
https://old.example.jp/pricing,https://new.example.jp/pricing,301,high,marketing,preserve,exact,approved,問い合わせ主要導線
https://old.example.jp/blog/legacy-guide,https://new.example.jp/resources/guide,301,medium,seo,preserve,exact,needs-review,記事を統合予定
https://old.example.jp/products/*,https://new.example.jp/shop/*,301,high,ecommerce,preserve,wildcard,approved,商品パス構造を維持

この粒度があると、公開前の確認で必ず出る質問に答えられます。

  • 恒久移転なのか、一時的なキャンペーン変更なのか
  • 移行先はユーザーの意図に合っているのか、それとも近いだけのトップページなのか
  • query string、UTM、クーポン、アフィリエイトIDを保持するのか
  • exact、wildcard、regexのどれで扱うのか
  • 商品終了、カテゴリ統合、記事削除の例外を誰が承認するのか
  • まだ本番投入すべきでない行はどれか

これらがマップに書かれていない場合、公開日の限られた時間で再判断することになります。

インポート前にリスクで分類する

すべての行を同じ深さでレビューする必要はありません。3万件、5万件、10万件のマップでも、重要URLと機械的に処理できるURLを分けると管理できます。

区分例レビュー基準
Tier 1: 事業上重要料金、商品、購入導線、資料請求、デモ、アカウント、主要SEO流入ページ1行ずつ人が確認
Tier 2: 構造化されたパス商品詳細、カテゴリ、記事一覧など、構造が維持される領域サンプル確認とパターン検証
Tier 3: 低価値の旧URL古いタグ、終了キャンペーン、流入のないアーカイブバッチ検証とfallback方針
例外販売終了商品、統合カテゴリ、削除記事、終了したオファー明示的な移行先判断

多くの移行はここで崩れます。wildcardは何千件も処理できますが、売上、被リンク、広告費に効く数件を隠してしまうこともあります。wildcardやregexは作業を速くする道具であり、判断の代わりではありません。

ルーティング層になる前に検証する

検証は2回必要です。インポート前の静的チェックと、stagingや限定公開環境でルールが動いてからの挙動チェックです。

インポート前に確認することは次のとおりです。

  • old_url の重複
  • 空または不正な移行先URL
  • protocolやhostnameの誤り
  • 旧URLがすでに別のリダイレクトを含んでいるケース
  • 移行先が404、410、5xx、または想定外のリダイレクトを返すケース
  • wildcardとexact ruleの重複
  • 広すぎる、またはアンカーされていないregex
  • キャンペーン計測と矛盾するquery string処理

インポート後は、構文ではなく実際の挙動を確認します。代表URLを Redirect Checker で確認し、大規模移行では全体をクロールします。

QAの目的は「リダイレクトが存在すること」ではありません。「旧URLが最適な新URLへ、意図したステータスコードで、chainやloopを作らず、必要なパラメータを失わずに到達すること」です。

公開日のredirect QA

公開日をリリースとして計画する

代理店案件の公開日は、単なる後片付けではありません。誰が何を見て、どのタイミングで判断し、どこまでなら切り戻すのかを決めておく必要があります。

タイミング確認すること担当
DNS変更48時間前Tier 1サンプル、wildcard、query保持、移行先のヘルスSEO + 開発
切り替え時間帯hostname routing、HTTPS、主要パス、広告URL、docs/support URL開発
最初の2時間404、redirect chain、主要国・端末、rule hits、クライアント報告SEO + アカウント担当
最初の7日自然検索LP、パートナーリンク、広告計測、想定外のfallback流入SEO + マーケティング

切り戻しは、移行全体を戻すことだけではありません。問題のあるバッチを止める、前のsnapshotを戻す、危険なパターンをexact ruleで上書きする、といった対応で済むこともあります。重要なのは、その判断が公開前に決まっていることです。

代理店が時間を失いやすい失敗

未決定の行をそのまま投入する

担当者やレビュー状態がない行を、インポートに紛れ込ませてはいけません。未解決として残し、移行先を誰かが承認するまで本番から外します。

終了した商品や記事を何でもトップへ送る

トップページは安全に見えますが、ユーザー体験にも移行の連続性にも弱いことが多いです。販売終了商品なら代替商品、カテゴリ、サポート記事、終了案内ページのほうが適切な場合があります。

複数の層に同じリダイレクトを持たせる

クライアント環境には、Nginx、Apache .htaccess、Cloudflare、EC-CUBE、Shopify、WordPress、CMSプラグイン、アプリmiddlewareのすべてにリダイレクトが残っていることがあります。移行用リダイレクトをどの層が持つのか決めないと、調査は遅くなり、責任分界も曖昧になります。

キャンペーンやアフィリエイトのパラメータを忘れる

クローラー上では正しく見えても、計測が壊れることがあります。utm_source、utm_medium、utm_campaign、クーポン、アフィリエイトID、LINE配信用パラメータなど、実際に使われているqueryを含めてテストします。

UrlEdgeでの位置づけ

UrlEdgeは、リダイレクトマップをサーバー設定やCMSプラグインの中に隠しておくには重要すぎる場合に向いています。基本の流れは次のとおりです。

  1. マップを作成し、承認する
  2. Bulk URL Management でルールをインポートする
  3. 重要URLを Redirect Checker で検証する
  4. レビュー済みsnapshotをedgeへ公開する
  5. 流入を監視し、rollbackを用意しておく

恒久的な移行では Permanent 301 Redirects と組み合わせます。古い設定が複数残っている場合は、Redirect Chains and Loops を確認しながらルーティング層を整理します。ドメイン変更を含む場合は、pathやUTMを失わずにドメインをリダイレクトする方法 もあわせて確認してください。

価値は、リダイレクトがedgeで動くことだけではありません。代理店にとっての価値は、移行作業をレビューでき、テストでき、公開でき、必要なら戻せる運用にすることです。

FAQ

すべての移行で301を使うべきですか？

いいえ。恒久的なURL移動では通常301または308を使います。一時的なキャンペーン変更では302または307が向いていることがあります。ステータスコードは設定の慣習ではなく、移行の意図に合わせます。

何件から手動設定では危険ですか？

共通の件数はありません。レビュー、担当者、検証、analytics、rollbackが構文より重要になった時点がサインです。その段階では、複数箇所の手作業より専用ワークフローのほうが安全です。

古いリダイレクトは長く残すべきですか？

重要な移行URLは長期維持を前提にします。被リンク、古いメール、印刷済みQRコード、パートナー資料、顧客のブックマークは、公開後も長く旧URLへ流入を送り続けます。

wildcardだけで大きなCSVマップを置き換えられますか？

場合によります。旧パスと新パスの構造が明確にそろっているならwildcardは有効です。高価値ページ、販売終了商品、統合カテゴリ、判断が必要な移行先には明示的なマッピングを残します。

参考資料

リダイレクトマップを本番前にレビュー可能な状態へ

CSVルールを取り込み、競合を検証し、重要URLを確認して、移行用リダイレクトをエッジから公開できます。

一括リダイレクトを計画する

関連記事

すべて見る