はじめに
先日、PHP本体にPHP2Shellと呼ばれる重大な脆弱性が公表されました。
認証なしでサーバー上のコードを実行される恐れがあります。
深刻度はCVSS v4.0で9.2です。
米CISAは、実際に悪用が確認された脆弱性の一覧にも登録しています。
国内でも、国の機関や自治体を含む246組織が、停止や緊急対応を告知しました。
これは予防的な停止も含む数で、被害の件数ではありません。
IPAは、国内の攻撃被害の事例について「把握しておりません」としています。
その後、WordPressを静的サイトへ移すサービスの発表が相次ぎました。
10月24日から11月5日までの約2週間で、確認出来ただけでも6社あります。
WordPressからの移行を考える企業は、増えているようです。
（市場の統計は見つからなかったので、ここは発表の数から見た印象です。）
ただ、「PHPは危ないからWordPressをやめよう」と考えるのは少し早い気がしています。
そこで、まずPHPが本当に危ないのかを整理します。
そのうえで、WordPressの移行先を本気で考えてみました。
この記事の情報は2026年11月6日時点のものです。
料金や各社の対応は変わることがあります。
検討するときは公式の情報を確認してください。
TL;DR
- 無条件で勧められる移行先はありませんでした
- どこへ移るにしても、まず今のWordPressのプラグインとPHPを整理するのが先です
- 移行しても保守は消えません。脆弱性対応が、ベンダーの障害や値上げ、依存関係の更新に変わるだけです
- 月額の差より効くのは、フロントを保守する人がいるか、予約公開や承認が要るか、撤退するときに原本を取り戻せるかの3つでした
| サイト | 第一候補 | 次点 |
|---|---|---|
| 小規模コーポレート（更新が年数回以下） | 素のHTML | WordPressを削って残す |
| 小規模コーポレート（更新が月数回） | WordPressを編集専用に残して静的化 | 予算があればStudio、Squarespace、Wix |
| 中規模コーポレート | WordPress + 保守契約かマネージド | Kuroco、microCMS + 静的フロント |
| オウンドメディア | WordPressのまま | microCMS、Kuroco + 静的フロント |
| ブログ（開発者あり） | Astro + Cloudflare + Git系CMS | EmDash（検索が重要でなければ） |
| ブログ（開発者なし） | WordPress + Simply Static Studio | Ghost(Pro)（英語の管理画面でよければ） |
PHPが危険なわけではない
PHPという言語が特別に危険なわけではありません。
同じような脆弱性は、ほかの言語や実行環境でも起きています。
| 言語・実行環境 | 脆弱性 | 時期 | 内容 |
|---|---|---|---|
| PHP | PHP2Shell | 2026年10月 | 認証なしでリモートコード実行（CVSS 9.2） |
| JavaScript（React） | CVE-2025-55182 | 2025年12月 | 認証なしでリモートコード実行（CVSS 10.0） |
| JavaScript（Node.js） | CVE-2026-111497 | 2026年10月 | 細工した圧縮データでリモートコード実行の恐れ（High） |
| Java（Log4j） | Log4Shell | 2021年12月 | 認証なしでリモートコード実行 |
Reactの脆弱性はCVSSが10.0で、PHP2Shellに劣らず深刻です。
（CVSSは版によって算出方法が違うので、数字を単純には比べられません。）
Node.jsの修正は、PHP2Shellと同じ10月21日に公開されています。
Node.jsの件は、アプリが攻撃者の圧縮データを展開する場合に限られます。
PHP2Shellと同列には語れません。
ただ、言語や実行環境に重大な欠陥が見つかること自体は珍しくありません。
それでもWordPressが危ないと言われやすいのは、使われ方の問題だと思います。
- 利用者が多い。全サイトの39.5%が使っていて、狙う側の効率がいい
- 公開サーバーで、PHPとデータベースと管理画面が常に動いている
- 第三者が作ったプラグインが、本体と同じ権限で動く。2025年の新規脆弱性の91%はプラグインでした
- 古いPHPのまま動いているサイトが多い。公式の統計では約32.6%がPHP 8.2未満です
JavaScript系の構成はリスクを減らしやすい
一方で、JavaScript系の構成は、WordPressより攻撃の入口を減らしやすいです。
言語の差というより、構成の差です。
理由は大きく3つあると思っています。
リクエストのたびに動かさなくて済む
Astroなどで事前にHTMLを作っておけば、アクセスがあってもサーバーでJavaScriptは動きません。
動いていないものは攻撃出来ません。
先ほどのReactの脆弱性でも、サーバーを使わないアプリは影響を受けないと公式に書かれています。
同じJavaScriptでも、サーバーで動かすかどうかで結果が変わるわけです。
ファイルを置かれても実行されにくい
PHPの一般的な構成では、公開フォルダの .php ファイルがURLからそのまま実行されます。
アップロード機能の不備などで、悪意のあるファイルを置かれることがあります。
するとWebシェルとしてサーバーを操作される恐れがあります。
一方、Node.jsのアプリは、基本的に起動時に読み込んだコードだけが動きます。
Cloudflare Workersなら、実行中に書いたファイルはリクエストをまたいで残りません。
サーバーの管理を手放しやすい
個人的には、実務で一番効くのはこれだと思っています。
WordPressはPHPとデータベースを常に動かします。
なので、レンタルサーバー、EC2、自社サーバーのようなサーバーの上で動かすのが基本です。
一方、Cloudflare Workersの公式の対応言語はJavaScript、TypeScript、Python、Rustです。
PHPは入っていません。
JavaScript系なら、サーバー自体を持たないサービスを選びやすいわけです。
置き場所によって、自分で見る範囲はかなり変わります。
| 置き場所 | OS | 実行環境（PHPなど） | アプリと依存関係 |
|---|---|---|---|
| 自社サーバー、EC2 | 自分 | 自分 | 自分 |
| レンタルサーバー | 事業者 | 事業者（版の選択は自分） | 自分 |
| マネージドWordPress | 事業者 | 事業者 | 一部は事業者 |
| Cloudflare Workers、静的ホスティング | 事業者 | 事業者 | 自分 |
たとえばEC2は、OSの更新やセキュリティパッチも利用者の責任です。
PHP2Shellのようなことが起きると、自分でPHPを更新しないといけません。
終わるまでサービスを止めるかどうかも、自分で判断します。
Cloudflare WorkersならOSも実行環境も自分では持ちません。
V8の修正も、通常24時間以内にCloudflare側で本番へ反映されるそうです。
ただ、これにも弱点はあります。
事業者に障害が起きると、利用者は待つしかありません。
2025年11月には、Cloudflareの大規模な障害で、CDNなどに5xxエラーが出ました。
Astroも今はCloudflare傘下なので、1社に寄りすぎないかは考えておきたいところです。
なお、WorkersはJavaScriptだけのものではありません。
レンタルサーバーなら、WordPressでもOSやPHPは事業者が見てくれます。
「WordPressはサーバー管理が大変」というのは、特にEC2や自社サーバーの場合の話です。
ただしリスクが消えるわけではない
JavaScript系でもリスクが無くなるわけではありません。
一番大きいのはnpmの依存関係です。
2026年3月には、定番のライブラリaxiosが乗っ取られました。
インストールしただけでマルウェアが動く版が公開されました。
公開サイトが静的でも、ビルドする環境は攻撃の対象になります。
Astro自体にも、直近12か月で40件のセキュリティアドバイザリが出ています。
件数が多いから危ないとは言えません。
ただ、「JavaScriptにすれば保守は要らない」わけでもありません。
逆に、PHPのサイトでも静的なHTMLにしてしまえば、公開サーバーでPHPは動きません。
共用サーバーならPHPの更新も事業者が行ってくれます。
PHP2Shellでも、エックスサーバーはPHP 5.6〜8.5に修正を適用したと報告されています。
なので、言語よりも構成とサーバーの選び方のほうが重要です。
| 構成 | アクセスのたびに公開側で動くもの | 主なリスク |
|---|---|---|
| WordPress | PHP、WordPress、プラグイン、データベース | PHP・本体・プラグインの脆弱性 |
| Node.jsでサーバー描画 | Node.js、フレームワーク | 実行環境・フレームワークの脆弱性 |
| Cloudflare Workers + CMS | 自分のコードと依存関係 | コードと依存関係の脆弱性 |
| 静的サイト（Astro、素のHTMLなど） | WebサーバーやCDN | ビルド環境の依存関係、アカウントの乗っ取り |
なので、「PHPかJavaScriptか」で選ぶのはあまり意味がなさそうです。
この記事では言語ではなく、サイトの構成と、保守を誰が担当するかで移行先を比べていきます。
なぜ今、移行を考えるのか
PHP2Shell以外にも、移行を考えるきっかけはいくつか重なっています。
- 更新の頻度が上がっています。WordPress 7.1の公開から約10週間で、セキュリティリリースが4回ありました。7.1.2はcriticalで、4.7系までバックポートされています
- PHPのサポート終了が近いです。PHP 8.2のセキュリティサポートは2026年12月31日で終わります。定番のContact Form 7も、最新版はPHP 8.3以上が必要です
- プラグインの乗っ取りも起きています。2026年4月には、売却された30超のプラグインに、買い手がバックドアを仕込む事件がありました
移行するかどうかに関係なく、PHPの更新とフォームの見直しは避けられません。
一方で、よく言われる「WordPressのシェアが落ちている」は、少し注意が必要です。
全サイトに占める割合は、2026年1月の43.0%から11月の39.5%へ下がりました。
3.5ポイントの低下です。
ただし、同じ期間に増えたのは「CMSなし」の3.6ポイントです。
Shopifyは0.3ポイント増、Wixは横ばいでした。
競合に流れたとは言えず、原因は分かっていません。
とはいえ、WordPressの開発は続いています。
7.2は12月8日に予定されています。
公式プラグインは約7.4万本あり、本体の日本語訳は100%です。
この強みを捨てるだけの理由があるのかは、冷静に見たほうが良いかなと思います。
どう比べたか
想定は、編集者3名前後で、非エンジニアを含む小〜中規模のサイトです。
| 項目 | 内容 |
|---|---|
| 調査日 | 2026年11月6日 |
| 対象のサイト | 小規模コーポレート、中規模コーポレート、オウンドメディア、ブログ |
| 比べた項目 | 費用、非エンジニアの更新、WordPressからの移行、データの持ち出し、保守に要る人 |
| 為替 | 1 USD = 158.46円 |
| 情報源 | 公式の料金ページ、ドキュメント、発表を優先 |
どの候補も、管理画面を実際に使って比べたわけではありません。
実際に試したのはPagefindの日本語検索だけで、ほかは公式の情報を読んだ結果です。
工数も測っていないので、総コストの話は推測を含みます。
候補一覧
19候補を並べました。
年額は1サイトの定価の目安で、開発費と人件費は含みません。税の扱いはサービスごとに違います。
| 候補 | 年額の目安 | 非エンジニアの更新 | WordPressからの移行 | 持ち出し | 保守に要る人 |
|---|---|---|---|---|---|
| WordPress + ハードニング | 約1.3万円 | 現状維持 | 不要 | 高い | 更新担当 |
| WordPress + Simply Static Pro | 約2.9万円 | 書き出しの工程が増える | プラグイン追加 | 高い | 更新担当 + 導入者 |
| 素のHTML（移行代行） | 初期3.3〜20万円 + 月0〜約2.5万円 | 自力では不可。依頼かAI | 公開ページの書き出し | 最も高い | 更新の依頼先 |
| マネージド（Kinsta、WP Engine） | 約5.3〜6.7万円 | 現状維持 | 無料移行あり | 高い | 更新担当 |
| ヘッドレスWordPress | 約5.1万円 + 開発費 | 投稿画面は同じ | フロントを新規開発 | 高い | 開発者 |
| ClassicPress | 約1.3万円 | クラシックエディタ | 公式プラグイン | 戻せる | 更新担当 + 検証者 |
| Studio | 約4.8万円 | 日本語。承認の仕組みは見つからず | XML、10MB、下書き | CMSは書き出せない | 更新担当 |
| Wix | 約2.8万円 + 税 | 日本語対応を明記 | 1回5,000記事 | ブログは書き出せない | 更新担当 |
| Squarespace | 約2.5万円 | 日本語画面は段階導入中 | 公式の取り込み | WXR、ブログ1本 | 更新担当 |
| Webflow | 約8.6〜10.5万円 | 英語。承認は月$2,500から | CSV経由 | CSV | 制作者 |
| Ghost(Pro) | 約5.5万円 | 管理画面は英語のみ | 2,500記事まで | JSONなど | 更新担当 |
| MovableType.net | 約3.9〜7.7万円 | ワークフローは上位プラン | WordPress形式 | 未確認 | 更新担当 |
| はてなCMS | 非公開 | 3段階の権限 | URLを引き継げる | 画像を含まず | 更新担当 |
| note pro | 約97万円 | 日本語 | WXR | 一部欠ける | 更新担当 |
| microCMS | 約6.5万円 + フロント | 日本語。予約とレビューあり | APIスクリプト | APIとCSV | 開発者 |
| Kuroco | 無料枠前後（試算）+ フロント | 日本語。多段承認 | WXRインポーター | CSVと画像ZIP | 開発者 |
| Astro + Cloudflare + Git系CMS | 0〜約4.6万円 | 予約投稿なし | Markdown化 | 最も高い | 開発者 |
| baserCMS | 約1.2万円〜 | 日本語が原語 | 公式の経路は確認出来ず | 自前のDB | 運用者 |
| EmDash | 約0.95万円 | 日本語はほぼ完了 | Exporterが手厚い | Portable Textは要変換 | 開発者 |
グループごとの評価
WordPressに残る
地味ですが、まず検討すべきはここだと思います。
公式のハードニング手順どおり、不要なプラグインを消し、2段階認証を入れ、バックアップを取る。
これが全サイトの出発点です。
Simply Staticは、WordPressを編集用に残して公開面だけを静的にする方法です。
効果を決めるのは、元のWordPressをBasic認証やIP制限で閉じられるかどうかです。
公開したままなら、攻撃の入口は残ります。
ヘッドレスWordPressは、WordPressの保守にフロントの保守が足されます。
小規模サイトには過剰かなと思います。
WP2Staticは2024年2月から更新が止まっています。
新規で選ぶのは避けたほうが良いと思います。
素のHTML
公開サーバーにHTML、CSS、画像だけを置く形です。
CMSもPHPもデータベースも持ちません。
Simply Staticとの違いは、WordPressを手放すところです。
はじめに書いたとおり、代行サービスの発表が相次いでいます。
検索で見つけた範囲なので、全数ではありません。
| 会社（サービス） | 発表 | 10ページ前後の初期費用 | 月額 | 移行後の更新 |
|---|---|---|---|---|
| セルフプラス | 9/9開始 | 20万円（税別） | 任意5万円 | Claude Code、またはEmDash |
| オサラロック | 10/24 | 49,800円（税込） | 記載なし | 記載なし |
| みらいスタジオ（ホットケル） | 10/26 | 15万円〜（税抜） | 9,800円〜 | AIの下書きを担当者が承認 |
| アプキー | 10/26 | 33,000円〜（税込） | 記載なし | 記載なし |
| VIOLET（WordPress卒業パック） | 10/26 | 20万円（税別） | 任意1万円〜 | microCMS |
| HuX（ひとことWeb） | 10/27 | 10万円〜 + 移行費（税抜） | 別途 | AIとの会話で作成 |
| アドバンプレス | 11/5 | 非公開 | 非公開 | 「案内」のみ |
中身を見ると、大きく3つの型に分かれます。
| 型 | 更新の方法 | 向くサイト | 弱点 |
|---|---|---|---|
| 凍結 | しない、または都度依頼 | 更新停止、会社案内 | 依頼先が消えると直せない |
| 依頼・AI | 依頼かAIで修正し、人が確認 | 更新が月数回まで | 新しい運用で実績が薄い |
| 静的 + CMS | microCMSやEmDashで編集 | 自社で更新する会社 | もはやヘッドレスの一種 |
CMSの保守が要らない代わりに、自分では更新出来なくなります。
更新が年数回以下なら、これが一番割に合うと思います。
ただし、各社とも万能とは言っていません。
頻繁に更新するサイトや、会員、予約、決済があるサイトは、対象外か不向きとされています。
アプキーは、旧WordPressの公開停止とサーバーの管理は引き続き必要と書いています。
旧環境を残したままでは意味が薄いです。
ドメイン、DNS、メール認証の管理も残ります。
移行後の品質については、移行済み117サイトのうち34サイトで不具合を確認したという調査もあります。
ただ、無作為抽出ではなく、移行が原因とも示されていません。
急いでHTMLにすべきかどうかも、落ち着いて考えたほうが良いと思います。
レンタルサーバーなら、まず事業者の対応を確認するのが先です。
緊急性が高いのは、自分で管理するサーバーで古いPHPを更新出来ない場合だと思います。
SaaS型サイトビルダー
日本語で楽に使える反面、他のサービスへ移りにくいです。
Studioは日本語の担当者だけで完結しやすいのですが、CMSのデータを書き出せません。
301リダイレクトもBusinessプランからです。
2026年10月には不正アクセスを公表しました。
確認時点では「取得されたものとみなして」対応を進めています。
新規で選ぶなら、調査の結果を見てからにしたいところです。
Wixもブログ記事を他のサービスへ書き出せません。
Webflowは画面が英語で、承認の機能には高額なプランが要ります。
日本の非エンジニア体制には勧めにくいです。
Ghost(Pro)は移行と持ち出しが最も整っていますが、管理画面は英語のみです。
「日本語で使いやすい」と「データを持ち出しやすい」は、同時に満たしにくいようです。
ヘッドレスCMS
国内ならmicroCMSとKurocoに絞られました。
| サービス | 特徴 | 注意点 |
|---|---|---|
| microCMS | データはすべて国内に保存、予約とレビューは全プラン | 権限管理はBusiness（¥75,000〜）から |
| Kuroco | WXRインポーター、多段承認 | 従量制で、費用は試算の域を出ない |
| Contentful | 2026年にSalesforceが買収 | Freeは商用不可で、実質$300/月から |
| Hygraph | 海外のヘッドレスCMS | 本文を検索出来ない、予約公開はEnterpriseのみ |
小規模サイトでは、月額の差より、フロントの初期開発と保守の費用のほうが大きいと思います。
サービスの終了もあります。
Newtは2026年11月24日に終了予定で、終了後はデータが削除されます。
静的サイト + Git系CMS
AstroとCloudflareの組み合わせは、費用も持ち出しやすさも優秀です。
Cloudflareは静的アセットの配信が無料で無制限です。
ただ、非エンジニアの運用には壁があります。
- Decap、Keystatic、TinaCMS、Pages CMSは、どれも予約投稿に標準で対応していません
- 保存しても即公開にならず、誤字の修正でもビルドを待ちます
- VercelのHobbyプランは商用利用出来ません
一番地味に困りそうなのはDNSです。
メールとドメインをレンタルサーバーでまとめて管理している会社もあります。
その場合、ネームサーバーの変更が実質の移行作業になります。
セルフホストのCMS
WordPressより楽になる候補は見つかりませんでした。
| 候補 | 気になった点 |
|---|---|
| Strapi | 予約公開は有料プラン（$45/月〜） |
| Directus | 無償は年商$5M未満かつ50人未満 |
| Payload | Figmaが買収。Payload Cloudは新規停止 |
| Craft CMS | 移行ツールは手厚いが、本体は有料でLaravelへ移行中 |
| baserCMS | 日本語が原語で共用サーバーで動く。公式の移行経路は確認出来ず |
Node.js系はVPSが必要になり、OSの管理も増えます。
保守の引き継ぎを重視するなら、日本で次の担当者を探しやすいかも見ておくと良いと思います。
EmDashはどうか
自分は今、EmDashでブログを試作しています。
評価が甘くならないよう、この節は公開情報だけで書きました。
EmDashは、Cloudflareが2026年4月に公開した、AstroベースのCMSです。
WordPressの「精神的な後継」を掲げています。
Exporterを使えば、ACF、Yoast、Rank Math、コメント、メニューまで移せます。
費用も年1万円ほどです。
低い月額とデータ移行を両立している候補は、ほかに見当たりませんでした。
それでも、今の判定は「開発者がいる新規の小規模サイト向け」です。
| 気になる点 | 内容 |
|---|---|
| 日本語検索 | 既定では日本語を分かち書きしない。trigramに変えられるが、3文字未満は検索出来ない |
| Workers Free | 1サイトの報告だが、管理操作の約1%がCPU超過で失敗。実質$5/月を見込む |
| 実績 | 稼働サイト数の発表は無い。Cloudflareのブログは移行済みだが、D1ではなく、目玉のサンドボックスも使えない構成 |
| 継続性 | Project LeadはCloudflare所属で財団は無い |
| エコシステム | レジストリは12件。WordPressは約7.4万本 |
WordPress共同創業者のMullenweg氏は「プラグインのセキュリティはCloudflare上でしか機能しない」と批判しました。
今はNode.jsでも動きますが、CPUなどの制限は強制されません。
「動くけれど、最も良い形はCloudflare上」というのが実態かなと思います。
一方、国内ではセルフプラスが移行サービスのCMS付きプランに採用しています。
少しずつ広がる気配はあります。
実際の納品例までは確認出来ませんでした。
離れても保守は消えない
調べていて、一番印象に残ったのがこれです。
2026年に起きたことを並べると、移行で問題が消えるのではなく、形が変わるだけだと分かります。
| 候補 | 2026年の出来事 | 利用者に残る作業 |
|---|---|---|
| PHP | PHP2Shell | PHPの更新、事業者の対応の確認 |
| Studio | 不正アクセスを公表 | パスワード変更、APIキーの再発行、報告の判断 |
| Webflow | 約14時間の障害と料金の再編 | 待つこと、プランの見直し |
| Newt | サービス終了 | 終了前の全移行 |
| Contentful | Salesforceが買収 | 方針の監視 |
| Directus | v12で独自ライセンスへ | ライセンスと会社規模の確認 |
| Astro | 12か月で40件のアドバイザリ | 依存関係の更新 |
アドバイザリの件数は安全性の順位にはなりません。
どの方法でも、パッチを当てる担当者か、直るのを待つ判断が必要です。
WordPressは自分で直す必要があり、SaaSは事業者が直すのを待つしかありません。
どちらが良いかは、お客さんと相談して決めるのが良いかなと思います。
どこへ移っても発生する作業
工数を決めるのはサイトの作り
同じ移行先でも、サイトの作りで工数は大きく変わります。
「投稿とテーマだけのブログ」と「Elementor、ACF、複数のフォームを使う企業サイト」では別物です。
- Elementorのレイアウトは非公開メタのJSONに入っていて、WordPressサイトの31.5%が併用しています
- 定番のwordpress-export-to-markdownが読む投稿メタは
_thumbnail_idだけで、YoastやACFは運びません - 661記事をAstroへ移した事例では、304記事の整形修正と973件の301が必要でした
移行先を比べる前に、自分のサイトがどちらなのかを見たほうが良いと思います。
リダイレクトの既定値が罠
Googleは、リダイレクトを「generally at least 1 year」維持するよう求めています。
ところが、標準の機能は301にならないものが多いです。
| 実装 | 既定の挙動 | 上限 |
|---|---|---|
| Hugoのaliases | meta refresh | - |
| Astroのredirects（静的） | meta refresh | - |
| Cloudflareの_redirects | 302 | 静的2,000 + 動的100 |
| VercelのBulk Redirects | 307 | Proで1,000 |
一番楽なのは、URLを変えないことです。
投稿名ベースのパーマリンクなら、同じパスを再現すれば301自体が要りません。
フォームと検索
フォームは、国産のformrunが月¥2,980からです。
Workerで自作するならTurnstileは無料です。
非エンジニアが項目を変えるならSaaSのほうが向いています。
SaaSに問い合わせを保存すると、事故のときの報告の判断が利用者に残ります。
通知だけ受けて、保存期間を短くしておくと安心です。
静的サイトの検索でよく使われるPagefindは、1.6.0を日本語の17ページで試しました。
語単位では検索出来ますが、次のような癖がありました。
| 検索語 | 結果 |
|---|---|
| サーバー | 「サーバ」を逃す |
| お問合せ | 「お問い合わせ」に当たらない |
| ＵＲＬ | 半角のURLと別扱い |
| 京都 | 「東京都庁」に当たる |
固有名詞を探す企業サイトなら十分です。
検索が主な導線のメディアでは対策が要りそうです。
法律
総務省は「企業等のホームページ運営・個人ブログ」を外部送信規律の対象外としています。
普通の企業サイトなら対象外です。
オウンドメディアは内容によるので、個別に確認してください。
結局どれを選ぶか
上から順に判断すると、候補はかなり絞れます。
残留は、放置の言い訳にはなりません。
更新の担当がいなくて保守費も出せないWordPressは、SaaSより危険です。
高影響の脆弱性の約半数は24時間以内に悪用されるという報告もあります。
おわりに
調べる前は「どこへ移るか」が問いだと思っていました。
調べ終わると、「保守の責任をどこへ置くか」に変わっていました。
どの移行先を選ぶとしても、次の4つは無駄になりません。
- URLの対応表
- 記事の原本
- SEOメタの写し
- フォームの置き場所の整理
これを手元に揃えておくと、サービスの終了や事故が起きたときの選択肢が増えます。
移行するか迷っているなら、まずここからかなと思います。
次の記事では、EmDashでブログを作ってみた話を書きます。
この記事の条件でいう「開発者がいる新規の小規模サイト」の例です。
少しでも皆さんの移行先選びの判断材料になれば幸いです。