WordPressからヘッドレスCMS＋静的サイトへ移行する手順。記事・画像・URLの移し方、301リダイレクト、フォーム、検索順位を落とさないための確認チェックリスト

この記事の結論：今あるWordPressのサイトをヘッドレスCMSと静的サイトへ移すときは、①旧サイトのURLと画像の一覧を機械で書き出す、②CMSの入力欄を決めて記事を取り込む、③表のサイトを旧URLと同じ形で書き出す、④URLが変わる所だけ301で転送する、⑤フォームを作り直す、⑥一覧と書き出し結果を毎回自動で照合する、⑦公開した日と翌週以降に検索の状況を見る、の7段で進めます。検索順位を守るうえで一番大事なのは、旧URLが「同じURLで開ける」か「301で中身の近いページへ転送される」かのどちらかになっていることを、人の目ではなくスクリプトで全件確かめることです。

この記事は、WordPressのサイトをヘッドレスCMSと静的サイトの構成に移したい中小企業の担当者と、それを請け負う制作者に向けた手順書です。WordPressからヘッドレスCMSへ移行するときの作業を、発注する側が進み具合を確かめられるチェックリストの形にしています。例に使う事実は、やまやまブログ（このブログ）の旧WordPressを、Astroで書き出しCloudflareから配る形へ切り替えたときのものです。ただし、このブログは記事をMarkdownのファイルで持っており、ヘッドレスCMSは使っていません。CMSに取り込む部分は一般的な手順として書き、このブログの実際の作業とは分けて示します。仕様の根拠は末尾にまとめ、2026年10月3日付の版で中身を照らし合わせました。

移行の手順は7段に分け、段ごとに「終わった」と言える条件を決める

WordPressからヘッドレスCMSへの移行は、段ごとに終わりの条件を決めておくと、公開の判断がしやすくなります。全体の流れは次のとおりです。

以下、段ごとに詳しく書きます。ヘッドレスCMSを入れない移行（記事をファイルで持つ形）でも、2段目以外はそのまま使えます。

1段目：旧サイトのURLと画像は、WordPressのREST APIから書き出して一覧にする

移す対象の一覧は、人が数えるのではなく、WordPress自身のREST APIから取り出して作ります。投稿、固定ページ、カテゴリー、タグ、メディアの5種類を取り出し、各項目の link（ページのURL）と source_url（画像のURL）を集めれば、旧サイトにあるURLの一覧になります。

import fs from 'node:fs/promises';

// WordPress の REST API は1回に最大100件まで。全体のページ数は X-WP-TotalPages の見出しで返る
const BASE = 'https://example.co.jp/wp-json/wp/v2';

async function fetchAll(type) {
  const items = [];
  let total = 1;
  for (let page = 1; page <= total; page++) {
    const res = await fetch(`${BASE}/${type}?per_page=100&page=${page}&_embed`);
    if (!res.ok) throw new Error(`${type} ${page}: ${res.status}`);
    total = Number(res.headers.get('X-WP-TotalPages') ?? 1);
    items.push(...(await res.json()));
  }
  return items;
}

for (const type of ['posts', 'pages', 'categories', 'tags', 'media']) {
  await fs.writeFile(`export/${type}.json`, JSON.stringify(await fetchAll(type)));
}

APIに出てこないURLもあるので、次のものは別に足します。

• 一覧ページの2ページ目以降のURL。記事の数と1ページの件数から計算する
• Search Console（ページのインデックス登録のレポート）や、アクセス解析で見られているURL。外からリンクされている古いURLが見つかることがある
• 旧サイトが出していたサイトマップ。WordPress標準のものか、SEOのプラグインのものかで名前が違う

このブログで書き出した結果は、ページが86件、画像がメディアの一覧とアイキャッチを合わせて290件でした。この2つの一覧が、6段目の照合の正解の表になります。

2段目：CMSの入力欄を先に決め、本文のHTMLを整えてから取り込む

ヘッドレスCMSへの取り込みは、CMS側の入力欄（スキーマ）を決めてから行います。WordPressの記事は「題名・本文・アイキャッチ・カテゴリー・タグ・スラッグ・公開日」に分けて取り出せるので、CMSにも同じ単位の欄を用意し、スラッグの欄は必須にします。

取り込みの前に、本文のHTMLで次のものを片付けます。

取り込みは、CMSの書き込み用のAPIか取り込み機能を使います。書き込み用のAPIキーは取り込みの間だけ作り、終わったら消します。取り込んだら、CMSの件数が1段目の一覧の記事の数と一致するかを確かめます。

3段目：表のサイトは、旧サイトと同じURLの形で書き出す

URLを決めるのはCMSではなく、表のサイトの側です。CMSのスラッグの欄からページのパスを作り、末尾のスラッシュの有無も旧サイトに合わせます。Astroなら、設定でディレクトリの形（/slug/index.html）に書き出し、末尾のスラッシュを付ける側にそろえられます。

画像の置き場所は、次の2つから選びます。

このブログは前者で、旧サイトの画像を同じパスのまま置きました。画像検索や、ほかのサイトに貼られた画像のリンクを切らずに済むからです。ヘッドレスCMSを入れる場合も、旧い画像は前者、移行後の新しい画像はCMS、と分けるのが安全です。

公開の操作をしたときに表のサイトが作り直されるよう、CMSのWebhookと配信先のデプロイフックもここでつないでおきます。

4段目：301リダイレクトは、パスの変更とホスト名の統一で置き場所を分ける

URLが変わる所だけに301（恒久的な転送）を置き、パスの変更とホスト名の統一は別の場所に書きます。Googleは、301と308をどちらも「転送先を正式なURLとして扱う合図」として扱い、302はそうではないとしています。

このブログでの分け方は次のとおりです。

旧サイトマップの転送は見落としやすい項目です。検索エンジンは旧サイトの robots.txt に書かれていたサイトマップのURLを覚えているので、そのURLが見つからないページのまま放置されると、新しいページを見つけてもらうのに時間がかかります。

転送を書くときの注意を、公式の資料から拾っておきます。

• Pagesの転送の設定ファイルは、静的な転送が2,000件、動的な転送（* や :placeholder を使うもの）が100件までで、クエリ文字列での振り分けはできません。件数が多い場合は、関数（Functions）か、ダッシュボードで作る一括の転送のルールに分けます
• 無くなったページをまとめてトップページへ転送すると、Googleには「見つからないページ」と同じ扱い（ソフト404）にされることがあります。転送先は中身の近いページにします
• 転送は、Googleの案内では少なくとも1年、できるだけ長く残します

5段目：フォームは静的サイトでは動かないので、作り直して両方の受信まで確かめる

WordPressのフォームのプラグインはWordPressの上で動くため、静的サイトに移すと使えなくなります。お問い合わせや資料請求のフォームは、サーバーレスの関数（Pages Functions など）か、フォームの受付サービスで作り直します。なお、このブログの問い合わせページは会社サイトの窓口へのリンクにしているため、ここは一般的な手順として書きます。

作り直すときの確認項目です。

フォームは問い合わせの入口そのものなので、ここが確かめられるまでは公開しません。

6段目：ビルドのたびに、旧URLと画像の一覧を書き出し結果と照合する

公開の前の確認は、目で見て回るのではなく、1段目の一覧とビルド結果をスクリプトで突き合わせて行います。旧URLごとに「同じパスにページがある」か「301の転送先のページが実在する」かを判定し、どちらでもないものを不足として出します。

このブログではビルドの直後に照合のスクリプトを流し、ページ86件と画像290件の不足が0件になったことを確かめてから切り替えました。転送の行が書いてあっても転送先のページが無いもの、を不合格にしているのがこのスクリプトの要点です。照合の実装と、DNSを2段階で切り替えた経過は、移行作業そのものの記録に書いています。

ヘッドレスCMSを使う場合は、CMSで記事を足したり消したりすると書き出されるページが変わるので、この照合をビルドの手順に組み込み、不足があればビルドを失敗させる形にしておくと、公開後の取りこぼしも防げます。

7段目：公開した日と翌週以降に、検索の状況を確かめる

公開の当日は転送と表示の確認、翌週以降は検索の管理画面でのエラーの確認、と時期で分けて見ます。Googleの案内では、中くらいまでのサイトでも、検索結果のURLが新しいものに置き換わるまで数週間かかることがあります。

公開の当日に確かめること：

• 旧URLの一覧から代表的なものを curl -I で開き、200か301になること。www なしのURLが www 付きの同じパスへ1回で転送されること
• 開発中に入れていた noindex や、robots.txt でのクロールの拒否が残っていないこと
• 新しいサイトマップを送信し、読み込みが成功と表示されるのを見る
• IndexNowで、BingなどIndexNowに参加している検索エンジンに新しいURLを知らせること（このブログでは、鍵のファイルをサイトに置き、サイトマップに載った全URLをまとめて送れるようにしました）
• フォームから実際に1件送り、両方のメールが届くこと

翌週以降に確かめること：

• インデックス登録のレポートで、404や転送のエラーの件数が増えていないか
• 表示回数とクリック数が、移行の前と比べて大きく落ちていないか
• CMSで公開した記事が、表のサイトに反映されているか（Webhookとデプロイフックの配線）

移行の進み具合を確かめるチェックリスト

発注する側が制作者に進み具合を聞くときは、次の表の項目ごとに「確かめた方法」を答えてもらうと、抜けが見つかります。

株式会社bundlyzeではサイト・HPの制作を行っています。上の表は、このブログを旧WordPressから静的な構成へ切り替えた際に、実際に一つずつ確かめた項目がもとになっています。旧サイトからの移行も含めた作り直しは、ホームページ制作のご案内から相談できます。

手順の裏付けに使った資料（2026年10月3日時点）