2021年、Seahawkに仕事を依頼してくれた大手英国小売企業のサイトは、インデックスされたURLが22,000を超えていた。開発チームは4ヶ月間、新しいプラットフォームで作業を続けていた。ローンチ日もあった。ステージング環境もあった。ただしリダイレクトマップだけはなかったし、実は考えてもいなかった。ざっくりしたものもなければ、何もなかった。SEOリードのプランは「ローンチ後に対応する」というものだった。あの会議を今でも思い出すことがある。
私たちはローンチを 3 週間延期しました。リダイレクト戦略をゼロから再構築しました。サイトはクリーンに起動され、移行を通じてオーガニック トラフィックの 94% を保持し、クライアントはスコッチウイスキーの瓶を私たちに送ってくれました。3 週間の遅延は、ほぼ確実に 6 か月の回復クロールになっていたであろう事態から彼らを救いました。
さて。このスケールでリダイレクトマップを実際に構築する方法、プロセス、ツール、優先順位付けのロジック、そしてほとんどの移行ガイドが黙って見過ごしている部分をここで説明する。
---
完全な URL インベントリから始める
カウントできていないものはマップできない。それより前に、本番サイト上のすべてのライブ、インデックスされたURLを完全にエクスポートする必要がある。サイトマップだけじゃない。サイトマップは嘘をつく。古いことが多い。ページネーション済みのURLは除外される。何年も積み重ねられたリンクを持つ商品ページやアーカイブページは定期的に省かれる。
Screaming Frog SEO SpiderをリストモードでXMLサイトマップとGoogle Search ConsoleからのすべてのインデックスされたURLの複合ソースに対して実行する。この二つのソースは一緒にすると、もう一方が見落としているURLをほぼ常に浮き彫りにする。20,000個のURLを持つサイトでは、実際のクロール数は18,000から35,000の間のどこかで返ってくることを想定しろ。ページネーション、フィルター、ファセット化されたナビゲーション、すべてだ。Screaming Frog SEO Spider in list mode against a combined source: the XML sitemap plus a Google Search Console export of all indexed URLs. Those two sources together almost always surface URLs the other misses. For a 20,000-URL site, expect the real crawl count to come back anywhere between 18,000 and 35,000, pagination, filters, faceted nav, all of it.
クロール結果をスプレッドシートにエクスポートします。最低限必要なのはURL、HTTPステータス、titleタグ、H1、内部リンク数、GSCにインプレッション付きで出現しているかどうかです。最後の列は人々が認めるより価値があります。
トラフィックがまだあるれている404も忘れずに。
GSCにいる間に、カバレッジレポートを引っ張り出して、過去6ヶ月間にGoogleがクロールしようとしたすべてのURLを手に入れろ。既存の404も含めて。壊れたページの中には、外部バックリンクがまだ向かっているものがある。メンテナンスされていなかった2年のサイトで、40のリファリングドメインを持つ404を見たことがある。これらも宛先が必要だ。
---
マッピング前にカテゴリ分けする
20,000個のURLの平坦なリストは使い物にならない。クロールエクスポートの後に最初にやることは、すべてのURLをタイプごとに分類することだ。URLが何かに依存して、マッピングロジックは完全に異なるからだ。is.
私が使う大まかなタクソノミはこれです:
- 商品ページは、可能であれば新しい商品URLに1対1でマップしろ。, 1:1 map to new product URL where possible
- カテゴリー・コレクションページは、同等の新しいカテゴリーまたは最も近い親要素にマップしろ。, map to equivalent new category, or nearest parent
- ブログ記事・記事は、スラッグ、タイトルの類似性、またはトピッククラスタで一致させろ。, match by slug, title similarity, or topic cluster
- タグページとアーカイブページは通常、カテゴリーまたはホームページに統合します。, usually consolidate to category or homepage
- ページネーション付きURL（例：/category/shoes/page/3）は、ほぼ常に親カテゴリーにリダイレクトします。 (e.g.
/category/shoes/page/3), almost always → parent category - ユーザー生成またはアカウント関連のURL は、通常削除するか、ログインページにリダイレクトします。, usually drop or redirect to login
- 古いキャンペーンランディングページは、リダイレクト判断前にリンク価値を評価します。, evaluate link equity before deciding
- 重複またはカノニカルバリエーション は、カノニカルにリダイレクト、これで終了です。, redirect to the canonical, full stop
Google Sheetsのドロップダウン列を使ってこの分類ステップを行うのに数時間かかります。それは数日を節約します。すべてを入力したら、20,000個の個別の決定を行うのではなく、異なるルールセットで各カテゴリーを処理できます。
---
マッチングフェーズ：自動化を優先、手動は次点
ほとんどのチームがここで失敗します。すべてのURLを手作業でマッチングしようとするんです。20,000行あれば、それは徹底的ではなく、神経衰弱になるだけです。
私のプロセスは自動マッチング優先、手動レビューは二次、実際に重要なURLのみです。
VLOOKUPとPythonを使った自動マッチング
URLの構造が旧サイトと新サイト間で似ている場合（例：/products/red-shoes/ が /shop/red-shoes/ になるなど）、Sheetsでスラッグ部分に対して単純なVLOOKUPを実行すれば、リストの60～70%を10分以内に解決できます。正規表現ベースの検索・置換で構造的なパターン変更に対応します。/products/red-shoes/ becoming /shop/red-shoes/), a simple VLOOKUP in Sheets on the slug portion sorts out 60–70% of the list in under ten minutes. Regex-based find/replace handles structural pattern changes.
より複雑な移行、プラットフォーム変更、IA全体の再設計の場合、旧クロール結果と新サイトのクロール間でページタイトルをあいまい一致させるPythonスクリプトを使用します。thefuzzライブラリ（旧FuzzyWuzzy）がこれに適しています。85%以上のマッチスコアは自動割り当て、以下は手動レビューキューに送ります。thefuzz library (formerly FuzzyWuzzy) does this well. Anything above an 85% match score gets auto-assigned. Anything below goes into a manual review queue.
手動キューは通常、リストの20～30%です。すべてが上級スタッフの注意を必要とするわけではありません。
手動キューの優先順位付け
20,000個のURLすべてが等しい時間を必要とするわけではありません。各URLを以下でスコアリングします：
- 直近90日間のGSCインプレッション、検索トラフィックを生成しているなら高優先度です。, if it's driving search traffic, it's high priority
- 参照ドメイン数（Ahrefsから取得）、失うことができないリンク価値です。 (pulled from Ahrefs), link equity you can't afford to drop
- クロール結果の内部リンク数、構造的重要性を示します。, signals structural importance
- 収益属性。クライアントがGA4のeコマースデータを提供できれば、コンバージョンを駆動しているページが上位に上がります。, if the client can provide GA4 ecommerce data, pages driving conversions jump to the top
インプレッション、バックリンク、収益に関するものはすべて人的判断でマッピングが必要。それ以外は ルールベースのフォールバック（通常は親カテゴリーまたはホームページへ）に従わせればよい。正直なところ、20,000URLのサイトであれば、実際に個別対応が必要なURLは800～1,200程度。残りはロングテール由来の不要な部分だ。
---
リダイレクトマップドキュメントの構成
最終的なマップはスプレッドシートに置かれます。シンプルです。この段階では巧妙なツールは不要で、ファイルが曖昧でなく、インポート可能であれば十分です。
使用している列は以下の通り：
- ソースURL（旧ページの完全かつ絶対URL）
- デスティネーションURL（新ページの完全かつ絶対URL）
- リダイレクトタイプ（ほぼすべての場合で301、302は本当に一時的な場合のみで、これは稀です）
- マッチタイプ（完全一致 / パターン / 正規表現）
- カテゴリ（分類ステップから）
- 優先度レベル（上記のスコアリングに基づいて、高 / 中 / 低）
- ステータス（保留中 / 確認済み / 実装済み / テスト済み）
- 注記
この「メモ」列は過小評価されています。ここに「クライアントが本製品の廃止を確認済み、カテゴリーにリダイレクト」や「Forbesのバックリンクがここを指しており、ホームページではなく最も近い同等品にマップ」といった情報を記入します。未来のあなたが今のあなたに感謝するでしょう。
ソースURLは末尾スラッシュの有無、クエリストリングを含めて、ちょうどそれらが表示される通りに保持してください。ここで矛盾があると部分一致が発生し、ローンチ後に診断するのが悪夢となるリダイレクトを見落とします。
---
パターンベース vs. 完全一致リダイレクト
このスケールではパターンベースのリダイレクトが絶対に必要で、完全一致のみでは不十分です。.htaccessファイルに20,000個の個別のRedirect 301行を書くのは、まあ動作しますが、脆弱で解析が遅く、メンテナンスの悪夢です。Redirect 301 lines in an .htaccess file is, well, it works, but it's fragile, slow to parse, and a maintenance disaster.
Apache/WordPress環境ではRegexベースのRewriteRulesを構造パターンに使用します。例えば、/old-blog/[post-slug]/下の古いURLがすべて/insights/[post-slug]/にマップされる場合、4,000個ではなく1つのルールです。regex-based RewriteRules for structural patterns. For example, if every old URL under /old-blog/[post-slug]/ maps to /insights/[post-slug]/, that's one rule, not 4,000.
Nginxでも同じ原則がrewriteディレクティブに適用されます。Cloudflareでは、Bulk Redirectsを使用できます（無料ティアは20個の完全一致ルールに対応；Workersまたは有料のRedirect Rulesプロダクトは大規模でのパターンロジックに対応）。rewrite directives. On Cloudflare, you can use Bulk Redirects (their free tier handles up to 20 exact-match rules; Workers or the paid Redirect Rules product handles pattern logic at scale).
マップドキュメントは、どのリダイレクトがパターン対象かを明記する必要があります。対照的に、完全一致が必要かどうか。通常：ブログ投稿、プロダクト、カテゴリーページはパターンに従います。古いキャンペーンページ、レガシーサブドメイン、奇抜な履歴URLは完全一致が必要です。
ライブ前にパターンをテストする
ステージング環境でURLリストに対してパターンルール全体を実行し、Redirect Checker（一括）やbashのcurlループなどのツールで全てのリダイレクト応答をログに記録します。チェーンリダイレクト（旧 → 中間 → 新）は問題です。Googleはチェーンを辿りますが、各ホップでリンク資産の一部を失います。ローンチ前にそれらを平坦化してください。Redirect Checker (bulk) or a curl loop in bash. Every chain redirect (old → interim → new) is a problem, Google will follow chains but loses some link equity at each hop. Flatten them before launch.
---
ロングテール対応：フォールバック戦略
20,000URLサイトについて考えると、そのうち数千は恐らくトラフィックがゼロ、バックリンクがゼロ、そして誰もが再度訪問する理由がゼロです。これらを全てホームページにリダイレクトするのは異なる問題を生み出します。Googleに操作的に見え、特定のリンクを辿ったユーザーを混乱させます。
私のフォールバック階層：
- URLがトラフィックがなく、リンクもないサブカテゴリーページの場合→親カテゴリーにリダイレクト
- タグまたは著者アーカイブの場合 → ブログインデックスへリダイレクト
- 論理的な同等物がない本当に孤立したページの場合 → 404を表示するか、ナビゲーション付きの良好に設計された404ページへソフトリダイレクト
文脈に応じた検索とポピュラーなカテゴリーリンクを備えた良好なカスタム404ページは、一括ホームページリダイレクトよりもこれらの訪問の多くを回復します。昨年Seahawkのクライアント向けに構築したものは、28%の「回復」率（404からほかのページへナビゲートするユーザー）を達成しましたが、以前は約9%でした。
---
ローンチ後の検証
リダイレクトマップはローンチで終わりではありません。最初の72時間が重要です。
立ち上げの前日にGSCプロパティの確認を設定し、最初の2週間は毎日カバレッジレポートを監視します。立ち上げ後に新しく404が出現するのは、通常、インベントリを見落とされたURL、ローグなパラメータバリエーション、hreflang代替、または外部メールキャンペーンの古いURLが原因です。
見つかった新しい404ごとに、リダイレクトを追加してプッシュします。小さな火災です。GooglebotがそれらのURLを完全に諦める前に、キャッチしたいです。
また、サーバーログも確認してください。GSCだけではありません。Googlebotは、過去のクロールデータに基づいて、どこにもリンクされていないURLにアクセスします。ログ解析（小規模なサーバーセットアップで簡単に読むにはGoAccessを使用しています）により、GSCが報告するのに1週間以上かかることがある404が明らかになります。
---
よくある質問
20,000 個の URL に対するリダイレクトマップの構築には、実際のところどのくらい時間がかかりますか？
現実的には、2～3週間の兼務努力、合計40～60時間程度を見積もってください。古いサイトのURL構造がどの程度ぐちゃぐちゃであるかに応じて異なります。自動マッチングフェーズは高速です。優先度の高いURLの手動レビューと検証フェーズに最も時間がかかります。クライアントやPMに「週末で終わる」と言わせてはいけません。
すべての URL をリダイレクトすべきか、それとも 404 のままにしておいても大丈夫ですか？
トラフィックなし、バックリンクなし、完全に無駄になった URL であれば、404 のままにして問題ありません。無関係なページへのリダイレクトを無理に作るほうが、ソフト 404 シグナルを送ってしまい、むしろ悪い結果を招きます。容赦なく優先順位をつけてください。重要なものはリダイレクトし、その他の部分には質の高いカスタム 404 ページを用意しましょう。
どのリダイレクトタイプを使うべきですか、301か302か？
マイグレーションではほぼすべてのケースで 301（恒久的）を使ってください。302 は Google に一時的な移動だと伝えるため、古い URL がインデックスに残ります。「安全のため」に 302 を使ったら、旧ドメインが検索順位を保ったまま新ドメインが何ヶ月も低迷している、という事例を何度も見ています。301 を使いましょう。
WordPress で 20,000 個のリダイレクトをプラグインで管理できますか？
できます。ただし慎重に選んでください。John Godley の Redirection は大量のリダイレクトに対応でき、.htaccess ではなくデータベースにルールを保存するため、大規模運用ではパフォーマンスに優れています。正確に一致するリダイレクトが 10,000 を超える場合、パターンベースのルールをサーバー設定に移行することをお勧めします。プラグインだけに依存するのは避けましょう。Redirection by John Godley handles large volumes well and stores rules in the database rather than .htaccess, which is better for performance at scale. For anything above ~10,000 exact-match redirects, I'd still recommend migrating pattern-based rules to server config rather than relying entirely on a plugin.
大規模マイグレーションで最も一般的なミスは何ですか？
リダイレクトマップを遅く開始すること。これは常に見ます。開発作業は90%完了し、立ち上げは2週間先なのに、誰かが「では、リダイレクトについてはどうですか？」と聞く。その時点では、バタバタしていて、必然的に何かを見落とします。リダイレクトマップは、新しいサイトのURL構造が確認された瞬間から構築を開始すべきです。事後対応ではなく、並行するワークストリームです。
---
3週間の遅延、ウイスキーのボトル1本、トラフィック保持率94%。これをきちんとやることの計算式は非常にシンプルだ。
リダイレクトマップはマイグレーションの華やかな部分ではありません。ケーススタディのヒーローバナーに載せる人はいません。しかし、それはマイグレーションとリカバリーの違いであり、どちらに請求したいか、私は知っています。