WordPress から Astro へ：リクエストパス上にデータベースを持たないコンテンツサイト.

WordPress から Astro へ移行されるものと、移行されないもの?

投稿、ページ、カテゴリー、タグ、著者、代表画像、作成日は、WXRエクスポートに入るため移行できます。でも、プラグインは移行されません。テーマと管理画面も同じです。コメントやカスタムフィールドはエクスポートに含められますが、サイト設定や添付ファイル本体は含まれないため、メディアファイルは別に集める必要があります。Astroでは、コンテンツをコレクションに置き、ビルド時にMarkdown、MDX、Markdoc、YAML、TOML、またはJSONファイルを読み込みます。そして、管理画面は移りません。

カスタム投稿タイプは、自分でスキーマを定義するコレクションになります。ここは難しくありません。ただし、ElementorのページはElementor独自の形式でJSONとして書き出されるため、レイアウトを変換するのではなく、コンポーネントとして作り直す必要があります。コメントにはホスティングサービス、フォームにはエンドポイントが必要です。そして、SEOプラグインのフィールドはフロントマターに移します。ドメインが変わると、メディアのURLが切れることがあります。これは、WordPressコアのTracで「エクスポート」の項目として挙がっている問題です。

検索トラフィックを維持するために、URLマップやリダイレクトをどのように計画すればよいでしょうか?

Astroのコードを書く前に、サイトが返している公開URLをすべて洗い出し、それぞれを新しいアドレスへ対応付けます。最初に作るのは、この対応表です。SEOプラグインのサイトマップには、投稿、ページ、カスタム投稿タイプ、タクソノミー、最終更新日が並ぶので、最初の照合に使えます。そして、すべてのスラグを維持するなら、リダイレクト表に書くのは例外だけで済みます。

次に、リダイレクトをどこで返すかを決めます。Astroのリダイレクト設定では、ルートと移動先を対応付けでき、/blog/[...slug]のような動的ルートも使えます。サーバーアダプター、または静的出力の静的アダプターを使うと、実際の 301 と 308 ステータスコードを返せます。ただし、アダプターを使わない場合は、ステータスコードなしの meta refresh タグが生成されます。シグナルは弱くなります。Google は、恒久的なサーバーサイドリダイレクトを推奨しています。

末尾のスラッシュは必ず見ます。Astroによると、リダイレクトではまだここをカバーできません。だから、ホスト上で確認します。推測はしません。連鎖リダイレクトは作らず、カノニカルタグが新しいURLを指していることを確認し、リダイレクトは少なくとも1年間残します。早く消すと、トラフィックを失います。

WordPressからのコンテンツの移行方法：エクスポート、API、またはクロール?

データ移行には、構造のエクスポートと、差分取得用のREST APIを使います。どちらにも入らないものだけをクロールします。wp exportやプラグインで作るWXRファイルには、投稿、ターム、コメント、著者、添付レコードが入ります。でも、添付ファイル本体は入りません。そのため、メディアは別に取得するか、.wxrzまたは.zipファイルを同梱するプラグインを使います。

REST APIの/wp/v2/posts、/wp/v2/pages、/wp/v2/mediaは、投稿、ページ、メディアをJSONで返します。メディアはページ送りで取得します。per_page のデフォルト値は 10 です。そして、modified_after を使うと、前回取得後に変更された内容を拾えます。ただ、ページを Elementor で作っている場合は、その JSON をエクスポートします。ファイル形式が必要なら、特定のプラグインで各投稿を .html として書き出せます。

コードを書く前に、取得したデータを、公開済みの全アイテム、ターム、著者、元のURLの一覧と照合します。まず差分を見つけます。だから、説明できない差分があれば、構築に入る前に止めて直します。ずれをそのまま持ち込むと、後で原因を探すのがずっと難しくなります。

WordPressと比較して、Astroでは編集者にはどのような機能がありますか?

編集担当者はWordPressの管理画面やプラグインを使えなくなります。その代わり、デプロイ前のプレビューと、管理者が直し続けなくてよいサイトを使えます。どちらを取るかは、現実的な交換条件です。ただ、コンテンツをMarkdownで管理する場合、編集担当者はファイルを編集し、Gitにコミットし、ビルドを実行して公開します。ある情報源では、ローカルプレビューは技術に詳しくない編集担当者にとって大きな壁になるとされています。自分のチームで試すのが確実です。困ればすぐ分かります。

AstroをヘッドレスCMSと組み合わせると、編集担当者はファイルではなくフィールドに入力できます。Sanityのビジュアル編集機能では、編集担当者がプレビュー内の要素をクリックすると、Studio内の対応するフィールドへ移動できます。SanityのドキュメントにもAstroはサポート対象として載っています。ただしその場合は、コンテンツ管理用の別システムを運用します。そして、そのシステムのログイン管理も別に必要です。

そして、WordPressが持つビジュアル編集画面も使えなくなります。その結果、レイアウトを変えるたびに開発者の作業費がかかります。

WordPress から Astro への移行にはどのくらいの時間がかかり、その作業量はどのような要因によって決まるのでしょうか?

移行期間は、今すぐ数えられる5つの要素で決まります。URL数、コンテンツの種類、メディア、連携機能、ロケールです。まずここを数えます。どのサイトにも当てはまる日数はありません。だから、ここを見ていない見積もりは信用しない方がよいです。公開されている事例では22日間の移行期間が報告されていますが、あなたのサイトはそれより大きいかもしれませんし、もっと単純かもしれません。

それぞれの要素が、事前に読める作業量を増やします。URLが増えると、リダイレクト表が長くなり、同一性の確認も増えます。コンテンツの種類が増えると、定義するスキーマも増えます。メディアファイルは取得して再ホストする必要があります。フォーム、コメント、アナリティクスには、それぞれ代わりのサービスが必要です。そして、ロケールが増えるたびに、hreflangとサイトマップの確認も増えます。

私はこうした移行を計画して実行し、これらの要素で作業規模を決めています。まず無料の診断を使います。実行を決める前に、スクリプトの負荷、ヘッダー、構造化データを確認できるからです。主観より数字の方が、判断しやすいです。

WordPressからAstroへの移行を控えるべき場合?

ログイン機能、パーソナライゼーション、複雑なインタラクティブ機能が必要なサイトは、移行しない方がよいです。それらはアプリケーションだからです。代わりに Sanity や Contentful などのヘッドレス CMS と Next.js を組み合わせることを勧めます。そして、多くの編集者が毎日サイト上で作業し、ビジュアル管理画面やそのプラグインに依存している場合も、現状維持がよいです。編集者の日々の作業手順も、コストに入ります。

ページがすでにうまく機能し、編集者が問題なく公開でき、プラグイン更新やパッチ適用の担当者がいるなら、現状維持が賢明です。移行にはチームの時間がかかります。しかも、必須ではない成果のために、検索トラフィックを危険にさらすことになります。でも、サイトがほぼ静的で、編集にCMSが不要で、ホスティングやパッチ適用の費用が管理画面を使う価値を上回っているなら、移行を検討します。

評価スコアは最も手っ取り早い判断材料となります。良好な評価を得られたのであれば、変更する必要性はほとんどないでしょう。

よくある質問.

次に読む.

1. 01WordPressの代替サービス現状維持、ヘッドレス化、または移行：各ページの内容に基づいて判断されます。
2. 02WordPress から Next.js へまずはヘッドレスWordPress、あるいはSanityへのコンテンツ取り込みから始めます。
3. 03Astro SEOチェックアイランド、コンテンツコレクション、構造化データ、Web Vitals。