Framer の代替案: Webflow、WordPress、Astro か継続か

異なるビジュアルCMSワークフローのためにWebflowを選択してください。編集とプラグイン主導の作業のために自ホストWordPressを選択し、チームがフロントエンドとインフラストラクチャを所有したいときはヘッドレスCMS付きのAstroを選択してください。Framerでのデザインとパブリッシングワークフローがすでに要件に合致している場合、Framerに留まることは有効な選択肢です。置き換えを選択する前に定期的なパブリッシングタスクをテストしてください。独立したホスティングが要件の場合は、エクスポートルートも検証してください。

変更する必要があるもの別のショートリスト

デザインの自由度とマネージドパブリッシングがすでに仕事に適合している場合はFramerに留まってください。
チームが異なるビジュアルCMSワークフローを求めている場合はWebflowを選択してください。
編集プロセスとプラグインが要件を駆動している場合は自ホストWordPressを選択してください。
フロントエンドとインフラストラクチャを所有する場合はAstroとヘッドレスCMSを選択してください。

各ルートは異なる質問に答え、各ルートは誰かに異なる作業セットを提供します。現在のホームページをどれだけ早くコピーできるかではなく、次年度のパブリッシングによって置き換えを判断してください。ホームページをコピーすることは簡単な部分であり、最も情報に乏しい部分です。

より広い文脈については、このサイトにWordPress代替案のガイドとヘッドレスCMSオプションの概要があります。

判定テーブル

すべての候補に同じ代表的な変更を適用します。新しいケーススタディページを関連サービスと著者にリンクさせ、独自のタイトルと説明を持たせ、古いURLからのリダイレクトを設定し、機能する問い合わせフォームを配置します。試行で変更をきれいに実行できないルートがあれば、低コストで学べます。

ルート	定期的なジョブに適している	コンテンツ公開の所有者	技術運用の所有者	コミットする前に実行する証明
Framerに留まる	デザイン主導のマーケティングサイトと管理された公開	Framerのビジュアルエディタ内のコンテンツチーム	Framerがプラットフォームを実行します。リバースプロキシを使用すればチームも配信レイヤーを所有します	現在のプロジェクトで代表的な変更を実行します。欠落している統合またはプロキシセットアップをテストします
Webflow	異なるビジュアルCMS、ステージング、承認が必要なマーケティングサイト	Webflow内のコンテンツチーム	Webflowがホストします。チームは構成と統合を所有します	1つのテンプレートとコレクションを再構築します。参照、プレビュー、リダイレクト、フォームを確認します
自ホストWordPress	エディトリアル集約的な公開とプラグイン主導の機能	WordPress内のエディタ。ワークフローは設定方法に依存します	チーム、ホスト、またはエージェンシー。コア、テーマ、プラグイン、ホスティング	ステージング上で提案されたプラグインを使用して変更を構築します。誰がアップデートを適用するか指名します
AstroとヘッドレスヘッドレスCMS	コード所有のフロントエンドとCMSから配信されるコンテンツ	選択したCMS内のエディタ。テンプレートの開発者	チーム。リポジトリ、ビルド、ホスティング、CMS接続	コンテンツをモデル化し、CMSからページをレンダリングし、エディタにプレビューを提供し、リダイレクトとフォーム処理を追加します

ビジュアルエディタとソース所有権は異なる質問に答えます。FramerとWebflowは編集サーフェスを提供し、プラットフォームがサイトを実行します。Astroはチームがフロントエンドコードを制御できるようにしますが、チームはまだエディタ向けCMSとその統合を選択する必要があります。ヘッドレスCMSはこの接続が構築されるとビジュアルプレビューと編集を提供できます。Sanityのビジュアル編集ガイドはこのようなアプローチの一例を示しています。

実際の乗り換え理由をテストする

「Framerは制限が多い」という人は、実は特定の1つのことを指しています。それを明確にしましょう。Framerはもはや単なる静的ポートフォリオツールではありません。そのCMSページには無制限の参照、組み込みのローカライゼーション、ドラフトと公開、ビジュアルコンテンツエディタが掲載されています。ステージングされたコンテンツは公開前にプレビュー可能で、CSVインポート、Googleシーツ連携、Airtable連携もリストされています。

そのため、あなたの理由を実際のリストと照らし合わせて確認してください。

コンテンツの関連性。リンクされたコレクション以上のものが必要ですか。ツールにそれができないと判断する前に、実際のコンテンツ(サービス、著者、ケーススタディ)をモデル化してください。
貢献者の権限。誰が編集でき、誰が公開でき、誰が提案だけできますか。ロールごとにこれを書き出し、各プラットフォームのドキュメントと比較してください。
レビューとプレビュー。Framerはドラフトとプレビューをリストしています。Webflowはドラフトプレビュー、ブランチング、ステージング、承認をリストしています。WordPressではインストール内容によって異なります。
ローカライゼーション。FramerとWebflowはどちらもこれをリストしています。デモページではなく、実際の言語とURLパターンでテストしてください。
統合。データを受け取るか送信する必要があるシステムを指定し、方向を明確にしてください。1つの統合がないだけで再構築が正当化されることはめったにありません。
ホスティング要件。ポリシーがトラフィックを承認されたインフラストラクチャ経由で実行する必要があると言っている場合、これは別の会話です。Framer自身のドキュメントが最も慎重になっているのはこの点です。

1つ注意があります。サードパーティのブログはFramerのプラン別CMSの上限を公開していますが、Framerの現在のプランドキュメントと照らし合わせて確認していないため、数字を繰り返しません。何かを決定する前にプランページで正確な上限を確認してください。

Webflow、WordPress、CMSを備えたAstro

以下の適合性は編集上の判断です。機能の事実はベンダーの公式ページから取得したものです。

Webflow

Webflowはそのクラウドベースのコンテンツ管理システムをビジュアルファーストでコンポーザブルと説明し、ドラフトプレビュー、粒度の細かい公開、参照フィールド、CSVバルクインポートを備えています。また、ブランチング、ステージング、承認、エンドツーエンドのローカライゼーション、さらにコンテンツを出し入れするためのヘッドレスCMS APIもリストしています。

Webflowは別のホストプラットフォームです。FramerからWebflowへの移行は編集または統合の要件に対応できますが、それ自体がインフラストラクチャの独立性を証明するわけではありません。ビルダーの変更がそれを満たしていると仮定する前に、実際のホスティングポリシーをWebflowのマネージドサービスと比較してください。

適合する場合: ビジュアル編集は好きだが異なるワークフローツールを望むマーケティングチーム。適合しない場合: 自社のインフラストラクチャでサイトを実行する必要がある場合。

自ホストWordPress

WordPressは公開システムと拡張エコシステムを提供します。WordPressの機能ページで説明されています。その魅力は編集構造、ロール、ほぼすべての統合のためのプラグインです。

誰かがそれを実行し続ける必要があります。WP Engine(マネージドWordPressベンダーなので、その点を念頭に読んでください)は自己管理の編集ワークフローと監査証跡が設定またはツールが必要であり、ホスティングとパフォーマンスはスタックに依存すると述べています。同じ記事は、組織はインフラストラクチャとホスティングの決定に対する完全な制御を保持していると述べています。そのコインの両側は真実です。制御と責任は一緒に現れます。

プラグインはまた編集体験も定義します。たとえば、Editorial Workflow Managerプラグインはブロックエディタに公開前チェックリストを追加し、デフォルトではアドバイザリで、オプションのブロックモードがあります。クラシックエディタではそのインターフェースを提供しません。承認プロセスが実際に存在するかどうかは、そのような小さな詳細によって決まります。

適合する場合: 編集量、カスタム投稿タイプ、プラグイン主導の機能、およびインストールにパッチを当てて監視するために割り当てられたチームまたはプロバイダー。適合しない場合: ホスティング、更新、プラグインの責任を誰も受け入れないプロジェクト。

AstroとヘッドレスというCMS

Astroはビジュアルビルダーではなく、フロントエンドフレームワークです。ドキュメントにはCMSガイドが含まれています。コンテンツはどこかから来る必要があります。非開発者が公開する場合は、コンテンツ編集レイヤー、エディタ向けのプレビューパス、公開をクリックしたときに実行されるビルドまたはデプロイプロセスが必要です。

これにより、あなたが所有するソースコードと、選択するホスティングが得られます。また、リポジトリ、パイプライン、監視する必要があるセキュリティサーフェースが得られます。エディタにとって優しいブロックを構築しない限り、開発者はすべてのレイアウト変更の一部になります。フレームワークの質問については、Astro対Next.jsを参照してください。

適合する場合: フロントエンドスキル、特定のパフォーマンスまたは統合ニーズ、およびスタックを所有する理由を持つチーム。適合しない場合: 来月セクションをドラッグしたいと期待するマーケティングチーム。

エクスポートとホスティング(2026年11月4日時点)

これはFramer自身のドキュメントが自分自身と矛盾する場所であり、私はそれを偽らないつもりです。

HTMLエクスポート記事はFramerが自己ホスティング用のHTMLエクスポートを提供していないと言っています。そのFAQはHTMLファイルまたは静的バンドルをダウンロードするかどうかの質問に「いいえ」と答えます。ページの事前レンダリング、動的画像リサイジング、フォントサブセット、サーバーサイドレンダリング、グローバル配信をプラットフォームで管理されたサービスとしてリストし、完全なホスティング制御またはソースコードエクスポートが必要な場合、Framerが適切なフィットではない可能性があると述べています。

データポータビリティに関する記事では、アウトプットについて正反対のことを述べています。すべてのサイトは標準的なHTML、CSS、JavaScriptおよび静的アセットとして公開され、ダウンロードして任意のホストに移動できます。また、CMSコンテンツはCSVまたはJSONとしてプラグインを通じてエクスポートでき、EU Data Actを参照しています。

両方の記事がFramerのヘルプFAQインデックスに現在の記事として表示されています。どちらが新しいものとして扱うことはできません。独立したレビューも矛盾を指摘し、サポートされたポータブルな動作サイトのエクスポートが確立されていないと述べました。唯一の誠実な立場は次のとおりです。現在のエクスポートルートとその出力を自分のプロジェクト用に検証してください。

リバースプロキシは配信制御であり、独立性ではありません

Framerはリバースプロキシルートのドキュメントを提供しており、このルートではサーバーがFramerサイトからページをリクエストして訪問者に提供します。Framerをコンテンツオリジンとして保ちながら、ヘッダー、認証および配信を制御できます。Advanced Hostingはプロ版ではアドオン、エンタープライズ版では含まれており、最大6つのリライトがあります。

ルーティングやヘッダーが必要な場合は有用です。ただし、Framerなしでサイトを運用できることの証拠ではありません。ドキュメントからいくつかの制限があります。

Reactで管理されたページコンテンツの変更はサポートされていません。タグの追加はサポートされています。
*.framer.appドメインをオリジンとして使用しないでください。
Canonical URLを設定します。このためにはAdvanced Hostingアドオンが必要です。
サブパスで提供する場合はパスを一致させ、末尾のスラッシュを避けてください。
カスタムCSPには注意が必要です。フォームアンチボット確認が実行できるようにworker-src 'self' blob:を含めてください。

Full Site Exportプラグインなどのサードパーティツールは公開されたサイトを読み取り、静的、Next.js、および読み取り可能なReactアウトプットを提供します。そのリストでは、読み取り可能なエクスポートはピクセル完全ではなく、サイトは公開されている必要があると述べています。これはサードパーティルートなので、公式な答えではなく、評価するものとして扱ってください。

コミットする前にこのエクスポート検証チェックリストを実行してください

エクスポートされたレンダリングページは自動的には編集可能なプロジェクトではなく、CMSの代替ではありません。すべてのエクスポートを検査する証拠として扱ってください。

利用可能なドキュメント化されたルートを通じて代表的なエクスポートを取得し、それをどのように取得したか正確に記録してください(ルート、ツール、日付、プラン)。
本番ドメインではなく、別のホストにコピーをデプロイしてください。
直接URLロード、内部リンク、メニュー、およびCMS駆動ページをテストしてください。
画像、フォント、ローカライゼーション、フォーム、およびインタラクションを確認してください。
コピーがまだ必要とするすべての外部リクエストとサービスをリストします。
将来のコンテンツ更新がどのように公開されるか、また誰によって公開されるかを確認してください。
ライブサイトに対して、URL、canonical、リダイレクト、およびメタデータを比較してください。
ルートを検証できない場合は、マイグレーションを誰かに約束する前に再構築をスコープしてください。

ステップ6はチームがスキップするものです。今日は動作するが明日コンテンツ変更を受け入れることができない静的コピーは、余分なステップがあるスクリーンショットです。

この件について別の視点がほしい場合は、代表的なコンテンツモデルとFramerが現在対応できないパブリッシングタスクを持ってきてください。ヘッドレスCMS開発を通じて実践的なCMSおよびフロントエンド評価を実行できます。

据え置き、および慎重な次のステップ

Framerに留まることは現実的な選択肢です。CMSがあなたのコンテンツモデルをカバーしており、編集者が快適で、ルーティング、ヘッダー、または1つの統合のような差分しかない場合、その小さな変更を再構築と比較してください。上記のリバースプロキシルートはまさにそのような配信要件のために存在し、CMSページにはデータ要件をカバーする可能性のある同期オプションが記載されています。

ここでは、すべてのFramerサイトがSEOが悪い、Core Web Vitalsに不合格である、または置き換える必要があるとは言っていません。そうではありません。プラットフォームの選択はどちらの方向でもSEOの保証ではありません。

合理的な流れ：

Framerが失敗している要件を1文で書き出してください。
Framerで代表的な変更をまず実行してから、1つの代替案で実行してください。
独立性が重要な場合は、エクスポートルートを検証してください。
その後でのみ再構築の見積もりを出してください。

最初のステップの文が曖昧であることが判明した場合、それが調査結果です。

Framerの代替案: デザインキャンバスを超えて選択する