WordPressからAstroへ移行する方法：URL維持・SEO・無停止切替の実践手順

この記事でわかること

WordPressブログをAstroの静的サイトへ置き換えるときに必要な作業を、実際の移行順序に沿って整理します。

記事、固定ページ、画像、データベースの退避方法
既存URLを変えずにAstroへ移す設計
検索、RSS、お問い合わせなど動的機能の置き換え
DNSを変更する前に新サーバーを検証する方法
失敗時にすぐ戻せる無停止切替の考え方

想定読者: 更新頻度が低い技術ブログや小規模メディアを、軽量で保守しやすい構成へ移したい人。

WordPressをAstroへ移す理由

WordPressは管理画面から記事を書け、テーマやプラグインも豊富です。一方で、PHP、データベース、プラグイン更新、ログイン画面の防御など、公開を続けるだけでも複数の保守対象があります。

Astroはコンテンツ中心のサイトを静的HTMLとして出力できます。記事をMarkdownなどのファイルで管理し、ビルド時にページを生成する構成なら、閲覧時にPHPやデータベースを動かす必要がありません。

ただし、誰にでも移行が向くわけではありません。複数人で管理画面から頻繁に更新するサイト、会員機能、EC、複雑な検索や投稿機能が必要なサイトは、WordPressを残すかヘッドレスCMSとして利用する選択肢もあります。Astro公式も、WordPressをCMSとして残す方法と、記事をローカルファイルへ移す方法の両方を案内しています。

移行前に決める4つのこと

1. URLを維持するか

既存記事が検索エンジンに登録されているなら、原則としてURLを変えない方が安全です。たとえばWordPressのURLが次の形式なら、Astro側でも同じパスを生成します。

/2026/04/25/docker-guide/

URLを変更する場合は、旧URLから新URLへの恒久リダイレクトを1件ずつ準備します。トップページへ一括転送するだけでは、記事ごとの対応関係が検索エンジンや読者へ伝わりません。

2. 記事の管理方法

小規模ブログなら、1記事1ファイルのMarkdown管理がシンプルです。AstroのContent Collectionsを使うと、タイトル、公開日、カテゴリー、URLなどの形式をスキーマで検証できます。

title: "記事タイトル"
description: "検索結果に表示する説明"
publishDate: "2026-07-12T13:30:00+09:00"
path: "/2026/07/12/example/"
categories:
  - name: "Linux"
    slug: "linux"

3. 動的機能をどう置き換えるか

WordPressが担当していた機能を一覧化します。

WordPressの機能	静的サイトでの置き換え例
記事検索	ビルド時に作るクライアント検索インデックス
RSS	AstroのRSS連携でXMLを生成
サイトマップ	ビルド時にXMLを生成
お問い合わせ	小さなAPI、フォームサービス、メールAPI
コメント	外部サービス、GitHub Discussions、廃止
関連記事	カテゴリーやタグをビルド時に集計
予約投稿	GitとCI/CD、またはビルドの定期実行

4. ロールバック方法

新サイトに問題があったとき、DNSを旧IPへ戻せる状態を残します。旧WordPressを先に削除してはいけません。少なくともDNS反映と主要ページの検証が終わるまでは、旧サーバーを起動したまま保持します。

手順1：WordPressを完全にバックアップする

最低限、次の4種類を別々に保存します。

WordPressエクスポートXML（WXR）
wp-content/uploads配下の画像
データベースのSQLダンプ
現在公開されているURL一覧

WXRには記事本文や分類情報が含まれますが、サーバー固有の設定や全プラグイン設定を完全に復元できるバックアップではありません。SQLとアップロードファイルも必ず保存してください。

URL一覧はサイトマップだけでなく、WordPress側の公開記事・固定ページから取得します。カテゴリー、タグ、RSS、画像、404ページなども検証対象に含めます。

手順2：記事をAstroのコンテンツへ変換する

記事数が少なければ手作業でも移せますが、数十件以上なら変換スクリプトを用意した方が再現性があります。変換処理では次を行います。

WXRから公開記事と固定ページを抽出
タイトル、概要、公開日、更新日、カテゴリー、タグをfrontmatterへ変換
本文のWordPressブロックコメントや不要なショートコードを整理
画像URLをローカルの公開ディレクトリへ対応付け
元のパーマリンクをpathとして保存

HTMLを完全にMarkdownへ変換すると、表、コードブロック、独自クラスが崩れる場合があります。最初の移行では本文HTMLをMarkdownファイル内に残し、表示確認後に段階的に整理する方法も現実的です。

手順3：既存URLをそのまま生成する

Astroの動的ルートで、各記事のpathから静的ページを生成します。重要なのは、スラッグを新しく作り直すのではなく、WordPressから取得したパスを正として扱うことです。

日本語や記号を含むURLでは、エンコード済みパスとデコード済みパスの扱いに注意します。次の3点をテストしてください。

ブラウザーで日本語URLを開ける
パーセントエンコードされた旧URLでも200になる
サイト内リンクが生成後のファイルへ到達する

カテゴリーとタグのアーカイブも、既存スラッグを維持して生成します。

手順4：SEOに必要な出力をそろえる

見た目だけでなく、次の出力を確認します。

ページごとのtitleとmeta description
canonical URL
OGPとSNS向けメタデータ
Article構造に必要な公開日・更新日
XMLサイトマップ
RSS
robots.txt
存在しないURLが本当に404を返すこと

旧WordPressの/feed/や/wp-sitemap.xmlへ外部リンクがある場合は、新しいRSSとサイトマップへリダイレクトします。

手順5：ローカルビルドとリンク検証

Astro公式ドキュメントでは、通常のビルドコマンドと出力先は次のように案内されています。

pnpm run build
# 標準の出力先: dist/

ビルド成功だけでは不十分です。生成後のHTMLを走査し、すべての内部リンク、画像、CSS、JavaScriptの参照先が存在するか確認します。

検証項目の例です。

公開記事数 = 移行元の公開記事数
固定ページ数 = 移行元の公開固定ページ数
内部リンク切れ = 0
画像参照切れ = 0
重複canonical = 0

手順6：新サーバーへ世代管理で配置する

distを直接上書きするのではなく、リリースごとにディレクトリを分け、currentシンボリックリンクを切り替えると安全です。

/srv/www/example/
├── current -> releases/20260712-1330
└── releases/
    ├── 20260712-1200
    └── 20260712-1330

新しいリリースに問題があれば、currentを前のディレクトリへ戻すだけでロールバックできます。nginxの設定は変更前にnginx -tで検証し、問題がなければreloadします。

手順7：DNS変更前に本番相当で確認する

DNSを変更する前でも、curl --resolveを使うと、ドメイン名とTLSの組み合わせを維持したまま新IPへ接続できます。

curl --resolve example.com:443:203.0.113.10 \
  https://example.com/

この状態で、トップページだけでなく全記事URL、画像、カテゴリー、RSS、サイトマップ、検索、お問い合わせを確認します。

手順8：DNSを切り替える

新サーバーでHTTPSまで確認できたら、Aレコードと、利用している場合はAAAAレコードを新IPへ変更します。

変更前のDNS値を記録する
A/AAAAレコードを変更する
権威DNSと複数の公開DNSで反映を確認する
通常のURLで新サーバーへ到達することを確認する
TLS証明書を新サーバーで正式に発行・自動更新設定する
アクセスログとエラーログを監視する

旧サーバーはすぐに削除せず、DNSキャッシュが残る利用者も考慮して一定期間保持します。

移行で起きやすい問題

プラグイン由来のHTMLやショートコードが残る

目次、装飾ボックス、ギャラリー、フォームなどはWordPressプラグインに依存している場合があります。変換時に検出リストを作り、Astroコンポーネントへ置き換えます。

画像以外のファイルまで公開してしまう

wp-content/uploadsには、キャッシュ、バックアップ、プラグイン生成ファイルが混在することがあります。公開対象の拡張子を限定し、設定ファイルやログをコピーしないようにします。

お問い合わせだけ動かない

静的HTMLはメール送信できません。フォーム送信先となるAPIか外部サービスを別途用意し、送信元アドレスと返信先アドレスを分離します。ハニーポット、入力長制限、回数制限も追加します。

新旧サイトのURL表記が混在する

canonical、OGP、RSS、サイトマップ、本文中の絶対URLをまとめて検査します。HTTPとHTTPS、wwwあり・なしも統一してください。

Astro移行が向いているサイト

記事更新が週数回以下の個人ブログ
PHPプラグインへの依存が少ない
コメントや会員機能が不要
GitやMarkdownでの管理に抵抗がない
1台のVPSで複数サイトを軽量に運営したい

複数サイトを1台へ置く具体的な構成は、2GB VPSで複数サイトを運営する方法で解説します。

まとめ

WordPressからAstroへの移行で最も重要なのは、フレームワークの書き方より、既存URLの維持、全コンテンツの退避、機械的なリンク検証、ロールバック可能な切替手順です。

旧環境を残したまま新サーバーを完成させ、ドメイン名を使った事前検証を終えてからDNSを変更すれば、停止時間と移行リスクを小さくできます。