WordPressからAstroへの移行：ヘッドレスでも完全移行でも、検索順位を落とさずに移す方法

結論から

W3Techsによると、2026年10月13日時点で、全ウェブサイトの40.1%がWordPressで動いています。そのため、サイト移行の多くはWordPressが出発点になります。Astro公式の移行ガイドは、2つの道筋を示しています。WordPressをヘッドレスCMSとして残し、フロントエンドをAstroで構築する方法と、コンテンツをWordPressから完全に移す方法です。

どちらを選んでも、トラフィックを守るための作業は同じです。アクセスを集めているURLをすべて残し、SEOプラグインが出力していたタイトルとディスクリプションを引き継ぎ、uploadsフォルダをコピーし、フロントエンドを担っていたプラグインを置き換え、変わるURLにはすべて恒久リダイレクトを設定します。この順番で進めれば、新しいサイトは検索順位をゼロからやり直すことなく、表示を速くし、運用コストを下げることができます。

ヘッドレスWordPressか、完全移行か

Astroのドキュメントは、どちらの方法も解説しています。WordPressをヘッドレスCMSとして使う方法とWordPressからの移行で、後者ではコンテンツの移行にwordpress-export-to-markdownというツールを勧めています。

公開中のWordPressサイト8つを調べてわかったこと

2026年10月13日、WordPress.org自身のニュースブログから大手メディアまで、WordPressで作られた8つのサイトを調べ、移行の際に何を当てにできるかを確認しました。

• 8サイト中7サイトが、REST APIで投稿を一般公開していた。エンドポイントは/wp-json/wp/v2/postsです。残る1サイトは401を返しました。ホスティング会社やセキュリティプラグインによってはAPIへのアクセスを制限しているため、APIを前提に計画を立てる前に、自分のサイトで確認しましょう。
• 8サイト中3サイトは、投稿ごとにYoast SEOのデータも返していた。Yoastは標準のREST APIのレスポンスにyoastheadjsonというフィールドを追加し、そのページに出力するタイトル、ディスクリプション、canonical URL、Open Graphタグ、構造化データ（schema）を含めます（Yoast開発者向けドキュメント）。必要なSEOメタデータが、そのまま再利用できる形で手に入るということです。
• 返された投稿URLはすべて末尾がスラッシュで終わり、7サイト中5サイトはURLに年が入っていた。/2026/10/post-name/のような形です。Astroでこの構造を正確に再現しなければ、すべての投稿にリダイレクトが必要になります。
• 8サイト中6サイトが、今もjQueryを読み込んでいた。WordPressのテーマがどれだけ多くのフロントエンドのコードを抱えているか、そしてAstroで作り直せばそれを置いていけることがよくわかります。

WordPressからAstroへの移行手順

1. すべてのURLを洗い出す。WordPressはバージョン5.5以降、/wp-sitemap.xmlにサイトマップを公開しています。ただし、SEOプラグインが独自のサイトマップに置き換えている場合は別です（Make WordPress Core）。そこにGoogle Search Consoleの「ページ」レポートを取得できる最長の期間で加え、「設定」>「パーマリンク」でパーマリンク構造を控え、リダイレクト用のプラグインを使っていればそのルールをエクスポートします。
2. ヘッドレスか完全移行かを決める。判断には上の表を使います。以降の手順はどちらにも当てはまります。ヘッドレスの場合、「エクスポート」は同じデータをビルド時にAPIから読み込むことを意味します。
3. コンテンツをエクスポートする。「ツール」>「エクスポート」で作成されるWXRファイルは、投稿、固定ページ、カスタム投稿タイプ、コメント、カスタムフィールド、カテゴリー、タグ、カスタムタクソノミー、ユーザーを含むXML形式のエクスポートです（WordPressのドキュメント）。スクリプトでエクスポートする場合、REST APIは1ページあたり最大100件の投稿を、それぞれのレンダリング済みHTMLとともに返します。
4. アップロードファイルをコピーする。画像はXMLファイルに含まれていません。wp-content/uploadsに、WordPressが画像ごとに作ったリサイズ版と一緒に保存されています。元の画像を残し、サイズ違いの生成はastro:assetsに任せ、旧画像のURLをそのまま保つか、リダイレクトが必要かを決めます。
5. SEOメタデータを引き継ぐ。Yoast SEOを使っているサイトなら、すべての投稿と固定ページについて、REST APIからyoastheadjsonを読み込みます。プラグインが保存しているテンプレートではなく、最終的なタイトルとディスクリプションが得られます。Yoastを使っていない場合は、エクスポートに含まれるプラグインのカスタムフィールドから取り出します。
6. テンプレートをAstroのコンポーネントとして作り直す。完全移行なら、投稿と固定ページをコンテンツコレクションか新しいCMSに移します。ヘッドレスWordPressなら、APIから取得します。いくつかの投稿のHTMLを開き、ショートコード、埋め込み、ページビルダーのマークアップがないか確認しましょう。旧テーマの外で正しく表示させるには、これらの整理が必要になることが少なくありません。
7. フロントエンドを担っていたプラグインを置き換える。フォームには専用の送信先（Cloudflare Worker、フォームサービス、CRMなど）が必要です。検索はPagefindのような静的なインデックスに置き換えられます。コメントは、残すか、外部サービスに移すか、閉じるかを決めます。ページを事前にビルドするようになれば、キャッシュ系のプラグインの出番はありません。
8. URL構造を合わせる。WordPressのパーマリンクは通常スラッシュで終わり、Astroのデフォルトのディレクトリ形式の出力と一致します。日付を含むパーマリンクは、/[year]/[month]/[slug]/のような動的ルートにします（Astroのルーティング）。カテゴリーやタグのアーカイブには、専用のページかリダイレクトが必要です。
9. WordPressの名残も含めて、リダイレクトはサーバーで行う。アダプターなしの静的なAstroビルドでは、設定したリダイレクトがmeta refreshのページに変換されます（Astroの設定リファレンス）。そのため、サイトのホスティング先で1対1の301リダイレクトを設定します。URLが変わった投稿だけでなく、WordPressが自動で作るURLも対象にしましょう。/feed/、?p=形式の短縮リンク、添付ファイルページ、投稿者アーカイブ、移動した/wp-content/uploads/内のファイルです。
10. 公開し、その後を見守る。DNSを切り替え、新しいサイトの確認が済むまでは旧WordPressを自分だけがアクセスできる状態で残し、その後の数週間はSearch Consoleのインデックス登録レポートを追います。公開日とその後90日間については、サイト移行SEOチェックリストで解説しています。

移行後に変わること

SEOを守るには

URL変更を伴うサイト移転に関するGoogleのガイドが、そのまま当てはまります。旧URLをすべて最も近い新URLに対応付け、サーバーサイドの恒久リダイレクトを使い、少なくとも1年間は維持します。WordPressは、末尾にスラッシュが付くパーマリンクがAstroのデフォルトと一致するため、多くのプラットフォームに比べて同じURLを保ちやすいほうです。手間がかかるのは、日付入りのパス、アーカイブ、そしてプラグインが生成していたすべてのURLの再現です。

次に、旧テーマとプラグインが各ページに追加していたものを確認します。canonicalタグ、Open Graph画像、構造化データ、多言語プラグインが出力するhreflangタグ、robotsのルールです。新しいサイトで欠けているものは、切り替えたその日にGoogleが失うシグナルになります。

DardoのWordPress移行の進め方

WordPressからの移行は、ウェブサイト移行サービスの一環として行います。URLとコンテンツの洗い出し、ヘッドレスか完全移行かの判断を行い、代表的な1ページを先に作り直して合意した幅で確認し、その後に残りのテンプレート、フォーム、リダイレクトへ進みます。構築そのものはAstroによるWeb開発です。そもそもWordPressから離れるべきか迷っているなら、WordPressとフルスクラッチのサイトの比較で、それぞれが割に合うケースを解説しています。そのほかのよくある移行元については、FramerとWebflowからの移行ガイドをご覧ください。

移行を検討中なら、サイトと変えたいことをお知らせください。見積もりを出す前に、ヘッドレスと完全移行のどちらが合うかをお伝えします。