HubSpot Content Hubは、Webサイトの制作と、問い合わせ後の顧客対応をつなげて考えるためのコンテンツ基盤です。
「ページの文章や画像を直すたびに制作会社へ依頼している」
「Webサイトの問い合わせや閲覧情報が、営業の顧客管理と別々になっている」
「ブログやLPを作りたいが、公開後に誰がどう運用するか決まっていない」——こうした課題を整理するには、ページの作り方と公開後の情報の受け渡しを一緒に確認する必要があります。
HubSpot Content Hubでは、Webサイトやブログなどのコンテンツを作成し、HubSpot CRMの顧客情報と結び付けて運用できます。ただし、ページを作るだけで担当者への引き継ぎが整うわけではありません。どのページで何を案内し、フォームで受け取った情報を誰が確認するかまで決めることが大切です。
本記事は「AI × CRMで企業価値を上げる設計思想|経営者が知るべきAI CRM戦略」シリーズの一部です。
本記事はStartLinkの「AI活用完全ガイド」関連記事です。
この分野の体系的な情報はHubSpot機能ガイドでまとめています。
この記事でわかること
Webサイトの更新を社内で進めたい方や、問い合わせ情報を営業・マーケティングへ引き継ぎたい方に向けて、Content Hubの機能と導入時の判断手順を解説します。読み進めながら、自社で最初に公開するページ、必要な編集範囲、公開後の対応担当を具体化してください。
- Content Hubの役割 — ページ制作とCRMの情報がどこでつながり、担当者が何を確認するかを整理します。
- 導入判断の視点 — ブログやLPから始める場合と、既存サイトの移行を検討する場合の判断材料を示します。
- 立ち上げの流れ — テーマ選択から編集、公開、ドメイン接続まで、次の工程へ進む前の確認事項を説明します。
- 公開後の活用 — 閲覧やフォームの情報をどう読み取り、ページと顧客対応を見直すかを解説します。
HubSpot Content Hubはサイト運用とCRMをつなぐ基盤です
Content Hubは、Webサイトやブログ、ランディングページを作成・管理するコンテンツ基盤です。フォームや訪問者の行動をCRMのコンタクト情報と結び付けて扱う構成も取れます。
この節では、ページの公開から問い合わせ対応までの情報の流れと、どの範囲をContent Hubで運用するかの決め方を整理します。
ページ制作と顧客管理を切り離さない
Webサイトの更新と顧客情報の管理が別々だと、問い合わせを受けた担当者が内容を別の台帳へ転記する場面が生まれます。転記先が複数あると、対応状況の確認先も分かれます。
Content Hubで作成したページにフォームを置く場合は、送信内容をCRMでどう扱い、誰が確認するかをページの設計と合わせて決めます。
次の画面は、HubSpot Content Hubのトップ画面。

次の画面は、HubSpot Content Hubのテンプレート選択画面。

設計時には、ページごとに次の項目を対応付けます。
- 訪問者に伝える内容
- 期待する次の行動
- フォーム送信後の対応者
例えば相談を受けるページなら、フォーム項目が担当者の初回対応に必要な情報を集めているかを確認します。
情報が不足するなら項目や案内文を見直し、十分なら公開後の対応手順の確認へ進みます。
Content Hubの情報が顧客対応へつながる流れ
基本の流れは、訪問者がコンテンツを見てフォームから問い合わせ、コンタクトとしてCRMに記録され、相談内容に応じて取引や顧客対応へ進む形です。
Content Hubは入口となるWebサイトやコンテンツを担います。請求などの後続業務まで扱う場合は、その業務で使う機能や情報の引き継ぎを別途設計します。
次の図は、コンテンツから顧客対応への流れを考える際のイメージです。

| 段階 |
Content HubやCRMで扱う情報 |
次の運用 |
| 訪問 |
ページ閲覧やコンテンツへの反応 |
関心のあるテーマを把握します |
| 問い合わせ |
フォームの入力情報 |
コンタクト情報として対応履歴を集めます |
| 商談化 |
営業が確認した相談内容 |
必要に応じて取引として進捗を管理します |
| 顧客化 |
受注後の顧客情報 |
顧客対応や関連業務へ引き継ぎます |
この流れを自社に当てはめる際は、まず問い合わせの記録先を決め、次に対応者が確認する項目と対応状況の記録方法を決めます。
- フォーム送信後に誰が動くか決まらない ── ページの追加より先に担当分担を整えます
- 対応者が記録を見て次の行動を判断できる状態になった ── 公開するコンテンツの範囲を広げるか検討できます
すべてのページを同じ仕組みで作る必要はありません
既存サイトの全面移行を前提にせず、ブログやLPなど、目的と担当者を決めやすい範囲から始める方法があります。候補となるページについて、更新の手間、問い合わせとの関係、既存サイトへの影響を並べて比べます。
- ブログから始める ── 記事の作成・確認・公開を担当者が続けられるかを確かめます
- LPから始める ── フォーム送信後に担当者が情報を受け取れるかを確かめます
いずれも運用手順が定まらなければ対象を広げず、つまずいた工程を見直してから次のページを追加します。
テーマとモジュールで更新の仕組みを整えます
Content Hubのページは、テーマやテンプレートを基礎に、モジュールを組み合わせて構成します。
- テーマ ── ページ群のデザインやテンプレートをまとめた単位です
- モジュール ── テキスト、画像、フォームなどを配置する部品です
この節では、編集担当者が画面上で変えられる範囲を確認し、開発担当者に任せる要件を見分ける方法を説明します。
次の画面は、HubSpot Content Hubの機能一覧画面。

次の画面も、Content Hubの画面例です。

テーマはサイトの共通ルールをまとめます
テーマを選ぶときは、デザインの印象だけで決めず、実際に作るページを想定して確認します。次の点を見ます。
- 必要なページのテンプレートがあるか
- 見出しやフォームを適切な位置に置けるか
- 編集担当者が変更したい箇所を扱えるか
テーマの決め方は、次の順で進めます。
- 合うテーマが見つかったら ── 代表的なページで文章や画像の変更を試し、公開前の確認担当にもプレビューを見てもらいます
- 必要な表示が設定項目に見当たらなければ ── 別のテンプレートで実現できるかを先に比べます
- それでも満たせない要件だけ ── 変更方法と保守担当を決めて開発を検討します
モジュールを使うとページの更新を分担できます
モジュールは、ページに追加する再利用可能な部品です。テキスト、画像、ボタン、フォームなどをエディタ上で配置し、内容を編集できます。
日常的な文章や画像の変更を編集担当者が行い、共通レイアウトや新しい機能の追加を開発担当者が担う形が考えられます。
分担を決める際は、更新担当者が実際に変更する箇所を洗い出し、その箇所を編集画面で扱えるか試します。
- 扱える ── 編集手順と公開前の確認項目を共有します
- 扱えない ── 編集範囲を変えるか、部品の調整を依頼するかを決めます
ノーコード編集には範囲があります
テーマやモジュールを使う場合は、次の順で確認します。
- まず、用意されたレイアウトと設定項目で要件を満たせるか確認します
- 次に、独自の表示や外部データの利用が必要な箇所を、実際のページ単位で特定します
- 「見た目を変えたい」という要望だけでは実現方法を決めず ── どの情報を、誰が、どの画面で更新するかまで整理します
- 設定項目で対応できる ── 編集担当者による運用手順を作ります
- 対応できない ── 別の標準部品で代替できるかを確認し、それでも必要な要件を満たせない場合に開発方法と保守担当を検討します
公開後も頻繁に変える箇所ほど、編集担当者が扱える形になっているかを重視します。
導入前に目的と更新体制を決めます
Content Hubの導入判断では、作れる機能だけでなく、公開するコンテンツ、更新担当、問い合わせ後の引き継ぎ先を並べて確認します。
この節では、最初に扱うページの選び方、表計算で管理している情報の整理、CRMで扱う範囲の決め方を説明します。
運用目的から最初の対象を決めます
コーポレートサイト、ブログ、LPでは、公開する情報と更新手順が異なります。まず改善したい業務を言葉にし、それに直接関係するページを選びます。
- 記事更新を進めたい ── ブログの編集・確認・公開手順を確認します
- 問い合わせへの対応を整えたい ── LPの内容・フォーム・担当者への引き継ぎを確認します
| 導入前に決めること |
確認する内容 |
判断の目安 |
| 運用目的 |
コーポレートサイト、ブログ、LPのどれを優先するか |
まず対象を絞り、公開内容を具体化します |
| 更新体制 |
社内で更新するか、制作会社と分担するか |
編集者と公開判断者を決めます |
| CRM活用範囲 |
フォーム後の営業連携まで扱うか |
連携するなら担当者と引き継ぐ情報を定めます |
| SEO方針 |
ブログや検索流入の改善に取り組むか |
継続的に記事を更新する体制を用意します |
| 移行範囲 |
既存サイト全体か、一部ページからか |
既存サイトへの影響を抑える範囲から始めます |
| SEO方針 |
ブログや検索流入の改善に加え、構造化データやAIO対策が必要かを確認する |
記事運用を行う場合は、必要な施策と担当体制を整理します |
表の項目は、単独の可否だけでなく、担当者と運用手順を組み合わせて確認します。
- ブログを優先するなら ── 原稿の確認者と公開判断者を決め、編集から公開までの手順を試してください
- ブログで担当者を決められない場合は ── 継続的な更新を前提にした運用には向きません
- LPを優先するなら ── フォームの項目と問い合わせ後の対応者を決めてから、ページ制作に進んでください
表計算の管理情報を整理してから移します
サイトの原稿、画像、更新日、担当者を表計算ファイルで管理している場合は、管理画面へ移す前に、今後も使う情報と管理先を整理します。
- 同じページを複数の表で管理している ── どれを最新版として扱うかを決めます
- ページごとに公開目的、更新担当、フォーム後の対応先を対応付ける ── 移すべき情報が見えます
表計算をすべてなくす必要はありません。企画や一覧整理には引き続き使い、公開中のページ情報や問い合わせ対応の正本はどこに置くかを決めます。
担当者が最新版を探し回る状態なら管理先を整理し、参照先が明確になったらページの移行や作成へ進みます。
CRM連携が必要な範囲を見極めます
訪問者の行動やフォーム送信を営業活動に使うなら、ページだけでなくCRM側の情報設計も確認します。
- まず、対応者が判断に使う問い合わせ内容を挙げます
- 次に、その情報をフォームで受け取るか、対応時に確認するかを決め ── 記録先と担当者を対応付けます
一方、閲覧や問い合わせの情報を顧客対応に使わないページでは、CRM活用を導入目的の中心に置かず、ページの作成と更新体制から評価できます。企業様によって最適な形は異なります。
必要な情報の流れが説明できる範囲を先に整え、活用目的が明確になったときに対象を広げます。
Content HubでWebサイトを立ち上げる手順
立ち上げでは、テーマとテンプレートを選び、ページを編集し、必要に応じてブログやLP、アクセス範囲、ドメインを設定します。
この節では各画面で何を確認し、次の工程に進む条件をどう決めるかを順に説明します。画面上の名称は、利用中のアカウントの表示に従って確認してください。
テーマを選びページを作成します
- 新規作成を選ぶ ── HubSpotの画面で「コンテンツ」から「ウェブサイトページ」へ進みます
- テーマとページテンプレートを選ぶ ── テンプレート選択画面で選ぶと、そのレイアウトを基に編集を始められます
- 実際に作るページを想定して確認する ── 自社で使う見出し、画像、フォームを置けるかを見ます
次の画面は、HubSpot Content Hubのブログ管理画面。

テーマを決めたら、次の内容を記録します。
- ページの目的
- 想定する訪問者
- 問い合わせ後の対応先
これらが決まらない段階では、見出しやボタンの文言も判断しにくくなります。ページで促す行動が明確になったら、必要なモジュールを選んで編集へ進みます。
エディタで文章や部品を編集します
ページエディタで見出しや本文を編集し、必要に応じて画像、ボタン、フォームなどのモジュールを追加します。配置済みの部品は並べ替えや複製ができます。
編集後は、次の点を確かめます。
- プレビューで確認する ── 文章の読みやすさとスマートフォンでの見え方を確認します
- フォームを置く場合 ── 入力項目と送信後の流れも確かめます
更新を分担するなら、編集者、内容の確認者、公開判断者を決めます。
プレビューで問題が見つかった場合は、文章や配置の修正なのか、テンプレート側の調整なのかを分けて対応します。表示と問い合わせ後の扱いを確認できたら、公開判断へ進みます。
ブログやLPを追加して公開します
- ブログ ── 「コンテンツ」からブログへ進み、新しい投稿を作成します
- LPを作る場合 ── ランディングページの作成画面からテンプレートを選びます
ページとブログでテーマやテンプレートの設定が異なる場合があるため、それぞれのプレビューで見出し、画像、フォームの配置を確認します。
次の画面は、HubSpot Content Hubのページ編集画面。

公開前には、訪問者が読む内容と、行動した後の処理を続けて確認します。
- フォームがあるページなら ── 送信内容が想定した記録先で確認でき、担当者が対応を始められるかを確かめます
- 公開後に問い合わせの内容とページの案内がかみ合わなければ ── まず案内文とフォーム項目を見直します
会員向けページは公開範囲を設定します
顧客向け資料や会員限定FAQなど、対象を限定して見せるコンテンツにはメンバーシップ機能を使えます。ページ設定でアクセス範囲を指定し、対象の連絡先グループを設定する方法があります。
公開範囲を決める前に、誰に閲覧を認め、誰が対象者を管理するかを決めます。パスワードを共有する方式と連絡先グループで制御する方式では、対象者への案内と管理の手順が異なります。
- 対象者の管理方法を決められない場合 ── 限定公開の設定を進める前に運用担当を定めます
- 限定する必要がない場合 ── 通常ページとして公開する選択もあります
ドメインを接続して公開します
ページを自社ドメインで公開する場合の流れです。
- 設定画面の「ドメインとURL」からドメイン接続に進みます
- HubSpotが提示するDNSレコード情報を、ドメイン管理側の設定に反映します
- 設定後は公開ページにアクセスし、表示内容、リンク、フォームの動作を確認します
次の画面は、HubSpot Content Hubのドメイン管理画面。

すでに別のサイトで使っているメインドメインを切り替える場合は、既存サイトの表示に影響する可能性があります。次の内容をそろえてから実施します。
- 対象ドメイン
- 切り替えるページ
- 作業担当者
- 公開後の確認方法
準備が整っていなければ、既存サイトへの影響を確認しやすい範囲でブログやLPから始める方法を検討します。
公開後はコンテンツと顧客データを一緒に見直します
公開後は、ページの表示状況だけでなく、訪問者の反応と問い合わせ後の対応を合わせて確認します。
この節では、次の内容を説明します。
- 閲覧情報の読み方
- 繰り返し更新する情報の管理方法
- 開発が必要な要件の見極め方
確認する内容はサイトの目的から決め、結果に応じてページや運用手順を直します。
次の画面は、HubSpot Content HubのSEO設定画面。

閲覧と問い合わせを次の行動へつなげます
訪問履歴やフォームの情報がコンタクトに結び付くと、関心のあるページや問い合わせ内容を手掛かりに対応を考えられます。
- マーケティング ── 訪問者が読んだ内容と問い合わせ内容にずれがないかを見ます
- 営業 ── 問い合わせの背景を確認してから連絡します
行動情報をスコアリングやセグメント配信に使う場合も、まず何を判断したいのかを決め、その判断に必要な行動を選びます。
ページを見た事実だけで購買意向を断定することはできません。閲覧情報と問い合わせ内容が異なる場合は、どちらかだけを根拠に決めず、担当者とのやり取りで確認します。
- 問い合わせが担当者へ届いていない ── 引き継ぎ手順を見直します
- 内容が伝わりにくい ── ページやフォームを見直します
- 自動化を加える場合 ── 対象と条件を定め、担当者が結果を確認できる状態から始めます
HubDBは繰り返し更新する情報に使います
HubDBは、ウェビナー、事例、サービス一覧などの構造化した情報を表として管理し、Webページに表示するための機能です。
似た形式の情報を複数の場所で更新している場合、項目を共通のデータとして管理できるか検討します。
- まず、掲載情報に共通する項目を洗い出す ── 開催情報なら、ページごとに必要な項目と表示方法をそろえられるか確認します
- 項目が共通し、一覧を更新する担当者も決められる場合 ── 表の列とページ表示を設計します
- 掲載内容ごとに構成が大きく異なる場合 ── 表での管理に向かないため、通常のブログ投稿やページ編集を選びます
高度なカスタマイズは開発領域として分けます
標準テーマやモジュールで表現できない要件には、デザインマネージャーやHubLを使った開発が関係します。HubLはHubSpotのテンプレートで使う言語です。
次のような分担が考えられます。
- 開発者 ── テーマや独自モジュールを用意します
- 編集担当者 ── 公開後の文章を更新します
開発前には、必要な表示を具体的なページ上で示し、標準モジュールで代替できるかを確認します。
- 代替できない場合 ── 外部データが必要か、表示を誰が保守するか、編集担当者がどこまで変更するかを決めます
- 保守担当を決められない要件 ── 公開後の更新方法を先に整理します
- 編集担当者が扱える範囲で目的を達成できる場合 ── その運用を試してから追加開発を判断します
Content Hubの機能別の設定手順と対応条件
ここまでの判断を、実際の設定に落とします。HubSpotの製品ページでは、Content Hub(CMS)の機能として、ドラッグ&ドロップのページエディター、テーマとテンプレート、エディター内のSEO提案、無料のSSL、独自ドメインの接続、ブログ・ランディングページ・フォーム・CTA、AIによるコンテンツ作成が挙げられています。エディションごとの対応は製品ページに一覧がないため、機能ごとに公式ナレッジで条件を確認します。
機能別の対応条件の早見表
| 機能 |
公式で確認できる条件 |
運用で決めること |
| 独自ドメインの接続 |
Super AdminまたはドメインSettings権限が必要。DNSプロバイダーの操作も必要 |
DNSの担当者と切り替え日、公開後の確認方法 |
| 会員限定ページ(メンバーシップ) |
ページ・ブログはContent HubのProfessionalまたはEnterpriseが対象。アクセスグループで制御 |
対象者の追加・削除を誰が管理するか |
| HubDB(表形式のデータ) |
動的ページとHubLでの利用はProfessionalまたはEnterprise。1テーブル最大10,000行、1テーブルの動的ページは最大10 |
共通項目と更新担当者 |
| エディター内のSEO提案・トピック |
ブログ・ページのエディターから利用。トピックの関連付けはProfessional以上 |
タイトル・説明文の確認担当 |
| AIによるコンテンツ作成 |
製品ページに記載。利用にはAI設定のオンが必要 |
出典の確認と公開判断の担当 |
出典:ドメインをHubSpotに接続する、会員登録が必要な非公開コンテンツ、HubDB(HubSpot開発者ドキュメント)。料金やエディションごとの差は、公式の料金ページで最新を確認してください。
独自ドメインを接続する手順と所要時間
- 画面上部の設定(歯車)をクリックし、左サイドバーの「コンテンツ」>「ドメインとURL」を開きます。
- 「ウェブホスティング」タブで「ホスティングドメインを接続」を押し、サブドメイン・ブランドドメイン・トップレベルドメインを入力します(ルートドメインにする場合はサブドメインを空にします)。
- 「詳細オプション」で主なコンテンツの種類(ウェブサイトページ、ブログなど)を選び、「次へ」を押します。リダイレクトは自動で設定されます。
- DNSプロバイダーにサインインするか、「手動で設定する」を選び、表示された「ホスト」「必要なデータ」の値をDNSに登録します。DNS管理者が別にいる場合は「設定リンクを共有」で依頼できます。
- 「確認」を押します。サブドメイン(例:www)はCNAMEレコード、ルートドメインはAレコードを登録します。
公式ナレッジでは、DNSの反映は通常15〜80分、最大24時間かかる場合があるとされています。SSLは接続後に自動で有効になり、通常は数分、最大4時間かかります。有効になるまでは、一部の訪問者に警告が表示されることがあります。既存サイトのドメインを切り替える場合は、DNS担当者と切り替えの時間帯、確認するページを決めてから実施します。
会員限定ページを設定する手順
- 「コンテンツ」>「ウェブサイトページ」(またはランディングページ)で対象ページを開き、エディター右上の「設定」を押します。
- 左メニューの「閲覧者のアクセス(Audience Access)」を選び、「アクセスグループのメンバーシップが必要」を選びます。
- 登録を認めるアクセスグループをチェックします。グループは、手動で追加する静的なものと、条件で自動追加される動的なものがあります。
- ダイアログを閉じ、「公開」または「更新」を押します。
- テスト用のコンタクトで、登録メールが届くことと、グループ外のコンタクトが閲覧できないことを確認します。
HubDBを使うか、通常ページにするかの判断表
| 状況 |
選ぶ方法 |
確認すること |
| ウェビナー・事例・拠点など、同じ項目の一覧を複数ページに出したい |
HubDBのテーブル |
列の定義と、行を更新する担当者 |
| 一覧の1行ごとに詳細ページを作りたい |
HubDBの動的ページ(hs_path・hs_name列) |
URLの末尾が小文字になっているか。1テーブルの動的ページは最大10 |
| 掲載内容ごとに構成が大きく異なる |
通常のブログ投稿・ページ編集 |
編集担当者が更新できる範囲 |
| 更新が年に数回で、項目も少ない |
通常のページ |
表で管理する負担のほうが大きくないか |
立ち上げの30日の進め方
- 1週目:公開する目的と対象ページ(ブログ、LP、コーポレートサイトの一部)、更新担当、公開判断者、フォーム送信後の対応者を決めます。
- 2週目:テーマとテンプレートを選び、代表的な1ページで文章・画像・フォームの変更を試して、編集担当者が扱える範囲を確かめます。
- 3週目:フォームの送信内容がコンタクトに記録され、担当者が確認できることをテスト送信で確かめます。ドメイン接続は、DNS担当者の予定を押さえて実施します。
- 4週目:公開後の表示、リンク、フォームの動作を確認し、閲覧とフォーム送信の状況から次に改善するページを選びます。
StartLinkのHubSpot導入・構築支援では、現状の整理・要件定義、設計・構築、テスト・検証、定着・運用改善の順に進め、サイトは最初にブログやLPなど範囲を絞って小さく始めます。HubSpotゴールドパートナーとして150社以上のHubSpot支援に携わってきた中でも、フォーム送信後の担当と記録先を先に決めたサイトほど、公開後の運用が続きやすいと考えています。詳しくはHubSpot導入・構築支援をご覧ください。後から変えにくい設定はHubSpotで後から変えにくい設定、多言語サイトは多言語サイト構築ガイド、AI検索を意識した記事運用はAIO対策としてのHubSpot Content Hub活用法で解説しています。
Content Hubの活用が向くケースと判断基準
Content Hubを検討する際は、次のうち、どこに課題があるかを特定します。
- Webサイトの更新
- 問い合わせの受け取り
- 顧客情報の活用
この節では、営業やマーケティングへの情報の引き継ぎ、社内更新、段階的な導入について、始める条件と見直す条件を整理します。
次の画面は、HubSpot Content Hubのポッドキャスト機能。

営業やマーケティングへ情報をつなぎたい場合
Webページの問い合わせ情報をCRMで扱い、担当者や取引の管理につなげたい場合は、ページと顧客データの流れを一緒に設計します。
営業とマーケティングが別々の表や連絡手段で情報を管理しているなら、どの情報を共通で確認するか、誰が対応履歴を残すかから決めます。
- すでに別の方法で安定してサイトを運用している場合 ── 移行によって改善したい業務を具体化します
- 問い合わせ後の確認先や担当分担に課題がある場合 ── その流れを対象に比較します
- 改善したい業務が明確でない場合 ── まず現在の対応手順を整理し、移行範囲の判断はその後に行います
更新作業を社内で進めたい場合
文章や画像の変更、ブログ投稿、LPの編集を社内で分担したい場合は、担当者が実際に行う変更をテーマとモジュールで扱えるか試します。編集できる箇所だけでなく、公開前に誰が内容と表示を確認するかも決めます。
- 必要な変更が標準の部品でできる ── 編集と確認の手順を共有して運用します
- 複雑な独自デザインやシステムとの連携が必要 ── その箇所を特定し、開発担当者と公開後の保守方法を決めます
- 社内で更新したい箇所が編集画面で扱えないまま ── ページを増やす前に構成を見直します
段階的に始めて運用を確かめたい場合
最初は、目的と更新担当を決めやすいLPやブログから始めます。編集担当者がページを更新できるか、確認者が公開判断を行えるか、フォームを使う場合は問い合わせ後の担当者が情報を確認できるかを順に確かめます。
- 途中で対応が止まる ── その工程の役割や設定を見直します
- 作成から顧客対応までの流れを説明できる状態になった ── 追加するページの目的を決めて対象を広げます
- HubDBによる一覧管理 ── 共通して更新する情報と管理担当が明確になった段階で検討します
よくある質問
WordPressなどの汎用CMSとContent Hubは何が違いますか?
Content Hubでは、Webサイトの作成や編集に加えて、フォーム情報や訪問者の行動をHubSpot CRMのコンタクト情報と結び付けて扱えます。比較するときは、作りたいページをそれぞれで表現できるか、更新担当者が必要な箇所を編集できるか、問い合わせ後の情報をどこで管理するかを同じ条件で確認します。顧客対応への引き継ぎに課題があるなら、その手順まで含めて判断してください。
会員限定ページや顧客向け資料ページを作れますか?
メンバーシップ機能を使って、ページやブログのアクセス範囲を設定できます。公式ナレッジでは、ページとブログはContent HubのProfessionalまたはEnterprise(旧Marketing Hub Enterpriseを含む)が対象とされています。ページ設定の「閲覧者のアクセス」で「アクセスグループのメンバーシップが必要」を選び、静的または動的なアクセスグループで対象者を管理します。設定前に、閲覧できる人を誰が決め、対象者の追加や変更を誰が管理するかを決めてください。
標準モジュールにない機能を追加できますか?
デザインマネージャーでテーマを調整したり、HubLを使ってカスタムモジュールを開発したりする方法があります。まず必要な表示と更新方法を書き出し、標準モジュールや別のテンプレートで満たせるか確認します。独自開発が必要なら、開発担当者だけでなく、公開後の保守担当と編集担当者が変更できる範囲も決めます。
既存サイトをContent Hubへ移すときは何から確認しますか?
移すページと、切り替えるドメインの範囲から確認します。次に、各ページの更新担当、フォームの扱い、公開後の表示確認方法を整理します。既存サイトのメインドメインを切り替える場合は表示への影響があり得るため、作業担当と確認方法が決まってから進めます。準備が整っていない場合は、ブログやLPなど対象を絞る方法を検討します。
Content Hubで独自ドメインを接続するのにどのくらい時間がかかりますか?
HubSpotの公式ナレッジでは、設定(歯車)>「コンテンツ」>「ドメインとURL」から「ホスティングドメインを接続」を選び、DNSプロバイダーにレコードを登録します。サブドメインはCNAME、ルートドメインはAレコードを使います。DNSの反映は通常15〜80分、最大24時間で、SSLは接続後に自動で有効になり、通常は数分、最大4時間かかります。
まとめ
HubSpot Content Hubは、Webサイトやブログの制作と、CRMの顧客情報を使った対応をつなげて設計できる基盤です。
- 導入時は、最初に改善したい業務を決め、対象ページ、編集担当、公開判断者、問い合わせ後の対応者を対応付けます
- 次に、選んだテーマで必要なページを作れるか、担当者が更新できるか、フォームを使う場合は情報が対応者へ届くかを確認します
- 公開後に手順が止まる箇所があればそこを直し、運用できる状態になってから対象ページや機能を広げてください
次の画面は、Content Hub。

CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
このテーマと関連する内容を、次の記事でも詳しく解説しています。