WordPressから移行する

中級約20分最終更新 2026-09-11

WordPressで運用しているサイトを、ShareDan CMS＋自前フロントエンドのヘッドレス構成へ移行する進め方をまとめます。コンテンツの移し替えはShareDanが運営代行する移行サービスとして提供し、開発者は配信フロントの実装とURL・リダイレクト設計に集中できます。本ガイドでは、自動で取り込まれる範囲・お預かりするデータ・移行後の連携までを解説します。

移行はShareDanが代行します。既存サイトからのコンテンツ移行は初期構築費に含まれない別途見積もりの有償サービスです。WordPressのDBダンプとメディアをお預かりし、投稿・固定ページ・カテゴリ・メディア・Contact Form 7 をCMSへ自動で取り込みます。範囲・費用は担当までお問い合わせください。

1. 移行の全体像（運営が代行）

モノリシックなWordPress（管理画面もテーマも同じサーバーで動く構成）は、更新のたびにサーバー全体へ負荷がかかり、プラグインの脆弱性がそのまま公開面のリスクになります。ShareDan CMSへの移行では、コンテンツ管理（CMS）と配信（自前フロント）を分離し、次の3点を狙います。

速度：配信はSSG/ISRで静的化されたページになり、WordPressの実行環境を経由しない。
保守：テーマ・プラグインの更新対応が不要になり、フロントはコード管理下に置ける。
セキュリティ：管理画面（wp-admin）が公開面から切り離され、攻撃対象領域が減る。

コンテンツの取り込みは、運営が専用ツールで一括処理します。.sqlのDBダンプを直接解析し、本文HTMLをエディタ（ProseMirror）形式へ変換、画像はファイル機能へ再ホストします。手作業で1件ずつ貼り付ける必要はありません。本番反映の前にdry-run（試行）で対象件数・変換警告を確認してから本実行するため、取りこぼしや意図しない変換を事前に把握できます。

全部を一度に切り替える必要もありません。WordPressを残したまま新フロントを別ドメイン/パスで先行公開し、コンテンツ種別ごと（お知らせ→FAQ→固定ページ…）に確認しながら、最後にDNSとリダイレクトを切り替える進め方が安全です。

2. 自動で取り込まれるもの

WordPressの投稿タイプ・分類・メディア・フォームは、CMSの概念へ次のように自動でマッピングされます。取り込み前のdry-runで、各投稿種別の件数とマッピング先を確認できます。

WordPressShareDan補足

投稿（post）投稿（お知らせ等の種別）本文HTML（Gutenberg／クラシック）をProseMirrorへ自動変換。公開／下書き／非公開／予約公開の状態も保持

カスタム投稿タイプ同名の新規投稿種別 news・works などは種別として再現。スライダー等プラグイン内部の投稿タイプは既定で取り込まない

固定ページ（page）固定コンテンツ WordPressのslugを基にkeyを採番

カテゴリ・タグカテゴリ・タグカスタムタクソノミーも汎用対応。投稿は代表1カテゴリに集約、未分類は既定カテゴリへ

メディア（アップロード）ファイル・アイキャッチ WebP変換・サムネイル生成のうえ再ホスト。本文中の画像URLも自動で新URLへ置換

Contact Form 7 フォーム項目定義（種類・必須・選択肢）を自動移送。送信先メール・自動返信・スパム対策は移行後に設定

抜粋・SEOメタ（Yoast等） post.meta（Standard以上） meta_title / meta_description / og_image_url に対応

Contact Form 7 も移行対象です。CF7で組んだフォームは、項目定義（テキスト・メール・電話・テキストエリア・ラジオ・チェックボックス・セレクト・ファイル）をそのままCMSのフォームへ取り込みます。送信先メール・自動返信・スパム対策は仕組みが異なるため、移行後にフォーム連携・送信後の通知を参照して設定します。

移行しないもの（ヘッドレス化に伴い対象外）

移行するのはコンテンツで、サイトの見た目（デザイン）は移行対象ではありません。次の要素は取り込まれないため、配信フロント側で実装します。

テーマ・テンプレート・ウィジェット・ナビゲーションメニュー・サイドバー等の見た目／レイアウト
コメント・トラックバック、プラグイン、ACF等のカスタムフィールド
リダイレクト設定・ユーザーアカウント

3. お預かりするデータ

運営代行では、次の2つをご用意いただきます。取り込み後の管理画面での修正は不要になるよう、可能な範囲で揃った状態でのお預かりが理想です。

WordPressのDBダンプ： .sql（または .sql.gz）。phpMyAdmin・mysqldumpいずれのエクスポートでも可。テーブル接頭辞は自動検出するため wp_ 以外でも問題ありません。
wp-content/uploads のzip：画像等のメディア。これを基に再ホスト（WebP変換・サムネイル生成）します。省略した場合は本文中の画像URLからの取得にフォールバックしますが、旧サイトが稼働中のときのみ有効です。

DBダンプの取り扱いについて。DBダンプにはユーザー情報や問い合わせ内容などの個人情報が含まれる場合があります。お預かりデータは非公開・暗号化されたステージングで扱い、短期間で自動失効・取り込み後に削除します。公開ファイル用のストレージとは分離しています。

取り込みはdry-run（試行）→本実行の2段階で進めます。処理は冪等なので、内容を調整して再実行しても重複しません。移行先は既存サイトを上書きせず、必ず新しいサイトとして作成するため、既存の公開サイトに影響を与えずに検証できます。

4. URL・リダイレクト設計

旧URLへのアクセス（外部リンク・検索エンジンのインデックス・ブックマーク）を失わないために、301（恒久）リダイレクトを設計します。リダイレクト設定はWordPressから移行されないため、配信フロント側で用意します。まずは代表的なWordPressのURLパターンと移行後URLの対応表を作りましょう。

記事ID型： /?p=123 → /news/{slug}
年月パーマリンク： /2024/05/slug/ → /news/slug
カテゴリアーカイブ： /category/notice/ → /news?category=notice

対応表さえ作れれば、実装は配信環境に合わせて選べます。

public/_redirects

# WordPress の record ID URL
/?p=123                 /news/launch-event      301

# 年月付きパーマリンク（スラッグは維持）
/2024/05/legacy-slug/   /news/legacy-slug       301

# カテゴリアーカイブ
/category/notice/       /news?category=notice   301

nginx.conf

# 記事ID型 → 新URL（1件ずつ書き出す）
rewrite ^/\?p=123$ /news/launch-event permanent;

# 年月パーマリンク → スラッグ維持のまま新URLへ
rewrite ^/\d{4}/\d{2}/([^/]+)/?$ /news/$1 permanent;

# カテゴリアーカイブ → カテゴリ別一覧
rewrite ^/category/([^/]+)/?$ /news?category=$1 permanent;

ヒント：取り込み時はWordPressのslugをそのまま新しい投稿のslugに引き継ぎます。旧slugと新slugが揃うので、記事IDやカテゴリアーカイブなどパターン化できるものだけリダイレクトを書けばよくなります。

5. 移行後のフロント連携

取り込みが完了すると、WordPressの投稿はそのまま公開APIから配信できます。あとはAstroで作るやNext.jsで作ると同じ要領で、種別ごとに一覧・詳細を組むだけです。本文はProseMirror JSONで返るため、SDKの renderProseMirror() でHTML化します。

src/lib/cms.ts

import { ShareDanCmsClient } from '@sharedan/cms-sdk';
import { renderProseMirror } from '@sharedan/cms-sdk';

const cms = new ShareDanCmsClient({
  baseUrl: 'https://api.cms.sharedan.co.jp',
  apiKey: import.meta.env.CMS_API_KEY,   // サーバー側だけで参照
  siteCode: 'main',
});

// 移行後は WordPress の投稿がそのまま種別 'news' の投稿として並ぶ
const { items } = await cms.posts.list('news', { perPage: 100 });

// 詳細は本文（ProseMirror JSON）を renderProseMirror でHTML化
const post = await cms.posts.get('news', 'launch-event');
const html = renderProseMirror(post.body);

公開APIには書き込みエンドポイントがありません（フォーム送信を除く）。移行後のコンテンツ修正・追加は管理画面から行い、フロントは読み取りに徹します。APIキーはサーバー側だけで扱い、ブラウザに露出させないでください。

Contact Form 7 から移行したフォームは、cms.forms.get('contact')で定義を取得してUIを描画し、cms.forms.submit('contact', values)で送信します。スパム対策（Turnstile・レート制限・ハニーポット・送信速度チェック・重複送信防止）はフォームごとに標準搭載なので、reCAPTCHA相当を個別に組む必要はありません。詳しくは問い合わせフォーム連携を参照してください。

段階移行のコツ：新フロントは本番切替前に別ドメイン/パス（例: new.example.com）で先行公開し、コンテンツごとに動作確認しておくと、切替当日はDNSとリダイレクトの反映だけで済みます。

FEEDBACK

このページはお役に立ちましたか？

改善要望・不具合・ドキュメントの分かりにくい点など、お気軽にお寄せください。いただいた内容は今後の改善に役立てます。