tva
← コラム

WordPressからAstroへの移行後のSEO対策：リダイレクトチェーン、サイトマップ、GSCのクリーンアップ

WordPressからAstroへ移行すると、ビルドとページ表示が速くなり、ホスティングコストも下がります。ただし、移行時にブログのURLを変更した場合、たとえば/post-slug/から/insights/post-slugへ変えた場合は、Googleがサイトの再クロールを終える数週間後になって初めて、SEO上の問題が表面化する可能性があります。

Google Search Consoleから「重複しています。Googleがユーザーが指定したものとは異なる正規ページを選択しました」や「見つかりません（404）の修正を検証できませんでした」といったメールが届き始めます。成果の高いページが不要なリダイレクトを経由している可能性もあります。気づかないうちに内容が重複する二つのサイトマップを管理している場合もあります。

このガイドでは、これらの問題を見つけて修正する方法を説明します。当社もWordPressからAstroへの移行後にすべての問題を経験し、SEOの修正方法をここにまとめました。

必要なもの

  • サーバーへのSSHアクセス（nginx設定）
  • 対象プロパティのGoogle Search Consoleへのアクセス
  • ローカルにインストールされたcurl
  • アクセス解析ツール（当社ではセルフホスト型のPlausibleを使用）

この手順で解決できること

  • 複数ホップのリダイレクトチェーン（2回以上のリダイレクト）を単一の301リダイレクトに集約
  • 重複する複数のサイトマップを1つの自動生成ソースに統合
  • noindexページをサイトマップから除外
  • 古いGSCプロパティとWordPressの旧サイトマップを削除
  • 旧URLと新URLの構造間で生じる正規URLの混乱を解消

ステップ1：リダイレクトチェーンの診断

主要なURLが何回リダイレクトされるか確認します。WordPressのURL末尾にスラッシュがあり、AstroのURLにはない場合、2段階のリダイレクトチェーンが発生している可能性があります。1回目でスラッシュを除去し、2回目で新しいパスの接頭辞を付けるパターンです。

curl -sL -w "Hops: %{num_redirects}, Final: %{http_code}, URL: %{url_effective}\n" \
  -o /dev/null "https://yourdomain.com/old-post-slug/"

出力がHops: 2なら、リダイレクトチェーンが存在します。トラフィック上位5ページで確認してください。余分なリダイレクトの影響が最も大きいのは、これらのページです。

アクセス解析とも照合します。同じ記事が複数のURL形式（末尾のスラッシュあり、なし、新しい接頭辞付き）で表示される場合、リダイレクトでトラフィックが集約されていません。当社では、最も読まれている記事がPlausible上で三つのURLに分かれていたため、上記のリダイレクト確認を行いました。

ステップ2：nginxを設定して単一ホップリダイレクトに修正する

nginxでURL末尾のスラッシュを除去する標準的なルールは、次のとおりです。

location ~ ^(.+)/$ { return 301 $1; }

このルールは末尾のスラッシュを除去しますが、ブログのパス変更には対応していません。そのため、リクエストは次のルールに進み、/slugから/insights/slugへリダイレクトされます。これで2回のリダイレクトになります。

スラグがブログ記事に一致するかを確認し、最終URLへ直接リダイレクトするルールに置き換えます。

# Blog slugs with trailing slash — single-hop to /insights/
location ~ ^/([^/]+)/$ {
    set $slug $1;
    if (-f /usr/share/nginx/html/insights/$slug/index.html) {
        return 301 https://www.yourdomain.com/insights/$slug;
    }
    return 301 https://www.yourdomain.com/$slug;
}
# Multi-segment paths — just strip the slash
location ~ ^(.+)/$ { return 301 https://www.yourdomain.com$1; }

最初のルールはルートレベルのスラグ（旧WordPressブログURL）を処理します。/insights/配下に対応するページが存在するかどうかを確認し、そこへ直接リダイレクトします。その他のルートレベルのパスも、同じルールで末尾のスラッシュを除去する1回のリダイレクトが行われます。複数のセグメントを持つパスは、2番目の汎用ルールに一致します。デプロイ後は次のコマンドで確認してください：

curl -sL -w "Hops: %{num_redirects}\n" -o /dev/null \
  "https://yourdomain.com/your-top-post-slug/"
# Expected: Hops: 1

ステップ3：サイトマップの統合

サイトマップが複数存在しないか確認します。移行後によく見られるパターンとして、移行時に手動で作成した静的なsitemap.xmlと、Astroの@astrojs/sitemapインテグレーションが自動生成するsitemap-index.xmlが共存していることがあります。

# Check both
curl -sI "https://yourdomain.com/sitemap.xml" | head -1
curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1

両方が200を返す場合、二つのサイトマップを管理しており、内容が同期しなくなる可能性があります。robots.txtがどちらを参照しているか確認しましょう：

curl -s "https://yourdomain.com/robots.txt" | grep -i sitemap

対処法：public/ディレクトリから静的なsitemap.xmlを削除し、robots.txtがsitemap-index.xmlを参照するよう更新し、あとはAstroのインテグレーションにすべて任せましょう。新しい記事はビルドのたびに自動的に追加されます。

静的サイトマップにnoindexページが含まれていないかも確認してください。sitemap.xmlに<meta name="robots" content="noindex">が設定された/legalや/privacy-policyなどのページが列挙されている場合、Googleに矛盾したシグナルを送ることになります。@astrojs/sitemapの自動生成サイトマップは、フィルタールールを設定することでこれらのページを正しく除外できます。

ステップ4：Google Search Consoleのクリーンアップ

GSCを開き、プロパティとサイトマップの2点を確認します。

プロパティ：ドメインプロパティ（sc-domain:yourdomain.com）とURLプレフィックスプロパティ（https://www.yourdomain.com/）の両方があると、同じ問題の通知が重複します。両方を保持しても問題ありませんが、重複するメールが煩わしい場合はどちらか一つを選びます。サブドメインが別のプロジェクトの場合は、URLプレフィックスプロパティのほうが整理しやすくなります。対象はそのプレフィックスに厳密に一致する配下のURLだけで、たとえば本番環境のwwwホスト上のURLです。

サイトマップ：「インデックス登録」→「サイトマップ」を開きます。まだ登録されている古いWordPressのサイトマップ（post-sitemap.xml、page-sitemap.xml、sitemap-post-type-product.xmlなど）をすべて削除し、新しいsitemap-index.xmlだけを送信します。

404の確認：「インデックス登録」→「ページ」→「見つかりません（404）」を開き、どのURLが一覧表示されているか確認します。もはや存在しないWordPressの旧パス（WooCommerceの商品ページ、著者ページ、フィードURLなど）であれば、時間が経てば自然にインデックスから除外されます。リダイレクトされるべきブログ記事であれば、nginxのルールを更新する必要があります。リダイレクトを修正したら「修正を確認」をクリックして再クロールをリクエストしましょう。

ステップ5：全体の確認

修正をデプロイしたら、以下のチェックを実施してください：

# 1. Redirect chains resolved
curl -sL -w "Hops: %{num_redirects}, URL: %{url_effective}\n" \
  -o /dev/null "https://yourdomain.com/your-top-post/"
# Expected: Hops: 1, URL ends in /insights/your-top-post

# 2. robots.txt points to generated sitemap
curl -s "https://yourdomain.com/robots.txt" | grep sitemap
# Expected: sitemap-index.xml

# 3. Old static sitemap returns 404
curl -sI "https://yourdomain.com/sitemap.xml" | head -1
# Expected: 404

# 4. Generated sitemap returns 200
curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1
# Expected: 200

# 5. Non-www redirects to www
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" \
  "https://yourdomain.com/insights"
# Expected: 301 https://www.yourdomain.com/insights

Googleが追いつくまでの時間

単一ホップのリダイレクトは、新たなクロールからすぐに反映されます。サイトマップの変更は数日以内に認識されます。Googleが新URLよりも旧URLを優先する正規URLの混乱は、解消にもう少し時間がかかります。Googleは<link rel="canonical">タグを指示ではなくヒントとして扱います。旧URLに多くの被リンクや過去のクリックデータがあると、数週間にわたって旧URLを正規URLとして選び続ける場合があります。

適切なリダイレクトと正本となる単一のサイトマップを組み合わせることで、Googleにできるだけ明確なシグナルを送れます。GSCプロパティを整理すると、残るレポートを追いやすくなります。当社では、修正をデプロイしてから2週間以内に、正規URLの重複に関する警告が減り始めました。

当社はこのような移行を、WordPressの性能改善・移行支援の一環として日常的に行っています。移行後のSEO問題でお困りの場合は、ご相談ください。

関連記事

関連記事

React SPAからAstroへ：移行の時期と理由

WordPress 7とElementorの性能：リビジョン削除の先にあるデータベースの健全性

実際に効果があったSEO修正：正規URL、サイトマップ、末尾スラッシュ