編集ブログまたは出版サイト

編集サイトは、EmDash の WordPress 由来の概念（コレクション、タクソノミー、拡張性）が、PHP ホスティングやプラグイン乱立を抱え込まずに活きる領域です。編集の基本要素はそのままに、フロントエンドは Astro ネイティブ、コンテンツモデルは型付き、そして本当にブラウザ編集が必要になるまで静的デプロイを維持できます。

良い状態の基準

まず、必要なコンテンツ構造を定義します。記事、著者、カテゴリ、タグ、必要ならシリーズや号などです。これを EmDash のコレクションとタクソノミーに対応付けることで、URL、RSS、内部リンクを予測可能に保てます。さらに、レイアウトと MDX を分離したテーマ構造にすれば、執筆者は内容に集中し、デザイナーは見た目の責任を持てます。

具体的な導入ステップ

1. 現行スタックの棚卸し。 WordPress（または既存 CMS）から記事サンプルをエクスポートし、維持必須の URL パターンを確認します。初日から外せない連携（コメント、ニュースレター、分析）も一覧化します。

2. 静的ファーストで最小構成を立ち上げる。 トラフィックの多いテンプレート（ホーム、記事、カテゴリ、タグ、著者）から先に公開します。ナビゲーションと RSS は早期に整備し、購読者と検索エンジンに継続性を示します。

3. 段階的に移行する。 まずエバーグリーンな記事、次に時系列依存のアーカイブを移します。URL 変更にはリダイレクトを設定し、移行ログを残して順位変動や分析変化を関係者に説明できるようにします。

4. プラグインは明確な課題がある時だけ導入する。 例えば、編集者が日常的にリッチメディアを貼るなら Embeds、外部フォーム提供者なしでリード獲得が必要なら Forms、コメントや投稿量が増えたら AI Moderation を追加します。

5. ランタイム拡張は意図的に計画する。 非技術者の編集者にブラウザ上ワークフロー、認証付きメディア、再ビルド不要のライブ更新が必要になった時に、Workers、D1、R2 を導入します。初週から標準で入れる前提ではありません。

例：週次の公開サイクル

月曜：Git ブランチまたは既存レビュー手順で構成案と下書き。火曜：MDX の差分でピアレビュー。水曜：画像と埋め込みを確定。木曜：ビルドを予約して Cloudflare Pages にデプロイ。金曜：SNS と配信チャネルで告知。このリズムはファイルベース運用でも、後で EmDash のフル管理画面へ移行しても有効です。

成果

静的配信から本格 CMS 動作までの明確な移行路を保ちながら、より高速で安全な公開基盤を提供できます。すべてのチームが初日からデータベースを必要とする前提にもなりません。