ecbeing 大規模リニューアルのURLとリダイレクト設計
ecbeingで構築したサイトを基幹連携ごとリニューアルする案件では、商品3万点、カテゴリ2千、コンテンツ5千といった規模でURLが全部変わります。リダイレクトを全部手で設定するのは無理なので、最初に設計の順序を決めます。
答えは、規則で対応し、規則から外れるものだけを個別に対応する、です。3万の商品URLが「旧の商品IDから新の商品IDへ」と変換できるなら、リダイレクトは1つの規則で済みます。規則で変換できない例外だけを、個別の対応表にします。統合された商品、削除されたカテゴリ、URLが特殊なコンテンツが該当します。この設計をリニューアルの初期にやっておかないと、切り替え当日に数万の404が出ます。
この記事では、URLの棚卸し、規則の設計、例外の抽出、切り替え当日の手順、移行後の監視を、時系列で整理します。
結論: 規則で9割、対応表で1割。切り替え前にステージングで全URLを検証する
段階 | 時期 | やること |
|---|---|---|
棚卸し | 3か月前 | 旧サイトの全URLを種別ごとに一覧化。検索流入・被リンクを付与 |
規則設計 | 2か月前 | 種別ごとに旧URL → 新URLの変換規則を定義 |
例外抽出 | 1か月前 | 規則で変換できないURLを抽出し、個別の対応表を作る |
検証 | 2週間前 | ステージングで全URLのリダイレクトを機械的に検証 |
切り替え | 当日 | リダイレクトを有効化。主力URLを手動確認 |
監視 | 切り替え後3か月 | 404、リダイレクトチェーン、索引数、流入を監視 |
重要な考え方: 数万URLの移転で「手で確認する」のは、主力の数十URLだけです。残りは、規則と機械的な検証で担保します。引っ越しで言えば、大事な食器だけ自分で運び、あとは業者のチェックリストに任せる形です。検証していないリダイレクトは、存在しないのと同じです。手で見るURLと機械で見るURLを、最初に分けます。
棚卸し: 旧サイトの全URLを種別ごとに
取得するもの | 方法 |
|---|---|
全URL | 旧サイトのサイトマップ、DBからのエクスポート、クローラーツール。3つを突き合わせて漏れを防ぐ |
種別 | 商品・カテゴリ・コンテンツ・キャンペーン・静的ページ・その他 |
検索流入 | Search Consoleの検索パフォーマンスから、過去12か月のクリック数をURLごとに |
被リンク | Search Consoleのリンクレポート |
索引状態 | Search Consoleのページレポート |
検索流入と被リンクの多いURLは、リダイレクトの優先度が高いページです。看板商品のページが典型です。切り替え当日に手で確認するURLには、印を付けておきます。
規則設計: 種別ごとの変換規則
種別 | 規則の例 | 規則で対応できる割合の目安 |
|---|---|---|
商品 | 旧 /item/{旧ID} → 新 /products/{新ID}。旧IDと新IDの対応はDBで持つ | 9割以上 |
カテゴリ | 旧 /cat/{旧コード} → 新 /category/{新パス}。対応表が必要 | 7〜8割 |
コンテンツ | 旧 /content/{旧ID} → 新 /contents/{新スラッグ} | 5〜7割 |
キャンペーン | 終了済みは本体の該当カテゴリへ | 個別 |
静的ページ | 個別 | 個別 |
規則は「旧URLのパターン → 新URLのパターン」と「パターン内の変数の対応表」で組み立てます。商品IDが変わらないなら、規則だけで済みます。変わるなら、対応表(旧ID, 新ID)が要ります。住所の表記だけ変わる引っ越しか、番地ごと変わる引っ越しかの違いです。商品IDが変わるかどうかは、基幹側に確認します。
例外の見つけ方
規則で変換できないURLは、機械的に抽出します。目視で探す必要はありません。
旧URLの一覧に対して規則を適用し、新URLを生成する
生成した新URLが新サイトに存在するかを確認する(ステージングで200が返るか)
存在しないものが例外。例外ごとに、統合先・移動先・削除(410)を決める
例外は、だいたい決まった場所に集まります。統合された商品(旧2商品 → 新1商品)、廃止されたカテゴリ、URLが手作りだったコンテンツです。この三つの種類から先に洗います。
検証: ステージングで全URLを
旧URLの一覧(数万件)を、ステージングの新サイトに対してリクエストする
各URLの応答コードと転送先を記録する
301以外(404、多段の301、302、200)を抽出する
抽出したものを修正し、再検証する
「全URLが1回の301で200のページに到達する」まで繰り返す
多段のリダイレクト(旧 → 中間 → 新)は、評価の減衰とクロールの無駄につながります。乗り換えが多い路線ほど、途中で降りる人が増えるのと同じです。1回の301で最終URLに届く設計にします。
切り替え当日にやること
リダイレクトを有効化する
検索流入・被リンク上位50件を手動で開き、正しく転送されるか確認する
Search Consoleにサイトマップを再登録する。旧サイトマップは削除する
robots.txtが新サイトの意図どおりか確認する(ステージングのDisallowが残っていないか)
主力ページのURL検査で、索引登録をリクエストする
ステージングで設定した noindex や Disallow: / が本番に残ってしまう事故は、大規模リニューアルで最も多い失敗の1つです。切り替えたら、まずここを見ます。
移行後に見るもの
時期 | 指標 | 対処 |
|---|---|---|
1週間 | Search Consoleの404、リダイレクトエラー | 漏れを対応表に追加 |
1週間 | 主力ページの索引 | 索引されていなければnoindex・robotsを再確認 |
1か月 | 索引数の推移 | 旧URLが減り、新URLが増えているか |
3か月 | 検索流入 | 旧水準に戻っているか。戻らなければ規則の漏れを再検証 |
移行後も、リダイレクトは続きます
リダイレクトは、切り替え当日で終わりません。旧URLへの被リンクは何年も残り、404は後から見つかります。基幹連携で商品IDが再発番される、カテゴリを再編する、そのたびに新しいリダイレクトが要ります。店の移転案内を何年も出したままにしておくのと同じです。
Search OSは、ecbeingなどの大規模サイトを対象に、404・リダイレクトチェーン・canonical・索引数の変化を継続的に監視します。ボットが取得している旧URLと新URLの対応も見ます。リニューアルで失われたページは、修正対象として整理します。リニューアルの作業を置き換えるものではありません。リニューアル後に穴を見つけ続ける担当は、あらかじめ決めておきます。
よくある質問
リダイレクトを何万件も設定すると、サイトが遅くなりませんか
規則ベースのリダイレクトは、件数に左右されません。個別の対応表が数万件になるなら、Webサーバーのマップ機能やCDNのリダイレクト機能で処理します。
旧URLを410(消滅)にしていいものは
流入も被リンクもなく、対応する新ページもないものです。404より410のほうが、検索エンジンは早く索引から外します。
移行後、いつまでリダイレクトを維持しますか
最低1年です。被リンクが残っている限りは、恒久的に残します。削除すると、被リンクの評価が失われます。
あわせて読みたい
参考資料
Google Search Central: Site moves with URL changes
Google Search Central: Redirects and Google Search
Google Search Central: Large site owner's guide to managing your crawl budget