リニューアルで順位を落とさない手順｜AIでSEOを引き継ぐ

「来期に向けて、コーポレートサイトのリニューアル計画が動き出した」——デザイン刷新、CMSの入れ替え、コンテンツの再編。社内が新しいサイトへの期待で盛り上がる一方、SEO担当者にとってリニューアルは、これまで積み上げてきた検索評価を失いかねない最大級のリスクイベントでもあります。実際、リニューアル後に検索流入が激減し、数か月気づかれないまま機会損失が続いた、という失敗は後を絶ちません。しかし恐れる必要はありません。Googleはサイト移転の公式ガイドで手順を明確に示しており、正しい手順で評価を引き継げば、順位の下落は防げる、あるいは一時的な変動にとどめられるからです。本記事では、その手順を最初から最後まで、生成AIで効率化できる工程とあわせて解説します。

リニューアルの話が動き出したら：デザインの前に決めること

リニューアルプロジェクトの初期は、デザイン案やサイトマップ（画面構成）の議論が中心になりがちです。しかしSEOの観点で最初に確定すべきは、もっと地味な論点——URLが変わるのか、変わらないのかです。ドメインは変わるのか、ディレクトリ構造は再編するのか、記事のURLは維持されるのか。この答えによって、必要な作業量がまったく変わります。URLが1つも変わらないリニューアルなら評価引き継ぎのリスクは大幅に小さく、URLが全面的に変わるなら本記事の手順一式が必要になります。

この論点を制作会社との要件定義に早めに持ち込むことが、SEO担当者の最初の仕事です。制作会社は必ずしもSEOの引き継ぎを標準工程に含めていません。見積もりと工程表に「URL設計の確認」「リダイレクト設計・実装」「移行後の計測確認」が含まれているかを確認し、含まれていなければ追加してもらいましょう。公開直前にリダイレクトの話を始めるのは手遅れです。プロジェクトの開始時点、つまり今この段階で議題に載せてください。

なぜリニューアルで順位が落ちるのか：評価はURLに積み上がる

そもそも、なぜリニューアルで順位が落ちるのでしょうか。検索エンジンは、ページの評価をURL単位で蓄積しています。コンテンツの内容、集まった被リンク、検索での実績——これらはすべて特定のURLに紐づいた資産です。リニューアルでURLが変わるということは、検索エンジンから見れば、評価済みのページが消えて、評価ゼロの新しいページが現れたのと同じことです。中身が同じでも、住所が変われば別人として扱われる。これが下落の基本メカニズムです。

この分断を防ぐ橋渡しが、旧URLから新URLへの転送、すなわちリダイレクトです。恒久的な転送を意味する301リダイレクトを設定すると、検索エンジンは移転を理解し、旧URLの評価を新URLへ引き継ぎます。逆に言えば、リダイレクトの漏れは、その分だけ評価資産を捨てることを意味します。なお、順位下落の原因はURL変更だけではありません。テスト環境の設定の持ち込み、コンテンツの削減、内部リンク構造の変化なども絡みます。これらは後半の失敗パターンとチェックリストでまとめて潰します。

全体像：移行は6つの手順で進める

ここからが本題の手順です。Googleの公式ドキュメント「URL の変更を伴うサイト移転」の推奨事項をベースに、実務の流れとして6つの手順に整理しました。まず全体像をつかんでください。

Googleのガイドによれば、移転がGoogleに処理されるまでの期間は、中規模のサイトで大半のページの反映に数週間、大規模サイトではそれ以上が目安とされています。つまり移行は公開日で終わらず、数週間から数か月の監視期間まで含めてワンセットです。また、規模の大きなサイトでは、全体を一度に移転せず区分ごとに移転する方法も公式に認められています。以降、各手順を詳しく見ていきます。

手順1：現状の棚卸し——全URLと流入データを記録する

最初の手順は、いま持っている資産の目録づくりです。まず、現行サイトの全URLリストを作ります。取得元としてGoogleが挙げているのは、XMLサイトマップ、サーバーログ、そしてSearch Consoleです。CMSのエクスポート機能やクローラーツールも併用すると漏れが減ります。このリストが、後のマッピング表の左側の列になります。

次に、URLごとの重要度がわかるデータを紐づけます。アクセス解析から過去1年の流入数、Search Consoleから表示回数・クリック数と主な検索キーワード、可能なら被リンクの状況も加えます。この作業の目的は2つあります。第一に、流入や被リンクの多い重要ページを特定し、マッピングとリダイレクトの優先順位を決めること。Googleも重要なコンテンツからマッピングを始めることを推奨しています。第二に、移行後の比較の基準値（ベースライン)を残すことです。移行後に「落ちたのか、元からこうなのか」を判断するには、移行前の記録が不可欠です。棚卸しの表はスプレッドシートで十分ですが、必ず日付つきで保存してください。

手順2：URLマッピング表を作る（公式ガイドの中心作業）

棚卸しができたら、移行作業の心臓部であるURLマッピング表を作ります。旧URLを左の列、対応する新URLを右の列に置いた、ただの対照表です。しかしこの表の精度が、移行の成否をほぼ決めます。原則は1対1の対応です。旧ページの内容を最も引き継ぐ新ページへ、1本ずつ対応させます。安易に「旧ページはぜんぶトップページへ転送」とまとめるのは悪手です。ユーザーは探していた情報にたどり着けず、検索エンジンにも適切な移転として伝わりません。

リニューアルではページの統合や廃止も発生します。統合されるページは、統合先の新ページへ転送します。廃止されるページは、内容が最も近い代替ページがあればそこへ、なければ無理に転送せず404（ページが存在しない）を返す判断もあります。関連性のないページへの一括転送より、正直な404のほうが健全というのがGoogleの考え方です。また、画像やPDFなどのファイルも埋め込みコンテンツとしてマッピング対象になる点は見落としがちです。数百〜数千行になるこの表づくりこそ、後述する生成AIの活躍どころです。

個別ページの対応に加えて、URLの表記ゆれの扱いも決めておきます。末尾スラッシュの有無、wwwの有無、httpとhttpsの混在、パラメータ付きURL——これらは1本ずつ対応表に書くのではなく、パターンとしてルール化して転送します。表記ゆれはリニューアルと無関係に発生しているものも多いため、このタイミングでまとめて正規化しておくと、移行後のサイトはクロールもアクセス分析もきれいになります。マッピング表には、個別対応の行とパターン対応のルールを分けて記載しておくと、実装する側にも意図が正確に伝わります。

手順3：リダイレクトを設計する——301の仕様と維持期間

マッピング表ができたら、それをリダイレクト設定に落とし込みます。Googleが推奨するのはサーバーサイドの恒久的リダイレクト（HTTPステータスコードの301または308）です。リダイレクトにはいくつか種類があり、検索での扱いが異なります。

種類	意味	検索での扱い
301 / 308	恒久的な移転	転送先を検索結果に表示し、正規のURLとして扱う強いシグナル
302 / 303 / 307	一時的な移転	転送元を検索結果に表示し続ける。恒久移転には不向き
meta refresh（0秒）	HTML側での転送	サーバー側で設定できない場合の次善策
JavaScriptによる転送	スクリプトでの転送	他の手段が使えない場合の最終手段

設計時の注意点は2つです。第一に、リダイレクトの連鎖（旧URL→中間URL→新URL）を作らないこと。Googleは最大10ホップまで追跡するとしていますが、連鎖は3回以下、理想は直接転送が推奨です。過去のリニューアルのリダイレクトが残っている場合、今回の設定と連鎖しやすいため、古い設定も新URLへ直接向け直します。第二に、維持期間です。公式ガイドはリダイレクトを最低1年間維持し、可能であれば無期限で維持することを推奨しています。被リンクは旧URLに向いたまま残り続けるため、「もう浸透しただろう」と早々に外すのは評価の取りこぼしにつながります。

手順4：テスト環境のnoindexを本番に持ち込まない

新サイトはテスト環境で構築・確認するのが普通です。テスト環境は検索結果に出てはいけないため、noindex（検索登録の拒否）やrobots.txtによるブロック、あるいはWordPressなら「検索エンジンがサイトをインデックスしないようにする」のチェックで、検索エンジンから隠されています。ここに、リニューアル事故の最大の火種があります。この隠す設定ごと本番公開してしまう——信じがたいかもしれませんが、リニューアル後の流入激減の原因として最も定番の一つです。

公開後にサイト全体がnoindexのままだと、検索エンジンは指示に従って、時間とともにページを検索結果から外していきます。数日〜数週間かけてじわじわ流入が減るため、原因に気づくのが遅れやすいのも厄介な点です。対策は仕組み化に尽きます。公開手順書に「noindex・robots.txt・CMSのインデックス設定の確認」を明記し、公開直後に複数人でチェックする。確認自体は、ページのHTMLソースにnoindexの記述がないか、robots.txtが全体をブロックしていないかを見るだけで、数分で終わります。数分の確認が数か月分の流入を守ります。

なお、テスト環境を検索から隠す方法そのものにも注意点があります。robots.txtでブロックするだけでは、クロールは防げてもURLの存在自体が検索結果に出てしまう場合があり、確実な隠蔽とは言えません。テスト環境はパスワード認証（Basic認証など）で保護するのが定石です。アクセス制限がかかっていれば検索エンジンは内容に到達できず、公開時は認証を外すだけで済むため、noindexの外し忘れという事故の構造そのものをなくせます。制作会社への要件として、プロジェクトの最初に伝えておきたいポイントです。

手順5：公開当日の作業——サイトマップと動作確認

公開当日は、切り替え作業に続けて確認作業を行います。第一に、リダイレクトの動作確認です。マッピング表から重要ページを中心に抽出し、旧URLにアクセスして、正しい新URLに301で転送されるかを確かめます。全件の機械的な確認は後述のAI活用で行うとして、当日はまず主要導線を人の目で確認します。第二に、新しいURLで構成したXMLサイトマップをSearch Consoleに送信します。Googleに新構成を効率よく伝える公式ルートです。ドメイン自体が変わる移転では、Search Consoleのアドレス変更ツールの利用も公式に案内されています（HTTPからHTTPSへの変更では不要です）。

第三に、計測の稼働確認です。アクセス解析や広告の計測タグはリニューアルで消えやすい代表格で、消えたことに気づかず「移行後のデータがない」となれば、順位が守れたかどうかの検証すらできなくなります。リアルタイムレポートで計測が動いているかをその場で確認してください。あわせて注意したいのが、公開直後のサーバー負荷です。

• 移転直後はGoogleのクロールが一時的に増えるため、サーバーの処理能力に余裕を持たせておく
• 旧URLが検索結果にしばらく残るのは正常な動作。手動での削除申請は原則不要
• 公開直後の順位変動は移行処理中のゆらぎであることが多い。1〜2週間は設定修正以外の大きな変更を避ける
• フォーム・問い合わせなどコンバージョン導線の動作確認も当日中に行う

手順6：公開後の監視——数週間は横ばいでも慌てない

公開後の監視で軸になるのはSearch Consoleです。見るべきは3か所。まずカバレッジ（ページのインデックス登録）で、新URLの登録が進み、旧URLがリダイレクトとして処理されているかを確認します。次に検索パフォーマンスで、サイト全体のクリック数・表示回数の推移を移行前のベースラインと比較します。最後にリンクレポートで、主要な被リンクが新URLへ評価として引き継がれていく様子を追います。クロールエラーや404の急増は、マッピング漏れの兆候です。見つけ次第、リダイレクトを追加します。

心構えとして大切なのは、時間軸の感覚です。前述のとおり、中規模サイトでも処理には数週間かかります。この期間、順位や流入が一時的に波打つのは想定内の動きです。慌てて設定を二転三転させると、かえって処理を混乱させます。週次で定点観測し、エラー対応以外はどっしり構えるのが正解です。逆に、1〜2か月経っても明確に流入が戻らない場合は、リダイレクト漏れ・noindex・内部リンク切れなど、どこかに実害が残っています。本記事後半のチェックリストで総点検してください。

比較の実務にも一工夫を。サイト全体の合計値だけを見ていると、製品ページの下落を記事ページの好調が打ち消して、異変が見えないことがあります。移行前に取ったベースラインをページ群単位（製品・記事・会社情報など）で集計し直し、週次で並べて見るのがおすすめです。この集計表の整形は、エクスポートしたデータを渡せば生成AIが数分で済ませてくれます。異変に気づく速さが、そのままリカバリーの速さを決めます。

AIの使い所(1)：リダイレクトマップ作成を半自動化する

ここからは、生成AIで工数を圧縮できる工程です。最大の活躍どころが、手順2のURLマッピング表づくりです。旧URLが数百〜数千本ある場合、1本ずつ新URLと突き合わせる作業は膨大です。そこで、旧URLリストと新URLリストの両方をAIに渡し、対応候補を提案させます。プロンプトの型はこうです。

以下は、リニューアル前後のURLリストです。

・旧URLリスト：（URLとページタイトルの一覧を貼る）
・新URLリスト：（URLとページタイトルの一覧を貼る）

やってほしいこと：
1. URLの構造とタイトルの類似性から、旧URLごとに対応する新URLの候補を提案する
2. 確信度を高・中・低の3段階で付ける
3. 対応先が見つからない旧URLを別リストにまとめる

出力は、旧URL・新URL候補・確信度の3列の表にしてください。

URLの命名やタイトルに規則性があれば、AIのマッチング精度はかなり高くなります。ポイントは確信度を付けさせることです。確信度の高いものは目視でサンプル確認、低いものは全件を人が判断という形で、人の確認時間を効果の大きい箇所へ集中できます。対応先が見つからないリストは、統合・廃止の判断が必要なページとして編集会議にかけます。数日仕事だったマッピングの下ごしらえが、これで数時間に縮みます。

AIの使い所(2)：設定の記述と公開後の確認を任せる

マッピング表が確定したら、サーバー設定への変換もAIに任せられます。確定した対照表を渡し、使っているサーバー環境（Apache、nginxなど）を伝えて、301リダイレクトの設定記述を生成させます。正規表現でまとめられるパターンと個別指定すべき行の整理も、AIが得意とするところです。ただし、サーバー設定ファイルの記述ミスはサイト全体を止めるリスクがあるため、生成された設定は必ずテスト環境で検証してから本番に適用してください。

公開後の全件確認も自動化できます。旧URLの一覧に順番にアクセスし、ステータスコードと転送先を記録するチェックスクリプトをAIに書かせれば、マッピング表どおりに動いているかを機械的に照合できます。目視では現実的でない数千件の検証が、一覧表として手に入ります。照合結果のうち、404が返る行や意図と違う転送先の行だけを人がレビューし、修正して再実行する。この回し方なら、リダイレクトの品質を数字で保証しながら移行を完了できます。

定番の失敗4パターン：事故はいつも同じ場所で起きる

リニューアル後の順位下落は、原因を並べてみると驚くほど同じ顔ぶれです。制作の失敗事例やSEO会社の報告で繰り返し挙げられる定番を押さえておきましょう。

• リダイレクトの設定漏れ・一括転送：URL変更したのに転送がない、全部トップページ行きにする——評価引き継ぎの断絶
• テスト環境のnoindexを本番に持ち込む：サイト全体が検索結果から静かに消えていく最悪パターン
• 計測タグの載せ忘れ：移行後のデータが取れず、問題の発見も効果検証もできなくなる
• コンテンツの無断削減：デザイン優先で本文や記事を減らし、評価されていた情報ごと失う

共通項は、どれも公開前の確認で防げることです。技術的に難しい失敗はほとんどありません。工程の終盤で時間が足りなくなり、確認が省略されたときに事故は起きます。だからこそ、次章のチェックリストを公開判定の関門として、プロジェクトの工程表に最初から組み込んでおくことをおすすめします。

移行前チェックリスト：公開ボタンを押す前に

公開前の最終確認として、以下を関係者全員で読み合わせてください。1つでも未完了があれば、公開日を延ばす勇気がリスクを最小化します。

• 旧サイトの全URLリストと流入・順位のベースライン記録を保存した
• URLマッピング表が完成し、重要ページは1対1の対応を目視確認した
• 301リダイレクトをテスト環境で検証し、連鎖や誤転送がないことを確認した
• 新サイトのnoindex・robots.txt・CMSのインデックス設定を確認した
• アクセス解析・広告などの計測タグが新サイトに実装されている
• 新URLのXMLサイトマップを用意し、公開後すぐ送信できる状態にした
• 公開後の監視担当者と確認スケジュール（当日・1週間・1か月）を決めた

このリストは最低限の共通項です。自社の状況——多言語サイト、EC機能、会員ページなど——に応じて項目を足してください。チェックリストの読み合わせという一手間が、リニューアルの成否を分ける最後の防波堤になります。

用語ミニ解説：移行の会議で出てくる言葉

最後に、リニューアルの打ち合わせで飛び交う専門用語を整理しておきます。制作会社との会話で意味の取り違えが起きると、そのまま設定ミスにつながるため、あいまいな言葉はこの表で確認してください。

用語	意味
301リダイレクト	恒久的な移転を示す転送。評価の引き継ぎに使う基本手段
URLマッピング	旧URLと新URLの対応表を作る作業。移行設計の中心
noindex	検索結果に登録しないよう指示する設定。テスト環境の隠蔽に使われる
robots.txt	クローラーへの巡回許可・拒否を書くファイル。全体ブロックの事故に注意
XMLサイトマップ	サイトのURL一覧を検索エンジンに伝えるファイル。移行後は新URL版を送信
404	ページが存在しないことを示す応答。廃止ページでは正直に返す判断もある

用語の理解は、丸投げ防止の意味でも重要です。設定の実作業は制作会社が行うとしても、何がどう設定されたかを発注側が検証できる状態にしておくことが、事故の早期発見につながります。この表の用語について「今回どうなっていますか」と質問できれば、確認すべき論点はほぼ押さえられます。

それでも落ちてしまったら：リカバリーの手順

手順を尽くしても、順位や流入が落ちてしまうことはあります。そのときは、感覚で動く前に事実の特定から始めます。Search Consoleの検索パフォーマンスで移行前後の期間を比較し、下落がサイト全体で起きているのか、特定のページ群だけなのかを切り分けます。全体で落ちているなら、noindexの残留・robots.txtのブロック・計測タグの欠落といった、サイト全体に効く設定をまず疑います。特定のページ群だけなら、そのグループのリダイレクト漏れ、内容の削減、内部リンクの断絶が有力候補です。この切り分けだけで、点検すべき範囲が一気に狭まります。

原因の候補が絞れたら、移行前チェックリストの該当項目を再点検し、旧URLのステータス確認スクリプトを再実行して、実害の残っている箇所を修正します。修正を終えたら、重要なページからインデックス登録をリクエストし、数週間単位で回復の推移を追います。焦りから旧サイトへの切り戻しを検討したくなるかもしれませんが、切り戻しは検索エンジンから見ると移転の二重発生であり、処理の混乱をかえって長引かせるリスクがあるため最終手段です。原因を特定して直し、待つ。回復はこの繰り返しでしか起きない——遠回りに見えて、これが最短の道です。

リニューアルを順位改善の機会に変える

ここまで守りの話を続けてきましたが、リニューアルは攻めの機会でもあります。サイト全体を棚卸しするタイミングだからこそできる改善があるからです。たとえば、内容が薄く重複していた記事の統合。手順1の棚卸しデータを使えば、流入のない類似ページを特定し、1本の充実したページにまとめられます。表示速度の改善も、テーマやサーバー構成を刷新するこの機会が最も低コストです。内部リンクの再設計、古い情報の更新、スマートフォン体験の改善——蓄積した課題を一括で解消できるのはリニューアルのときだけです。

ここでも生成AIが下ごしらえを担えます。棚卸しデータを渡して統合候補の組み合わせを挙げさせる、新しいサイト構成案に対して内部リンクの設計案を出させる、といった使い方です。守りの移行手順を土台に、攻めの改善を上乗せする。この二段構えができれば、リニューアルは「順位が落ちませんように」と祈るイベントではなく、検索流入を一段引き上げる投資になります。改善の優先順位づけには手順1の棚卸しデータがそのまま使えます。データに基づいた取捨選択ができるのは、移行手順を丁寧に踏んだチームだけの特権です。

まとめ

リニューアルで順位を落とさない要点は、URLマッピングと301リダイレクトで評価の引っ越しを設計し、公開前チェックで定番事故を潰すことに尽きます。検索評価はURLに積み上がるため、Google公式ガイドに沿って、棚卸し→マッピング→リダイレクト→テスト確認→公開作業→監視の6手順で進めます。リダイレクトは301で最低1年、できれば無期限に維持。noindexの持ち込みと計測タグの消失は、チェックリストの読み合わせで防ぎます。マッピングの下ごしらえ、設定の記述、公開後の全件検証は生成AIで半自動化できるようになりました。リニューアルの話が動き出したいまが、手順を工程表に組み込む最良のタイミングです。まずは現行サイトの全URLリストづくりから着手してみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。