WebサイトリニューアルでSEO・AI検索・問い合わせ計測を失わない方法

Webサイトのリニューアルは、デザインやCMSを変える作業だけではありません。URL、本文、初期HTML、構造化データ、内部リンク、CTA、フォーム、計測設定を同時に変えると、検索で見つかる入口と問い合わせまでの接続が切れることがあります。

この記事は、リニューアルの前後で営業基盤を確認するための実務チェックリストです。デザインの良し悪し、CMSの選定、制作会社の比較は扱いません。リニューアル前に何を保存し、公開日に何を確認し、公開後にどの期間で見直すかに範囲を絞ります。

Netsujo SIGNALの現在の進め方では、症状を観測するObserve、実装上の原因を特定するTrace、変更内容を仕様化するSpecify、実装を進めるExecute、公開と成果を確認するVerifyの5工程で扱います。Netsujo SIGNALのサービスページでは、各工程の入力・出力と確認範囲を公開しています。

結論：リニューアル前に「残す・変える・なくす」を対応表にする

最初に作るべき資料は、デザイン案ではなくURLと営業基盤の対応表です。旧URLを新URLへどう対応させるか、何を引き継ぐか、何を終了するかを決めます。そのうえで、次の3つを別々の時点で確認します。

• 公開前：重要URL、検索・問い合わせの基準値、本文と会社情報、計測イベントを保存する
• 公開直後：redirect、canonical、初期HTML、構造化データ、内部リンク、CTA、フォームを確認する
• 公開後：7日程度で早期の異常を確認し、28日程度で検索・アクセス・問い合わせの変化を基準期間と比較する

7日と28日は当社の運用目安です。サイト規模、更新頻度、季節性によって適切な期間は変わるため、公開前に比較期間と判断者を決めておきます。検索順位、AI回答への掲載、問い合わせ数は、どの期間を取っても保証できません。

1. 公開前に保存する6つの基準

新サイトが完成してから旧サイトを確認すると、変更前の状態を再現できません。少なくとも次の情報を、取得日と取得元を添えて保存します。

Search ConsoleやGA4の数値は、対象期間を固定して保存します。数値が無い場合は「0」ではなく「未計測」と記録します。AI検索の回答は毎回同じとは限らないため、サービス名だけでなく、質問文・実行日時・利用したサービスを残します。

2. URL移行は、対応表・redirect・canonicalを一緒に確認する

URLを変えるリニューアルでは、旧URLと新URLの対応が最初の検査対象です。Google Search Centralのサイト移転ガイドも、URL対応表の準備、redirect、公開後の監視を一連の手順として説明しています。

redirectを設定しただけでは完了ではありません。新URLのcanonical、robotsのnoindex、sitemap掲載、サイト内の内部リンク、言語切替リンクが同じ方針になっているかを確認します。Googleはcanonicalの指定方法としてredirect、rel="canonical"、sitemapを挙げていますが、それぞれの強さや役割は異なります。canonicalの公式ガイドを参照し、1つの方法だけで移行が終わったと判断しないでください。

対応表には、少なくとも次の列を持たせます。

1. 旧URL
2. 新URL
3. redirectの種類と実装場所
4. 新URLのcanonical
5. sitemap掲載の有無
6. 内部リンクの更新元
7. 担当者
8. 公開後の確認日

3. 初期HTML・metadata・構造化データを分けて確認する

リニューアル後の画面がブラウザで正しく見えても、初期HTML、JavaScript実行後のDOM、構造化データが同じ情報を持つとは限りません。重要なサービス名、対象顧客、提供結果、問い合わせ先がどこで出力されるかを分けて確認します。

構造化データは、ページの意味を検索エンジンへ伝える手がかりになります。ただし、正しく実装しても検索結果への表示を保証するものではありません。画面上の主要情報と構造化データを一致させ、公開後はGoogleの構造化データガイドとRich Results Testなどで検証します。

初期HTMLとDOMの差分を深掘りしたい場合は、JavaScriptレンダリングとクローラーの確認方法へ委譲します。構造化データの種類やJSON-LDの書き方は、構造化データ実装ガイドが担当します。

4. CTAとフォームの計測を「名前」ではなく行動で引き継ぐ

リニューアルでボタンの見た目やフォームの仕組みが変わると、GA4イベントが発火しなくなったり、同じクリックが二重計測されたりします。公開前に、旧サイトの計測イベントを一覧にして、新サイトでどう扱うかを決めます。

GA4ではイベントがWebサイト上のユーザー行動を測定し、RealtimeやDebugViewで発火状況を確認できます。GA4公式のイベント設定ガイドに沿って、イベント名とパラメータを記録します。イベント数だけでなく、どのページからどのサービスの問い合わせへ進んだかも残します。

計測設計の詳細は、SEO・AIO施策を問い合わせにつなげる計測方法で扱っています。この記事では、リニューアル前後で計測の連続性を失わないための確認に限定します。

5. 制作会社へ渡す内容を1件ずつ仕様化する

「SEOを落とさない」「AI検索に対応する」「計測を引き継ぐ」だけでは、実装担当者が作業を始められません。課題ごとに、対象URL、確認した事実、変更内容、完了条件、公開後の確認を1件の仕様へ落とします。

仕様書の書式と記入例は、Web改善仕様書の書き方へ委譲します。リニューアル記事で14項目をすべて再説明すると、仕様書そのものの主意図と競合するためです。

6. 公開直後・7日後・28日後で見る項目を分ける

公開当日に検索順位を評価しても、クロールや利用者行動の変化を判断できません。一方、公開直後にstatusやフォームを確認しなければ、問題が残ったまま観測期間へ入ってしまいます。

公開後に数値が動いても、リニューアルだけが原因とは限りません。季節性、コンテンツ追加、広告、競合、検索エンジン側の変化を併記し、観測できた事実と推測を分けて記録します。

7. 既存の制作会社を変えずに進める方法

リニューアルの実装担当と、検索・AI・計測の課題を整理する担当は同じ会社である必要はありません。既存の制作会社へそのまま渡せる粒度で、次のものを共有します。

• URL対応表と、残す・変える・なくすの判断
• 公開前に保存した基準値と取得元
• 旧サイトと新サイトの実装差分
• CMS、リポジトリ、タグ、ドメイン、GA4、Search Consoleの担当者
• 課題ごとの変更内容、完了条件、公開直後の検証
• 質問事項、未確認事項、判断期限

Netsujo SIGNALは、既存の制作会社を置き換えることを前提にしていません。無料診断は公開情報を対象とし、権限や契約範囲に応じてGA4・Search Console、CMS、リポジトリ、GTMなどを確認します。必要に応じて、制作会社が見積もり・実装へ進める改善仕様、コード例、差分、Pull Requestなどへ変換します。詳細はAIO・AI検索対策支援とNetsujo SIGNALの分析範囲を確認してください。

よくある質問

URLを変えなければ、SEOの確認は不要ですか？

不要ではありません。URLを維持しても、初期HTML、title、canonical、構造化データ、内部リンク、CTA、フォーム、計測タグが変わる可能性があります。URL移行の確認が減るだけで、営業基盤全体の確認は残ります。

redirectを設定すれば移行は完了ですか？

完了ではありません。redirect先の内容、canonical、sitemap、robots、内部リンク、言語切替、計測、公開後のSearch Consoleを確認します。関係の薄いページへ一括redirectすると利用者にも検索エンジンにも意図が伝わらないことがあるため、対応表を先に確定します。

リニューアルの実装は既存の制作会社、診断はSIGNALという分担にできますか？

できます。重要なのは、診断結果を「SEOを改善する」という方針で止めず、対象URL、確認事実、変更内容、完了条件、検証方法へ変換することです。実装者と検証者の担当範囲、必要な権限、公開日を先に共有します。

まとめ：リニューアルを営業基盤の検証可能な変更にする

Webサイトリニューアルで守るべきなのは、デザインだけではありません。次の順で確認します。

1. 重要URL、検索・問い合わせの基準値、事業情報、計測イベントを保存する
2. 旧URLと新URLの対応表を作り、redirect・canonical・sitemap・内部リンクをそろえる
3. 初期HTML、metadata、JSON-LD、レンダリング後DOM、CTA、フォームを別々に確認する
4. 課題を対象URL・変更内容・完了条件・検証方法の仕様へ変換する
5. 公開直後、7日程度、28日程度で見るものを分ける

リニューアル前後の差分を自社だけで切り分けにくい場合は、SIGNALの無料診断で公開情報から最初の確認点を整理できます。無料診断は公開情報のみを対象とし、検索順位、AI回答への掲載、問い合わせ数を保証するものではありません。