BtoB企業のCMS選びでは、記事を公開できるかだけでなく、更新を続けられるか、問い合わせ後の対応につなげられるかを確かめます。10製品の違いを、自社の業務と担当体制に沿って比較する方法を解説します。
「オウンドメディアを始めたいが、どのCMSを選べばよいかわからない」
「WordPressを使っているが、更新や保守の負担が大きくなってきた」
「記事から問い合わせを得ても、その後の顧客管理や営業連携が分かれてしまう」
こうした悩みを機能一覧だけで解決するのは難しいものです。同じ「フォームが使える」という説明でも、送信された情報の記録先や、営業担当者への通知方法は利用する構成によって変わります。
CMSとは、Webサイトや記事のコンテンツを作成・管理するシステムです。選定ではまず、自社がCMSに任せる範囲を決めます。記事の編集と公開が主な用途なのか、フォームから受け取った情報の管理まで含めるのか。その範囲が決まると、試すべき操作と費用を比較する条件が明確になります。
本記事は「コンテンツマーケティングとは?BtoB企業が成果を出す基礎知識と実践ステップ」シリーズの一部です。コンテンツ施策の全体像を整理したい場合は、記事の企画から公開、問い合わせ後の対応までの流れを先に確認できます。
この記事でわかること
この記事は、CMSの新規導入や見直しを担当するマーケティング、Web運用、営業の担当者に向けたものです。CMSに求める要件の決め方、10製品を比較するときの着眼点、社内体制に合わせた選び方を扱います。
さらに、費用の対象範囲をそろえる方法と、移行時に確認すべきページ・フォーム・顧客情報の引き継ぎを整理します。進め方は次のとおりです。
- 業務上の課題を特定する
- 同じ作業で製品を試す
- 費用と移行条件を比べる
各節の確認事項に担当者と結果を書き加えると、選定会議で「何ができたか」「何が未確認か」を説明できます。
次の表は、HubSpot CMSを検討するときの確認項目です。
利用する構成で各操作を試し、自社が設定・管理する範囲を確認してください。特に、フォームの作成と営業への引き継ぎは別の作業として確かめます。
| 項目 |
評価 |
| カスタマイズ性 |
中程度(テーマ・モジュールで対応) |
| SEO |
SEO推奨機能、トピッククラスター管理が標準搭載 |
| リード獲得 |
フォーム、CTA、LP作成が標準搭載 |
| CRM連携 |
HubSpot CRMと完全統合 |
| 運用コスト |
判断の目安となるプラン別の月額費用。 |
| セキュリティ |
SaaS型のため、セキュリティはHubSpotが管理 |
- CMSに求める要件 — 記事公開、問い合わせ受付、営業への引き継ぎに必要な作業から優先順位を決めます。
- BtoB向け10製品の比較 — 製品タイプごとに、自社で設定・保守する範囲を確認します。
- WordPress・HubSpot・Notionの違い — 同じ記事更新と問い合わせの流れを試す際の分かれ目を示します。
- 自社に合う選び方 — 編集、承認、開発、営業の担当体制に照らして判断します。
- 移行時の確認事項 — ページの対応表を作り、URL、SEO情報、フォーム、顧客情報を点検します。
BtoB企業がCMSに求める5つの要件
最初に、現在の記事公開から問い合わせ対応までを一枚の業務一覧にします。次を書き出してください。
どこで更新や対応が止まるかを確認してください。CMSに必要な機能は、その止まる箇所から優先づけます。
たとえば、次のように課題が異なれば、先に試す機能も変わります。
- 記事を公開できても修正のたびに開発担当者の作業が必要な場合 ── 編集権限とページの作り方が選定条件になります。
- フォーム送信後の担当者が分からない場合 ── CMSを比較する前に情報の記録先と引き継ぎ方法を決める必要があります。
次の表は、CRMとの連携を重視するときに比較する構成です。順位だけで決めず、既存サイトを活かす場合と、サイトの構成を変更する場合で必要な作業を比べてください。
- 既存サイトの更新に支障がなければ ── 問い合わせ後の流れを先に試します。
- 更新そのものが止まっているなら ── 編集から公開までを先に試します。
| 推奨度 |
CMS |
理由 |
| 1位 |
HubSpot CMS(Starter/Professional) |
CRM/MAとの連携を確認できる |
| 2位 |
WordPress + HubSpotプラグイン |
既存WordPress資産を活かしつつHubSpotと連携 |
| 3位 |
Webflow |
デザイン性と運用効率のバランスが良い |
複数の担当者や配信先が関わる場合は、次を追加します。
- 編集権限
- 承認手順
- 配信先ごとの表示確認
- 開発保守の分担
次の並びも、必要な権限と配信方法を実際の構成で確かめてから評価します。承認後の訂正を誰が反映するかまで決められない構成は、公開手順を確認してから比較を続けます。
| 推奨度 |
CMS |
理由 |
| 1位 |
HubSpot CMS(Enterprise) |
エンタープライズ向け機能(権限管理、マルチドメイン等) |
| 2位 |
Drupal |
高いカスタマイズ性と大規模サイト対応力 |
| 3位 |
Contentful |
ヘッドレスCMSとして複数チャネルに配信 |
次の要件表では、重要度を自社の業務に合わせて見直します。すべてを同時に満たそうとする前に、次に分けてください。
- 導入時に欠かせない
- 運用後に見直す
- 今回の用途では使わない
欠かせない要件には、その機能を使って完了させる作業も併記します。
| No. |
要件 |
内容 |
重要度 |
| 1 |
SEO機能 |
メタタグ、構造化データ、サイトマップなどのSEO機能 |
最重要 |
| 2 |
リード獲得機能 |
フォーム、CTA、ランディングページの作成・管理 |
最重要 |
| 3 |
CRM/MA連携 |
顧客データ・MAツールとのシームレスな連携 |
重要 |
| 4 |
運用のしやすさ |
非エンジニアでもコンテンツの作成・更新が可能 |
重要 |
| 5 |
セキュリティ |
HTTPS対応、定期アップデート、脆弱性対策 |
重要 |
SEOとコンテンツ管理
公開中の記事を一つ選び、編集担当者がタイトル、ディスクリプション、見出し、画像、内部リンクを変更する手順を確認します。変更前の内容を控え、次の順にたどってください。
- 下書きの確認
- 承認
- 公開
- 公開後の訂正
公開後は、編集画面で保存した内容が実際のページに反映されているかを確認します。
判断の分かれ目は、日常的な修正を予定した担当者が完了できるかです。
- 開発担当者の作業が必要な場合 ── その作業を減らせるか、依頼手順として受け入れるかを決めます。
- 編集担当者が承認前の内容を誤って公開できる場合 ── 権限と確認手順を見直してから次の製品を評価します。
リード獲得と顧客情報の連携
フォームやCTAは、作成できることに加えて、送信後の流れを確認します。テスト用の問い合わせを送り、次を順にたどってください。
- 完了画面
- 情報の記録先
- 通知先
- 営業担当者が確認する画面
営業担当者には、届いた情報だけを見て次の対応と連絡先を判断してもらいます。
判断できない場合は、必要な情報がフォームで得られていないのか、記録や通知の途中で止まっているのかを切り分けます。入力項目を増やす前に、その情報を誰が何に使うかを決めてください。次のように見直し、同じテストを再実行します。
- 記録先の情報が足りない場合 ── 項目を見直します。
- 通知が届かない場合 ── 通知先を見直します。
- 担当が決まらない場合 ── 割り当て手順を見直します。
日々の運用と社内リソース
記事の下書き、承認、公開、緊急時の修正、デザイン変更、保守をそれぞれ誰が担うか記入します。兼務の担当者がいる場合は、不在時に別の人がどこまで対応できるかも試してください。
- 代行者が必要な画面に入れない場合 ── 権限を見直します。
- 作業内容を判断できない場合 ── 引き継ぎ手順を見直します。
次の表は、担当体制から比較対象を考えるためのものです。「おすすめCMS」の欄をそのまま選定結果とせず、表の理由にある作業を自社の担当者が実行できるか確認します。
「運用工数が最小限」という記載も、対象とする記事更新、公開、問い合わせ対応の範囲をそろえて確かめてください。
| 社内リソース |
おすすめCMS |
理由 |
| エンジニアあり |
WordPress、Drupal、ヘッドレスCMS |
カスタマイズの自由度を活かせる |
| マーケティング担当者が運用する場合 |
HubSpot、Wix、STUDIO |
必要な操作と運用範囲を確認 |
| 兼務担当 |
HubSpot、Notion |
運用工数が最小限 |
セキュリティと保守
CMS本体、サーバー、プラグイン、連携先ごとに、設定を管理する人と、問題を発見した人から連絡を受ける人を記録します。あわせて、次を分けます。
- 管理画面で確認する設定
- 公開ページで確認する表示
- フォーム送信で確認する記録先
SaaS型でも、提供元の管理範囲と自社の設定・運用範囲を確認してください。
たとえば次のように切り分けます。
- 記事が表示されず、管理画面では公開済みになっている場合 ── 公開ページと配信に関わる設定を確認する担当へ渡します。
- ページは表示されるのに問い合わせが届かない場合 ── フォームの送信結果、記録先、通知先の順に調べます。
- 原因を特定できないとき ── 発生した画面と操作を残して連絡できるようにします。
保守担当を割り当てられない項目があれば、問い合わせ先と対応方法を決めてからその構成を選びます。担当者が決まったら、設定変更や障害対応の後に、影響するページとフォームを誰が再確認するかまで運用手順に含めます。
| 要件 |
確認する内容 |
選定時の見方 |
| SEO |
メタタグ、構造化データ、サイトマップ |
担当者が継続して使えるか |
| リード獲得 |
フォーム、CTA、ランディングページ |
獲得情報の管理先が明確か |
| CRM・MA連携 |
顧客情報やマーケティングツールとの連携 |
手作業の転記を減らせるか |
| 運用性 |
非エンジニアによる作成・更新 |
社内の担当体制に合うか |
| セキュリティ |
HTTPS、更新、脆弱性対策 |
保守の責任範囲が明確か |
要件を整理したら、導入時に欠かせない作業から試します。作業が止まった場合は、次のどれかを記録してください。
- 設定変更で進める
- 別の担当者の作業が必要
- 製品の利用方法を変える必要がある
運用後に見直す項目には、「更新のたびに依頼が発生する」「問い合わせ情報の照合が続く」など、再評価を始める状態も記録します。
BtoB向けCMS10製品の機能比較
CMSには、次の構成があります。
- 自社で手配する構成 ── サーバーや保守を自社で手配します。
- 提供元の環境を利用する構成
- APIで配信する構成 ── コンテンツをAPIで配信します。
製品タイプが異なると、編集画面だけでなく、公開ページの表示やフォームの管理に必要な作業も変わります。
独自ドメインを利用する場合は、接続条件と設定手順をHubSpotのドメイン接続に関する案内など、検討中の製品の公式資料で確認してください。次の担当者も決めます。
- ドメインの設定担当者
- 公開時に接続結果を確認する担当者
以下の表では、機能名を確認の入口として使います。
「標準機能」「連携可能」という記載だけで判断せず、自社で使う構成と担当者で同じ作業を試してください。
機能を追加して実現する場合は、導入時の設定に加え、設定変更と保守を誰が行うかまで比較します。
次の表は、WordPressを利用する場合の確認項目です。プラグインで実現する機能は、導入時の設定と公開後の更新・保守を合わせて評価します。
| 項目 |
評価 |
| カスタマイズ性 |
非常に高い(テーマ・プラグインが豊富) |
| SEO |
Yoast SEO等のプラグインで対応 |
| リード獲得 |
Contact Form 7等で対応 |
| CRM連携 |
HubSpot、Salesforce等のプラグインあり |
| 運用コスト |
サーバー費+ドメイン費+保守費 |
| セキュリティ |
プラグインの脆弱性リスクあり、定期更新が必須 |
次の表は、Notionを記事管理に用いる構成の確認項目です。記事の入力に加え、公開ページを作る方法、SEO情報、フォーム、顧客情報の管理先を一続きの業務として確認します。公開に別の仕組みを使う場合は、Notionでの編集から公開ページへの反映までを試してください。
| 項目 |
評価 |
| カスタマイズ性 |
限定的 |
| SEO |
基本的な対応のみ |
| リード獲得 |
別途ツール(Typeform等)が必要 |
| CRM連携 |
Zapier等で連携可能 |
| 運用コスト |
ほぼ無料〜月額数千円 |
| セキュリティ |
Notion側で管理 |
10製品の比較一覧
一覧では、自社が管理する範囲を見つけます。次を分けてください。
- 編集者が公開まで行う構成か
- 開発担当者が表示部分を管理する構成か
- 問い合わせの記録に追加設定が必要な構成か
利用条件や設定で変わる項目は、実際に使う環境で確認します。
まず、次のうち欠かせない条件を選びます。
- 「記事更新を担当者だけで完了したい」
- 「既存サイトの表示を維持したい」
- 「複数の配信先を管理したい」
その条件に関わる作業を実行できた製品について、フォームと顧客情報の扱いを確かめます。表の運用難易度は、自社の担当体制で作業を試すための目安です。
| CMS |
タイプ |
SEO |
フォーム |
CRM連携 |
運用難易度 |
| WordPress |
オープンソース |
プラグイン |
プラグイン |
要設定 |
中 |
| HubSpot CMS |
SaaS |
標準機能 |
標準機能 |
統合済み |
低 |
| Wix |
SaaS |
標準機能 |
標準機能 |
連携可能 |
低 |
| Squarespace |
SaaS |
標準機能 |
標準機能 |
連携可能 |
低 |
| Webflow |
SaaS |
標準機能 |
標準機能 |
連携可能 |
中〜高 |
| Drupal |
オープンソース |
モジュール |
モジュール |
要設定 |
高 |
| Contentful |
ヘッドレス |
API対応 |
別途必要 |
API連携 |
高 |
| microCMS |
ヘッドレス |
API対応 |
別途必要 |
API連携 |
中〜高 |
| Notion + Blog |
ツール活用 |
限定的 |
別途必要 |
要設定 |
低 |
| STUDIO |
SaaS |
標準機能 |
標準機能 |
連携可能 |
低 |
製品タイプで比較対象を分ける
- 編集担当者がページを更新し、公開まで進めたい場合 ── 管理画面の操作と承認手順から試します。
- 既存サイトの表示や機能を維持したい場合 ── 代表的なページを選び、表示の再現と公開後の保守を担う人を確認します。
- 複数の配信先に同じ内容を使いたい場合 ── 入力画面だけでなく、各配信先の表示と訂正方法まで試します。
ここでの分かれ目は、必要な作業を誰が最後まで実行するかです。
編集者だけでは公開できない構成でも、開発担当者の作業を運用に組み込めるなら比較を続けられます。担当を割り当てられない場合は、ページの作り方や配信方法を見直し、実行できる構成で試し直してください。
比較表から実際の業務へ進む
比較対象を絞ったら、同じ記事と同じテスト用問い合わせを使います。
- 記事 ── 見出しと画像の修正、承認、公開後の訂正を試します。
- 問い合わせ ── 送信後の画面、記録先、通知先、営業担当者が見られる内容を照合します。
作業ごとに、操作した人、確認した画面、結果を残してください。
止まった箇所は、画面上の操作、設定、社内の引き継ぎのどこに原因があるか分けます。記事を更新できても問い合わせの担当が決まらないなら、まずテスト送信が記録先に届いたかを確認します。
- 届いていなければ ── フォームと記録先の設定を調べます。
- 届いているのに担当が決まらなければ ── 通知先と割り当て手順を確認します。
修正した箇所から同じテストを再実行し、営業担当者が対応を始められるところまで確かめてください。
欠かせない業務を最後まで実行でき、継続する作業の担当も決まった段階で費用を比較します。完了していない作業があれば、必要な設定や担当者を明示したうえで、見積もりの範囲に含めるか判断します。
WordPress vs HubSpot CMSでは、両者の編集、運用、顧客情報の扱いを詳しく比較できます。オウンドメディアの立ち上げ方では、CMS選定の前後に必要な企画、制作、運用体制の組み立て方を確認できます。
WordPress・HubSpot・Notionを比較する
WordPress、HubSpot CMS、Notionを使った構成では、記事の作り方だけでなく、公開ページの管理範囲と問い合わせ情報の扱いが異なります。まず、現在のサイトについて次を分けてください。
そのうえで、同じ記事更新とフォーム送信を試すと、製品名からは見えにくい作業の差が分かります。
次の画像は、HubSpotのCRM画面内でNotionページを閲覧・編集する画面です。ここで確認できるページの扱いと、Webサイトの記事を公開・管理する作業は別に確認してください。

それぞれの運用上の特徴
WordPressでは、現在使っているテーマ、プラグイン、フォーム、独自の表示を洗い出します。
- 使い続ける場合 ── 編集者が更新できる箇所と、開発・保守担当者が管理する箇所を分けます。
- 移行を検討する場合 ── 維持したいページを一つ選び、表示と更新手順を比較してください。
ページは再現できても、公開後の修正を担当できる人がいなければ、その運用方法を決めてから評価します。
HubSpot CMSでは、記事とフォームから得る情報をどう扱うかを先に決めます。
- 先に定めるもの ── 登録先、営業へ渡す条件、担当者が確認する画面を定め、テスト送信で確かめます。
- 独自の表示が必要な場合 ── 対象ページで再現方法と更新担当を確認します。
フォーム送信後の情報は、営業担当者が実際に確認する画面まで追います。
Notion + Blogでは、Notionで管理する内容が公開ページへどう反映されるかを確かめます。
- 記事を修正したとき ── SEO情報やフォームへの導線も必要に応じて更新できるかを試してください。
- 公開や連携に別の仕組みを使う場合 ── その管理担当も決めます。
Notion上で編集が完了しても、公開ページの訂正まで終わったかを別に確認します。
機能と社内負担の比較
| 比較項目 |
WordPress |
HubSpot CMS |
Notion + Blog |
| カスタマイズ |
テーマ・プラグインで幅広く対応 |
テーマ・モジュールで対応 |
限定的 |
| SEO |
SEOプラグインを利用 |
SEO機能を利用 |
基本的な対応 |
| リード獲得 |
フォームプラグイン等を利用 |
フォームやCTAを利用 |
別途ツールが必要 |
| CRM連携 |
プラグイン等で設定 |
HubSpot CRMと統合 |
外部連携の設定が必要 |
| 主な運用負担 |
サーバー、プラグイン、保守 |
自社の要件に合わせた設定 |
ブログ化や外部連携の管理 |
| 向いている体制 |
開発・保守の担当者がいる |
顧客情報と施策を連携したい |
小規模にコンテンツを管理したい |
- 既存ページの表示を維持することが欠かせない場合 ── そのページの再現と更新を先に試します。
- 営業への引き継ぎが課題の場合 ── フォーム送信後に担当者が必要な情報を受け取れるかを先に試します。
支障が残った場合は、追加する設定、作業する人、再確認する方法を決めてから評価してください。
CMSから営業までの流れを設計する
問い合わせ対応を含めてCMSを選ぶ場合は、次を決めます。
- フォームで受け取る情報
- 記録先
- 通知先
- 営業担当者が対応状況を確認する場所
情報が複数の場所に残るなら、どこを確認先とするかを明確にしてください。
次に、テスト送信を行い、営業担当者が画面上の情報から次の対応を判断できるか試します。
- 情報が足りない場合 ── 入力項目と引き継ぎ方法を見直します。
- 使わない項目がある場合 ── 収集する理由を確認します。
担当者が対応を始められ、その結果を決めた場所に記録できたら、運用手順として残します。
運用を始めた後は、担当者が決まらなかった問い合わせや、必要な情報を確認できなかった問い合わせを見直すきっかけにします。次のどこで止まったかを調べ、該当する手順を修正してから再度テストします。
HubSpot CMSを選ぶ場合も、最初から扱う情報や自動化を広げる必要はありません。必要なフォーム、顧客情報、営業への引き継ぎ条件を定め、担当者が運用できることを確かめてから対象を広げます。HubSpotのSEOツール完全ガイド|トピッククラスター設計・検索順位モニタリングでは、記事間の関係を設計し、公開後の検索状況を確認する際の考え方を詳しく扱っています。
自社に合うCMSを社内体制から考える
企業規模は比較の手掛かりになりますが、人数だけで運用負担は決まりません。次の担当者を業務ごとに割り当て、実際に作業できるかを確認します。
担当者が兼務する場合は、通常時と不在時の両方で、どの作業が止まるかを確かめます。
小規模なチームで始める
専任の開発者がいない場合は、記事を担当する人が下書きの修正、承認依頼、公開後の更新まで進められるかを試します。HubSpot CMS、WordPress、STUDIO、Notionなどを比べる際も、同じ担当者と同じ作業で確認してください。
問い合わせを受けるなら、次を誰が続けるかも決めます。
作業が特定の人に集中する場合は、その人が不在でも必要な更新や返信につなげられるよう、引き継ぎ先と手順を用意してから選びます。代行者が作業を再現できない場合は、権限か手順のどちらが不足しているかを確かめます。
マーケティングとCRMを連携する
マーケティング施策と営業の顧客管理をつなげたい場合は、HubSpot CMSと、既存のWordPressにHubSpotを組み合わせる構成を比較できます。Webflowを検討する場合も、サイトの更新方法と問い合わせ情報の扱いを同じ条件で試します。
既にWordPressを使っているなら、記事更新の負担と問い合わせ後の引き継ぎを分けて調べます。
- 記事更新が滞る場合 ── 編集・承認手順を先に確認してください。
- 営業への情報共有が滞る場合 ── フォーム送信後の流れを先に確認してください。
原因が分かれば、サイト全体を移す必要があるか、現在の構成で対応できるかを判断しやすくなります。現在の構成で課題を解消できた場合も、設定変更と保守を継続する担当者を決めてから判断します。
次の表は、マーケティング目的から比較する機能を整理したものです。機能を選ぶ前に、その機能を使う業務と担当者を明確にします。複数の目的がある場合は、現在止まっている業務に関わる行から試してください。
| マーケティング目的 |
重視すべきCMS機能 |
おすすめCMS |
| SEO集客 |
SEOツール、ブログ機能 |
HubSpot、WordPress |
| リード獲得 |
フォーム、CTA、LP |
HubSpot |
| ブランディング |
デザイン自由度 |
Webflow、STUDIO |
| コンテンツ配信 |
API、マルチチャネル |
Contentful、microCMS |
多くの担当者や配信先が関わる
複数の部門が記事を扱うなら、次の流れを試します。
- 編集者が変更する
- 承認者が確認する
- 公開担当者が反映する
権限によって誰がどこまで操作できるか、修正依頼がどこへ戻るかを記録してください。差し戻された記事を編集者が直し、承認者が再確認できるところまでが確認範囲です。
配信先が複数ある場合は、同じ内容を修正したときに各画面へどう反映されるかを確認します。ヘッドレス型を検討するなら、コンテンツの入力だけでなく、表示部分の開発と保守を担う人も必要です。その担当を割り当てられない場合は、配信方法や構成を見直します。
規模別の比較範囲を整理する
| 想定する体制 |
候補 |
比較で確認すること |
| 小規模なチーム |
HubSpot CMS、WordPress、STUDIO、Notion |
更新作業と問い合わせ管理を誰が担うか |
| マーケティング担当がいる |
HubSpot CMS、WordPress + HubSpot、Webflow |
CRM連携やページ改善の運用方法 |
| 複数部門や配信先が関わる |
HubSpot CMS、Drupal、Contentful |
権限、開発保守、配信方法 |
表の体制に自社を当てはめたら、編集、承認、公開、保守、問い合わせ対応の担当者を実名または役割で記入します。
- 空欄が残った作業 ── 誰が担うかを決めてから比較を進めてください。
- 担当を置けない場合 ── その作業を減らせる構成があるか、運用範囲を狭められるかを検討します。
CMSの費用と選定基準を整理する
費用はライセンスだけを並べず、同じ業務を実現する範囲で比べます。次までを対象にし、自社で行う作業と外部へ依頼する作業を分けてください。
- 記事の作成・公開
- フォームの設定
- 問い合わせの記録
- 公開後の保守
見積もりを求める前に、必要なページ、フォーム、連携、確認作業を製品ごとに同じ条件で示します。
次の表は、推奨度ごとにCMS、理由を整理したものです。
| 推奨度 |
CMS |
理由 |
| 1位 |
HubSpot CMS(Enterprise) |
エンタープライズ向け機能(権限管理、マルチドメイン等) |
| 2位 |
Drupal |
高いカスタマイズ性と大規模サイト対応力 |
| 3位 |
Contentful |
ヘッドレスCMSとして複数チャネルに配信 |
費用を比較する単位は、製品名ではなく「完了させる業務」です。たとえば次のようにそろえます。
- 記事公開 ── ページの作成だけでなく、承認、公開後の訂正、表示確認を含めるかをそろえます。
- 問い合わせ ── フォームの設置だけでなく、送信結果の記録、通知、担当者の確認までを含めるかをそろえます。
範囲が違う見積もりは、その違いを明記してから比較してください。
次の表は、複数の部門や配信先が関わる構成を比較するためのものです。記載順にかかわらず、自社に必要な権限設定、配信方法、開発保守の条件を満たすか確認します。
総所有コストで比較する
| コスト項目 |
WordPress |
HubSpot |
ヘッドレスCMS |
| ライセンス |
無料のソフトウェアでも、利用環境の費用は別途発生 |
プランや利用条件による |
プランや利用条件による |
| サーバー |
自社構成により発生 |
SaaSの提供範囲による |
別途必要となる構成がある |
| プラグイン・アプリ |
利用内容による |
利用内容による |
連携や開発が必要な場合がある |
| 保守・更新 |
CMS、プラグイン、サーバーの管理 |
提供元と自社の管理範囲を確認 |
CMSと配信環境の管理が必要 |
| フロントエンド開発 |
テーマや要件による |
テーマやモジュールで対応 |
開発が必要な構成がある |
見積もりを比べる前に、各項目について次を記録します。
- 必要な作業
- 実施する人
- 見積もりに含まれる範囲
- 公開後も続く作業
たとえばフォーム作成が含まれていても、通知先の変更や連携の保守が含まれているとは限りません。範囲の違いが見つかったら確認し、同じ条件にそろえてから費用を比較します。
見積もりに含まれない作業は、まず作業一覧に戻して扱いを決めます。
- 社内で担う場合 ── 担当者がその作業を実行できるか試し、通常業務と重なる時期にも対応できるか確認してください。
- 外部へ依頼する場合 ── 依頼する作業、納品時に確認する結果、公開後の修正を依頼できる範囲を伝えます。
実施方法が決まった項目から費用を確認し、未確定の項目は金額を推測して埋めず、確認先と回答を受ける担当者を記録します。
比較を進める条件は、欠かせない業務の作業範囲、実施者、確認方法が各製品でそろうことです。
見積もりに差がある場合は、まず含まれる作業と公開後の担当範囲を照合します。範囲をそろえても差が残る場合に、その費用を自社の運用体制と照らして判断してください。
5つの基準で比較対象を絞る
| 判断基準 |
確認すること |
選び方の分かれ目 |
| マーケティング目的 |
SEO、リード獲得、ブランド、複数チャネルのどれを優先するか |
必要機能が標準か、追加開発かで比較 |
| 社内リソース |
編集者、開発者、保守担当者の有無 |
開発を担えない場合は運用負担の少ない候補を優先 |
| 総所有コスト |
ライセンス、サーバー、アプリ、保守、開発 |
使い始めの費用と継続作業を合わせて比べる |
| 拡張性 |
コンテンツ量、多言語、CRMや分析との連携 |
将来必要になる機能を先に洗い出す |
| 移行性 |
インポート、エクスポート、URL、SEO情報 |
移行後のURLとコンテンツを対応づけられるか確認 |
判断は、次の順に進めます。
- 欠かせない業務
- 実行する担当者
- 必要な設定
- 費用
実行方法が決まっていない業務は、見積もりの対象範囲も定まりません。機能を使えることが確認できても、担当者や保守方法が決まらなければ、その点を解消してから費用を評価します。
選定会議では、各製品について次を分けて示します。
- 実行できた作業
- 追加設定で実行できる作業
- 実行方法が未確認の作業
導入時に欠かせない作業が未確認なら、説明資料上の機能名だけで可否を決めず、担当者と確認手順を定めて再試行します。実行できた作業については、公開後も同じ担当体制で続けられるかを確認してから、費用と移行条件を比べます。
最初から要件を広げすぎない
導入時は「記事更新」「フォーム送信」「営業への引き継ぎ」を一続きで実行できるか確認します。将来使う可能性のある機能は分けて記録し、必要になる条件を決めておきます。
たとえば、次の状態になったら見直します。
- 記事更新のたびに開発依頼が必要になる
- 問い合わせ情報の照合が続く
- 配信先ごとに同じ修正を繰り返す
まず現在の設定と手順で解消できるか試し、それでも担当者が業務を完了できない場合に構成の変更を検討してください。
見直し時にも同じ記事と問い合わせの作業を使えば、変更によって止まっていた業務を進められるか確認できます。
CMS移行ではURLと顧客情報を引き継ぐ
CMSを移行する場合は、ページの表示だけでなく、次を引き継ぎます。
- 旧URLからの到達先
- 検索向けの情報
- フォーム送信後の記録先
ページごとに移行先と確認担当者を決め、公開前と公開後に同じ一覧で結果を確認できるようにします。公開の判断には、作業が済んだ記録と、利用者がたどる経路を確認した結果の両方を使います。
コンテンツとSEO情報を棚卸しする
旧URL、新URL、タイトル、ディスクリプション、canonical、構造化データ、本文、画像、フォーム、問い合わせ先をページごとに記録します。移行担当者、確認担当者、確認結果の欄も設けてください。URLを維持するページと変更するページを分け、変更するページには対応する転送先を記入します。
次に、移行先のページを開いて次を照合します。
フォームは表示だけで済ませず、テスト送信した情報の記録先と通知先まで追います。表示は正しくても問い合わせを受け取れないページは、確認済みにせず、止まった箇所と修正担当者を記録します。
次の表は、検索向けの情報を引き継ぐ際の確認項目です。各行をページの対応表に照らし、実際の公開ページで確かめます。
| No. |
ポイント |
具体策 |
| 1 |
URL構造の維持 |
既存のURL構造をそのまま新CMSで再現する |
| 2 |
301リダイレクト |
URL変更が必要な場合は全ページ301リダイレクトを設定 |
| 3 |
メタタグの移行 |
title、description、canonical等を新CMSに移行 |
| 4 |
構造化データの移行 |
既存の構造化データを新CMSでも実装 |
| 5 |
Search Consoleの設定 |
新CMSでサイトマップを再送信、インデックス状況を監視 |
構造化データは、現在のページにある記述を確認し、移行後のページ内容と一致するか点検します。ページの内容や構成を変更するなら、以前の記述をそのまま移す前に対応関係を見直してください。
リダイレクトとサイトマップを確認する
URLが変わるページは、旧ページの内容に対応する新ページを転送先にします。旧URLを一律にトップページへ送るのではなく、ページごとの対応表を作ってください。転送先を決められないページは、その扱いを公開前に判断します。
公開前に旧URLから意図した新ページへ到達するかを確認し、公開後は公開サイトでも同じ経路を確かめます。サイトマップの送信後は、インデックスやエラーの状況を確認します。問題があれば、該当URL、実際の転送先、修正担当者、再確認した結果を対応表に残します。
顧客情報と営業への引き継ぎを確認する
次を順に点検します。
- フォームの入力先
- 通知先
- CRMへの登録
- 担当者の割り当て
テスト送信した情報が意図した場所に記録され、営業担当者が画面を開いて次の対応を判断できるかまで確認してください。
情報が届かない場合は、フォーム送信、通知、登録、担当者への連絡のどこで止まったかを切り分けます。
- 送信完了画面は表示されるのに記録が見つからない場合 ── 入力先と登録結果を調べます。
- 記録はあるのに担当者が気づけない場合 ── 通知先と確認する画面を調べます。
修正後に同じテストを行い、対応担当者まで情報が届いてから次の段階へ進みます。
移行作業を段階に分ける
| 段階 |
主な作業 |
次へ進む目安 |
| 準備 |
要件定義、コンテンツ棚卸し、URL設計 |
各ページの移行先と担当が決まっている |
| 構築 |
CMS設定、デザイン、コンテンツ移行 |
ページとフォームが新環境で確認できる |
| テスト |
表示、リンク、リダイレクト、SEO情報を確認 |
主要な導線と旧URLの転送先が確認できている |
| 公開 |
DNS切り替え、監視開始 |
公開サイトでページとフォームが動作している |
| 安定化 |
検索状況やエラーを確認し調整 |
発生した問題の修正と担当が明確になっている |
各段階で、作業の実施記録と、次へ進む条件を満たした確認結果を分けて残します。
- 旧URLの転送先やフォーム送信後の記録先が未確認の場合 ── たとえばテスト段階でページを表示できても、公開の判断は保留します。
- 公開日程を決める条件 ── 修正担当者が対応し、確認担当者が同じ手順で再確認できてから決めます。
日程を組む際は、次の順に進めます。
- ページを分ける ── まず対象ページの対応表を埋め、再現に開発作業が必要なページと内容確認が必要なページを分けます。
- 担当者を割り当てる ── 各ページの作業担当者と確認担当者を割り当て、確認する内容を明確にします。
URL変更、独自の表示、フォームや顧客情報の引き継ぎが必要なページは、通常の記事移行と同じ作業としてまとめず、それぞれの設定・確認を工程に入れてください。
次の表の「期間」欄は、日程を確定するための数値ではありません。実際の日程は、対象ページごとに必要な作業を並べ、担当者が着手できる順序、承認待ち、修正後の再確認を含めて決めます。
- 構築の完了見込みを出す前 ── たとえば再現方法が未定のページを洗い出します。
- テスト中に転送先やフォームの記録先に不備が見つかった場合 ── 修正と再確認を終えるまで公開へ進む条件を満たしません。
- 確認結果によって工程が増えた場合 ── 該当する段階の日程を見直します。
| フェーズ |
期間 |
作業内容 |
| 準備 |
対象範囲と確認工程を洗い出して所要期間を見積もる。確認事項が残る場合は期間を確定しない |
要件定義、コンテンツ棚卸し、URL設計 |
| 構築 |
判断材料となる長さの期間 |
CMS構築、デザイン、コンテンツ移行 |
| テスト |
期間の目安を検討する段階 |
表示崩れ、リダイレクト先、SEO設定を確認し、不備があれば修正する。ただし、この確認だけで公開後の検索順位は判断できない |
| 公開 |
公開後すぐに成果を確認しにくい場合は、一定期間を見据えて判断します。 |
DNS切り替え、監視開始 |
| 安定化 |
期間が落ち着くまで |
検索順位監視、エラー修正、微調整 |
未確定のページや連携が見つかったら、影響する段階の作業と担当者を更新します。
- テストで転送先が違った場合 ── URL対応表へ戻ります。
- フォームの記録先が違った場合 ── 設定と営業への引き継ぎ手順へ戻ります。
修正後の確認が済むまで、該当する段階の完了条件は満たしたことにしません。公開後も、問題を発見した人の連絡先と、修正結果を確認する人を決めておきます。
よくある質問
BtoB企業にはどのCMSが向いていますか?
企業様によって最適な形は異なります。まず、記事の更新担当者、問い合わせ情報の管理先、営業への引き継ぎ方法を決めてください。CRMとの連携を重視するならHubSpot CMS、既存サイトの活用やカスタマイズを重視するならWordPress、Notionで記事を管理するなら公開方法と外部連携を含む構成を比較できます。同じ記事更新とフォーム送信を試し、欠かせない作業を担当者が完了できるかで判断します。
CMSを選ぶときは何を優先すればよいですか?
記事公開から問い合わせ対応までの業務を書き出し、止まっている箇所に関係する要件から優先してください。SEO、リード獲得、CRM連携、運用性、セキュリティを確認し、それぞれに編集、開発、保守、営業の担当者を割り当てます。欠かせない作業の担当者や実行方法を決められない場合は、運用手順を整えてから同じ作業を試します。
ライセンス費が低いCMSなら、運用費も抑えられますか?
ライセンス費だけでは判断できません。WordPressでは利用するサーバーやプラグインの管理、ヘッドレスCMSでは表示部分の開発・保守が必要になる構成があります。SaaS型でも、自社の設定や連携にかかる作業を確認します。記事公開と問い合わせ対応を同じ条件にそろえ、初期構築、継続的な更新、保守について、費用と担当者を並べて比較してください。見積もりから抜けた作業は社内で担うか依頼するかを決め、実施範囲と確認方法がそろってから費用を判断します。
CMSを移行するとき、SEOのために何を確認しますか?
ページごとに旧URLと新URL、タイトル、ディスクリプション、canonical、構造化データを記録します。URLが変わる場合は、対応する新ページへの301リダイレクトを設定し、公開前後に実際の到達先を確認してください。公開後はサイトマップ、インデックス、エラーの状況を確認し、問題があるページは担当者が修正して同じURLから再確認します。
まとめ
CMSの比較は、記事を更新する人、保守する人、問い合わせ情報を確認する人、営業へ引き継ぐ人を明確にするところから始めます。それぞれ自社の作業に当てはめて確認してください。
- WordPress ── カスタマイズと保守
- HubSpot CMS ── 顧客情報を扱う業務
- Notion + Blog ── 公開方法と外部連携の管理
次の順序で進めると、比較の結果を選定に使えます。
- 記事作成、承認、公開、フォーム管理、営業への引き継ぎの担当者を記録します。
- 導入時に欠かせない業務を決め、必要な設定と保守作業を整理します。
- 比較するCMSで同じ記事更新とフォーム送信を試し、止まった箇所と解決する担当者を記録します。
- 欠かせない業務を完了できた構成について、初期構築と継続運用の作業範囲をそろえて費用を比べます。
- 移行する場合はページの対応表を作り、各段階の確認条件を満たせる作業範囲と日程を決めます。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。現在の記事公開から問い合わせ対応までの流れを一緒に整理し、CMS選定や移行で確認すべき作業、担当者、次へ進む条件を具体化できます。
あわせて読みたい
記事の企画と公開後の改善を進める際は、次の記事で外注先への依頼内容、キーワードの選び方、記事間の関係を確認できます。CMSを選ぶ前後の運用設計には、WordPressとHubSpot CMSの比較、およびオウンドメディア立ち上げの手順も役立ちます。