2017年のことですが、あるクライアントから慌てた電話がありました。彼女がフローリストショップのサイトを GoDaddy のウェブサイトビルダーで構築したのです。週末でできて、モバイルでもそこそこ見えて、本人も満足していました。ところが彼女はシンプルなイベントカレンダーを追加したくなった。ただのカレンダーです。GoDaddy ではできません。ジュニア開発者も顔を赤らめるような醜い回避策なしにはできないのです。結局彼女は全体を WordPress に移行するのに私の手を借りることになって、その時思ったのです。なぜ人々はここから始めるんだろう、と。WordPress, and I remember thinking:why do people start here at all?
重要なポイント：GoDaddyのビルダーは、ライバルよりも柔軟性と引き換えに単純さを優先しており、WordPress、Webflow、Squarespaceはすべて同等の価格でより大きな拡張性を提供しています。GoDaddy's builder trades flexibility for simplicity harder than its rivals; WordPress, Webflow, and Squarespace all offer more headroom at comparable cost.
理解できますよ、正直に言って。GoDaddyの売り文句は魅力的です。登録して、テンプレートを選んで、ビジネス名を入力して、昼前にはサイトを公開。CMSに一度も触ったことがない人にとっては、このスピード感は超能力に思えます。でも、それは借りた時間に過ぎません。Seahawkで12,000を遥かに上回るサイトを構築してきた経験から言うと、期待以上に急速に成長してGoDaddyから移行する羽目になったクライアントのマイグレーション対応は、もう数え切れません。Seahawk, I've now lost count of how many GoDaddy migrations I've done for clients who grew out of it faster than they expected.
それでは、実際にクライアント（および自分自身）を移行した先と、その理由をお話しします。
---
GoDaddy ビルダーの問題は速度ではない。それは上限だ。
GoDaddyのウェブサイトビルダーは、本当に素早く立ち上げられます。そこは誤魔化しません。彼らのAIレイヤーであるGoDaddy Airoなら、ロゴとメールキャンペーンテンプレート付きのブランド化されたサイトを、あなたがコーヒーを飲み終わる前にスキャフォルドできます。エディタはクリーンで直感的、divが何かも知らない人、学びたくない人にとって脅威を感じさせません。The editor is clean, intuitive, and non-threatening for people who don't know what a div is and don't want to learn.
しかし。
セクションを自由に移動できない。HTML や CSS を編集できない。事前に用意されたオプション以外のレイアウトに変更できない。当然ながら、彼らの閉ざされたエコシステムに存在しないプラグインをインストールすることもできない。あるビルダーの詳細なレビューが率直に述べている通り、セットアップの利便性は本物ですが、デザインの基本以上の何かが欲しくなった瞬間に壁にぶつかります。one thorough review of the builder puts it bluntly -- the convenience of setup is real, but the moment you want anything beyond the basics of design, you hit a wall.
その壁が問題です。ビルダー自体ではなく。
あるクライアントがいました。ブリストルの理学療法クリニックで、GoDaddy を3年間使っていました。見た目の良いサイトでした。ところが彼らはオンライン予約と intake フォーム、彼らの診療管理ソフトウェアとの統合、運動ビデオライブラリのためのメンバーエリアが欲しくなった。私たちは2時間かけて GoDaddy がネイティブに対応できるものを監査しました。その答えは本質的にそのリストの何もかもでした。3年分のコンテンツがあるのに、彼らはアーキテクチャから始め直す必要がありました。
これはGoDaddy特有の警告ではありません。どれだけ速く始められるかではなく、どこまで進められるかに基づいてプラットフォームを選ぶことの重要性を示す警告です。start rather than how far you can go.
---
WordPress: 依然としてほとんどの人にとって賢明なデフォルト
ここ10年近く、WordPress が死んでいると宣言している人がいます。それでもなお、ウェブ全体の約40%を動かしています。これは惰性ではない。何ものも押し出すことができなかったスケールでのネットワーク効果です。around 40% of the entire web. That's not inertia -- that's network effect at a scale that nothing has managed to dislodge.
それでも推奨する理由
プラグインエコシステムだけで元が取れる価値がある（ちなみに無料だ）。60,000以上のプラグインがあるということは、想像できるほぼあらゆる機能が誰かによって既に構築され、数千のサイトで本番環境でテストされ、YouTubeで徹底的にドキュメント化されているということだ。eコマース向けのWooCommerce。カスタムフィールド向けのACF。SEO向けのYoastまたはRank Math。このスタックは退屈で、それは本当に褒め言葉だ。
エージェンシーにとって、才能プールも重要だ。ロンドン、ラゴス、またはリュブリャナでWordPressデベロッパーを雇い、彼らがカスタム投稿タイプが何かを知っているという合理的な確信を持つことができる。専有ビルダーでそれを試してみてください。
正直に言うWordPressの注意事項
完璧ではない。プラグインの競合は現実だ。40個のプラグインを何も壊さずに更新し続けることは、あるHacker Newsのコメンターが言ったように「MySQLの面倒を見ること」だ。セキュリティは、メンテナンスの悪い古いバージョンのプラグインを実行しているときには本当の懸念事項だ。ブロックエディタ（Gutenberg）はまだほぼ神学的に感じられる方法で意見を分ける。
しかし、本当の柔軟性、コンテンツの所有権、そして彼らと一緒に成長できるサイトが必要なクライアントのためには？ブリーフが明確に他の方向を指していない限り、WordPressは依然として私の最初の推奨だ。
---
Headless WordPressとJamstack：ブリーフが他の方向を指しているとき
約3年前、Seahawk は「パフォーマンス」が nice-to-have ではなくハード要件というブリーフをもっと多く受け始めました。高速なロード時間。高い Core Web Vitals スコア。複数の環境でコンテンツを配信する。ウェブ、アプリ、小売環境のキオスク画面かもしれません。従来の WordPress ホスティングではカットできません。Core Web Vitals scores. Content served across multiple surfaces -- web, app, maybe a kiosk screen in a retail environment. Traditional WordPress hosting wasn't going to cut it.
それが私たちがヘッドレスアーキテクチャにより強く寄り掛かり始めた時だ。
ヘッドレスが実際に意味すること（専門用語なし）
Headless WordPress は、WordPress をバックエンド（コンテンツリポジトリ、クライアントがログインする管理インターフェース）として保ちながら、フロントエンドを完全に分離することを意味します。「head」（ユーザーが見るもの）は Next.js や Astro のような JavaScript フレームワークで構築されます。WordPress は REST API または GraphQL を通じてコンテンツを提供します。フロントエンドはそのデータを取得して好きなように render します。 means you keep WordPress as the backend -- the content repository, the admin interface your client logs into -- but you decouple the frontend entirely. The "head" (what users see) is built in a JavaScript framework like Next.js or Astro. WordPress serves content via its REST API or GraphQL. The frontend fetches that data and renders it however it likes.
結果として、ページロード速度が非常に速くなり、PHPのレンダリングボトルネックがなくなり、フロントエンドアーキテクチャの完全な自由度が得られます。WordPress管理画面が同じ方法で公開されないため、セキュリティも向上します。
Jamstack CMSの環境
完全にJamstackを採用するなら、バックエンドとしてWordPressを使う必要さえありません。このアーキテクチャ向けに特別に構築されたヘッドレスCMSの選択肢は、堅牢で増え続けています。本番環境で使用したものの中から、いくつか挙げます：headless CMS options built specifically for this architecture. A few I've used in production:
- Contentful -- 熟成度が高く、ドキュメント充実、スケーリングではやや高額だが非常に堅牢 -- mature, well-documented, slightly expensive at scale but rock-solid
- Sanity -- 極めて柔軟なコンテンツモデリング、優れた DX、編集チームのためのリアルタイムコラボレーション -- extremely flexible content modelling, great DX, real-time collaboration for editorial teams
- Storyblok――ビジュアルエディタは本当に優秀で、リアルタイムで変更を見たい非技術者クライアント向けには素晴らしい -- the visual editor is genuinely impressive for non-technical clients who want to see changes in real-time
- Strapi――オープンソース、自社ホスト可能、Node.js ベース。インフラコストを抑えたい場合に適している -- open-source, self-hostable, Node.js-based, good if you want to keep infrastructure costs down
- Directus――過小評価されている。特にデータが多いプロジェクトで、適切なデータベース抽象化レイヤーが必要な場合に有効 -- underrated, especially for data-heavy projects that need a proper database abstraction layer
これらのどれもすべてのプロジェクトに完璧ではありません。Storyblokのビジュアルエディタは編集者にとって喜ばしいものですが、開発者側の複雑さが増します。SanityのGROQクエリ言語には学習曲線があります。ハイプではなく、実際のプロジェクトに基づいて選択してください。
---
EmDash: 注目する価値のある新参者（ただし注意点あり）
2026年4月に興味深いものがリリースされた。EmDash は Cloudflare が支援する新しい CMS で、WordPress の精神的後継者として位置づけられている――モダンなウェブテクノロジーで構築され、Cloudflare Workers 経由でプラグイン分離が可能で、AI ツールがネイティブに読める構造化データとしてコンテンツを保存しているEmDash is a new CMS backed by Cloudflare, positioning itself as a spiritual successor to WordPress -- built on modern web technologies, with plugin isolation via Cloudflare Workers, and content stored as structured data that's natively readable by AI tools.
このピッチは本当に興味深いものです。WordPressはPHPで動作していますが、2026年にゼロから設計するなら選ばないテクノロジーです。EmDashはエッジネイティブデプロイメント、構造化コンテンツ、そしてAIアシスタントがますます情報発見の手段となる世界のために構築されています。
私はまだ本番環境にEmDashをデプロイしていません。ベータ版で立ち上がり、私は様子を見ています。注目する価値のある懸念点がいくつかあります。
- エコシステムはまったく新しいものです。WordPressプラグインの60,000個対...それほどでもない。まだ。
- プラグイン分離機能は Cloudflare のランタイムでのみ動作する――そのインフラに専念しているなら問題ないが、そうでなければ制限がある
- ベータ製品です。本質的なリスクがあります。安定性が必要なクライアントの前でベータ版は使いません。
実際にテストした人たちからの率直な合意は：技術的には印象的、実務的には不完全。12～18ヶ月後に再検討する価値があります。私も正にそうするつもりです。honest consensus from people who've tested it is: technically impressive, practically incomplete. Worth revisiting in 12-18 months. I'll be doing exactly that.
---
これらのオプションの実際の選び方
重要なのはこれだ――オンラインの「どの CMS がベストか」というコンテンツのほとんどは、スペックシート比較のように扱っている。チェックボックス。機能マトリックス。実際のプロジェクトでプラットフォームを選ぶときはそうじゃない
私が実際にアプローチする方法はこうだ：
- クライアントが今日ではなく 18 ヶ月後に何が必要かを尋ねる。個人花屋なら、マネージドホスティング上の WordPress でおそらく十分だ。VC から資金調達を受けたスタートアップで 10 倍のトラフィック成長を見込んでいるなら、今からそれに向けて設計すべき。If they're a solo florist, WordPress on managed hosting is probably fine. If they're a VC-backed startup expecting 10x traffic growth, architect for that now.
- ローンチ後、誰がそれを保守するのかを尋ねる。ヘッドレス Jamstack セットアップは素晴らしいが、58 歳のクライアントのマーケティングマネージャーがブログ記事を更新しなければならなくなると、サポートチケットになる。技術的複雑さをチームに合わせる。A headless Jamstack setup is brilliant until the client's 58-year-old marketing manager has to update a blog post. Then it's a support ticket waiting to happen. Match the technical complexity to the team.
- コンテンツが 1 つ以上の場所に行くかどうかを尋ねる。複数のフロントエンド（ウェブ + アプリ + その他）はほぼ常にヘッドレスを指す。Multiple frontends (web + app + whatever) almost always points toward headless.
- 統合について聞き出そう。CRM、予約システム、決済プロセッサ、アナリティクス――プラットフォームにコミットする前に、これらをマップしておくこと。後からじゃなくCRM, booking systems, payment processors, analytics -- map these before you commit to a platform, not after.
- 継続的なメンテナンスの予算について質問しておきましょう。自前でホストするStrapi インスタンスは、Node.js バージョンを最新に保つ誰かが必要です。これは時間か金銭のコストがかかります。織り込んでおいてください。A self-hosted Strapi instance needs someone keeping the Node.js version updated. That costs time or money. Factor it in.
---
誰も話さないマイグレーションの現実
GoDaddy（または他の独占的ビルダー）から移行することは簡単ではありません。コンテンツは何らかの形でエクスポート可能なことが多いですが、構造はそうでないことがほとんどです。GoDaddyはクリーンなデータベースエクスポートやコンテンツAPIを提供しません。通常はスクレイピング、コピペ、またはサードパーティのマイグレーションツール（仕事の70%をこなして、残りは手動でクリーンアップする必要があります）を使うことになります。structure often isn't. GoDaddy doesn't give you clean database exports or content APIs. You're typically scraping, copy-pasting, or using third-party migration tools that do about 70% of the job and leave you cleaning up the rest manually.
これだけのマイグレーションを経験すれば、僕なりのプロセスはある。でも、洗練されているとは言わない。実際の時間をかけろ。そして GoDaddy からのドメイン移管は細心の注意を払うこと――彼らには不必要に摩擦を増やす歴史がある
良いニュースは、一度出てしまえば終わりということです。WordPressまたはヘッドレスCMSに移行したクライアントはほぼ100%戻ってきません。
---
よくある質問
GoDaddyのウェブサイトビルダーは何か役に立つのか？
本当に、特定のユースケースではそう――地元の職人向けのワンページサイト。単にオンラインプレゼンスと電話番号が必要というだけ。一時的なランディングページ。非技術者が数時間で本番に上げる必要があって、大きく変更することはない。そういった場合は、セットアップの速度は本当の利点になる。成長を見込むなら、すぐに限界に達する
WordPressに移行するにはコーディングを知っている必要がありますか？
必ずしもそうではありません。Kinsta、WP Engine、さらにはHostingerなどのプロバイダーからのマネージドWordPressホスティングは、運用面をはるかにアプローチしやすくします。管理インターフェースである程度の快適さが必要で、トラブル時に相談できる人がいるのが理想的です。しかし、多くの小規模ビジネスオーナーはコードに一行も触れることなくWordPressサイトを実行しています。
ヘッドレスCMSと通常のCMSの違いは何ですか？
伝統的な CMS（クラシック WordPress など）はコンテンツ保存とページレンダリングの両方を扱う――結合されたシステムだ。ヘッドレス CMS はコンテンツ保存だけを扱い、API 経由で公開する。フロントエンド――好きなフレームワークで構築する――がコンテンツを取得して、どう表示するかを決める。利点は柔軟性とパフォーマンス。欠点は、サイトビルダーだけでなく、フロントエンド開発者が必要だということ
EmDashは本番環境での使用に対応していますか？
私の見方では、ほとんどのビジネスには対応していません。2026年4月にベータ版でローンチされ、エコシステムは本当に初期段階です。基盤となるアーキテクチャは興味深く、Cloudflareによるバッキングは信頼性を与えます。しかし、WordPressと実績のあるヘッドレス代替案が存在する場合、ベータ版CMSでクライアントのプライマリマーケティングサイトを運用することはできません。2027年にこの領域を注視してください。
WordPressをヘッドレスCMSとして使用できますか？
はい、実際にはかなり実用的な中間地点です。WordPressには組み込みのREST APIがあり、WPGraphQLはあなたのコンテンツをGraphQL経由で公開する成熟したプラグインです。つまり、クライアントが既に知っている馴染みのある管理インターフェース、膨大なプラグインエコシステムを得ることができますが、Next.jsまたはAstroでフロントエンドを構築し、モダンなJamstackセットアップのパフォーマンス利点を得ることができます。Seahawkでこの方法でいくつかのプロジェクトを納品しており、うまく機能しています。
---
2017年の花屋さんはいまだにクライアントです。いまではWordPressを使っていて、ちゃんと予約プラグインとイベントカレンダーが導入されている。それ以来、パニック状態で電話をかけてくることはありません。それが本当の目標なんです。問題にならなくなるものを作って、クライアントが自分たちの本当の仕事に集中できるようにすること。
つまらないものを選んでください。柔軟性のあるものを選んでください。引き継ぐことができるものを選んでください。