ACT3の自社サイトを、WordPressからAstro 5による静的サイトへ移行しました。既存の記事、問い合わせフォーム、サイト内検索、旧URLを維持しながら、通常のページ表示を静的ファイルの配信へ切り替えています。
ここでは、WordPressの記事をMarkdownへ変換した手順、フォーム処理をPHPとして残した構成、本番デプロイ時に発生したPagefindと.htaccessのトラブルシュートを記録します。
移行前に整理した要件
移行前のサイトでは、WordPressで記事や固定ページを管理し、独自PHPによる問い合わせフォームを運用していました。静的サイトへ移行するにあたっては、既存サイトの機能やURLを確認し、移行後にどの仕組みで置き換えるかを先に決める必要があります。
今回は、次の要件を移行対象としました。
- 記事とお知らせの既存URLを維持する
- WordPress内の記事をMarkdownへ移行する
- 問い合わせフォームの検証・スパム対策を維持する
- データベースを使わずにサイト内検索を提供する
- Xserver上の既存ディレクトリ構成を踏まえて公開する
静的HTMLの生成、Markdownコンテンツの管理、既存のSass・JavaScript資産の移植に対応しやすかったことから、フレームワークにはAstroを採用しました。
移行プロジェクトの流れ
移行作業では、既存のwebpack・Sass構成、WordPressに入っていた記事データ、問い合わせフォームのセキュリティロジック、サイト内検索を整理しながら、Astro上で組み直しました。
Phase 1：Astro 5の基盤構築
まず、既存プロジェクト内の app/astro/ に独立したAstro 5プロジェクトを作成しました。その後、ディレクトリ構成を整理し、現在は app/ 直下をAstroプロジェクトとして管理しています。
既存のSass資産を引き継ぐ際には、非推奨になっていた関数も整理しました。たとえば darken() のような古い関数は、@use "sass:color"; を宣言したうえで color.adjust() へ置き換え、今後のビルドで警告が出にくい状態に整えています。
Phase 2：共通UIのコンポーネント化
ヘッダー、フッター、モバイルメニュー、CTAといった共通UIを、Astroコンポーネントへ分割しました。
あわせて、WordPress側で管理していた「よくあるご質問」「相談の流れ」などの可変データも、Astro内で扱いやすいデータ構造に整理し直しています。HTMLを直接書き並べるのではなく、再利用しやすい形でページを組み立てられる構成にしました。
Phase 3：WordPress記事のMarkdown化
WordPressの wp_posts テーブルをSQLダンプから取り出し、Node.js製の変換ツールとTurndownを使ってHTMLからMarkdownへ変換しました。
Gutenberg由来のHTMLブロックも可能な範囲で読みやすいMarkdownへ整え、Frontmatter付きの記事データとしてAstroのContent Collectionsで扱えるようにしています。記事コンテンツをGitで管理できるようになり、変更履歴や差分の確認もしやすくなりました。
Phase 4：Pagefindによる静的サイト内検索
静的化によってWordPressの検索機能は使えなくなるため、サイト内検索にはPagefind 1.5.2を採用しました。
Pagefindは、ビルド済みのHTMLから検索インデックスを生成し、クライアントサイドで検索を行う仕組みです。WP_Query のようにサーバー側で検索処理を走らせる代わりに、静的ファイルとして生成されたインデックスをブラウザ側で読み込んで検索します。この仕組みにより、データベースなしでもサイト内検索を維持できました。
Phase 5：フォーム処理の移植
問い合わせフォームについては、フォーム画面をAstroで静的に生成し、送信処理だけをサーバー上の独立したPHP（process.php）に切り出しました。WordPress本体を動かさず、フォーム処理だけを最小限のPHPに分離する構成です。
既存フォームで使用していた以下の検証・スパム対策もそのまま移植しています。
- CSRFトークンの確認
- 送信時間の制限によるスパム対策
- 送信頻度の制限
- Honeypot
- Google reCAPTCHA v3
- 入力値の検証
- メール送信処理
本番デプロイでハマったこと
ローカルやテスト環境では問題なく動いていても、本番サーバーに配置すると、サーバー設定や既存の.htaccessの影響でトラブルが起きることがあります。
Pagefind検索時に invalid gzip data が発生する
本番環境で検索機能を確認したところ、ブラウザのコンソールに次のエラーが表示されました。
Failed to load the Pagefind WASM: Error: invalid gzip data原因は、Pagefindが生成する .pf_meta、.pf_index、.pf_fragment、.pagefind ファイルに対するサーバー側のエンコーディング設定が、Pagefind自身の処理と競合していたことです。
Pagefind関連ファイルはPagefind自身が圧縮・解凍を管理しており、公式ドキュメントでもサーバー側のgzip対応は不要とされています。今回のXserver環境では、.htaccess に以下の設定を追加し、余分なエンコーディング情報が付かないようにすることで解消しました。
<IfModule mod_mime.c>
RemoveEncoding .pf_meta
RemoveEncoding .pf_index
RemoveEncoding .pf_fragment
RemoveEncoding .pagefind
RemoveType .pf_meta .pf_index .pf_fragment .pagefind
AddType application/octet-stream .pf_meta .pf_index .pf_fragment .pagefind
</IfModule>静的サイトはPHPやデータベースを使わない分シンプルですが、サーバー側のMIMEタイプやエンコーディング設定の影響を受けます。既存サイトの設定を引き継ぐ場合はとくに確認が必要です。
末尾スラッシュのURLで404になる
記事ページのURLでも問題が発生しました。次の index.html 付きのURLは表示できた一方で、本来アクセスさせたい末尾スラッシュのURLが404になっていました。
/insights/4294/index.html/insights/4294/原因を調べると、親ディレクトリ側の.htaccessに旧WordPress用の内部リライトが残っていました。
RewriteRule ^insights/([0-9]+)/?$ /insights/post.php?post_id=$1 [QSA,L]このルールによって、実在するAstroの静的ディレクトリではなく、存在しない post.php へ内部的にリライトされていました。旧WordPress用のリライトルールを削除し、Astroが生成したHTMLへ直接アクセスできるようにして解決しました。
WordPressから静的サイトへ移行する際は、ファイルの置き換えだけでなく、上位ディレクトリの.htaccess、旧URLのリダイレクト、内部リライト、キャッシュ設定まで確認しておく必要があります。
移行後も残る動的処理と保守対象
通常のページは静的ファイルとして配信する構成へ変更しましたが、サイト全体が静的ファイルだけで完結しているわけではありません。
問い合わせフォームでは、引き続きPHP、セッション、メール送信処理を使用しています。フォームの設定ファイルやメールテンプレートもサーバー上に配置するため、アクセス制限とデプロイ対象の確認が必要です。
サイト内検索はデータベースを使用しませんが、記事を追加・修正した際は、Astroのビルド後にPagefindのインデックスも再生成する必要があります。また、Astro、Pagefind、Sass、npmパッケージ、PHP、サーバー設定は継続して保守対象になります。WordPress固有の更新作業はなくなりましたが、移行後の構成に合わせた更新・検証・バックアップは必要です。
Xserver上で静的サイトへ移行する際の確認事項
今回の移行では、Astro側の実装よりも、既存サイトの設定を引き継ぐ段階で問題が発生しました。Xserver上でWordPressから静的サイトへ切り替える場合は、公開前に次の項目を確認しておく必要があります。
- 親ディレクトリを含む
.htaccessのリライトルール - 旧URLから新しいURLへのリダイレクト
- ディレクトリURLと
index.htmlの扱い - Pagefind関連ファイルのMIMEタイプとエンコーディング
- PHPフォーム、設定ファイル、メールテンプレートの配置先
- デプロイ対象に必要なPHPや
.htaccessが含まれているか - 404ページが正しいHTTPステータスで返るか
既存のURLや機能を維持したまま静的サイトへ移行する場合は、WordPress側のデータだけでなく、公開ディレクトリの外側にあるサーバー設定も含めて調査する必要があります。
