サイトリニューアルは、デザインを更新するだけでなく、検索順位や流入にも影響する取り組みです。既存のSEO評価をできる限り維持しながら、新たな検索流入を獲得するには、企画段階から公開後まで一貫して対策する必要があります。本記事では、サイトリニューアル時に必要なSEO対策を、準備・実装・確認・公開後の監視という流れに沿って解説します。

サイトリニューアルがSEOに与える影響

サイトリニューアルが検索順位に与える影響は、事前の調査と移行設計によって変わります。目的がデザイン刷新やCMS変更であっても、URL、コンテンツ、内部リンク、クロール・インデックス設定を適切に引き継がなければ、検索順位や流入が下がる可能性があります。一方、既存の課題を把握して改善すれば、SEOとユーザー体験を同時に高める機会にもなります。

リニューアル後に検索順位や流入が下がる理由

リニューアル後に順位や流入が下がる主な原因は、検索流入のあるページを削除したり、URLを変更したにもかかわらず適切なリダイレクトを設定しなかったりすることです。旧ページと関連性の高い新ページを用意し、恒久的なリダイレクトで移転を伝えれば、URL変更による影響を抑えられます。

ページの内容や内部リンクが大きく変わった場合も、検索エンジンによるページの理解や重要度の判断が変化します。さらに、誤ったnoindex、canonical、robots.txt、ステータスコードの設定、表示速度やモバイルでの使いやすさの悪化なども流入減少の原因になります。

リニューアルによってSEO評価を高められる場合

一方で、リニューアルを機に既存サイトの構造や導線を見直し、SEOパフォーマンスとユーザー体験を同時に高めるサイト設計を検討することで、逆にSEO評価を上げることができます。このためには、タイトルの調整、パンくずリストの最適化、内部リンク設計の強化、重複ページの改善、canonicalタグの調整などの内部SEO対策に加え、キーワード調査と競合比較に基づいた戦略設計が必要です。

具体的には、現在のサイトで獲得できていない検索ニーズを調査し、必要に応じて新しいページを追加したり、既存ページを改善したりします。また、ユーザーが必要な情報へたどり着きやすいサイト構造へ整理することは、回遊性とクローラビリティの改善にもつながります。

重要なのは、リニューアルを単なる「古いサイトを新しくする」という作業ではなく、「サイトの価値を最大限に引き出す」という戦略的な機会として捉えることです。

サイトリニューアル時に起こるSEOリスク

リニューアル時のSEOリスクは多岐にわたり、企画段階での対策が重要です。URL構造、内部リンク構造、URL正規化、テクニカルSEOの実装仕様などをすべて洗い出し、踏襲・変更・廃止を判断する必要があります。これらのリスクを正しく認識し、事前に対策することで、リニューアルによる流入減少を最小限に抑えることができます。

重要コンテンツの削減による検索流入の減少

検索流入があるページを安易に削除すると、サイト全体のトラフィックが減る可能性があります。ページを廃止する場合は、内容を引き継ぐ関連性の高いページがあれば301リダイレクトを設定します。適切な後継ページがなければ、無関係なページへ転送せず、404または410を返すことも選択肢です。旧URLと新URLの対応表を作り、ページごとに処理方法を決めましょう。

低品質ページか高品質ページかの判断は、複合的なデータから総合判断する必要があります。検索意図との一致度、独自性の有無、ユーザー行動の質（離脱率、スクロール率、CV貢献度）、インデックス状況、内部リンクでの評価配分などを総合的に見て判断しましょう。例えば、離脱率が非常に高く、検索意図を満たしていないと判断されるページであれば、削除の対象になるかもしれません。しかし、その前にページを改善できないかを検討することが大切です。

削除だけでなく、改善、統合、再構築によって既存コンテンツを活かせないか検討します。検索流入がないという理由だけで不要と判断せず、ビジネス上の役割、被リンク、内部リンク、コンバージョンへの貢献も確認したうえで、維持・改善・統合・削除・noindexのいずれが適切かを決めます。

表示速度やクローラビリティの悪化

リニューアルに伴うサーバー移行やシステム変更により、サイトの表示速度が低下することがあります。ステージング環境で検証し、サーバースペックやデータベース処理などがボトルネックになっていないか確認しましょう。大規模サイトでは、応答速度の悪化や5xxエラーの増加がクロールやユーザー体験に影響する場合があります。

サーバーの応答が不安定だったり処理能力が不足していたりすると、Googlebotがクロールできる量にも影響します。ただし、クロールバジェットが重要な課題になるのは、主にURL数が非常に多い大規模サイトや更新頻度の高いサイトです。一律の応答時間をSEO基準とするのではなく、Search Consoleのクロール統計、サーバーログ、Core Web Vitalsなどから問題を確認します。

クローラビリティを改善するには、URL構造、内部リンク、canonical、ステータスコード、robots.txtなどの実装仕様を整理します。noindexはインデックスから除外するための設定であり、クロールを止める設定ではありません。また、robots.txtでクロールを拒否すると、Googleがページ内のnoindexを確認できないため、目的に応じて使い分ける必要があります。

NYマーケティングでは、社内ツールでWebサーバーの生ログを分析し、GooglebotがクロールしているURLや頻度を可視化したうえで、大規模サイトのクロール改善に活用しています。詳細はクロール分析サービスの解説をご覧ください。

301リダイレクトの設定ミスによる評価の引き継ぎ失敗

301リダイレクトの設定ミスは、リニューアル後の流入減少の大きな原因になります。一般的な原因は事前のURL対比表の漏れやミスで、システム的な設定ミスもあるため必ずステージング環境でテストすることが重要です。

301リダイレクトは、旧URLが恒久的に新URLへ移転したことをユーザーと検索エンジンに伝える方法です。Googleは恒久的なリダイレクトを、転送先を正規URLとして扱うための強いシグナルとして利用します。ただし、関連性の低いページへの転送やリダイレクトチェーン、設定漏れがあると、期待した移行になりません。

canonicalタグはリダイレクトではなく、重複または非常に類似した複数のURLがアクセス可能な状態で、優先するURLを示すシグナルです。URLを恒久的に変更する場合は301または308、重複URLを残す必要がある場合はcanonicalというように、目的を分けて使用します。

内部リンク構造の変更による重要ページの評価低下

内部リンク構造の変更は、重要ページの発見されやすさやサイト内での位置づけに影響します。DB型サイトでは、トップページ、カテゴリページ、詳細ページという階層を基本に、関連するカテゴリや詳細ページへ移動できる構造を設計します。

トップページや主要カテゴリから重要ページへのリンクがなくなったり、クリック階層が深くなったりすると、ユーザーとGooglebotの双方がページを見つけにくくなります。重要度、関連性、新規ページへのクロール経路を考慮して内部リンクを設計しましょう。

詳細ページ同士の内部リンクも関連性を重視して設計し、仕様書に落とし込んで実装担当者と認識をそろえます。WordPressを使った記事型メディアでも、関連記事へのリンクを整理することで、トピック間の関係を示しながらユーザーの回遊を促せます。

NYマーケティングでは、SEOツール「NYSEO」を内部リンク候補の抽出や設計に活用しています。社内の運用例では、従来の手作業と比べて工数を大幅に削減できたケースがあります。詳細はNYSEOの紹介ページをご覧ください。

CMS・ドメイン変更時に発生する固有のリスク

CMS（コンテンツ・マネジメント・システム）の変更やドメイン変更は、リニューアルの中でも確認項目が多い施策です。CMSを変更すると、タイトル、見出し、canonical、構造化データ、内部リンク、レンダリング方法などが意図せず変わることがあります。旧サイトと新サイトのHTMLを比較し、ページの主題や構造が適切に伝わる状態を維持できているか確認します。

ドメイン変更ではすべてのURLが変わるため、旧URLと対応する新URLへの恒久的なリダイレクト、内部リンク・canonical・サイトマップの更新、Search Consoleのアドレス変更などを行います。移行処理に漏れがあると、旧サイトの評価や流入を新サイトへ適切に引き継げない可能性があるため、通常のデザイン変更以上に慎重な管理が必要です。

リニューアル企画段階で行うSEOの準備

リニューアルを機に成功させるためには、企画段階での綿密な準備が不可欠です。既存のURL、流入、順位、被リンク、サイト構造などを定量的に把握することが、リスク軽減とSEO強化の基盤になります。この段階でしっかり現状を可視化することで、どの資産を守り、どこに投資するかが明確になります。

既存URL・流入・順位・被リンクを棚卸しする

リニューアル前に実施すべき重要なステップは、サイト全体の現状を定量的に把握することです。CMS、サイト内クロール、XMLサイトマップ、Search Console、アクセス解析、サーバーログなど複数の情報源を組み合わせ、旧URLを可能な限り網羅します。次に、ログ分析でURLごとのクロール状況を可視化し、Googlebotが各ページをどの程度訪問しているのかを確認します。

さらに、Google Search Consoleや、URL Inspection APIを利用した外部の一括確認ツール「Google Bulk Inspect URLs」などで、インデックス状況を確認します。順位計測ツールとGA4のデータも組み合わせれば、URLごとの順位、流入、コンバージョンへの貢献を整理できます。

クロール、インデックス、順位、流入の順に課題を切り分け、リニューアル時の施策へ反映します。クロール頻度が低い重要カテゴリは内部リンクを見直し、インデックスされていないページは、クロール可否、canonical、noindex、内容の重複や品質を確認します。インデックス対象として適切なURLであれば、内部リンクとXMLサイトマップにも含めます。

被リンクはAhrefsなどのツールで確認し、特に重要なリンクが集まっている旧URLを把握します。リニューアル後もリンク先として適切なページを維持し、URLを変更する場合は対応する新URLへリダイレクトします。必要に応じて、主要なリンク元へURL変更を案内することも検討しましょう。

維持すべきページと統合・削除できるページを判断する

既存URL、流入、順位を把握した後は、それぞれのページを「維持」「統合」「削除」に分類する必要があります。この判断は後々のリニューアルの成否に大きく影響するため、慎重に進める必要があります。

流入、表示回数、順位、被リンク、コンバージョンへの貢献があるページは、原則として内容とURLを維持します。URLを変更する場合は、関連性の高い新URLへ恒久的なリダイレクトを設定します。流入規模はサイトによって異なるため、一律の数値ではなく、サイト内での相対的な重要度から判断しましょう。

ページの品質は、検索意図との一致、情報の独自性・正確性、コンバージョンへの貢献、インデックス状況、被リンクや内部リンクなどから総合的に判断します。離脱率やスクロール率も参考になりますが、ページの目的によって適正値が異なるため、単独で削除基準にはしません。

類似ページは統合し、古い情報は更新するなど、既存の資産を活用できないか検討します。削除やnoindexを選ぶ場合も、流入の有無だけでなく、事業上の必要性、被リンク、内部リンク、コンバージョンへの貢献を確認します。

リニューアル方式ごとのSEOリスクを整理する

サイト全体を一度に変更するフルリニューアルは、短期間で新しい設計へ移行できる一方、問題が発生した際の影響範囲が広くなります。段階的なリニューアルは、影響を確認しながら進めやすい反面、新旧の仕様が混在する期間の管理が必要です。また、URLを維持するのか、CMSやドメインまで変更するのかによってもリスクは変わります。

変更範囲とサイト規模を踏まえ、調査・設計・テスト・公開後の監視と修正に必要な期間と予算を確保します。大規模な移行では、影響の小さい範囲で先行テストできるかも検討しましょう。

キーワード・コンテンツ・サイト構造の方針を決める

リニューアルの目標は、流入数だけでなく、問い合わせ、購入、会員登録などサイトの事業目的に合わせて設定します。そのうえで、既存流入を守る領域、改善する領域、新たに検索需要を獲得する領域を分けます。売上への貢献が大きいページや重要な導線は、流入とコンバージョンの両面から慎重に変更範囲を決めましょう。

新たな検索需要を獲得する場合は、競合・市場調査、PLP（検索キーワードごとの流入先ページ）の設計、URL・サイト構造設計、内部リンク設計、コンテンツ設計の順に落とし込みます。

これは単なる「キーワード追加」ではなく、ユーザーが「知りたい」「欲しい」と思うキーワードに対して、サイト全体の構造や内容を最適化するプロセスです。例えば、キーワード調査で「商品名 + 価格」というキーワードに検索ボリュームがあることが分かったなら、そのキーワードを狙ったページを新規作成したり、既存ページを改善したり、サイト構造を見直してそのページへの導線を強化したりするといった施策が考えられます。

サイトリニューアルを機にSEOを強化する方法

リニューアルは、既存サイトの構造や導線を見直し、SEOとユーザー体験を改善する機会です。既存の評価を守る移行対策と、新たな検索需要を獲得する改善施策を分けて計画しましょう。

既存コンテンツとキーワード戦略の改善優先順位を決める

既存コンテンツの改善では、表示回数や検索需要がある一方で順位やクリック率が伸びていないページ、流入があるのにコンバージョンへつながっていないページなどを優先候補にします。特定の順位だけで機械的に判断せず、改善余地と事業への貢献を比較しましょう。

追加したい内容が既存ページとは異なる検索意図を持つ場合は、無理に1ページへ詰め込まず、新しいページを作成して内部リンクでつなぎます。同じ検索意図であれば、既存ページへの統合を優先し、類似ページの増加を防ぎましょう。

検索ボリュームに対して流入が少ないページや、順位が低くても一定のアクセスを得ているページには改善余地がある可能性があります。ただし、順位を上げるだけでコンバージョンが増えるとは限らないため、検索意図と自社サービスとの関連性も確認します。

常にアクセスがあるのにコンバージョンが生まれていないページは、検索順位向上ではなくコンバージョンレート向上の施策を優先すべきです。例えば、ページのデザイン改善、CTA（行動喚起）の明確化、信頼性の向上など、ユーザー体験向上に注力します。

検索ボリュームが小さくても、商談や購入につながっているテーマは改善対象になります。特にBtoBでは、少量の流入が大きな売上につながる場合があるため、検索規模だけで判断しないことが重要です。

サイト構造と内部リンクを見直す

ユーザー観点での内部リンク設計を確認し、SEO観点で重要ページに内部リンクが集められているか、検索意図に沿ったページ設計になっているかを見直す必要があります。これは、ユーザーが求めている情報へ自然に到達できるパスを作ることと、Googleのクローラーが重要なページを発見しやすくすることの両方に貢献します。

複数のページが同じ検索意図で競合している場合は、役割を分けるか、1ページへ統合します。ただし、キーワードが似ているだけで統合を決めず、実際の検索結果や各ページの目的を確認しましょう。統合する場合は、残すページへ内容を集約し、廃止するURLからリダイレクトします。

パンくずリスト構造が正しくマークアップされているか、階層構造が明確かを確認することで、Googlebotがサイト全体を理解しやすい設計にすることができます。パンくずリストはユーザーの現在地を示す重要な要素であり、同時にサイト構造をGoogleに明示する役割も果たします。

ユーザーが比較・検討時に閲覧するページでは、自社の強み、実績、選ばれる理由を分かりやすく示します。重要ページへの導線を整えることで、検索流入後の回遊やコンバージョンも改善しやすくなります。

表示速度・モバイル対応などの技術基盤を改善する

大規模サイトでは、システム設計がボトルネックとなり、応答速度の低下や一時的な5xxエラーが発生することがあります。Search Consoleのクロール統計、サーバーログ、監視ツールを使い、リニューアル前後で応答時間やエラー率が悪化していないか確認します。

ユーザー体験の観点では、PageSpeed Insightsや実ユーザーデータを使ってCore Web Vitalsを確認します。SEO担当者だけで数値目標を決めるのではなく、エンジニアと連携し、画像、JavaScript、CSS、キャッシュ、サーバー処理などの原因を切り分けて改善します。

モバイル対応は必須です。ユーザーもスマートフォンが多く、クローラーもスマートフォンサイトを見て評価しています（モバイルファーストインデックス）。リニューアルを機に、モバイルサイトが十分に最適化されているか、特にタッチ操作のしやすさ、読みやすいフォントサイズ、適切な画像最適化などを確認します。

旧URL・新URLのマッピングとリダイレクト設計

旧URLから新URLへのマッピングとリダイレクト設定は、リニューアル後の流入減少を防ぐ最重要タスクです。全URLの把握から対応表作成、リダイレクト実装、期間管理まで、システマティックに進める必要があります。この作業に漏れがあると、それまで築いたSEO資産が失われる恐れがあります。

旧URLと新URLの対応表を作成する

URLマッピングでは、旧サイトのURLを可能な限り網羅することが重要です。CMS、サイト内クロール、サーバーログ、Google Search Console、アクセス解析、XMLサイトマップなどからURLを集めます。

それぞれの情報を合算して重複を除き、画像やPDFなど移行対象となるファイルも含めて旧URLリストを作成します。新サイト側についても、ステージング環境のクロールやCMSのデータから新URLを取得します。

次に、各旧URLに対して、対応する新URLを指定します。この作業は、既存のサイト構造と新規サイト構造の対応を理解している者が実施する必要があります。新URLが既に決定していない場合は、この段階で新しいURL設計方針に沿って新URLを決定します。

対応表は、Excelなどの表計算ソフトを使い、「旧URL」「新URL」「処理方法」「対応状況」「確認結果」などの列を用意します。処理方法には、301リダイレクト、URL維持、統合、404・410などを記録します。数百から数千のURLを扱う場合は、可能な範囲を自動生成し、人による確認を組み合わせるとミスを減らせます。

301リダイレクトとcanonicalを正しく使い分ける

301リダイレクトとcanonicalは、どちらも正規URLの判断に関係しますが、用途が異なります。旧URLを廃止して新URLへ恒久的に移す場合は、原則としてサーバー側の301または308リダイレクトを使用します。

canonicalは、パラメータ付きURLや印刷用ページなど、重複または非常に類似したURLを残す必要がある場合に、優先するURLを検索エンジンへ示すために使用します。canonicalは強制的な指示ではなくシグナルであり、ユーザーを転送する機能もありません。

同じ旧URLに301リダイレクトと旧URL側のcanonicalを重ねて設定する必要は通常ありません。移転にはリダイレクト、アクセス可能な重複URLの整理にはcanonicalと、目的に応じて使い分けましょう。

リダイレクトの設定期間と削除ページの処理を決める

URLを恒久的に変更する場合は301または308、一時的な転送には302または307を使用します。サイトリニューアルで旧URLを新URLへ置き換える場合は、恒久的なリダイレクトが基本です。

Googleは、サイト移転時のリダイレクトを可能な限り長く、一般には少なくとも1年間維持することを推奨しています。外部リンクやブックマークから旧URLへアクセスするユーザーもいるため、運用上可能であれば、それ以降も継続する方が安全です。

削除したページに関連性の高い後継ページがない場合は、トップページなどへ一律に転送せず、404または410を返します。複数ページを1つに統合した場合は、統合先へ個別にリダイレクトします。

内部SEO設定とサイトマップの移行確認

リニューアル後のページが正しくクロール・インデックスされるように、内部SEO設定とXMLサイトマップを確認します。リニューアル前後の差分を一覧化し、意図しない変更がないかを検証しましょう。

タイトル・見出し・メタディスクリプションを確認する

リニューアル時に見落としやすいのが、タイトルタグ、見出しタグ（h1～h6）、メタディスクリプションの変更です。テンプレート変更によって一括で書き換わる場合があるため、重要ページを中心に新旧の内容を比較します。

タイトルタグは、ページの内容を端的に表し、検索結果のタイトルリンク生成にも使われる重要な要素です。見出しは、ページの主題と内容の階層がユーザーに伝わるように設定します。H1を1つにすることは管理しやすい設計ですが、複数あることだけでSEO上の問題になるわけではありません。

メタディスクリプションは、Googleが検索結果のスニペット生成に使用する場合があります。直接的なランキング要因としてではなく、検索結果でページ内容を伝え、ユーザーのクリック判断を助ける要素として整えます。

canonicalタグを新しいURLに合わせて設定する

canonicalタグは、重複または非常に類似したURL群の中で、優先するURLをGoogleへ示すシグナルです。新サイトでは、インデックスさせたい各ページに新URLを指す自己参照canonicalを設定し、旧URLやステージング環境のURLが残っていないか確認します。

ドメインやURLを変更する場合、canonicalだけで移転を済ませるのではなく、旧URLから新URLへの恒久的なリダイレクトを設定します。内部リンク、hreflang、構造化データ、XMLサイトマップなどに含まれるURLも新URLへ更新しましょう。

内部リンクとパンくずリストを新URLへ更新する

リニューアル時には、既存ページ間の内部リンクが新URLを直接指すように更新します。旧URLへのリンクが残ると、不要なリダイレクトが発生し、設定漏れがあるURLでは404エラーにつながります。

パンくずリストは、ユーザーが現在地や上位階層を理解できるように設置します。必要に応じてBreadcrumbListの構造化データも更新し、リニューアル後の階層と表示内容が一致しているか確認します。

robots.txtとnoindexの役割を分けて確認する

robots.txtはクローラーのアクセスを制御し、noindexはページを検索結果へ表示しないよう求める設定です。noindexをGoogleに認識させるには、対象ページをクロールできる状態にする必要があります。

管理画面など外部公開すべきでない領域は、robots.txtだけに頼らず認証で保護します。検索結果から除外したい公開ページにはnoindexを使用します。大量の不要URLへのクロールを抑える場合にrobots.txtを検討しますが、すでにインデックスされているURLの削除目的では使用しません。

XMLサイトマップを更新してSearch Consoleに送信する

XMLサイトマップには、インデックスさせたい正規URLを掲載します。リニューアル後は新URL体系に合わせて更新し、Google Search Consoleから送信します。旧URLやリダイレクトURL、noindexページ、404ページが新しいサイトマップに混在していないか確認しましょう。

最終更新日時を示すlastmodは、実際に重要な更新があった場合に正確な値を記載します。Googleはpriorityとchangefreqを利用しないため、SEO上の優先順位を伝える目的で設定する必要はありません。

ステージング環境で確認すべきSEO項目

本番環境での問題を事前に防ぐため、ステージング環境での十分な検証が重要です。リダイレクト、メタタグ、内部リンク、ステータスコードなどの細部をチェックし、設定漏れを防ぐ必要があります。本番公開前のこのフェーズが、後々の問題を最小化するための重要な関門です。

ステージング環境へのアクセス制限を確認する

ステージング環境は、Basic認証やIP制限などで外部からアクセスできない状態にするのが基本です。robots.txtのDisallowだけではURLが検索結果に表示される可能性があり、機密情報の保護にもなりません。

やむを得ず公開状態で検証する場合はnoindexも検討しますが、本番公開時に解除し忘れない仕組みが必要です。ステージング環境のURLがサイトマップ、内部リンク、canonicalに混入していないかも確認します。

ステータスコード・内部リンク・メタタグをクロールテストする

ステージング環境でScreaming Frogなどのクローラーツールを使用し、公開対象ページのステータスコードが想定どおりか確認します。意図しない404や5xxがあれば、公開前に修正します。

内部リンク構造をテストし、リンク先が存在するか、リンク先が新URLを指しているか確認します。特に、301リダイレクト対応表が完全か、設定漏れがないか念入りにチェックします。

メタタグ（title、description、noindexなど）が正しく設定され、ページ内容と一致しているか確認します。canonicalタグの参照先や、意図しない重複ページの有無も検証します。

公開前の最終チェックリストで設定漏れを防ぐ

本番公開前に、以下のようなチェックリストを用意し、全項目を確認することで、設定漏れを防ぐことができます。

• URLを変更するページのリダイレクト設定が完了したか
• 新URLのXMLサイトマップを準備し、公開後にSearch Consoleへ送信できる状態か
• インデックス対象ページのcanonicalタグが正しく設定されているか
• タイトル、メタディスクリプション、h1タグが正しく設定されているか
• robots.txtが正しく設定されているか
• ステージング環境がBasic認証やIP制限で保護されているか
• 内部リンクが新URLを指しているか
• パンくずリストが正しくマークアップされているか
• GA4などの計測設定とSearch Consoleの所有権・連携に問題がないか

公開後のSEO監視と順位下落時の対応

リニューアル公開後は、クロール・インデックス状況、検索順位、オーガニック流入を継続的に監視し、想定外の変化があれば原因を切り分けて対応します。

Google Search Consoleでクロールとインデックスを監視する

リニューアル公開後は、Google Search Consoleのページのインデックス登録レポートやURL検査を使い、新URLの認識状況を確認します。想定する正規URL数と登録済みページ数に大きな差がないか、除外されたURLに想定外のものが含まれていないかを見ます。

「クロール済み – インデックス未登録」などのURLが増えた場合は、設定漏れと決めつけず、canonical、noindex、内部リンク、コンテンツ、サーバー応答などを確認します。4xxや5xxが急増していないかも監視しましょう。

クロール統計では、リクエスト数、応答時間、ダウンロードサイズなどを監視し、前回のリニューアル前後で大きな変化がないか確認します。応答時間が異常に長い場合は、サーバーやシステムのボトルネックを調査する必要があります。

GA4と順位計測ツールで流入の変化を確認する

Google Analytics 4（GA4）でオーガニック流入とコンバージョンの推移を確認し、リニューアル前の同曜日・同期間や前年同期と比較します。季節性や広告、計測設定の変更も影響するため、サイト全体だけでなくディレクトリやランディングページ単位で見ましょう。

順位計測ツールで重要キーワードの推移も確認します。サイト移転では一時的に順位が変動することがあり、処理にかかる期間はサイト規模やクロール状況によって異なります。大幅な下落や長期化が見られる場合は、リダイレクト、コンテンツ差分、内部リンク、canonical、noindexなどを確認します。

ディレクトリ・テンプレート・URLパターン別に原因を切り分ける

流入が下落した場合、単純に「流入が減った」と判断するのではなく、細かく原因を切り分けることが重要です。DB型サイトの場合、どのテンプレートで流入が下落しているかを把握します。例えば、トップページの流入は維持されているが、カテゴリページだけ下落している、というケースもあります。

テンプレート単位（トップ、カテゴリ、詳細）で原因を切り分けられない場合、カテゴリの中でもURLパターン、条件掛け合わせパターンごとで切り分けて原因を探っていきます。例えば、「/category/a/」配下のページは流入が回復したが、「/category/b/」配下のページはまだ回復していない、というように、パターン別に対応策を検討します。

リダイレクト・インデックス・コンテンツの問題を修正する

原因が判明したら、影響範囲と優先度を整理して修正します。リダイレクト漏れは対応する新URLを確認して設定し、インデックス登録が減少している場合は、サイトマップ、内部リンク、canonical、noindex、ステータスコードを点検します。

リニューアル時に重要なコンテンツを削減したことが原因と考えられる場合は、検索意図を再確認し、必要な情報を復元または再構成します。ただし、修正後の順位回復は保証できないため、クロール・インデックス・順位・流入の変化を継続して確認します。

サイトリニューアル時によくあるSEOの失敗例

よくある失敗は、企画段階の調査、実装時の管理、公開前のテスト、公開後の監視をそれぞれ行うことで発見しやすくなります。

URLマッピングやリダイレクトに漏れがあった

事前のURL対比表の漏れやミスが一般的で、システム的な設定ミスもあるため必ずステージング環境でテストすることが重要です。例えば、ページング（/page/2、/page/3など）や、パラメータ付きURL（?id=123など）の対応を見落とすことがあります。

大規模サイトでは、全URLの対応表を可能な範囲で自動生成し、人によるダブルチェックとクロールテストを組み合わせます。旧URLから最終的な新URLへ直接転送されるか、リダイレクトチェーンやループがないかも確認しましょう。

検索流入のあるページやコンテンツを削除した

検索流入や被リンクのあるページを調査せずに削除すると、リニューアル後の流入減少につながります。企画段階で既存URL、流入、順位、被リンク、コンバージョンへの貢献を棚卸しし、維持・統合・削除の判断を記録します。

関連性の高い後継ページがある場合は301リダイレクトを設定し、後継ページがない場合は404または410を返します。いずれの場合も、内部リンクやサイトマップから削除済みURLを取り除きます。

公開後もnoindexやアクセス制限が残っていた

ステージング環境で使用したnoindex、Basic認証、IP制限、robots.txtの「Disallow: /」などが本番環境に残ると、Googlebotが新サイトをクロールまたはインデックスできません。

本番公開時のチェックリストに解除確認を含め、公開後も実際のレスポンスとHTMLを確認します。問題が見つかった場合は設定を修正し、重要URLはSearch ConsoleのURL検査から再クロールをリクエストします。多数のURLがある場合は、XMLサイトマップも送信します。

まとめ｜サイトリニューアルでは公開前後のSEO管理が重要

サイトリニューアルでは、既存のSEO資産を守る移行対策と、新しい検索需要を獲得する改善施策を分けて考えることが重要です。企画段階で既存URLや流入を調査し、URLごとの処理を管理したうえで、公開前のテストと公開後の監視を継続します。

テクニカルSEOだけでなく、ユーザーの課題を解決できるコンテンツ、分かりやすい導線、自社を選ぶ理由も見直しましょう。既存の評価を維持することを優先しながら、競合・市場調査、PLP設計、サイト構造、内部リンク、コンテンツの順に改善を進めることで、リニューアルをSEO強化の機会にできます。

サイト規模が大きい場合や、CMS・ドメイン・URL構造を同時に変更する場合は、専門的な調査と移行管理が必要になることがあります。NYマーケティングでは、企画段階の調査からURL設計、公開前テスト、公開後の監視まで支援しています。詳細はSEOコンサルティングサービスの紹介ページをご覧ください。