HubSpot CMSのGoogleインデックス：マーケティングチームのための完全ガイド
HubSpotのコンテンツ戦略ツールとテクニカルSEOの基本を調和させて、最大の検索可視性を実現します
このガイドの内容
HubSpot CMSは、SEO推奨をコンテンツ作成に直接統合し、ピラーページを中心としたトピッククラスターを提供し、オーガニックトラフィックとリードジェネレーションを結びつけます。マーケティングチームにとって、この緊密な統合は変革的ですが、特定のインデックスの課題を生み出します。
サブドメインホスティングモデルはドメインオーソリティを分割します（blog.company.com対www.company.com）。フォームの背後にあるゲートコンテンツはGooglebotには見えません。システムページが誤ってインデックスされます。本ガイドでは、SEO推奨ツール、トピッククラスター、サイトマップ管理、HubLテンプレート、サブドメイン戦略、ゲートコンテンツの処理、システムページのクリーンアップを網羅します。
HubSpotのSEO推奨ツールとトピッククラスター
HubSpotのSEOツール（HubSpotナビゲーションのMarketing > SEO）は、トピッククラスターモデルを中心に設計されています。トピック（「メールマーケティング」のような広範なテーマ）を作成し、そのトピックの権威リソースとしてピラーページを指定し、サブトピックのブログ記事をピラーページにリンクします。HubSpotのSEO推奨ツールは各ページを分析し、実行可能な提案を提供します：メタディスクリプションの追加、H1でのターゲットキーワードの使用、ピラーページへの内部リンクの追加、画像のaltテキストの最適化など。
トピッククラスターモデルは、Googleのアルゴリズムが報いるクリアな内部リンク構造を作成するため、SEOにとって本当に効果的です。ピラーページは、リンクしているすべてのサブトピックページからオーソリティを蓄積し、サブトピックページは、リンクし返すピラーページのオーソリティから恩恵を受けます。HubSpotはこれをSEOツールでハブ＆スポーク図として視覚化し、どのサブトピックページがリンクされているか、どれが孤立しているかを示します。
SEOツールを効果的に使用するには、まずビジネスの5〜10のコアトピックを定義します。各トピックについて、トピックを広範にカバーする包括的なピラーページ（2,000語以上）を作成します。次に、各々がトピックの特定の角度を深くカバーする10〜20のサブトピックブログ記事を作成します。各サブトピック記事を書くと、HubSpotのコンテンツエディタはその記事のSEO推奨を表示します。これには、ピラーページにリンクしているかどうか、ピラーページがリンクし返しているかどうかが含まれます。
推奨ツールは、オンページSEO要因に基づいて各ページに0から100のスコアを付けます：タイトルタグの最適化、メタディスクリプションの存在と長さ、見出し構造、内部リンク、画像のaltテキスト、コンテンツの長さ。すべての公開されたページで80以上のスコアを目指します。ツールはまた、欠落しているcanonicalタグ、重複したタイトル、サイトマップにないページなどの技術的問題にフラグを立てます。
ただし、ツールには制限があります。ページ速度、構造化データ、外部バックリンクは評価しません。また、Googleが実際にページをインデックスしたかどうかも伝えません — その情報はHubSpotではなくGoogle Search Consoleにあります。SEO推奨ツールはコンテンツ最適化チェックリストとして使用しますが、実際のインデックスステータスはSearch Consoleで確認してください。
サブドメインアーキテクチャ：オーソリティ分割問題
最も一般的なHubSpot実装では、ブログにサブドメインを使用します：blog.company.com（HubSpot CMSでホスト）、一方でwww.company.comは別のプラットフォーム（WordPress、カスタムビルドなど）でホストされます。ランディングページはoffers.company.comやlanding.company.comに存在する場合があります。これは実際のSEOの問題を作り出します：ドメインオーソリティが複数のサブドメインに分割されます。
Googleはサブドメインを半分別個のエンティティとして扱います。www.company.comとblog.company.comの間にはある程度のオーソリティ共有がありますが、すべてを1つのドメインの下に持つことと同じではありません。blog.company.comのブログ記事は、ブログ記事がwww.company.com/blog/post-titleにある場合よりも、www.company.comへのバックリンクから得る恩恵が少なくなります。このオーソリティ分割は、競争の激しいキーワードで1ページ目と2ページ目にランクされるかの違いを意味する可能性があります。
理想的な解決策は、サイト全体をHubSpot CMSでホストすることです — メインウェブサイト、ブログ、ランディングページを含め、すべてwww.company.comの下に。HubSpot CMSはほとんどの企業ウェブサイトに対して十分機能的であり、すべてを1つのドメインに統合することでオーソリティの集中を最大化します。多くのHubSpot CMS Hub ProfessionalおよびEnterpriseプランは、カスタムテンプレート、サーバーレス関数、動的ページでこの設定をサポートしています。
サブドメインを使用しなければならない場合（おそらく、メインサイトが移行できないプラットフォームを使用しているため）、サブドメインの数を最小限に抑え、最高価値のコンテンツをプライマリドメインに保持してください。ブログがオーガニックトラフィックのほとんどを生成する場合、メインサイトを現在のプラットフォームに保ちながらブログトラフィックをHubSpotにルーティングするリバースプロキシを使用して、ブログをプライマリドメイン（www.company.com/blog）でホストすることを検討してください。これは技術的に複雑ですが、ドメインオーソリティを保持します。
HubSpotが導入した別のオプションは、リバースプロキシなしでプライマリドメインのサブフォルダ（www.company.com/blog/）の下にHubSpotホストコンテンツを提供できるカスタムドメインマッピング機能です。これがサブスクリプションティアで利用可能かどうかをHubSpotアカウントチームに確認してください。
アーキテクチャに関係なく、各サブドメインをGoogle Search Consoleで別々に検証してください。各サブドメインに対して別々のサイトマップを送信します。各プロパティのIndex Coverageレポートを独立して監視してください — blog.company.comのインデックスの問題は、www.company.comのSearch Consoleプロパティでは見えません。
ページレベルのSEO設定とHubLテンプレート
HubSpot CMSの各ページには、ページエディタのSettingsタブからアクセスできる個別のSEO設定があります。これらの設定は、ページタイトル、メタディスクリプション、URLスラッグ、canonical URL、注目画像（ソーシャル共有に使用）、ページがサイトマップに含まれるかどうかを制御します。
ページタイトルフィールドはHubLパーソナライゼーショントークンをサポートしますが、SEOクリティカルなページには使用しないでください。タイトルが「Welcome, {{ contact.firstname }}!」で、Googlebotが連絡先コンテキストなしでページをクロールする場合、タイトルは「Welcome, !」とコンマがぶら下がってレンダリングされます。インデックスさせたいページには、静的でキーワード最適化されたタイトルを使用してください。
URLスラッグはSettingsタブで編集可能です。HubSpotはページタイトルからスラッグを自動生成しますが、カスタマイズする必要があります：ストップワードを削除し、60文字未満に保ち、主要キーワードを含めます。ブログ記事の場合、URL構造は通常/blog/post-slugです。ウェブサイトページの場合、/page-slugまたは/subfolder/page-slugです。URLが公開されてインデックスされたら、変更を避けてください — 変更する必要がある場合、HubSpotは古いURLから新しいURLへのリダイレクトを自動的に作成します。
canonical URLフィールドはデフォルトでページ自身のURLで、ほとんどのページで正しいです。意図的な重複コンテンツがある場合にのみオーバーライドしてください — たとえば、元のランディングページにシグナルを統合すべきランディングページのバリアントなどです。HubSpotはcanonical設定を尊重し、HTMLに正しい<link rel="canonical">タグを出力します。
HubL（HubSpotのテンプレート言語）は、テンプレートレベルでメタタグを制御できます。テンプレートの<head>セクションで、カスタムメタタグ、構造化データ、条件ロジックを追加できます。たとえば、特定のフォルダのページにnoindexタグを条件付きで出力できます：{% if content.absolute_url contains '/internal/' %}<meta name="robots" content="noindex, follow">{% endif %}。このテンプレートレベルの制御は、個々のページを編集することなく多くのページにSEOルールを適用するのに強力です。
HubSpotのコンテンツステージング機能を使用すると、ステージング環境でテンプレートとコンテンツに変更を加え、公開する前にプレビューできます。これを使用して、ライブサイトのインデックスに影響を与えることなくSEOの変更（タイトルタグテンプレートの変更や構造化データの追加など）をテストしてください。
ゲートコンテンツとフォームページの処理
HubSpotのコア価値提案はリードジェネレーションです。つまり、多くのマーケティングチームは、アクセスするためにフォーム送信を必要とするコンテンツを作成します：電子書籍、ホワイトペーパー、ウェビナー、テンプレート、ツール。フォームのあるページ（ランディングページ）はGooglebotにアクセス可能ですが、フォームの背後にあるコンテンツ（メールまたはサンキューページで配信）はそうではありません。これは、SEO（アクセス可能、クロール可能なコンテンツを報いる）とリードジェネレーション（フォームの背後にコンテンツをゲート）の間の固有の緊張を生み出します。
ランディングページ自体はインデックス可能であり、適切に最適化されている場合、関連するキーワードでランクできます。ランディングページにゲートコンテンツの実質的な説明を書きます — リソースがカバーする内容、対象者、読者が学ぶ内容を説明する少なくとも300〜500語。目次や章の要約を含めます。これにより、ランディングページにランクするのに十分なユニークコンテンツが得られます。フォームの背後に完全なリソースがある場合でも。
ただし、サンキューページ（ユーザーがフォーム送信後に到達するページ）はインデックスの問題を提示します。/thank-you/ebook-nameのようなURLのサンキューページは、アクセス可能なURLを持つ通常のHubSpotページであるため、しばしばインデックスされます。検索結果でサンキューページのURLを見つけた人は誰でも、フォームを記入することなくゲートコンテンツにアクセスでき、リードジェネレーションの目標が損なわれます。
サンキューページがインデックスされるのを防ぐには、すべてのサンキューページでrobotsメタタグをnoindexに設定します。HubSpotで、ページエディタに移動し、Settingsをクリックし、「Advanced Options」までスクロールして、「Allow search engines to index this page」のチェックを外します。これにより、ページにnoindexメタタグが追加されます。すべてのシステムページ：メール購読解除ページ、メール設定センター、フォーム確認ページ、パスワード保護されたページのログイン画面に対しても同じことを行ってください。
より積極的なアプローチとして、最も重要なキーワードに対してゲートコンテンツが正しい戦略かどうかを検討してください。Googleは自由にアクセス可能なコンテンツに報い、第1位にランクされる包括的でゲートされていないガイドは、3ページ目にランクされるゲートされた電子書籍よりも多くの適格なリードを生成する可能性があります（コンテンツ内のCTAやニュースレター登録を通じて）。多くのマーケティングチームは、ベストコンテンツのゲートを解除し、SEO駆動のトップオブファネルとして使用することが、実際には総リード量を増やすことを発見しています。
パフォーマンス、トラッキングスクリプト、Core Web Vitals
HubSpot CMSには、すべてのページにJavaScriptを追加する組み込み分析トラッキングが含まれています。このトラッキングスクリプトはページビュー、フォーム送信、CTAクリックを測定し、HubSpotの分析ダッシュボードにデータをフィードします。このトラッキングはマーケティングに価値がありますが、ページロード時間に追加され、Core Web Vitalsスコアに悪影響を与える可能性があります。
HubSpotトラッキングスクリプトは非同期に読み込まれるため、初期レンダリングをブロックすべきではありません。ただし、多くのHubSpotモジュール（フォーム、CTA、チャットウィジェット、ポップアップ）を持つページでは、累積JavaScript実行がLargest Contentful Paint（LCP）とInteraction to Next Paint（INP）を不良領域に押し込む可能性があります。GoogleはCore Web Vitalsをランキングシグナルとして使用するため、遅いページは検索結果で優先度が下げられる可能性があります。
HubSpot CMSでパフォーマンスを最適化するには、SEOクリティカルなページのHubSpotモジュールの数を最小限に抑えます。チャットウィジェットを遅延ロードパターンに移動します（ページロード時ではなく、ユーザーインタラクション後にロード）。折り目下の画像にはHubSpotの遅延ロード機能を使用します。HubLテンプレートでカスタムCSSとJavaScriptを最小限に抑えます。
HubSpot CMSには、エッジロケーションからグローバルに静的アセットを提供する組み込みCDN（コンテンツデリバリーネットワーク）が含まれています。このCDNはすべてのHubSpotホストコンテンツに対して自動的に有効になり、良いベースラインパフォーマンスを提供します。ただし、CDNは動的コンテンツ（パーソナライゼーショントークン、スマートコンテンツ、A/Bテストバリアントを持つHubLページ）をキャッシュしないため、重いパーソナライゼーションを持つページは静的ページよりも遅くなります。
HubSpotを介してA/Bテストを実行するマーケティングチームは、A/Bテストバリアントが同じページに対して複数のURLを作成することに注意してください。HubSpotは、バリアントを同じURLの下で提供することにより、これを正しく処理します（別々のURL経由ではなく、サーバーサイドでコンテンツを切り替えます）。ただし、実装でこれを確認してください。テストバリアントが何らかの理由で別々のURLを作成する場合、重複コンテンツの問題を引き起こす可能性があります。
Google Search Consoleの「Core Web Vitals」レポート（Experienceの下）でCore Web Vitalsを監視してください。HubSpotページがLCPまたはINPスコアが低いことを示す場合、重いJavaScriptモジュールがないかページを監査し、それらを最適化または削除してください。HubSpotのDesign Managerを使用すると、デフォルトの機能豊富なモジュールよりもパフォーマンスの高い軽量カスタムモジュールを作成できます。
自動サイトマップとサイトマップ管理
HubSpot CMSは、ドメインのために/sitemap.xmlでXMLサイトマップを自動生成します。このサイトマップには、設定で「Allow search engines to index this page」が有効になっているすべての公開されたページ（ウェブサイトページ、ランディングページ、ブログ記事）が含まれます。ページを公開、非公開、または変更すると、サイトマップは自動的に更新されます。
HubSpotのサイトマップはコンテンツタイプ別に整理されています。ブログ記事、ウェブサイトページ、ランディングページの別々のサブサイトマップを生成し、/sitemap.xmlのメインサイトマップインデックスからリンクされます。各サブサイトマップには、最終更新日付きのURLが含まれます。
サイトマップに表示されるページを制御するには、ページレベルの設定を使用します：「Allow search engines to index this page」（ページエディタのSettingsタブ、Advanced Optionsの下）。これを「No」に設定すると、HubSpotはnoindexメタタグを追加し、サイトマップからページを除外します。インデックスさせたくないすべてのページにこの設定を使用します：サンキューページ、内部ランディングページ、テストページ、システムページ。
マルチ言語ページグループを使用するマルチ言語HubSpotサイトの場合、HubSpotは各言語バージョンに対して別々のサイトマップエントリを生成し、サイトマップにhreflangアノテーションを含めます。これは、HubSpotのマルチ言語コンテンツシステム（Content > Pages > マルチ言語バリエーションを作成）を使用して言語バリアントを作成するときに自動的に処理されます。XMLを開き、各URLに他の言語バージョン用の対応するxhtml:link要素があることを確認して、サイトマップ内のhreflangエントリを検証してください。
HubSpotのサイトマップの制限：手動で外部URLや他のサブドメインのURLを追加することはできません。サイトが複数のサブドメインにまたがる場合（別のプラットフォームのwww.company.comとHubSpotのblog.company.com）、各サブドメインには独自の別々のサイトマップがあります。両方のサイトマップをそれぞれのGoogle Search Consoleプロパティに送信してください。
HubSpotは、ページレベルでのinclude／exclude以外のサイトマップカスタマイズをサポートしていません。個々のページやコンテンツタイプにカスタム優先度を設定したり、頻度を変更したりすることはできません。より細かいサイトマップ制御が必要な場合（Googleが優先度とchangefrequencyヒントをほぼ無視するため、まれです）、HubSpotの外で補助サイトマップを生成し、ドメインでホストする必要があります。
ステップバイステップガイド
HubSpotコンテンツのインデックスギャップを監査する
Google Search Consoleを開き、HubSpotホストドメインのIndex Coverageレポートをレビューします。インデックスされたページ数を、HubSpotで公開されたページ数（Content > Pages、「Published」でフィルタリング）と比較します。インデックスされたページが公開されたページをはるかに超える場合、インデックスにシステムページ、サンキューページ、テストページが漏れている可能性があります。インデックスされたページが公開されたページよりはるかに少ない場合、Googleはすべてのコンテンツを発見またはインデックスしていません。HubSpotで、Marketing > SEOに移動し、トピッククラスターをレビューします。SEOの問題（メタディスクリプションの欠落、内部リンクなし、トピッククラスターから孤立）でフラグが立てられたページを確認します。最適化するページの優先順位付きリストを作成してください。
すべての公開ページでページレベルのSEO設定を最適化する
HubSpotで公開されたすべてのページについて、ページエディタを開き、Settingsタブをクリックします。主要キーワードを含む60文字未満のカスタムPage Titleを書きます。説得力のある価値提案を含む150〜160文字のMeta Descriptionを書きます。主要キーワードを含み、不要な単語を削除するためにURLスラッグをカスタマイズします。Googleのインデックスに表示したいすべてのページで「Allow search engines to index this page」がチェックされていることを確認します。ブログ記事の場合、Featured Imageが設定されていることを確認してください（og:imageとして使用されます）。インデックスすべきでないページ（サンキューページ、テストページ、内部ページ）については、インデックスオプションのチェックを外します。これが最も影響力のあるステップです。
トピッククラスターと内部リンクを構築する
Marketing > SEOに移動し、5〜10のコアビジネストピックに対するトピッククラスターを作成します。各トピックについて、トピックを包括的にカバーするピラーページを指定します。次に、HubSpotのトピッククラスターインターフェイスでサブトピックブログ記事をピラーページにリンクして関連付けます。各サブトピック記事のコンテンツでは、ピラーページへのコンテキストハイパーリンクを追加します。ピラーページのコンテンツでは、各サブトピック記事へのリンクを追加します。HubSpotのSEOツールには、どのサブトピックページがリンクされているか、どれが孤立しているかが表示されます。トピッククラスター内の他のページに対して、すべてのページに少なくとも3つの内部リンクが入出することを目指してください。
すべてのシステムページとサンキューページをnoindexする
インデックスすべきでないシステムページについてHubSpotページを監査します。一般的な原因：ゲートコンテンツのオファーのために作成されたサンキューページ、フォーム確認ページ、メール購読解除と設定センターのページ、パスワード保護されたページのログイン画面、A/Bテストバリアントページ。それぞれについて、ページエディタを開き、Settings > Advanced Optionsに移動し、「Allow search engines to index this page」のチェックを外します。テンプレートレベルの制御には、特定のフォルダのページ（例：/thank-you/*、/system/*）に適用される条件付きnoindexタグをHubLテンプレートに追加します。これらのページのHTMLソースで<meta name="robots" content="noindex">タグを確認して検証してください。
サブドメインオーソリティの問題に対処する
HubSpotコンテンツがメインサイト（www.company.com）とは別のサブドメイン（blog.company.com）にある場合、統合オプションを評価します。最良のオプションは、サイト全体をプライマリドメイン下のHubSpot CMSに移行することです。それが実行不可能な場合は、プライマリドメインのサブフォルダ（www.company.com/blog/）からHubSpotコンテンツを提供するリバースプロキシ設定を検討してください。サブドメインを維持する必要がある場合は、各サブドメインがGoogle Search Consoleで検証され、独自のサイトマップが送信されていることを確認します。クロスサブドメイン内部リンクを最大化します：ブログ記事からメインサイトページへ、そしてその逆へリンクします。これはオーソリティ分割を完全に解決するわけではありませんが、Googleが関係を理解するのに役立ちます。
Core Web Vitalsのためにページパフォーマンスを最適化する
最も重要なHubSpotページについて、Google Search ConsoleとGoogle PageSpeed InsightsでCore Web Vitalsスコアを確認します。LCPまたはINPスコアが低い場合、重いJavaScriptモジュールがないかページを監査します。HubSpotでの一般的なパフォーマンスの低下要因：ページロード時に読み込まれるチャットウィジェット（ユーザーインタラクションに遅延）、1つのページの複数のフォームモジュール、テンプレート内の重いカスタムJavaScript、最適化されていない画像。HubSpotの組み込み画像最適化（サポートされているブラウザにWebP画像を提供）を使用し、折り目下の画像に対して遅延ロードを有効にします。デフォルトモジュールが重すぎる場合は、HubSpotのDesign Managerで軽量カスタムモジュールを作成してください。
IndexBoltで優先ページを送信し結果を監視する
最適化を完了した後、IndexBoltを使用して最も重要なページをGoogleに送信して高速インデックスします。ピラーページ（トピッククラスターの権威ページ）、高コンバージョンのランディングページ、新しく公開されたブログ記事を優先します。サブドメインアーキテクチャを持つHubSpotサイトの場合、プライマリドメインとブログサブドメインの両方からページを送信します。Google Search ConsoleとHubSpotのTraffic Analytics（Reports > Traffic Analytics）の両方で結果を監視し、オーガニック検索トラフィックへの影響を確認します。商品ローンチページ、ウェビナー登録ページ、または遅延インデックスがリード損失を意味するその他の時間に敏感なコンテンツには、IndexBoltのInstantモードを使用してください。
よくある問題と解決方法
サブドメインのブログがドメインオーソリティを希釈する
原因： HubSpotのデフォルト設定は、ブログをサブドメイン（blog.company.com）でホストし、メインウェブサイトはwww.company.comにあります。Googleはこれらを半分別個のエンティティとして扱うため、ブログへのバックリンクはメインドメインへのオーソリティの恩恵を減少させ、その逆も同様です。競争の激しいニッチでは、このオーソリティ分割は、1ページ目と2ページ目のランキングの違いを意味する可能性があります。
解決方法： すべてのコンテンツをwww.company.comに置く単一ドメインアーキテクチャに移行します。これが実行不可能な場合は、リバースプロキシを使用して、www.company.com/blog/からHubSpotコンテンツを提供します。最低でも、クロスサブドメイン内部リンクを増やし、両方のサブドメインがGoogle Search Consoleで検証され、別々のサイトマップが送信されていることを確認してください。
サンキューページとシステムページがGoogleにインデックスされる
原因： HubSpotのサンキューページ（フォーム送信用）、メール設定センター、購読解除ページ、その他のシステムページは、デフォルトでインデックスが有効になって公開されます。これらのページには固有のURLがあり、Googlebotがアクセスできるため、サイトの品質シグナルを希釈する薄く低価値のコンテンツとしてGoogleのインデックスに入ります。
解決方法： HubSpotのページエディタで各システムページを開き、Settings > Advanced Optionsに移動し、「Allow search engines to index this page」のチェックを外します。テンプレートレベルの制御には、特定のURLパターンに一致するページに対してnoindexメタタグを出力するHubL条件をテンプレートの<head>セクションに追加します。Google Search ConsoleのIndex Coverageレポートで、すり抜けるシステムページを監視してください。
フォームの背後のゲートコンテンツがGooglebotに見えない
原因： フォーム送信後に配信されるコンテンツ（電子書籍、ホワイトペーパー、ツール）は、検索エンジンには完全に見えません。フォームのあるランディングページはクロール可能ですが、実際のコンテンツアセットはフォームゲートの背後にあります。Googleはフォームに記入できないため、ゲートコンテンツは決してインデックスされません。ランディングページ自体は、よくランクするには独自のコンテンツが少なすぎる可能性があります。
解決方法： ランディングページ自体に実質的なコンテンツを追加します：リソースを説明する300〜500語、目次、主要な統計や要点、お客様の声。これにより、ランディングページにランクするのに十分なユニークコンテンツが得られます。最高価値のコンテンツについては、完全にゲート解除し、代わりにコンテンツ内CTAをリードキャプチャに使用することを検討してください。第1位にランクされるゲート解除された包括的なコンテンツは、通常、3ページ目にランクされるゲートコンテンツよりも多くのリードを生成します。
HubSpotのトラッキングスクリプトがCore Web Vitalsを劣化させる
原因： HubSpotの分析トラッキングコード、チャットウィジェット、フォームモジュール、ポップアップCTA、その他のマーケティングモジュールを組み合わせると、ページに大量のJavaScriptが追加されます。累積JavaScript実行はLargest Contentful Paintを遅らせ、Interaction to Next Paintを劣化させ、Core Web Vitalsスコアを不良範囲に押し込みます。
解決方法： SEOクリティカルなページでHubSpotモジュールを最小限に抑えます。ユーザーインタラクションまでチャットウィジェットの読み込みを遅延します（ページロード時にロードする代わりにIntersectionObserverトリガーを備えたカスタムモジュールを使用）。SEOトラフィックが主目的であるページからポップアップCTAを削除します。HubSpotのDesign Managerを使用して、重いデフォルトモジュールを置き換える軽量カスタムモジュールを作成します。Search ConsoleでCore Web Vitalsを監視し、反復してください。
マルチ言語ページにhreflangアノテーションが欠落している
原因： HubSpotはマルチ言語ページグループを通じてマルチ言語コンテンツをサポートしますが、hreflangアノテーションは、HubSpotのマルチ言語コンテンツシステムを使用してページが言語バリアントとして適切にリンクされている場合にのみ生成されます。公式の言語バリアント機能を使用せずに各言語に対して手動で別々のページを作成した場合、hreflangタグは生成されません。
解決方法： HubSpotの公式マルチ言語コンテンツ機能を使用します：ページエディタで地球アイコンをクリックして言語バリアントを作成します。これにより、HTMLとサイトマップに hreflangタグが自動的に生成されます。すでに各言語に別々のページがある場合は、適切な言語バリアントグループに統合します。ページソースを表示し、<head>セクションに<link rel="alternate" hreflang="xx" href="...">タグがあることを確認して、hreflangタグを検証してください。
プロのヒント
よくある質問
HubSpot CMSは自動的にSEOを処理しますか？+
HubSpot CMSは強力なSEO基盤を提供します：自動サイトマップ、SSL、canonicalタグ、コンテンツ最適化を導く組み込みSEO推奨ツール。ただし、メタディスクリプションを自動的に書いたり、内部リンクを構築したり、検索のためにコンテンツを構造化したりはしません。SEO推奨ツールは何を修正するかを伝えますが、変更を手動で実装する必要があります。HubSpot CMSは、ガイド付き最適化提案を備えた優れたSEOインフラを提供すると考えてください。完全に自動化されたSEOではありません。
なぜ私のHubSpotブログがメインドメインではなくサブドメインにあるのですか？+
HubSpotのデフォルト構成は、ほとんどのHubSpotの顧客がメインウェブサイトに別のプラットフォームを使用しているため、ブログをサブドメイン（blog.company.com）でホストします。これは、既存のウェブサイトに接続したマーケティングプラットフォームとしてのHubSpotの起源からの歴史的なパターンです。プライマリドメインを使用するには、サイト全体をHubSpot CMSに移行するか、リバースプロキシを使用してプライマリドメインのサブフォルダからHubSpotコンテンツを提供できます。サブスクリプションティアで利用可能なドメイン統合オプションについては、HubSpotアカウントチームに相談してください。
HubSpot CMSページに構造化データをどのように追加しますか？+
HubSpotのDesign Managerで、ページテンプレートを編集し、HubLテンプレート変数を使用して<head>セクションにJSON-LDスクリプトブロックを追加します。ブログ記事の場合、headlineにcontent.name、datePublishedにcontent.publish_date、URLにcontent.absolute_urlを使用してArticleスキーマを出力します。商品またはサービスページには、適切なSchema.orgタイプを使用します。HubSpot CMS Hub ProfessionalとEnterpriseは、サーバーサイドで動的構造化データを生成できるサーバーレス関数もサポートしています。常にGoogleのRich Results Testを使用して出力を検証してください。
どのHubSpotページがサイトマップに表示されるかを制御できますか？+
はい、個別のページレベルで。ページエディタで、Settings > Advanced Optionsに移動し、「Allow search engines to index this page」を切り替えます。無効にすると、ページはサイトマップから除外され、noindexメタタグを受け取ります。ただし、HubSpotのサイトマップでカスタム優先度を設定したり頻度を変更したりすることはできません — これらはプラットフォームによって自動的に制御されます。HubSpotのサイトマップに外部URLを追加したり、コンテンツタイプ別にカスタムサイトマップセグメントを作成したりすることもできません。
HubSpotのトピッククラスターモデルはGoogleインデックスにどのように役立ちますか？+
トピッククラスターは、Googleがコンテンツ階層を理解するのに役立つクリアな内部リンク構造を作成します。15のサブトピックブログ記事にリンクされたピラーページ（およびその逆）は、Googleに強力なトピック関連性シグナルを送信します。内部リンクは、Googlebotが関連するすべてのページを効率的に発見してクロールするのに役立ちます。Googleのアルゴリズムは、トピックの深さとオーソリティをますます報います — これはクラスターモデルが構築するものです。重要なのは実行です：クラスター内のすべてのページがピラーページと他の関連サブトピックページにリンクし、すべてのリンクがコンテキスト的（コンテンツに埋め込まれており、単なるサイドバーウィジェットではない）でなければなりません。
ベストコンテンツをゲートすべきか、SEOのためにオープンのままにすべきですか？+
これはビジネスモデルに依存しますが、傾向はトップオブファネルコンテンツのゲート解除に向かっています。競争の激しいキーワードで第1位にランクされる、自由にアクセス可能な包括的なガイドは、3ページ目にランクされるゲートされた電子書籍よりも多くの総リードを生成します（コンテンツ内CTA、ニュースレター登録、ブランド認知を通じて）。読者がすでにブランドを認識しているミドルオブファネルコンテンツ（ケーススタディ、ROI計算機、デモアクセス）にはゲートを予約してください。SEOには、Googleが完全なコンテンツをクロール、インデックス、ランクできるため、ゲート解除コンテンツが常に勝ちます。