ウェブサイト移行後のトラフィック低下？失ったランキングを回復する方法

新しいサイトをローンチしました。すべてが素晴らしく見えます。デザインは最新で、パフォーマンス指標も優れており、チームは喜んでいます。そして月曜日の朝。Google Search Consoleはトラフィックが40%低下したことを示しています。電話が鳴り始めます。

このような状況を何度も経験してきました。WordPressからNext.jsへ、モノリシックプラットフォームからヘッドレスアーキテクチャへ、レガシーCMSからAstroへ、サイトを移行してきましたが、移行後のトラフィック低下は最も予測可能で（そして防ぐことができる）ウェブ開発の問題の1つです。良いニュースは、ほとんどの場合、完全に回復することができます。時には前より良い結果になることもあります。ただし、素早く体系的に行動する必要があります。

この記事は、Social Animalで移行がうまくいかなかった時に実際に使用している回復プレイブックです。理論はありません。ただ機能するステップです。

目次

• 移行後にトラフィックが低下する理由
• 最初の48時間：トリアージチェックリスト
• 根本原因の診断
• リダイレクト問題の修正
• コンテンツとURL変更からの回復
• 技術的SEO回復ステップ
• パフォーマンスとコアウェブバイタル
• タイムライン：実際の回復のプロセス
• 将来の移行でトラフィック低下を防ぐ
• よくある質問

移行後にトラフィックが低下する理由

何かを修正する前に、これが起こる理由を理解しましょう。Googleは新しいサイトを見て、すぐに信頼することはありません。移行するとき、複数のことが同時に変わり、その1つがランキング低下をトリガーする可能性があります。

最も一般的な原因

| 原因 | 頻度 | 深刻度 | 回復時間 | |-------|-----------|----------|---------------|| | 欠落または壊れたリダイレクト | 非常に一般的 | 高い | 2～6週間 | | 適切なマッピングなしでのURL構造変更 | 非常に一般的 | 高い | 4～12週間 | | コンテンツの変更または削除 | 一般的 | 中～高 | 4～8週間 | | 内部リンク構造の変更 | 一般的 | 中 | 2～4週間 | | Robots.txtがクローラーをブロック | 時折 | 致命的 | 修正後数日 | | ステージング環境のNoindexタグが残る | 時折 | 致命的 | 修正後数日 | | ドメインまたはプロトコルの変更 | 時折 | 中 | 6～12週間 | | 構造化データの喪失 | 一般的 | 中 | 2～6週間 | | ページ速度の低下 | 一般的 | 低～中 | 2～4週間 | | JavaScriptレンダリング問題 | SPA向け | 高い | 2～8週間 |

ほとんどの記事が教えてくれないことがあります。移行中のトラフィック低下が10～20%というのは、すべてを正しく行っても実は正常です。Googleは新しいURLをクローリングし直し、処理し直す必要があります。それには時間がかかります。問題は、その低下がそれより大きい場合、または数週間以内に回復しない場合です。

Googleのリクロールと再評価期間

Googleが新しいURL（正しくリダイレクトされていても）に出くわすとき、以下が必要です：

1. リダイレクトを発見する
2. 新しい宛先URLをクローリングする
3. 新しいページをインデックスする
4. コンテンツの品質と関連性を再評価する
5. ランキング信号を更新する

このプロセスは即座ではありません。大規模なサイト（10,000ページ以上）では、Googleがすべてを完全に処理するのに数週間かかることができます。この期間中、変動が見られます。それは予想されています。予想されていないのは、4～6週間後の継続的な低下です。

最初の48時間：トリアージチェックリスト

トラフィック低下に気付いたら、パニックにならないでください。ただし迅速に行動してください。ここが最初の48時間に実施するトリアージチェックリストです：

ステップ1：クローリングがブロックされていないことを確認する

これは私が見てきた最もよくある「あ、しまった」という瞬間です。誰かがrobots.txtファイルの更新を忘れるか、ステージング環境のnoindexメタタグが本番環境に出荷される場合です。

# robots.txtを確認
curl -s https://yoursite.com/robots.txt

# これらの赤いフラグを探します：
# User-agent: *
# Disallow: /

またページソースのnoindexタグを確認します：

<!-- これはあなたのランキングを破壊します -->
<meta name="robots" content="noindex, nofollow">

Next.jsでは、環境ベースのメタタグが正しく設定されていない場合、これが発生することがよくあります：

// layout.jsまたは_app.jsを確認
// 本番環境でnoindexを条件付きでレンダリングしていないことを確認
export const metadata = {
  robots: {
    index: process.env.NODE_ENV === 'production',
    follow: process.env.NODE_ENV === 'production',
  },
};

Next.js開発チームと協力している場合、デプロイ前にこれをキャッチするCI/CDチェックがあります。ただし自分で処理している場合、デプロイ後の検証ステップを追加してください。

ステップ2：Google Search Consoleで即座に確認

Search Consoleに移動して、以下を確認します：

• カバレッジ/ページレポート：ページはインデックスされていますか？新しいエラーはありますか？
• クロール統計：Googlebotのクロールレートは低下しましたか？
• 手動アクション：移行が手動ペナルティをトリガーしましたか？（稀ですが、確認します。）
• コアウェブバイタル：パフォーマンスが低下しましたか？

ステップ3：サイトマップを確認

新しいサイトマップが送信され、正しいURLが含まれていることを確認してください：

curl -s https://yoursite.com/sitemap.xml | head -50

サイトマップが古いURLを指していた、または悪いことに、ステージングドメインを指していた移行を見てきました。これはどのURLが正規のものかについてGoogleに矛盾した信号を送ります。

ステップ4：重要なページをスポットチェック

移行前のオーガニックトラフィックで上位20ページを取り、手動で確認します：

• 古いURLは新しいURLに正しくリダイレクトされていますか？
• 新しいページのコンテンツは同じ（またはより良い）ですか？
• タイトルタグとメタディスクリプションは保持されていますか？
• 構造化データはまだ存在していますか？

根本原因の診断

トリアージを完了したら、正確に何が低下の原因かを判断する必要があります。これはコンピュータ科学であり、複数のソースからのデータが必要です。

Google Search Consoleのパフォーマンスレポートを使用

移行前の28日間と移行後の28日間を比較します。以下に注目してください：

• **どのクエリがインプレッションを失いましたか？**特定のクエリクラスターが低下した場合、コンテンツまたはURL問題である可能性があります。
• **どのページがクリックを失いましたか？**これは、どの特定のページが影響されているかを示します。
• **サイト全体が低下しましたか、または特定のセクションだけですか？**サイト全体の低下は技術的な問題（robots.txt、noindex）を示唆しています。セクション固有の低下はリダイレクトまたはコンテンツ問題を示唆しています。

Googleのようにサイトをクロール

Screaming Frog、Sitebulb、またはAhrefs'のサイト監査を使用して新しいサイトをクロールします：

# screaming-frog CLIの使用（利用可能な場合）
screamingfrog --crawl https://yoursite.com --output-folder ./audit

# またはNode.jsベースのクローラーを使用して迅速に確認
npx broken-link-checker https://yoursite.com --recursive

以下を探します：

• 存在すべきページ上の404エラー
• リダイレクトチェーン（2ホップ以上）
• 404を返しているソフト404ページ（200ステータスですが、エラーコンテンツ付き）
• 指しているページがない孤立したページ

リダイレクトマップを実装と比較

事前移行リダイレクトマップは、実際に正しく実装された場合のみ有用です。完璧に計画されたリダイレクトマップは、タイプ、間違ったステータスコード、または単に欠落しているエントリで実装されたのを何度も見ました。

// リダイレクトを検証するクイックNode.jsスクリプト
const https = require('https');
const oldUrls = [
  '/old-blog/my-post',
  '/products/widget-a',
  '/about-us',
  // ... 完全なリスト
];

oldUrls.forEach(url => {
  https.get(`https://yoursite.com${url}`, { method: 'HEAD' }, (res) => {
    if (res.statusCode === 301 || res.statusCode === 302) {
      console.log(`✅ ${url} → ${res.headers.location} (${res.statusCode})`);
    } else if (res.statusCode === 404) {
      console.log(`❌ ${url} → 404 見つかりません`);
    } else {
      console.log(`⚠️  ${url} → ${res.statusCode}`);
    }
  });
});

リダイレクト問題の修正

リダイレクトは、移行後のトラフィック低下の#1の原因です。正しく取得しましょう。

301対302：まだ重要です

移行に301（永続）リダイレクトを使用します。句読点。302（一時）リダイレクトは、Googleに古いURLをインデックスに保持するよう指示します。それはあなたが望むものではありません。

Next.jsでは、リダイレクトはnext.config.jsに存在します：

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-blog/:slug',
        destination: '/blog/:slug',
        permanent: true, // これは301にします
      },
      {
        source: '/products/:category/:product',
        destination: '/shop/:product',
        permanent: true,
      },
    ];
  },
};

Astro（多くの開発プロジェクトに使用）では、リダイレクトはastro.config.mjsまたはホスティングプラットフォームで設定できます。

リダイレクトチェーンの処理

リダイレクトチェーンは次のようになります：A→B→C→D。各ホップはリンクエクイティを少し失い、3～4ホップ後、Googlebotは単に続くのをやめるかもしれません。チェーンを修正するには、最終的な宛先にすべてを直接指すようにします。

大量リダイレクト実装

大規模なサイトでは、プラットフォームレベルのリダイレクトが必要になる可能性があります。これが、Vercel（Next.jsデプロイメント向けで一般的）を使用した大規模なリダイレクトの処理方法です：

// vercel.json
{
  "redirects": [
    { "source": "/old-path", "destination": "/new-path", "permanent": true },
    { "source": "/blog/2024/:slug", "destination": "/blog/:slug", "permanent": true }
  ]
}

Netlify向け：

# _redirectsファイル
/old-path    /new-path    301
/blog/2024/* /blog/:splat 301

コンテンツとURL変更からの回復

移行中にコンテンツを変更した場合（「改善」した場合でも）、Googleはページの対象クエリとの関連性を再評価する必要があるかもしれません。

すべてを同時に変更しないでください

これは誰かが長年前に私に言ってくれたいと思うアドバイスです：移行は横の動きであるべきです。テックスタック、デザインは変更しますが、初期段階ではコンテンツ、URL、タイトルタグ、およびメタディスクリプションを同じに保つようにしてください。移行が安定した後、コンテンツを最適化できます。

コンテンツを既に変更してランキングを失っている場合：

1. 古いコンテンツ（archive.orgまたはバックアップから）を新しいコンテンツと比較
2. トラフィックを最も失ったページを特定
3. それらのページがまだ同じキーワードをターゲットにしているかを確認
4. 最も影響を受けたページのコンテンツを戻すことを検討

URL構造の変更

URL構造を変更した場合（例：/blog/2024/01/my-postから/blog/my-postへ）、すべての古いURLに対応するリダイレクトがあることを確認してください。事前移行クロールデータを使用して、完全なリストを作成します。

ヘッドレスCMS移行でよくある間違いは、スラッグ形式を変更することです。古いCMSが日付付きのスラッグを生成し、新しいCMSがそうでない場合、すべてのポストのリダイレクトが必要です。

技術的SEO回復ステップ

ここが、私が従う体系的な回復プロセスです：

1. すべてのクロールエラーを修正

Google Search Consoleで、ページ>インデックスされていないに移動し、すべての「見つかりません（404）」および「ソフト404」エラーを修正します。移行前にトラフィックがあったページを優先します。

2. サイトマップを再送信

Search Consoleから古いサイトマップを削除し、新しいものを送信します。次に、URLインスペクションツールを使用して、最も重要なページのインデックスを要求します。

3. 内部リンクを再構築

見落とされやすい移行問題の1つは、壊れた内部リンクです。古いサイトには、古いURLを指す数百の内部リンクがあるかもしれません。それらのURLが現在リダイレクトされる場合、リダイレクトを通してリンクエクイティを不必要に渡しています。

新しいURLを直接指すようにすべての内部リンクを更新します：

// コンテンツ内の古いURLを見つけるスクリプト
const glob = require('glob');
const fs = require('fs');

const oldDomain = 'old-site.com';
const files = glob.sync('src/**/*.{md,mdx,jsx,tsx}');

files.forEach(file => {
  const content = fs.readFileSync(file, 'utf8');
  if (content.includes(oldDomain)) {
    console.log(`古いドメイン参照が見つかった：${file}`);
  }
});

4. 構造化データを復元

古いサイトにスキーママークアップ（Product、Article、FAQ、BreadcrumbList）がある場合、それが新しいサイトに複製されていることを確認してください。失われた構造化データは、失われたリッチスニペットを意味し、それは低いCTRを意味し、それはより少ないトラフィックを意味します。

5. 正規タグを確認

すべてのページは、自分自身のURLを指す自己参照正規タグを持つべきです。正規タグが古いURLやステージングドメインを指していないか確認してください。

<!-- これは現在のページのURLを指すべき -->
<link rel="canonical" href="https://yoursite.com/current-page" />

6. Hreflangタグを確認（多言語の場合）

サイトが複数の言語または地域を提供している場合、移行後の壊れたhreflangタグは国際市場でのトラフィック低下を大幅に引き起こす可能性があります。

パフォーマンスとコアウェブバイタル

チームが最新フレームワークに移行する主な理由の1つは、より良いパフォーマンスです。しかし時には反対が起こります。

クライアント側レンダリングの落とし穴

サーバー側レンダリング（SSR）なしでReact SPAに移行した場合、Googlebotはコンテンツを見るのに苦労するかもしれません。Googleはレンダリングを改善しましたが、まだ完璧ではありません。レンダリングはインデックスの第2波で発生し、コンテンツが検索結果に表示されるのに時間がかかることを意味します。

これが、コンテンツが豊富なサイトにSSRまたはSSGを強く推奨する理由です。App RouterのNext.jsはデフォルトでサーバーコンポーネントを提供します。Astroはクライアント側インタラクティビティにオプトインしない限り、すべてを静的HTMLにレンダリングします。

コアウェブバイタル比較

CrUXデータまたはPageSpeed Insightsを使用して、移行前後の比較を実行します：

メトリック	移行前	移行後	ターゲット
LCP	2.1秒	?	<2.5秒
INP	180ms	?	<200ms
CLS	0.05	?	<0.1
TTFB	800ms	?	<800ms

移行後のメトリックが悪い場合、それはランキング低下に寄与している可能性があります。パフォーマンスの問題を最初に修正してください。すべての他の問題を悪化させます。

タイムラインの実際の回復のプロセス

現実的な期待を設定しましょう。我々が処理した移行に基づいて：

シナリオ	予想される回復時間
技術的問題のみ（robots.txt、noindex）	修正後1～2週間
小規模サイト（<500ページ）のリダイレクト問題	2～4週間
大規模サイト（5000ページ以上）のリダイレクト問題	4～8週間
コンテンツの変更+URL変更	6～12週間
ドメイン変更	8～16週間
複数の複合問題	3～6か月

回復曲線は線形ではありません。急な低下、その後の停滞、その後の段階的な上昇が見られます。ページによって回復速度が異なります。強いバックリンク表記を持つ高品質ページは最初に跳ね返る傾向があります。

心配する時間

すべての修正を実施した後、8週間経ってもなんの改善も見られていない場合、より深い問題があります。その時点で、以下を検討してください：

• 専門的なSEO監査
• Googleが移行をサイト品質変更として扱っているかどうか
• 移行中に重要なバックリンクを失ったかどうか

将来の移行でトラフィック低下を防ぐ

予防は常に回復より良いです。ここが移行前のSEOチェックリストです：

移行前

1. 既存サイトの完全なクロール～すべてのURL、タイトル、メタディスクリプション、正規タグ、構造化データ、内部リンクを保存します
2. リダイレクトマップ～すべての古いURLを新しい宛先にマップします
3. コンテンツフリーズ～移行中にコンテンツを変更しないでください
4. 現在のパフォーマンスをベンチマーク～Search Consoleデータ、ランキング、コアウェブバイタルを保存します
5. ステージングでのリダイレクステスト～本番環境に行く前にすべてのリダイレクトを確認します
6. robots.txtとメタrobotsを確認～本番環境設定がクローリングを許可していることを確認します

移行中

1. トラフィックが少ない時間帯にデプロイ
2. ローンチ直後にリダイレクトを確認
3. Google Search Consoleに新しいサイトマップを数時間以内に送信
4. クロール統計をリアルタイムで監視

移行後

1. 最初の2週間、Search Consoleを毎日監視
2. ローンチ後48時間で完全なサイト監査を実行
3. トップ50キーワードのランキングポジションを毎日確認
4. 発見後24時間以内に問題を修正

ヘッドレスアーキテクチャへの移行を計画している場合、当社の価格ページでは、ほとんどの機関がスキップするSEO保存作業を含む移行パッケージに含まれるものの概要を示しています。

よくある質問

ウェブサイト移行後にトラフィックが回復するのにどのくらいの時間がかかりますか？ ほとんどのサイトは、問題が迅速に特定して修正された場合、4～8週間以内に回復します。robots.txtをブロックするか、noindexタグなどの単純な技術的問題は数日で解決でき、トラフィックは1～2週間以内に戻ります。URL構造の変更、コンテンツ変更、またはドメイン変更を含むより複雑な問題は、完全な回復に3～6か月かかることがあります。根本原因を診断して修正する速度が重要な要素です。

ウェブサイト移行後のトラフィック低下は正常ですか？ はい、移行が十分に実行された場合でも、10～20%の一時的な低下は完全に正常です。Googleはサイトをリクロール、インデックス、再評価する時間が必要です。この処理期間は通常2～4週間続きます。正常ではないのは、30%を超える低下、または6週間後に回復の兆候を示さない低下です。それらのパターンが見られている場合は、修正が必要な技術的な問題がある可能性があります。

サイト移行に301または302リダイレクトを使用すべきですか？ サイト移行には常に301（永続）リダイレクトを使用してください。301はGoogleに移動が永続的であり、新しいURLにランキング信号を転送することを指示します。302（一時）リダイレクトはGoogleに古いURLをインデックスに保持するよう指示し、移行の目的を損なわせます。唯一の例外は、コンテンツを元のURLに戻す計画がある場合です。これはほぼ移行中に適用されることはありません。

CMSの変更はランキングを低下させる可能性がありますか？ CMS自体の変更はランキング低下を引き起こしません。ただし、CMS変更の副次的な影響はしばしばそうします。異なるCMSは異なるURL構造、HTMLマークアップ、内部リンク作成パターン、ページロード特性を生成します。新しいCMSが適切なリダイレクトなしで異なるURLを生成したり、構造化データを削除したり、コンテンツ構造を変更したり、サーバー側の代わりにクライアント側でコンテンツをレンダリングする場合、トラフィック影響が見られる可能性があります。

Googlebotが新しいサイトを正しく見られているか、どうやって知りますか？ Google Search ConsoleのURL検査ツールを使用します。任意のページのURLを入力し、「ライブURLをテスト」をクリックします。Googleは、Googlebotが見るものを正確に表示します。レンダリングされた出力から重要なコンテンツが不足している場合、JavaScriptレンダリング問題があります。また、Search Consoleの「クロール統計」レポートをチェックして、移行以来Googlebotのクロールレートが変更されたかどうかを確認できます。

新しいウェブサイトに移行すると、バックリンクを失いますか？ 古いURLから新しいURLへの適切な301リダイレクトを実装すれば、バックリンクは失われません。バックリンクは古いURLを指したままになりますが、リダイレクトはリンクエクイティを新しいページに渡します。ただし、最も価値のあるバックリンクを持つサイトに連絡してURLを直接更新するよう依頼することをお勧めします。これはリダイレクトホップを排除し、最大のリンクエクイティ転送を確保します。

移行中にURL構造を変更すべきですか？ できれば、いいえ。同じURL構造を保つことで、リダイレクトの必要が完全になくなり、SEOにとって最も安全なアプローチです。URL を必ず変更する必要がある場合（例えば、日付ベースのパスを削除またはカテゴリを再構成する）、すべての古いURLをカバーする完全なリダイレクトマップがあることを確認します。対応する301リダイレクトなしにURLを変更しないでください。

移行後にトラフィック回復を監視するにはどのツールを使用すべきですか？ Google Search Consoleは、Googleがサイトを見る方法を正確に示す主要なツール です。Google Analytics 4でトラフィック監視、Screaming FrogまたはSitebulbで技術的なクローリング、AhrefsまたはSemrushでランキング追跡、PageSpeed Insightsでパフォーマンス監視と組み合わせます。移行後の最初の2週間はこれらのツールを毎日確認し、その後、トラフィックが安定するまで毎週確認します。