「サイトをリニューアルしたら検索順位が急落した」——Web担当者からいただく相談の中でも、これは特に深刻な部類に入ります。何年もかけて積み上げた検索流入が、公開ボタンひとつで細っていくことが現実に起きます。しかも原因はリニューアルそのものではなく、旧サイトの評価を新サイトへ引き継ぐ設計の漏れであることがほとんどです。
私はSEOコンサルタントとして、月間4,500万セッション級メディアの支援実績を持つ立場から仕事をしています。リニューアルの事前設計と下落後の復旧の、どちらの現場にも立ち会ってきました。制作の実務側では、店舗ビジネスのHPリニューアルをリダイレクト設計込みで担当し、公開後2ヶ月でアクセスを約3倍にした経験もあります。
この記事にまとめたのは、順位が落ちる3つの原因、評価を引き継ぐ実務6ステップとリダイレクト対応表の作り方、そして「設定したつもり」を見つける検証工程です。読み終えたときには、制作会社との打ち合わせにそのまま持ち込める判断材料が手元に残ります。
求人・EC・不動産など、大量のページを抱えるサイトのSEOは「設計」で成果が決まります。インデックスされない・カニバリ・競合に負ける——DBSEO（データベース型SEO）の設計でボトルネックを特定します。まずは無料でご相談ください。
先に結論：Googleの評価はサイトではなく1本ずつのURLに付く
まず最初に、結論からお伝えします。
1つ目。順位に効く評価の大半は、1本ずつのURLとその中身に積み上がっています。サイト単位で働くシグナルもゼロではありませんが、リニューアルで壊れるのはURL単位の引き継ぎのほうです。
URLが変わる・中身が減る・技術設定が変わる。この3つが評価の連続性を切る原因で、デザインの刷新そのものが下落の主因になることはまずありません。
2つ目。対策の本丸は、旧URLから新URLへの1対1のリダイレクト対応表です。公開前にこの1枚を作り切れているリニューアルは、大きな事故になりにくいというのが現場での実感です。
3つ目。そして最大の事故要因は、対応表を作らなかったことではありません。作ったはずの転送が、実際のHTTP応答としては転送になっていなかった——という「設定したつもり」が、いちばん見つけにくい形で評価を落とします。
この記事の中心には、それを見つけるための検証工程を置きました。
読者の状況によって、先に読むべき場所は変わります。次の表から自分に近い行を選んでください。
| いまの状況 | 先に読む場所 | その章の目的 |
|---|---|---|
| これからリニューアルする | 実務6ステップ／プロの判断基準 | 事故を公開前の設計で防ぐ |
| 公開した直後 | 応答を測る検証工程／公開後チェックリスト | 漏れを数日以内に見つける |
| すでに順位が下がった | 確かめる順番／想定内の範囲 | 原因を切り分けて手を打つ |
サイトリニューアルで順位が落ちる3つの原因｜デザイン変更は無罪
リニューアル後に順位が下がったという相談を分解していくと、原因はほぼ3つに集約されます。どれもデザインの良し悪しとは無関係で、公開前の設計と確認で防げるものばかりです。
- 原因1：URLが変わり、旧URLの評価が新URLへ渡っていない
- 原因2：中身が減っている（テキスト・内部リンク・構造化データ）
- 原因3：技術設定が変わっている（noindex・canonical・robots.txt）
| 原因 | 何が起きるか | 典型的な見落とし |
|---|---|---|
| URLの変更が引き継がれていない | 旧URLの評価が新ページに渡らず、ゼロからの再評価になる | リダイレクト未設定・一律トップページへ転送 |
| コンテンツの削減 | 評価されていたテキストやページが「軽くなった」「消えた」 | デザイン優先で文章を削る・古いページを黙って削除 |
| 技術設定の変化 | クロールやインデックスを妨げる設定が紛れ込む | noindexの外し忘れ・サイトマップ未更新・表示速度の悪化 |
先に強調しておきたいことがあります。デザインの刷新そのものは、下落の主因にはなりません。Googleが見ているのは見た目ではなく、URLごとの中身と技術的な健全性です。
「見た目は大きく変わったのに順位は安定している」リニューアルは、普通に実現できます。
原因1：URLが変わり、旧URLの評価が新URLへ渡っていない
もっとも件数が多く、もっとも取り返しがつきにくいのがこれです。ページの中身をそのまま移したつもりでも、アドレスが変われば検索エンジンから見れば別のページになります。旧URLに積み上がっていた評価は、転送という形で「このページはここへ移りました」と伝えない限り、新しいURLには渡りません。
Googleは重複URLの正規化について、方法を3つ挙げています。リダイレクト、rel="canonical"、サイトマップへの記載の3つです。
このうちリダイレクトは「リダイレクト先が正規ページになるべきことを強く示すシグナル」とされています。3つの中でもっとも効果が高い方法という位置づけです（Google 検索セントラル「重複した URL を統合する」）。
裏を返せば、リダイレクトを置かずに他の方法だけで引き継ごうとすると、伝わり方は弱くなります。
特に多い事故が、旧URLをすべてトップページへ転送する「一律リダイレクト」です。GoogleのURL変更を伴うサイト移転ガイドが示すとおり、引き継ぎの基本はページ同士の対応関係です。
Google自身も、多数の元のURLから関連性の低い1つのURL（新しいサイトのホームページなど）へリダイレクトすることは避けるよう案内しています。理由として「このようなリダイレクトはユーザーに混乱をきたし、soft 404 エラーとみなされる場合もあります」と説明されています（Google 検索セントラル「URL が変更されるサイト移転」）。
個別ページの評価をトップに集めても引き継がれません。ただし、複数のページに分かれていた内容を1本に統合した場合に、元の複数URLを統合後のページへ渡すのは問題ありません。
- URL構造は原則そのまま。変えるのは目的がある部分だけ
- 統合するページは、内容がいちばん近い1本へ対応させる
- 対応先を決めた根拠を、対応表の備考に1行残す
- 旧URLをまとめてトップページへ転送する
- CMSの都合でURL形式を変え、対応表を作らない
- 流入のあるページを、報告なしに削除・統合する
原因2：中身が減っている（テキスト・内部リンク・構造化データ）
2番目の「中身の削減」は、悪気なく起きるのが厄介なところです。デザイナーから見ると長い文章は野暮ったいので、リニューアル案では文章がキャッチコピーや画像に置き換わりがちです。ところが検索エンジンが評価していたのは、まさにその長い文章だったりします。
減りやすい要素は3つあります。1つ目は本文テキストで、旧サイトで流入のあったページは本文を原則そのまま引き継ぎ、見せ方だけを変えるのが安全です。
2つ目は内部リンクで、サイドバーや関連記事の枠がデザイン刷新で消えると、ページ同士のつながりが一気に痩せます。SEOの内部対策では、この配線の考え方を掘り下げています。
3つ目は構造化データです。よくある質問やパンくずの記述はテンプレートに埋め込まれていることが多く、テンプレートを入れ替えると気づかないうちに消えます。
あわせて、タイトルタグと説明文が旧サイトから引き継がれているかも確認してください。ここはタイトルタグの設計で詳しく整理しています。
原因3：技術設定が変わっている（noindex・canonical・robots.txt）
3つ目は、目に見えない設定が入れ替わってしまうケースです。代表的なものを3つ挙げます。
noindexは「このページを検索結果に出さないでください」という指示のことです。公開前の確認用サイトでは全ページに付けておくのが普通なので、本番公開時に外し忘れると、サイトごと検索結果から抜けます。
canonicalは「このページの正規のアドレスはこれです」という申告で、テンプレートの生成ロジックが変わると別のURLを指してしまうことも珍しくありません。robots.txtはクロールしてよい範囲を書いたファイルで、確認用の設定が本番に残ると巡回そのものが止まります。
ここで押さえておきたいのは、canonicalが命令ではないことです。Googleの説明でも、指定されたURLが正規ページになるべきことを「強く示すシグナル」と表現されています（Google 検索セントラル「重複した URL を統合する」）。設定したのに効いていないように見える場面があるのは、そもそも強制力を持つ仕組みではないからです。
表示速度の悪化も、この分類に入ります。画像の大型化やスクリプトの追加で体感速度が落ちるのはリニューアルの定番で、詳しくはページ表示速度とSEOを参照してください。なお、これらの設定が「変わっていないか」をどう確かめるかは、この記事の中心テーマとして後の章で扱います。
評価を引き継ぐ実務6ステップ｜リダイレクト対応表の作り方まで
ここからは、評価を引き継ぐための実務手順を6つのステップに分けて説明します。骨格はGoogleが公開しているサイト移転の推奨手順に沿っており、そこに現場で必要になる判断を足した形です。
- ステップ1：旧サイトの全URLを、実績の数字とセットで洗い出す
- ステップ2：1対1のリダイレクト対応表を作る（列の決め方）
- ステップ3：対応先がないURLをどう扱うか決める
- ステップ4：公開前にステージングで全URLを確認する
- ステップ5：公開と同時に301リダイレクトを有効化し、応答を測る
- ステップ6：サイトマップを送り直し、ドメイン変更ならGoogleへ通知する
GoogleのURL が変更されるサイト移転の解説では、推奨される流れがこう示されています。新しいサイトを準備して十分にテストし、現在のURLから新しい形式へのURLマッピングを準備する。
そのうえでリダイレクトするようサーバーを設定して移転を開始し、元のURLと新しいURLの両方でトラフィックを観察する、という順番です。以下の6ステップは、この流れを日本の制作現場の分業に合わせて分解したものです。
この工程で決めること：守る対象
どのURLが検索流入を生んでいるかを数字で確定させます。ここが曖昧なままだと、以降の判断がすべて感覚になります。
この工程で決めること：対応関係
旧URL1本ごとに、渡す先を1本決めます。決められない行が残っている状態では、公開日を確定させません。
この工程で決めること：例外の扱い
対応先が見つからないURLを、統合・親カテゴリ・非対応のどれにするかを決めます。判断の根拠も残します。
この工程で決めること：公開の可否
公開前の確認用サイトで、転送先と技術設定を1本ずつ照合します。ここが公開を止められる最後の地点です。
この工程で決めること：応答の実測
設定どおりの応答が本番から返っているかを測ります。設定画面の見た目ではなく、返ってきた結果で判断します。
この工程で決めること：通知と観測
Googleへ移転を伝え、旧新どちらの数字も追える状態にします。観測の設計まで含めて1つの工程です。
ステップ1：旧サイトの全URLを、実績の数字とセットで洗い出す
最初にやるのは棚卸しです。Search Consoleとサイトマップ、それにサイト内のクロール結果を突き合わせて、公開されている全URLを書き出します。ここまでは多くの記事に書かれています。
実務で効いてくるのは、その先です。URLの一覧で終わらせず、1本ずつに直近の表示回数・クリック数・平均掲載順位を添えてください。数字が入った瞬間に、一覧はただのリストから「守るべき資産の順位表」に変わります。
対応先を1本ずつ考える時間は有限なので、どこに時間を使うかを決める材料が必要です。
この棚卸しは、発注側が主体になって進めるほうが抜けが少なくなります。誰がこの一覧を作るのかを、見積もりの段階で決めておいてください。
ステップ2：1対1のリダイレクト対応表を作る（列の決め方）
ここが全工程の中核です。旧URLから新URLへの対応表を、スプレッドシートで1対1に作ります。よく「対応表を作りましょう」とだけ書かれていますが、実際に詰まるのは列の設計なので、私が使っている列構成をそのまま出します。
| 列 | 何を入れるか | なぜ必要か |
|---|---|---|
| 旧URL | 公開されていたアドレスをそのまま | 照合の基準。末尾スラッシュの有無まで写す |
| 新URL | 渡し先のアドレス1本 | 1対1が原則。複数書けるなら判断が未了 |
| 転送の種別 | 永続的な転送か、一時的な転送か | 意図が残る。後任者が変更してよいか分かる |
| 表示回数・クリック | 旧URLの直近の実績 | 確認の優先順位を決める。上から潰す |
| 対応先なしの扱い | 統合・親カテゴリ・非対応の別 | 例外を空欄にしない。判断を明文化する |
| 確認日 | 実際に確かめた日付 | いつ時点の話かが分かる。再点検の基準 |
| 応答の実測結果 | 返ってきた応答をそのまま記録 | 設定ではなく結果で判定する。次章の中心 |
埋め方の判断は1つだけ覚えてください。新URL欄に2本以上の候補が浮かぶ行は、まだ判断が終わっていない行です。
「あとで決める」と空欄にせず、その場で1本に決めるか、対応先なしの扱いを明記します。決めきれない行を一律でトップページへ寄せるのは、個別ページの評価が渡らないため避けてください（理由は原因1に書いたとおりです）。
行数が数百を超えると全件を人の目で見るのは現実的ではなくなります。その場合も、表示回数の多い上位から順に人が確認し、残りはパターン単位でまとめる、という優先順位の付け方は変えません。
ステップ3：対応先がないURLをどう扱うか決める
棚卸しをすると、新サイトに対応するページが存在しないURLが出てきます。ここを詰めきれずに公開日を迎えるパターンが、事故のかなりの割合を占めています。選択肢は3つです。
統合先を決めるのは、内容が近いページが新サイトにある場合です。テーマが重なる薄いページを複数残すより、1本に集約したほうが評価は集まりやすくなります。
親カテゴリへ寄せるのは、個別の内容は失われるが分類としては生きている場合です。たとえば終了したキャンペーンページを、そのサービスの一覧ページへ渡します。
残さないと決めるのは、流入も外部リンクもなく、内容としても役割を終えている場合だけにしてください。判断に迷ったら、ステップ1で添えた数字を見ます。表示回数がゼロに近く、他サイトからのリンクもないURLであれば、無理に対応先を作る必要はありません。
ステップ4：公開前にステージングで全URLを確認する
ステージングとは、本番と同じ構成で作った公開前の確認用サイトのことです。ここで対応表の行を1本ずつ照合します。
新URLが実在するか、中身が旧ページから引き継がれているか、タイトルと本文が痩せていないか。この3点が基本の確認項目になります。
あわせて、技術設定の取り違えを潰します。もっとも多いのがnoindexの付け外しです。確認用サイトには検索結果に出さない指示を付けておくのが通例です。
本番公開時に外し忘れると全ページが検索結果から抜け、逆に確認用サイトから外してしまうと公開前のページが検索結果に載ってしまいます。
ここは公開を止められる最後の地点でもあります。対応表に空欄が残っている、確認できていない行がある、といった状態なら、公開日をずらす判断を検討してください。公開後に埋めるコストは、公開前に埋めるコストよりずっと大きくなります。
ステップ5：公開と同時に301リダイレクトを有効化し、応答を測る
公開のタイミングで転送を有効化してください。Googleは「技術的に可能な場合はサーバーサイドの永続的なリダイレクトを使用してください」と案内しています。あわせて、可能であれば永続的なHTTPリダイレクト（例: 301、308）を使うことを推奨しています（Google 検索セントラル「URL が変更されるサイト移転」）。
転送が何段にも連なる構成は、できる範囲で1段に整理しておきたいところです。Googleも、Googlebotはリダイレクトのチェーンに含まれる最大10個のホップをたどれるとしています。そのうえで「最終的な宛先に直接リダイレクトすることをおすすめします」と案内しています（同「URL が変更されるサイト移転」）。
私が1段にこだわる理由はもう1つあって、多段になるほど、どこで意図がねじれたのかを後から検証しにくくなるからです。旧URLから最終的な新URLまで、途中に何が挟まっているかを説明できる状態にしておいてください。
あわせて、転送をいつまで残すかも公開前に決めておきます。Googleは「リダイレクトをできるだけ長く保持します（一般的には1年以上）。この期間、Googleは古いURLを指している他のサイト上のリンクの再クロールや再割り当てなどを行い、すべてのシグナルを新しいURLに転送できます」と案内しています（同「URL が変更されるサイト移転」）。
| 対象 | 転送を維持する期間 | 根拠 |
|---|---|---|
| 原則（すべてのリニューアル） | できるだけ長く。一般的には1年以上 | Google「URL が変更されるサイト移転」 |
| ドメイン移転でアドレス変更を申請した場合の下限 | 上の原則に加えて、少なくとも180日間。検索からの流入がまだあるならさらに維持 | Google「アドレス変更ツール」 |
サーバーの入れ替えで設定が消えないよう、転送の設定をどこに書いたかを対応表と一緒に記録しておいてください。
そして、この工程には続きがあります。転送を有効化したことと、転送が実際に返っていることは別の話です。ここが本記事でいちばんお伝えしたい論点なので、次の章でまとめて扱います。
ステップ6：サイトマップを送り直し、ドメイン変更ならGoogleへ通知する
最後にGoogleへ伝える工程です。ここは「どのリニューアルでも共通の作業」と「ドメインが変わるときだけの作業」を分けて考えてください。
| 作業 | いつ行うか | 根拠 |
|---|---|---|
| 新しいサイトマップの送信 | どのリニューアルでも共通 | Google「URL が変更されるサイト移転」 |
| アドレス変更ツールでの申請 | ドメイン・サブドメインが変わるときだけ | Google「アドレス変更ツール」 |
| 旧URLと新URL両方のトラフィック観察 | どのリニューアルでも共通 | Google「URL が変更されるサイト移転」 |
共通で行うのは、新しいサイトマップの送信です。Googleの案内でも、Search Consoleで新しいサイトマップを送信することが手順に含まれています（Google 検索セントラル「URL が変更されるサイト移転」）。
一方、Search Consoleの「アドレス変更ツール」は、どのリニューアルでも使うものではありません。Googleは「アドレス変更ツールは、ドメインレベルのプロパティでのみ使用できます」と説明しています。
そのうえで、サイト内のある場所から別の場所へのページ移動、httpからhttpsへの変更、同じドメイン内のwwwの有無の移転では使用しないよう案内しています（Google「アドレス変更ツール」）。同一ドメインの中でURLを組み替えるだけのリニューアルなら、リダイレクトとサイトマップの更新で対応します。
ドメインやサブドメインが変わる場合は、新旧どちらについても所有権を確認したうえでアドレス変更を申請してください。URL構造の変更とドメイン変更を同時に行うと、下落が起きたときの切り分けが難しくなるため、可能なら時期を分けることをおすすめします。
通知して終わり、にはしないでください。同じくGoogleの案内には、元のURLと新しいURL両方のトラフィックを観察する工程が含まれています。
旧URL側の表示回数が落ちながら、新URL側が立ち上がっていく。この移り変わりを両方の目盛りで見られる状態にしておくことが、サイト移行で検索順位を維持するための最後の仕上げになります。
最大の事故要因は「設定したつもり」｜応答を測る検証工程
ここからが、この記事でもっとも書きたかった章です。私の経験上、リニューアルの事故は「対応表を作らなかった」から起きるとは限りません。作った設定が、実際の応答としては反映されていなかった——という形で起きることのほうが、見つけにくいぶん深刻でした。
「設定を見る」のではなく「応答を測る」
自社で運営しているサイトの改修で、こんなことがありました（自社の実装記録・2026年7月10日）。非正規な形のURLを正しい形へ転送する処理を、アプリケーション側に実装していました。設定としては書けていて、コードを読む限り転送されるはずでした。
ところが実際にアドレスを叩いて応答を確かめると、永続的な転送の応答が返っていませんでした。ページ生成の途中で走る転送処理が、転送の応答ではなくHTMLとして書き出される仕組みになっていたためです。配信の段階で永続的な転送を返す構成へ変更し、ようやく設計どおりの応答になりました。
同じ改修では、旧パスから新パスへの301も追加しています。すると、それまで壊れていたフッターのリンクと、検索結果から入ってきた人のリンク先が、どちらも実在するページを指すようになりました。設定は前から書いてあったのに、応答としては返っていなかった、というのがこの件の正体です。
誤解のないように補足すると、Googleは即時のmeta refreshリダイレクトを永続的なリダイレクトとして解釈すると明記しています（Google 検索セントラル「リダイレクトと Google 検索」）。ただし公式での位置づけは、サーバー側のリダイレクトをプラットフォームに実装できない場合の代替手段です。
つまり問題は「無視される」ことではありません。設計した方式と、実際に返っている方式がズレていることに誰も気づけない点が問題なのです。だから切り分け手順には、「設定を見る」ではなく「応答を測る」を入れてください。
設定ミスは、画面上まったく異常に見えない
同じ時期の改修では、もう1つ見つかった問題があります（自社運営サイトの実装記録・2026年7月10日）。比較のための検索条件ページで、canonicalが本番環境でだけ別のURLに化けていたのです。原因は、内部で並び順を書き換える処理が先に走り、その後のcanonical生成が書き換え後の並びを読んでいたことでした。
厄介だったのは、ページタイトルは元の並びのままだった点です。ブラウザで開いても、見た目には何ひとつおかしなところがありません。
目視の点検を何度繰り返しても、この種のズレは見つけられませんでした。修正後は、本番環境でcanonical・永続的な転送・サイトマップの並び順を、それぞれ実測して確認しています。
公開前にステージングで全ページを目視確認しました。それでも見落としが出るのでしょうか……。
目視で見つかるのは、表示崩れやリンク切れのように画面に出る不具合です。転送の種別・canonical・noindexは画面に出ないので、目視の対象になりません。
見えないものは、見るのではなく測る。これがこの章の判断基準です。
検証を工程に組み込む3つのタイミング
検証は「気づいたらやる」ではなく、工程に組み込んでおくものです。私は次の3つのタイミングを、あらかじめスケジュールに入れています。
- 公開前：確認用サイトで、対応表の上位行の応答を実測する
- 公開直後：本番で転送・canonical・noindexの3点を実測する
- 公開1週間後：Search Consoleの登録状況と表示回数を突き合わせる
公開前は、対応表のうち表示回数が多い行から順に確かめます。全件を測れるならそれに越したことはありませんが、時間が足りない前提で優先順位を決めておくほうが現実的です。公開直後は、範囲を広げるより3点に絞って本番で測ることを優先してください。
公開1週間後は、機械的な確認から数字の確認へ切り替えます。ここで見るのは旧URL側の表示回数が想定どおり落ちているかと、新URLがインデックスに登録され始めているかの2点です。
新URL側の表示回数が立ち上がるまでには数週間かかるのが普通なので、1週間時点の数字の小ささを事故と読み違えないでください。なお、どの設定をどんな手順で測るかは環境によって変わるため、ここでは判断の枠組みまでに留めます。
本文に貼ったURLの形も、引き継ぎの対象になる
引き継ぎの盲点をもう1つ挙げます。内部リンクの継承は、リンクの本数だけの話ではありません。
本文に貼ったURLの「形」も、そのまま引き継がれてしまいます。
自社メディアで実際にあった例です（自社メディアの運用・2026年7月29日修正）。公開前の記事は?p=記事番号という形のアドレスを返すため、予約投稿中の記事へ内部リンクを張ると、その形が本文に残ります。点検したところ、既存17本の記事に、延べ107か所この形のリンクが残っていて、一括で修正しました。
読者からは正しくページが開けてしまうので、誰も気づきません。URLの形は、管理画面で設定を選んだ時点では守られないのです。
「本文に貼るURLは公開後の形をそのまま書く」という運用ルールまで決めて、初めて守られます。リニューアルで本文を移す際も、この点は同じように点検してください。
求人・EC・不動産など、大量のページを抱えるサイトのSEOは「設計」で成果が決まります。インデックスされない・カニバリ・競合に負ける——DBSEO（データベース型SEO）の設計でボトルネックを特定します。まずは無料でご相談ください。
プロの判断基準：URLを変えるかは「失うもの」を数字で決める
ここまで読むと「URLは一切変えないほうがいい」と受け取られそうですが、私の立場はそこまで単純ではありません。変えないことを目的にすると、構造の改善ができなくなるからです。判断は、感覚ではなく数字で行います。
「変えない理由」を探すのではなく、失うものを数字で見る
自社メディアでも、URLを移す判断をしたことがあります（自社メディアの運用・2026年7月16日）。トップページを作り替えるにあたり、記事一覧を別のURLへ移すことになりました。
このとき私がやったのは、旧URLの実績をSearch Consoleで確認することでした。クリックはゼロ、表示は4回。この数字を確かめたうえで、失うものは小さいと判断して切り替えました。
逆にクリックが立っているURLだったなら、同じ判断はしていません。
やっていることは単純ですが、順番が違います。多くの現場では「変えない理由」を探しにいきます。
| 判断の進め方 | 最初に探すもの | 起きること |
|---|---|---|
| よく見る進め方 | URLを変えない理由 | 構造の改善まで止まってしまう |
| この記事の進め方 | 変えたときに失うものの数字 | 変えるべきところは変えられる |
そうではなく、変えたときに失うものを先に数字で見る。この順番にすると、変えるべきところは変えられるようになります。
その前提として、私は次の3点を外さないようにしています。リニューアルの設計初期からSEOを組み込むこと、対応表は最終的に人の目で精査すること、そして公開後しばらくは一時的な下落もありうると織り込んでおくこと。数字で決めるというのは、この3点を飛ばしてよいという意味ではありません。
4つの数字で決める判断フレーム
実際の会議で使えるように、判断材料を4つに絞りました。旧URLごとに、この4つを埋めてから決めます。
- 旧URLの直近の表示回数とクリック数（守る価値の大きさ）
- そのURLに集まっている内部リンクの本数（張り替えの手間）
- 外部から張られているリンクの有無（自社で制御できない分）
- URLを変えて得られる運用上の利益（何が楽になるか）
使い方は、4つのうち上3つが「失うもの」、いちばん下が「得るもの」だと考えてください。上3つがすべて小さいなら、変える判断は取りやすいはずです。逆に外部リンクが付いているURLは、自社の努力では取り戻せない資産なので、慎重に扱います。
この表を社内会議や制作会社との打ち合わせにそのまま出せるようにしておくと、議論の質が変わります。「なんとなく変えたくない」「なんとなく変えたい」という水掛け論が、4つの数字の比較に置き換わるからです。埋められない欄があるなら、それは判断材料が足りていないというサインになります。
それでも変えると決めたときに、外せない3つのこと
変えると決めたなら、あとは設計の問題です。発注の場面で確認すべきことは3つに絞れます。
制作会社から「SEOも考慮してリニューアルします」と言われています。任せておけば大丈夫でしょうか……。
「SEO考慮」の中身を、具体的な成果物で確認してください。最低限、①旧URL全件のリスト、②リダイレクト対応表、③公開前の確認用サイトでのチェック、この3点が契約や見積もりに含まれているかどうかです。
旧サイトの検索資産の棚卸しが工程に入っているかどうかは、制作会社の体制によります。SEOまで内製している会社もあれば、デザインと実装に専念する会社もあるからです。だからこそ、口頭の「SEO考慮」ではなく成果物として見積もりに書いてもらうのが、もっとも実務的な確認方法だと考えています。
成果物が約束できたら、あとは実務6ステップの順番どおりに進めます。この3点を確認するだけで、事故の大半は防げるというのが私の実感です。
なお、AI検索やチャット型の回答から流入が入り始めている企業では、リニューアルの前後で参照のされ方も変わります。この観点を掘り下げたのがBtoB企業のLLMO対策です。
公開前後のチェックリストと、順位が下がった後に確かめる順番
ここからは持ち帰って使える形にまとめます。前半は公開前後のチェックリスト、後半はすでに順位が下がってしまった場合に確かめる順番です。どちらも社内にそのまま共有できる粒度にしてあります。
公開前チェックリスト
公開日を確定させる前に、次の項目を埋めます。担当と期限の欄を空けてあるので、そのままスプレッドシートに写して使ってください。
| 確認項目 | 誰が | いつ | 確認 |
|---|---|---|---|
| 旧サイトの全URLを書き出した | 発注側 | 設計着手時 | □ |
| URLごとの表示回数・クリックを添えた | 発注側 | 設計着手時 | □ |
| 対応表が1対1で埋まっている（空欄なし） | 発注側 | 公開2週間前 | □ |
| 対応先なしのURLの扱いを明記した | 発注側 | 公開2週間前 | □ |
| 転送の種別を行ごとに決めた | 制作側 | 公開2週間前 | □ |
| 新URLがすべて実在する | 制作側 | 公開1週間前 | □ |
| 本文テキストが旧ページから痩せていない | 発注側 | 公開1週間前 | □ |
| タイトルと説明文が引き継がれている | 制作側 | 公開1週間前 | □ |
| 内部リンクの本数が減っていない | 制作側 | 公開1週間前 | □ |
| 構造化データがテンプレートに残っている | 制作側 | 公開1週間前 | □ |
| noindexの付け外しを本番想定で確認した | 制作側 | 公開前日 | □ |
| canonicalの出力先を実測した | 制作側 | 公開前日 | □ |
| robots.txtの内容を本番想定で確認した | 制作側 | 公開前日 | □ |
| 表示速度が旧サイトから悪化していない | 制作側 | 公開前日 | □ |
この表は、事故が起きたときに「どこで漏れたか」を特定する診断表としても機能します。順位が下がった場合は、上から順に確認していけば原因箇所に行き当たるはずです。
公開後チェックリスト
公開後は、確認するタイミングを2つに分けます。当日から3日以内に見るものと、1週間後にあらためて見るものは役割が違うからです。
| 確認項目 | 誰が | 公開直後 | 1週間後 |
|---|---|---|---|
| 対応表の上位行の応答を実測した | 制作側 | □ | □ |
| 本番のcanonicalを実測した | 制作側 | □ | — |
| 本番のnoindexを実測した | 制作側 | □ | — |
| サイトマップを送信し直した | 制作側 | □ | — |
| アドレス変更の通知を送った（ドメイン変更時） | 制作側 | □ | — |
| 主要ページの表示崩れを確認した | 発注側 | □ | — |
| リダイレクトの維持期限を対応表に記録した | 制作側 | □ | — |
| 計測タグが新サイトで動いている | 発注側 | □ | □ |
| インデックス登録の状況を確認した | 発注側 | — | □ |
| 旧URLと新URLの表示回数を突き合わせた | 発注側 | — | □ |
| ページ群単位で急落がないかを見た | 発注側 | — | □ |
計測タグの確認を入れているのには理由があります。リニューアルで計測が途切れると、下落が起きていても気づけません。AI検索経由の流入計測のように、従来の指標では見えにくい流入も出てきているため、計測の連続性はリニューアル時に欠かせない確認項目です。
あわせて、実務でよく見る「やってはいけないこと」も挙げておきます。
- 旧URLを全部トップページへ一律リダイレクトする
- 公開日を先に確定し、対応表が未完成のまま公開する
- リニューアルと同時にドメイン変更・CMS変更を全部やる
- 設定画面のスクリーンショットを確認の証跡にする
- 公開後の監視をせず、翌月の報告で下落に気づく
最後の項目は特に多い失敗です。公開直後の1〜2週間は、リダイレクト漏れが旧URL側の「表示回数の急減」として最初に現れる期間で、ここで気づけば傷は浅く済みます。発見が遅れるほど流入の落ちた状態が長く続き、原因の切り分けにも手間がかかるようになります。
順位が下がったとき、どの順で確かめるか
この記事に実際に届いている検索の言葉の中には、「サイトリニューアル 順位落ちた」という、すでに事故が起きた後のものがあります（自社Search Console実測・2026年5月21日〜8月18日）。上位に並ぶ記事の多くは公開前の注意点に寄っているので、ここでは事後の順番を正面から書きます。
確認する順番は、次のように決めています。先に範囲と時期を押さえ、そのあとは「戻せるまでの時間が短いもの」から順に見ていく形です。
| 順番 | 何を見るか | 戻せるまでの時間 |
|---|---|---|
| ①下落の範囲を特定する | 一部のキーワードだけか、サイト全体か | —（原因の絞り込み） |
| ②時期とトリガーを見る | 下落の開始日が公開日と一致しているか | —（原因の絞り込み） |
| ③技術トラブル系 | 転送の応答・noindex・canonical・robots.txt | 数時間で戻せる可能性がある |
| ④サイト変更系 | 本文の削減・内部リンクの減少・ページの統廃合 | 週の単位 |
| ⑤外部要因 | 検索結果全体の変動や競合の動き | 月の単位 |
③の技術トラブル系を、④や⑤より先に見るのには理由があります。技術トラブルは、原因が特定できれば数時間で元に戻せる可能性があるからです。
一方で本文の作り直しや外部要因への対応は、着手から効果が出るまでに週から月の単位がかかります。戻せる可能性が高く、かつ短時間で片付くものから順に潰すのが、下落時の時間の使い方として合理的です。
①と②を先に置いているのは、範囲と時期が分かれば原因の候補が一気に絞れるからです。サイト全体が同時に落ちているなら、個別ページの問題ではなくサイト単位の設定を疑います。
逆に一部のページ群だけなら、対応表のその部分に穴が空いている可能性が高いでしょう。⑤の外部要因については、コアアップデートからの回復で切り分けの考え方をまとめています。
どこまでの下落なら「想定内」か
下落が起きたとき、いちばん困るのは「これは待てばよいのか、直すべきなのか」が分からないことです。判断の目安になるのが、Googleが示している反映までの期間です。
Google 検索セントラルは、「原則として、小規模から中規模のサイトで大半のページの移転が反映されるのには数週間かかり、より大規模なサイトであればそれより長くかかります」と説明しています（「URL が変更されるサイト移転」）。つまり公開直後の数週間は、順位や表示回数が上下すること自体は珍しくありません。
見分ける目安は範囲と期間です。期間の基準はGoogleが示す数週間に置きます。
| 見え方 | 範囲と期間 | どう扱うか |
|---|---|---|
| 再評価にともなう揺れ | サイト全体がゆるやかに上下する／数週間のうち | 待つ。全体に手を入れない |
| 設定の問題を疑う場面 | 特定のページ群だけが急落し、戻らない | 落ちたURLを個別に確認する |
揺れと事故の分かれ目は「範囲」です。慌てて全体に手を入れる前に、落ちたページのURLを個別に確認してください。
数週間という目安を過ぎても戻らないときは、待つのをやめて前の見出しの順番に戻ります。なお、回復の時期や幅は元の評価やサイト規模によって変わるため、「いつまでに元に戻る」と約束できる性質のものではありません。AI検索での参照状況もあわせて見たい場合は、LLMO診断で現状を把握するところから始められます。
実例：リニューアルを機にアクセス約3倍にした店舗ビジネス
ここまでは守りの話が続きましたが、正しく設計したリニューアルは攻めの一手にもなるというのが実際のところです。私が制作からSEOまで担当した事例と、その裏側でまだ片付いていない宿題を、あわせて書きます。
何をやったか
店舗ビジネスのHPリニューアルを担当した事例です（守秘義務のため店名と実数は伏せます）。古いHPが長年放置され、ページが散在して内容が重複し、スマホ表示も崩れている状態からのスタートでした。
| 観点 | リニューアル前 | リニューアル後 |
|---|---|---|
| ページ構成 | 同じ内容のページが散在 | テーマ単位に整理・統合 |
| URL | 旧構成のまま放置 | 対応表を作って設計し直し |
| 検索の受け皿 | 地域や業種の言葉と噛み合わず | 実際に使われる言葉へ合わせる |
| スマホ表示 | 崩れが残る | 全ページで整備 |
実施したのは4点です。短期間での制作、散在していたページの整理と統合、旧URLからのリダイレクト設計、そして地域と業種の掛け合わせで実際に使われる言葉に合わせたページ構成。結果として、公開から2ヶ月でアクセスは約3倍になりました。
この事例で効いたのは、リニューアルを「デザインの刷新」ではなく「検索資産の再配置」として扱ったことです。どのページに何が積み上がっているかを先に把握したからこそ、整理と統合を思い切って進められました。
「うちは流入が少ないから、引き継ぐ資産もない」と思われるかもしれません。それでも棚卸しはやる価値があります。
少ない流入がどのページに来ているかを知ることは、新サイトの構成で何を優先すべきかをそのまま教えてくれるからです。壊さない設計と伸ばす設計は、同じ棚卸し作業から生まれます。
それでも残る宿題
成功事例だけを並べるのは誠実ではありません。自社の未解決の課題も開示します。
今泉の視点：この自社メディアにも、まだ直していないリダイレクトが残っています。2026年7月16日にトップを作り替えて記事一覧を別URLへ移した際、旧いページ送りのURLはSearch Consoleでクリック0・表示4回だったため切り替えました。ところが現在も旧URLは新しい一覧へ転送されず、静的なトップページを返しています。サーバーとリダイレクトの管理権限を得た段階で301を追加すると、運用文書に未対応のまま記録してあります。
この話をあえて書いたのは、リダイレクト漏れが特別な事故ではないからです。設計を知らなかったから残るのではなく、権限やタイミングの都合で普通に残ります。誰かが手を抜いたわけではなく、体制の隙間に落ちるのです。
だからこそ、公開後の点検を工程に入れておく必要があります。私は「公開したら終わり」ではなく「公開後1週間の点検までがリニューアル」だと判断しています。残っている宿題を運用文書に書き残しておくことも、次に権限が揃ったときに取りこぼさないための実務です。
よくあるご質問
まとめ：公開前の1枚の対応表が、公開後の結果を決める
- 評価はURLと中身に付く。デザイン変更自体は順位を下げない
- 本丸は旧URL→新URLの1対1対応表。一律トップ転送は避ける
- 最大の事故要因は「設定したつもり」。応答を実測して確かめる
- URLを変えるかは、失うものを4つの数字で見てから決める
- 下落時は範囲と時期を押さえ、技術トラブル系から確認する
次の一歩は、リニューアルの計画があるならSearch Consoleから全URLと流入の一覧を書き出すこと。すでに公開済みなら対応表の上位行の応答を実測すること。
もう下がってしまったなら、範囲と時期を押さえることです。どれも今日のうちに着手できます。
ここまで判断の枠組みを書いてきましたが、実際にどの設定をどう直すか、どの順番で手を付けるかは、サイトの規模・CMS・体制によって大きく変わります。具体的な実装や優先順位付けは個別状況に強く依存するので、判断に迷う場面があればSEO診断・メディア支援にご相談ください。リニューアルのタイミングではE-E-A-Tの整備もあわせて見直すと、守りと攻めの両方が前に進みます。
求人・EC・不動産など、大量のページを抱えるサイトのSEOは「設計」で成果が決まります。インデックスされない・カニバリ・競合に負ける——DBSEO（データベース型SEO）の設計でボトルネックを特定します。まずは無料でご相談ください。
