サイトリニューアル後に検索順位を落とさない｜公開前の移行チェック

サイトリニューアルの公開会議で、デザインとフォームは確認済みなのに、旧URLの行き先を尋ねると対応表がない。公開後、検索流入が落ちても、URL変更、本文変更、計測漏れが同時に起きているため原因を切り分けられない。これは想定例ですが、公開直前までSEO移行を「設定の話」として残すと起こり得る状態です。

図解

リニューアルで守る順番

1. 1 現状を記録 URL、流入、順位、問い合わせ
2. 2 移行表を作る 旧URLと新URLを対応
3. 3 転送と計測 リダイレクト、解析、フォーム
4. 4 公開後に監視 エラーと主要指標を確認

公開前に、URLと計測の引き継ぎを確認する。

SEO移行は公開直前の設定作業ではなく、旧サイトの役割を新サイトへ引き継ぐ設計です。この記事では、Google Search Centralの公式文書を2026年8月12日に再確認し、公式に案内されている事項と、火種が実務上すすめる進め方を分けて説明します。制作会社へ任せきりにせず、マーケティング担当者が公開可否を判断できる状態を目指します。

検索流入を失う原因は、URL変更だけではありません

リニューアル後に検索流入が変わる要因は、大きく三つに分けられます。これらを同じ日に変えると、どこが原因かを判定しにくくなります。

原因1：検索エンジンが旧ページと新ページの関係をたどれない

URLを変更したのにリダイレクトがない、行き先が無関係なトップページになっている、内部リンクやサイトマップが旧URLのまま、といった状態です。利用者も検索エンジンも、以前のページがどこへ移ったか判断できません。

原因2：同じURLでも、検索意図へ答えていた内容が消える

文章を短くし、サービスの特徴、料金条件、事例、よくある疑問、関連ページへの導線をまとめて削ると、URLが同じでもページの役割は変わります。見た目を整えることと、検索者が判断に使っていた情報を消すことは別です。

原因3：ページは見えても、クロール・描画・計測のどこかで止まる

本番にnoindexが残る、robots.txtで必要な資源を遮る、JavaScript実行後でなければ本文やリンクが出ない、解析タグやフォーム完了イベントが動かない、といった状態です。計測だけが欠けた場合は検索流入が落ちたように見えるため、検索の問題と計測の問題を分けて確認します。

最初に、何が変わるリニューアルなのかを分けます

Googleの公式ガイドは、利用者から見えるURLが変わる移行と、URLを変えずホスティング基盤だけを変える移行を別に案内しています。火種の推奨は、制作要件を受け取った時点で次の四つへ分類し、必要な確認を決めることです。

ドメイン変更と同時にCMS、情報設計、本文、デザインまで変えたいこともあります。ただしGoogleは、可能なら変更を一つずつ行うよう案内しています。これは「同時変更は禁止」という意味ではありません。公開期限などで分けられない場合は、変更点の一覧、旧版の記録、切り戻し条件を増やし、原因を追える状態にする必要があります。

URLを変えない場合も、本文・内部リンク・描画・計測が変わるならSEO移行の確認対象です。反対に、画像の差し替えや軽微な配色変更だけなら、全ページのURL対応表を作るより、代表ページの表示と計測確認へ時間を使えます。変更の大きさに合わせて検品範囲を変えます。

公開前の基準値は、重要ページから記録します

移行後に「順位が落ちた気がする」と話しても、公開前の状態がなければ比較できません。まず現行URLの一覧を作り、検索流入、問い合わせや購入への関与、内部・外部リンク、更新要否を記録します。全URLを同じ深さで分析できない場合は、集客と事業への影響が大きいページから始めます。

Googleの移行ガイドも、重要な旧URLを探す材料として、サイトマップ、解析データ、サーバーログ、Search Consoleのリンク情報を挙げています。ここまでは公式資料で確認できる事実です。そこへ問い合わせや営業での利用状況を加えるのが、火種の推奨です。検索流入が少なくても、商談前の説明に使う料金ページやPDFは、事業上の重要度が高い場合があるからです。

比較期間は、事業の季節性やキャンペーンを踏まえて決めます。直前の一日だけを基準にすると、曜日差や広告配信の変化を移行影響と誤認しやすくなります。基準値には対象期間と取得画面を添え、スクリーンショットだけでなく再集計できる形式でも残してください。

旧URLと新URLは、内容の対応関係で結びます

URLを変更するなら、旧URL、新URL、移行理由、扱い、確認担当を一行ずつ対応表へ記載します。新サイトの構成図だけでは、統合・廃止になった旧ページが抜けるためです。新旧のページ名が似ているかではなく、検索者が求めていた内容を新ページが引き継ぐかで行き先を決めます。

残すページは、最終の新URLへ直接移動させます

Googleは、URL変更時にサーバー側の恒久的なリダイレクトを推奨し、HTTPの301または308を例示しています。また、途中URLを何度も経由するチェーンを避け、可能なら最終URLへ直接送るよう案内しています。新ページ側では自己参照canonical、内部リンク、新サイトマップも新URLへ更新します。

「新URLが開く」だけでは確認不足です。旧URLから最終URLまでのHTTP応答と、移動先の内容をセットで確認します。ブラウザ表示だけでは途中のリダイレクトを見落とせるため、制作担当はHTTP応答を確認し、マーケ担当は行き先が利用者の期待に合うかを確認します。

統合・廃止するページは、トップページへ一律に送らないようにします

複数の旧記事を一つの新しいガイドへ統合し、内容が実際に引き継がれているなら、その統合先が候補です。一方、代わりになる内容がないページは、削除理由を確認し、404または410を返す選択があります。Googleは、無関係な多数の旧URLを一つのトップページへ送ると、利用者を混乱させ、soft 404として扱われる可能性があると説明しています。

「301なら評価をすべて守れる」と考えるのも正確ではありません。Googleは301などの恒久的リダイレクト自体によるPageRankの損失はないと案内していますが、移動先の内容、クロール可否、内部リンク、同時に行った変更まで同じとは限りません。リダイレクトは重要な土台であり、順位を保証する設定ではありません。

公開前は「検索できる・読める・測れる」の三つを分けます

ステージング環境でデザインを確認したら、検品を三群に分けます。担当者と完了日、確認したURLも残し、口頭の「確認済み」で終わらせません。

• 検索できるか：本番のrobots.txt、noindex、canonical、サイトマップ、HTTPステータス、内部リンク
• 読めるか：タイトル、見出し、本文、画像代替テキスト、構造化データ、モバイル表示、PDFや画像
• 測れるか：解析タグ、コンバージョン、フォーム送信、電話・メールリンク、完了ページ、同意管理

テスト環境に付けたnoindexやクロール制限は、本番公開時の解除漏れがないよう公開手順へ明記します。一方で、公開前の環境を検索エンジンへ見せる必要はありません。Googleのホスティング移行ガイドは、テスト用ホストのインデックスを防ぐ方法としてnoindexを案内し、本番移行時には一時的なブロックを外すよう説明しています。テストと本番で設定値を分けて管理します。

JavaScript化したページは、完成画面だけでなく取得・描画結果を見ます

GoogleはJavaScriptページをクロール、レンダリング、インデックスの段階で処理すると説明しています。GoogleがJavaScriptを実行するから確認不要、とはなりません。初期HTMLに本文やリンクがなく、資源がブロックされ、エラーで描画が止まれば、利用者のブラウザで見える画面と検索エンジンが取得できる内容がずれる可能性があります。

代表ページをSearch ConsoleのURL検査でライブテストし、レンダリング後の画面、取得HTML、読み込めなかった資源を確認します。ただし公式ヘルプでは、ライブテストで「インデックス登録可能」と表示されても、実際の登録や検索表示を保証するものではないとされています。公開前の技術確認と、公開後のインデックス確認を別にします。

問い合わせ導線は、公開済みのホームページから問い合わせが来ない原因の切り分けも使い、フォームの送信だけでなく、入口から完了までを確認すると抜けを見つけやすくなります。

制作会社と自社は、実装ではなく確認責任まで分けます

制作会社がリダイレクトを実装できても、どのページが売上や問い合わせに重要かは自社のほうが把握しています。反対に、自社が移行方針を決めても、サーバー設定、CMS、JavaScript、構造化データの実装と技術検証は制作側の確認が必要です。

実装者とは別に確認者を置き、公開を止める条件も事前に決めます。たとえば重要URLが404になる、フォームが送れない、本番にnoindexが残る場合は延期する、といった条件です。順位が動くかもしれない、という抽象的な不安では止められません。観測できる条件へ変えます。

すべての変更を一度に公開せざるを得ない場合は、旧環境へ戻せる期限、戻す担当、戻したときに失われるデータも決めます。切り戻しが不可能な工程なら、その事実自体を公開判断者へ共有します。制作会社へ「SEOも含めてお願いします」とだけ伝えるのではなく、重要URL、対応表、検品表、公開後の監視まで成果物として合意します。

公開日は重要URLの実測、公開後は変化の切り分けを行います

公開直後はトップページだけでなく、重要な旧URL、新URL、フォーム、計測イベントを実機で確認します。旧URLは意図した新URLへ移るか、新URLは200を返すか、本文とCTAは読めるかを一組で見ます。大規模なURL一覧は自動検査を使い、重要ページは人が内容まで確認します。

ドメイン変更では、条件を満たす場合にSearch ConsoleのChange of Addressを使います。ただし公式ヘルプでは、HTTPからHTTPSへの変更や、同一サイト内の一部パス変更では使わないとされています。ツールを使えばリダイレクトが不要になるわけでもありません。新旧プロパティの所有権、リダイレクト、サイトマップを先に確認します。

Googleの移行ガイドは、リダイレクトを可能な限り長く、一般に少なくとも一年維持するよう案内しています。これは公式の目安です。火種としては、外す日を公開時点で決め打ちせず、旧URLへの利用者・クローラーのアクセス、外部リンク、契約やサーバー運用を確認して判断することをすすめます。

公開後はSearch Consoleのページ登録状況、サイトマップ、検索パフォーマンスに加え、解析ツール、サーバーログ、404を見ます。Googleは大きな変更で、再クロールと再インデックスの間に一時的な順位変動が起こり得ると説明しています。変動しただけでリダイレクトを外したり本文を何度も書き換えたりせず、まず技術的な不備があるかを確認します。

順位が落ちたときは「移行ミス」と「別要因」を分けます

公開後に検索流入が落ちても、すべてが移行ミスとは限りません。季節性、広告停止、需要変化、競合ページ、検索システムの変化でも数字は動きます。一方、「いずれ戻る」と待つだけでは、noindexや誤ったリダイレクトを放置する恐れがあります。次の順番で切り分けます。

Search ConsoleのURL検査では、登録済みの情報とライブテストが異なる場合があります。公開したばかりの修正はライブ側で直っていても、登録済みの情報にはまだ反映されていないことがあります。どちらの画面を見たか、最終クロール日はいつかを記録し、「直っていない」と「まだ再処理されていない」を混同しないようにします。

技術不備を直した後に内容の改善が必要なら、公開済みのLP改善チェックリストも参照し、一度に変える要素を絞ります。リニューアル直後にURL、本文、CTAを再び同時変更すると、また比較基準を失います。

まとめ：今日、重要な旧URLを10件だけ対応表へ入れます

検索流入を守るには、変更の種類を分け、公開前の基準値を残し、旧URLと新URLを内容で対応させます。そのうえで検索できるか、読めるか、測れるかを別々に検品し、実装者と確認者を分けます。公開後の変動は、技術不備、内容変更、計測、外部要因の順に切り分けます。

今日やることは、失いたくない旧URLを10件選び、新URL・扱い・確認担当を一行ずつ並べることです。「未定」が残っても構いません。その未定を公開日までの課題として見えるようにすることが、SEO移行の出発点です。

公式情報と確認日：Google Search Central「Site Moves and Migrations」「Changing Your Web Hosting and SEO」「Redirects and Google Search」「Understand JavaScript SEO Basics」、Search Consoleヘルプ「URL Inspection tool」「Change of Address tool」（いずれも2026年8月12日確認）。