WordPress からヘッドレス構成へ移す作業でつまずくのは、たいてい「どう動かすか」ではなく「どう決めるか」です。投稿を貼り替える手そのものは単純で、迷うのはいつもどこまでをCMSに載せるか、カテゴリとタグをどう整理するか、旧URLをどう受けるかといった設計判断のほうです。逆に言えば、この判断さえ先に固めておけば、実際の移し込みは淡々と進みます。
この記事は手順書ではありません。移行を始める前に決めておくと後がラクになる5つの論点を挙げ、それぞれで ShareDan CMS の仕組みがどう効いてくるかを説明します。実際の貼り替え手順・リダイレクトの書き方はWordPressから移行するにまとめてあるので、手を動かす段になったらそちらを開いてください。
1. どこまでをCMSに載せるか
最初の判断は「全部CMS化しない」と決めることです。WordPress は会社概要からブログまで一つの管理画面に押し込む作りですが、ヘッドレスに移すときは更新頻度で線を引くのが素直です。
よく更新する— お知らせ、FAQ、導入事例。ここは公開APIにつなぎ、CMSで運用します。
ほとんど変わらない— トップやLP、凝ったレイアウトのページ。フロント側に静的なコンポーネントとして持ったままで構いません。
ShareDan CMS はこの線引きをサイト単位のスイッチとして持っています。サイトごとに「投稿を使う／FAQを使う／固定コンテンツを使う／フォームを使う」を個別にON/OFFでき、使わない種別のエンドポイントは公開API上で404を返します。つまり最初はお知らせだけを有効にして公開し、あとからFAQ、固定コンテンツ…と足していく段階移行が仕組みとして支えられています。一度に全部を切り替える必要はありません。
迷ったら「これは月に一度でも編集者が触るか？」で判断してください。触るならCMS、触らないなら静的。この基準だけで大半は仕分けできます。
2. 種別・カテゴリ・タグの三層をどう対応づけるか
WordPress の分類（投稿タイプ・カテゴリ・タグ）は、ShareDan CMS では役割の違う三つの層に対応します。ここを最初に対応表にしておくと、後の登録作業で悩みません。
種別（post type）← 投稿タイプ。
post/page/ カスタム投稿タイプを、news（お知らせ）・case（事例）のような種別に割り当てます。公開URLも種別ごとに分かれます。カテゴリ← カテゴリ。ただしカテゴリは種別に属し、1つの投稿に割り当てられるのは1件だけです。
タグ← タグ。こちらは投稿に何個でも付けられる多対多で、任意です。
WordPress に慣れていると引っかかるのが、カテゴリの数です。WordPress はひとつの投稿に複数カテゴリを付けられますが、ShareDan CMS では投稿はちょうど1つのカテゴリに属します。「大分類はひとつに絞り、細かい横串はタグで表現する」と役割を分けると、この制約はむしろ整理のきっかけになります。移行はカテゴリ体系を見直す数少ない好機なので、使われていないカテゴリを畳むのはこのタイミングが一番です。
もうひとつの前提が、カテゴリが種別の下にぶら下がる点です。newsのカテゴリとcaseのカテゴリは別物として管理され、種別ごとにデフォルトカテゴリ（削除できない受け皿）が1件用意されます。あるカテゴリを消しても、そこに属していた投稿は宙に浮かず、デフォルトカテゴリへ付け替わります。移行後にカテゴリを整理し直すときも、投稿が迷子にならないということです。
3. 固定ページをどう扱うか
WordPress の固定ページ（page）は、移行時にいちばん判断が割れるところです。ShareDan CMS 側の受け皿は2つあり、ページの性格で選び分けます。
(a) ページ全体を種別として持つ— 固定ページが何十件もあり、一覧やカテゴリ分けが要るなら、page相当の種別を1つ作って投稿として扱うのが素直です。1件ずつURL（slug）が付き、一覧APIにも乗ります。
(b) ページの一部だけを差し替え可能にする— 「会社概要ページの本文だけ編集できればよく、周りのレイアウトは固定」という場合は、固定コンテンツが向いています。キーを決めておき、公開APIから本文を1件だけ取り出してページの一部に流し込みます。
GET /api/v1/contents/company-profile固定ページを丸ごとCMSに載せるか、レイアウトはフロントに残して本文だけCMS化するか。ページ数が少なく体裁も固定なら (b)、件数が多く一覧性が要るなら (a) ——この二択で仕分けると、固定ページの扱いはほぼ決まります。
4. URLとリダイレクトをどう設計するか
移行でSEOとブックマークを失わないための肝が、URL設計です。ここでまず区別しておきたいのが、公開APIのパスとサイトの公開URLは別物だということです。
公開APIは種別とslugでコンテンツを引きます。
GET /api/v1/posts/news # 種別 news の一覧
GET /api/v1/posts/news/launch-event # 個別記事
GET /api/v1/posts/news?category=notice # カテゴリで絞り込み一方、利用者がブラウザで踏むサイトのURLは、あなたのフロント側で自由に決められます。/news/launch-eventでも/blog/2026/launch-eventでも構いません。だからリダイレクト設計は「APIに合わせる」のではなく「旧サイトのURLをどう受けるか」で考えます。
ここでの一番の近道は、旧サイトのslugを新しい投稿のslugにそのまま引き継ぐことです。slugさえ揃えば、/2024/05/legacy-slug/のような年月パーマリンクは末尾のslugを取り出して新URLへ流すだけで済み、書くべきリダイレクトはパターン化できるもの（記事ID型・カテゴリアーカイブ）だけになります。カテゴリアーカイブは、上のカテゴリ絞り込みを使ってフロント側の一覧ページ（例/news?category=notice）へ301すれば再現できます。
_redirectsや nginx での具体的な書き方はWordPressから移行するに対応表つきで載せてあります。この記事の段階では「slugを維持する」と決めておけば十分です。
リダイレクトは移行の“最後の一手”です。新フロントを別ドメインで先行公開して中身を確認し、切替当日はDNSとリダイレクトの反映だけにする——この順番だと事故が起きにくくなります。
5. フォームとメディアをどう移すか
最後は、プラグインとアップロードファイルです。
フォーム（Contact Form 7 など）は、管理画面でフォーム定義を作り直します。項目とバリデーションを設定すれば、フロントは定義の取得と送信の2ステップで完結します。
const form = await cms.forms.get('contact'); // 項目定義を取得してUIを描画
await cms.forms.submit('contact', values); // 送信reCAPTCHA やプラグインで個別に組んでいたスパム対策は、フォーム側に標準で入っています（Turnstile・レート制限・ハニーポット・送信速度チェック・重複送信防止）。移行時に対策を組み直す必要はありません。ひとつだけ決めておきたいのはAPIキーの置き場所です。公開サイトに直に埋め込むのではなく、自分のサーバー（フロントのAPIルート）を1枚かませてキーをサーバー側に置くのが安全です。通知やSlack連携まで含めた具体は問い合わせフォーム連携を参照してください。
メディア（画像・ファイル）は、元のアップロードURL（/wp-content/uploads/...）を引き継げないのが前提です。画像・ファイル機能へ再アップロードし、本文内のパスを差し替えます。旧メディアへの直リンクが検索やSNSに残っている場合は、これも4のリダイレクト対象に含めておきます。
まとめ
移行で本当に決めるべきは、手順ではなく判断です。①どこまで載せるか（更新頻度で線引き、使う種別だけ有効化して段階移行）、②種別・カテゴリ・タグの対応（カテゴリは種別配下で1投稿1件、横串はタグ）、③固定ページ（本文だけの固定コンテンツか、種別化か）、④URL（APIパスとサイトURLは別物、slugを維持してリダイレクトを減らす）、⑤フォームとメディア（定義を作り直し、キーはサーバー側、メディアは再アップロード）。この5つを先に固めてから、WordPressから移行するの手順に沿って手を動かせば、移行はぐっと見通しよく進みます。配信側の作り方はAstroで作る・Next.jsで作るを、APIの詳細はAPIリファレンスをどうぞ。