WordPressからSanityへ移行する方法｜REST API・画像・SEOを安全に移す手順

← Blogに戻る

WordPressからSanityへの移行は、ページをコピーするのではなく『コンテンツを構造化し直す』作業です

WordPressからSanityへ移行する場合、単純な記事コピーでは終わりません。SanityはWebページそのものではなく、記事、著者、カテゴリ、FAQ、CTA、商品情報などを構造化されたデータとしてContent Lakeに保存し、WebやアプリからAPIで利用するヘッドレスCMSです。

そのため移行では、①WordPressからデータを取り出す、②Sanity側のスキーマを設計する、③記事・固定ページ・カテゴリ・タグ・著者・画像を変換する、④HTMLやブロックをPortable Textへ変換する、⑤URL・SEO・フォーム・計測を新しいフロントエンドへ再実装する、という流れになります。CMS変更と同時に情報設計を整理できる点が、Sanity移行の大きな特徴です。

Sanity公式の移行方法｜WordPress REST APIからMigration CLIで取り込む

Sanity公式のWordPress移行コースでは、WordPressが標準で持つREST APIを使って既存コンテンツを取得し、Sanity CLIのMigration機能でContent Lakeへ書き込む方法が案内されています。WordPressのREST APIは通常 `/wp-json/wp/v2` からアクセスでき、posts、pages、categories、tags、usersなどを種類ごとに取得できます。

Sanity側ではMigrationスクリプトを作成し、WordPressのAPIをページングしながら読み込み、`createOrReplace` などのmutationへ変換します。公式コースでは、画像のアップロード、HTMLからPortable Textへの変換、WordPress blocksの変換、参照関係の再構築まで扱われています。

大量記事でも再実行可能なスクリプトにできるのが利点です。

ステップ1｜最初に『何を構造化したいか』を決める

WordPressでは本文エディタの中へ見出し、画像、CTA、FAQ、表、装飾、ショートコードなどをまとめて入れているサイトが多くあります。Sanityへ移行する際は、そのまま長い本文として移すこともできますが、将来AIや別チャネルで再利用したい情報は独立フィールドへ分ける方が有利です。

例えば記事なら、タイトル、要約、著者、カテゴリ、本文、FAQ、CTA、関連サービス、監修情報、更新履歴を別々に持てます。商品や事例も同様です。

移行時に『WordPressのデータ構造をそのまま再現する』のではなく、『今後どう使いたいか』を基準にSanity schemaを決めると、移行後の価値が大きくなります。

ステップ2｜WordPress REST APIで件数と取得可能なデータを確認する

次にWordPress REST APIへアクセスし、移行対象データが取得できるかを確認します。Sanity公式では、投稿件数をレスポンスヘッダーで確認しながら、1ページあたりの取得件数を指定して順番に読み込む方法を紹介しています。

セキュリティプラグインなどでREST APIが制限されている場合は、移行用にローカル環境やステージングへWordPressのデータベースを複製して取得する方法も考えられます。標準投稿だけでなく、カスタム投稿タイプ、カスタムフィールド、ACF、独自タクソノミーなどを使っている場合は、そのデータがREST APIへ公開されているかを確認します。

取得できないデータがあれば、XML、WPGraphQL、DBエクスポートなど別経路を検討します。

ステップ3｜Sanity schemaを先に作り、WordPressの各データ型との対応表を作る

Sanity公式の移行例では、WordPressのcategoriesをSanityのcategory、postsをpost、pagesをpage、tagsをtag、usersをauthorへ対応させます。ただし企業サイトでは、この1対1対応だけでなく整理し直す価値があります。

例えばWordPressの固定ページとして保存されている導入事例をSanityではcaseStudyへ、LPをlandingPageへ、FAQを独立したfaqへ分けることができます。移行前に『旧データ型→新スキーマ』の対応表を作り、必須フィールド、参照関係、slug、画像、公開日時を定義します。

ここが曖昧なままスクリプトを書くと、取り込み後に大量の手修正が必要になります。

ステップ4｜Migration CLIでdry-runしてから本番データへ書き込む

SanityのMigration CLIは、移行スクリプトをdry-runで確認してから実データへ反映できます。公式例では `sanity migration create` で移行スクリプトを作り、WordPress REST APIから取得したデータをSanity documentへ変換し、dry-runでmutation内容を確認した後に本番実行します。

大量データではCLI側がmutationをtransactionへまとめるため、API制限を意識した処理もしやすくなります。重要なのは、最初から本番datasetへ全件書き込まないことです。

数件のテスト、全件dry-run、検証用dataset、本番datasetという順番にすると、schemaの間違いや文字化け、参照ミスを早い段階で見つけられます。

ステップ5｜HTML・Gutenbergブロック・ショートコードをPortable Textへ変換する

WordPress本文はHTMLやGutenbergのblock markupとして保持されています。一方、SanityではPortable Textを使うと、見出し、段落、リンク、画像、独自オブジェクトを構造化して持てます。

Sanity公式コースでも、HTMLからPortable Textへの変換とWordPress blocksからPortable Textへの変換が独立した工程として扱われています。ここで注意したいのがショートコードやページビルダー独自記法です。

Contact Form 7、Elementor、Visual Composerなどのコードが本文へ混ざっている場合、そのままでは表示できません。移行前に独自記法を検出し、『削除』『通常テキストへ変換』『Sanityの独自blockへ置換』のどれにするかを決めます。

ステップ6｜画像はURL参照のままにせず、Sanity Assetsへ移す

WordPressの画像を旧サーバーURLのまま参照すると、WordPress環境を停止したときに画像が消えます。そのため本文中画像、アイキャッチ、OGP用画像などをSanity Assetsへアップロードし、Sanity documentからasset referenceとして参照する構成へ変えるのが基本です。

Sanity公式の移行コースでもassetsの取り込みが扱われています。移行時には画像ファイルだけでなく、alt、caption、元記事との対応、ファイル名、重複画像の扱いも確認します。

数千枚ある場合は、同じ画像を何度もアップロードしないよう、旧attachment IDと新asset IDの対応表を保持して再利用すると効率的です。

ステップ7｜URL・301・canonicalをCMS移行とは別工程で設計する

Sanityはコンテンツ管理を担当するCMSであり、実際のURL構造はNext.js、Astro、Cloudflare Workersなど表示側のアプリケーションで決めます。そのためWordPressのパーマリンクが自動的に引き継がれるわけではありません。

検索流入を守るには、現在インデックスされているURLを一覧化し、新サイトで同じURLを再現できるか確認します。変更するURLには旧URLから新URLへの301リダイレクトを設定し、canonicalも新URLへ揃えます。

カテゴリ、タグ、著者アーカイブ、年月アーカイブなど、WordPressが自動生成していたURLを新サイトで残すのか統合するのかも決めます。不要URLを大量に404へする前に、検索流入・被リンク・内部リンクの有無を確認します。

ステップ8｜SEOプラグインの値を『データ』として必要なものだけ移す

Yoast SEO、Rank Math、All in One SEOなどを使っている場合、meta title、description、canonical、noindexなどの値が独自フィールドに保存されています。Sanityへ移す際は、SEOプラグインそのものを再現する必要はありません。

個別設定された値のうち新サイトでも必要なものだけを抽出し、Sanity schemaのseoオブジェクト等へ保存します。一方、サイト名を付加したtitleやOGP画像のfallbackなど、ルールで生成できるものはフロントエンド側で共通化した方が保守しやすくなります。

移行前後で代表ページのHTMLを比較し、title、description、canonical、robots、OGP、JSON-LDが意図通り出ているか確認します。

ステップ9｜フォーム・検索・会員・ECはSanityの外へ分離して考える

Sanityはコンテンツ基盤なので、WordPressプラグインで実現していたフォーム、サイト内検索、会員機能、予約、ECをそのまま置き換える製品ではありません。問い合わせフォームならフォームSaaSや独自API、検索ならAlgolia等、認証ならAuthサービス、ECならShopifyなど、用途ごとに適したサービスを組み合わせます。

これは一見システムが増えるように見えますが、CMSと決済、CMSと認証などを分離することで、コンテンツ更新が重要機能へ影響しにくくなります。移行前にWordPressプラグイン一覧を作り、『プラグイン名』ではなく『何の業務を担当しているか』へ翻訳して、新しい担当システムを決めます。

ステップ10｜AI・自動化を前提にするなら、書き込み権限と承認フローを先に設計する

Sanityへ移行する企業が増える理由の一つは、構造化コンテンツをAPIで扱いやすいことです。ただしAIエージェントや自動投稿システムへ強い権限をそのまま渡すと、誤更新の影響も大きくなります。

記事生成、要約、タグ付け、FAQ生成、翻訳、更新提案など、AIが行う処理を分け、どこまでdraftへ書き込めるか、誰がpublishするかを決めます。CATARIVEのように『AIが下準備→品質ゲート→人または決定論的Publisherが公開』という分離にすると、CMSがAPI対応している利点を活かしやすくなります。

Sanity移行は単なるCMS変更ではなく、コンテンツ業務そのものを再設計する機会になります。

切り替え前後｜GA4・GTM・Search Console・フォームCVを同時に検証する

Sanity移行ではフロントエンドも変わることが多いため、計測タグの再実装が必要です。GA4、GTM、広告コンバージョン、Meta Pixel、ヒートマップ、Cookie同意管理、チャットなどを一覧化し、新サイトで発火するか確認します。

公開前に主要イベントをステージングでテストし、公開直後はGA4リアルタイム、GTM Preview、フォーム送信、Search Consoleを確認します。サイトマップURLやrobots.txtも新しいフロントエンドで生成する必要があります。

CMSデータが正しく移っていても、計測が切れてしまえば移行後の成果判断ができません。コンテンツ移行、SEO移行、計測移行を3本の並行タスクとして扱う方が安全です。

Sanity移行が向いている会社・別のCMSを選んだ方がよい会社

Sanityが向いているのは、Webだけでなくアプリ、SNS、メール、AIなど複数チャネルへ同じ情報を再利用したい会社、コンテンツモデルを自社に合わせて設計したい会社、開発チームや制作パートナーと継続的に改善できる会社です。一方、担当者だけでページデザインまで自由に変更したい、開発者をほとんど確保できない、既存WordPressプラグイン中心の運用をそのまま維持したい場合は、StudioやEmDashなど別の選択肢が適する可能性があります。

Sanityの価値は管理画面が新しいことではなく、『コンテンツをサイトから独立させ、再利用できるデータ資産にする』点にあります。

FAQ｜WordPressからSanityへの移行でよくある質問

Q. WordPressの記事は自動でSanityへ移せますか。A. Sanity公式はWordPress REST APIとMigration CLIを使った移行方法を公開しています。

標準投稿だけなら自動化しやすい一方、独自フィールドやプラグイン依存データは追加変換が必要です。Q. Gutenbergの記事は移せますか。

A. 可能ですが、WordPress block markupをPortable Textへどう変換するかの設計が必要です。Sanity公式コースでも変換工程が扱われています。

Q. URLはSanityが決めますか。A. いいえ。

URLは表示側のWebアプリで決まるため、旧WordPressのURLを維持するか、301するかを別途設計します。Q. WordPressを停止したら画像は消えませんか。

A. 旧URLを参照したままだと消えるため、Sanity Assetsなど新しい配信先へ画像を移す必要があります。Q. 移行後はWordPressをすぐ削除してよいですか。

A. 検証期間を設け、URL、画像、フォーム、検索流入、計測を確認してから停止する方が安全です。

まとめ｜Sanity移行の価値は、WordPressを捨てることではなくコンテンツを再利用可能にすること

WordPressからSanityへの移行は、REST APIでデータを取り出し、Migration CLIで書き込めば終わる作業ではありません。旧サイトのコンテンツを棚卸しし、新しいschemaへ再設計し、HTMLやブロックをPortable Textへ変換し、画像を移し、URL・SEO・フォーム・計測を新しいフロントエンドへ繋ぎ直す必要があります。

その分、移行後は記事や事例をWebページだけに閉じ込めず、SNS、メール、アプリ、AIなどへ再利用しやすくなります。CMS移行を『サイトの引っ越し』ではなく『コンテンツ運用基盤の再設計』として進めることが、Sanityを選ぶ意味です。

無料・約30秒

あなたのサイト、WordPressをやめられる？

URLを入れるだけで、移行難易度・デザインやSEOの維持しやすさ・推奨構成・概算費用を自動で簡易診断します。

↗