技術系B2BサイトのSEO対策とGoogle広告の進め方

SEO と Google 広告の相談では、次のような話がよく混ざります。

• まず SEO をやるべきか、広告をやるべきか
• 記事を増やせば検索流入は伸びるのか
• AI で記事を量産してもよいのか
• Google 広告はホームに流せばよいのか
• Search Console と Google 広告はどう使い分けるのか
• 問い合わせを増やしたいのに、PV だけ増えて終わるのはなぜか

この話は、単に SEO が大事 とか 広告が早い だけでは整理できません。 実際には、どんな問い合わせを取りたいのか、どのページで転換させるのか、何をコンバージョンとして測るのか で、ほぼ決まります。

flowchart TB
    accTitle: SEOと広告の進め方を決める3つの問い
    accDescr: SEOが大事か広告が早いかではなく、どんな問い合わせを取りたいのか、どのページで転換させるのか、何をコンバージョンとして測るのかという3つの問いで進め方がほぼ決まることを示す図。
    q1["どんな問い合わせを 取りたいのか"] --> q2["どのページで 転換させるのか"]
    q2 --> q3["何をコンバージョン として測るのか"]
    q3 --> r1["SEOと広告の進め方が ほぼ決まる"]

図1: 施策の議論より先に、この3つの問いを決めると整理できる。

この記事では、SEO と Google 広告を 別々の施策 としてではなく、同じ検索需要を別の角度から取りに行く仕組み として整理します。 特に、KomuraSoft / comcomponent.com のような 技術系 B2B サイト を念頭に、Google の公式情報を前提にした実務寄りの進め方をまとめます。^1234567

この記事の読み方

長い記事なので、目的別の入口を先に置いておきます。

この記事で使う用語

マーケティング側の用語がまとまって出てくるので、先に一行ずつ整理しておきます。

1. まず結論

先に結論を並べておくと、実務での進め方はだいたいこうなります。

• SEO と Google 広告は どちらか一方を選ぶもの ではなく、意図の違う検索を別々に取りに行くもの です。
• SEO で大事なのは、検索エンジン向けの小手先 よりも、人に役立つページを、Google が見つけて理解しやすい形にすること です。Google 自身も、helpful, reliable, people-first content と Search Essentials を基本線として示しています。³²
• Google は多くのページを自動発見できますが、内部リンク、サイトマップ、適切なタイトル、説明、URL、構造化データ は、発見と理解を助けます。^113141516
• 逆に、robots.txt で非公開にしようとする、似たページを大量に作る、AI で価値の薄い記事を量産する、タイトルや説明を全ページで使い回す といった運用は相性が悪いです。^1721814
• Google 広告で最初にやるべきことは、入札テクニックではなく 計測の整備 です。Google 公式でも、正確なコンバージョンデータ、強いタグ基盤、enhanced conversions、Consent Mode を重視しています。⁴⁶⁷
• 検索広告の運用は、コンバージョン設計 → ランディングページ → キーワード / 検索語句 → 広告文 → 入札 の順で見るほうが崩れにくいです。
• Google は Smart Bidding + broad match + responsive search ads を推していますが、これは 正しいコンバージョン計測が前提 です。計測が弱いまま広げると、ただの無駄打ちになりやすいです。⁴¹¹
• 技術系 B2B サイトでは、広く浅いアクセス よりも、少なくても意図の濃い検索 を取りに行くほうが自然です。 具体的には、Windowsアプリ開発、既存Windowsソフトの改修・保守、技術相談・設計レビュー、既存資産活用・移行支援 のような サービスページ を主役にし、その周辺に 技術記事 と 事例 を置く構成が強いです。
• 要するに、SEO は資産作り、Google 広告は需要の刈り取りと仮説検証 と見ると整理しやすいです。

flowchart TB
    accTitle: SEOと広告の役割の見方
    accDescr: SEOとGoogle広告はどちらか一方を選ぶものではなく、意図の違う検索を別々に取りに行くものであり、SEOは資産作り、Google広告は需要の刈り取りと仮説検証と見ると整理しやすいことを示す図。
    s0["同じ検索需要"] --> s1["SEO"]
    s0 --> s2["Google広告"]
    s1 --> s3["資産作り （蓄積しやすい）"]
    s2 --> s4["需要の刈り取りと 仮説検証（早い）"]
    s3 --> s5["意図の違う検索を 別々に取りに行く"]
    s4 --> s5

図2: SEOは資産作り、広告は刈り取りと仮説検証という分担で見る。

この記事の知識マップ

この記事は、技術系B2BサイトにおけるSEOとGoogle広告の役割分担を整理した実務ガイドです。SEOはGoogleが示すhelpful contentやSearch Essentials、Core Web Vitals、mobile-first indexingといった基本要件を満たすことを前提とし、内部リンクやcanonical URL、構造化データ、サイトマップで検索エンジンの理解を助けます。Google広告はコンバージョン計測を出稿前の土台とし、enhanced conversionsやConsent Modeで精度を上げ、キーワードのマッチタイプやスマート自動入札、レスポンシブ検索広告を組み合わせて運用します。両者は検索語句レポートを介して需要を相互に反映し合い、技術系B2Bサイトでは記事や事例に囲まれたサービスページが問い合わせを生む主役として推奨されます。

flowchart LR
    accTitle: SEOとGoogle広告の知識マップ
    accDescr: SEOがhelpful contentやSearch Essentials、Core Web Vitals、mobile-first indexingといった検索エンジン向けの基本要件を満たすことを前提にし、Google広告がコンバージョン計測を土台にキーワードのマッチタイプや自動入札を組み合わせ、両者が検索語句レポートとサービスページを介して連携する関係を示す図です。
    seo["SEO(検索エンジン最適化)"]
    google_ads["Google広告"]
    helpful_content["people-first content(人のためのコンテンツ)"]
    search_essentials["Google Search Essentials"]
    scaled_content_abuse["scaled content abuse"]
    internal_link["内部リンク"]
    canonical_url["canonical URL"]
    xml_sitemap["サイトマップ"]
    robots_txt["robots.txt"]
    noindex["noindex"]
    core_web_vitals["Core Web Vitals"]
    mobile_first_indexing["mobile-first indexing"]
    structured_data["構造化データ(Structured Data)"]
    search_console["Google Search Console"]
    conversion_tracking["コンバージョン トラッキング"]
    enhanced_conversions["enhanced conversions"]
    consent_mode["Consent Mode"]
    smart_bidding["スマート自動入札"]
    keyword_match_type["キーワードのマッチタイプ"]
    responsive_search_ads["レスポンシブ検索広告(Responsive Search Ads)"]
    quality_score_ads["品質スコア"]
    landing_page_experience["ランディングページの品質(Landing Page Experience)"]
    search_terms_report["検索語句レポート"]
    service_page["サービスページ"]
    helpful_content -->|"推奨される対応"| seo
    search_essentials -->|"推奨される対応"| seo
    scaled_content_abuse -->|"両立しない"| helpful_content
    seo -->|"利用する"| internal_link
    seo -.->|"利用する"| canonical_url
    seo -->|"利用する"| xml_sitemap
    seo -->|"利用する"| robots_txt
    robots_txt -->|"用いるのは非推奨"| noindex
    core_web_vitals -->|"推奨される対応"| seo
    mobile_first_indexing -->|"推奨される対応"| seo
    seo -->|"利用する"| structured_data
    seo -->|"利用する"| search_console
    conversion_tracking -->|"推奨される対応"| google_ads
    conversion_tracking -.->|"利用する"| enhanced_conversions
    conversion_tracking -.->|"利用する"| consent_mode
    google_ads -.->|"利用する"| smart_bidding
    smart_bidding -.->|"前提とする"| conversion_tracking
    google_ads -->|"利用する"| keyword_match_type
    keyword_match_type -.->|"前提とする"| conversion_tracking
    google_ads -->|"利用する"| responsive_search_ads
    google_ads -->|"利用する"| quality_score_ads
    quality_score_ads -->|"利用する"| landing_page_experience
    google_ads -->|"利用する"| search_terms_report
    search_terms_report -->|"推奨される対応"| seo
    service_page -->|"推奨される対応"| seo

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全25件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. SEO と Google 広告は何が違うのか

SEO と Google 広告は、同じ検索画面に出ることがあります。 でも、運用の性質はかなり違います。

技術系 B2B サイトでは、特にこの差がはっきり出ます。

たとえば、

• Windows アプリ開発 受託
• COM ActiveX 移行
• 既存 Windows ソフト 改修
• 技術相談 設計レビュー Windows

のような検索は、検索回数自体は大きくなくても、問い合わせ意図がかなり濃い です。 こういう語は Google 広告とも相性がよく、SEO でもサービスページを中心に取りにいく価値があります。

一方で、

• VBA とは
• WPF WinForms 違い
• 管理者権限 いつ必要
• Media Foundation カメラ 列挙

のような語は、今すぐ外注したい人 と 単に調べている人 が混ざります。 この層は SEO の記事で取り、その記事からサービスページや問い合わせへ自然に流すほうが効きやすいです。

商談に近い検索は広告でも取り、周辺の学習・比較需要は SEO で拾う。この役割分担が、一番現実的です。

flowchart TB
    accTitle: 検索意図ごとの取り方
    accDescr: 問い合わせ意図が濃い商談に近い検索は広告でも取り、サービスページでも取りにいく価値があり、今すぐ外注したい人と単に調べている人が混ざる学習・比較の検索はSEOの記事で取り、記事からサービスページや問い合わせへ流すのが現実的な役割分担であることを示す図。
    k1{"検索の意図は"}
    k1 -->|"商談に近い・意図が濃い"| a1["広告でも取り、サービス ページでも取りにいく"]
    k1 -->|"学習・比較で人が混ざる"| a2["SEOの記事で取る"]
    a2 --> a3["記事からサービスページや 問い合わせへ流す"]

図3: 高意図は広告とサービスページ、混ざる層は記事で受けて流す。

3. SEO のベストプラクティス

3.1 まず「検索エンジン向け」ではなく「人向け」で考える

Google Search Central の基本線はかなり明確です。 Google の自動ランキングシステムは、人のために作られた、役に立ち、信頼できる情報 を優先する方向で設計されています。³

また、Search Essentials では、ユーザーを欺いたり、ランキングを不自然に操作したりする行為 がスパムポリシーの対象になると示されています。²

この前提から、SEO ではまず次を決める必要があります。

1. このページは 誰の、どの場面 のためのページか
2. その人は検索時点で 何を知りたい / 何をしたい のか
3. このページを読んだあと、何を次にしてほしい のか

ここが曖昧だと、

• キーワードを詰め込んだだけのページ
• 何のための記事か分からない記事
• 検索流入はあるが問い合わせにつながらない記事

が増えます。

flowchart TB
    accTitle: 書く前に決める3点
    accDescr: SEOではまず、このページは誰のどの場面のためか、その人は検索時点で何を知りたいのか、読んだあと何を次にしてほしいのかを決める必要があり、ここが曖昧だとキーワードを詰め込んだだけのページや問い合わせにつながらない記事が増えることを示す図。
    p1["誰の、どの場面の ためのページか"] --> p2["検索時点で何を知りたい / 何をしたいのか"]
    p2 --> p3["読んだあと、次に 何をしてほしいのか"]
    p3 -.-> p4["曖昧なままだと流入は あっても問い合わせに届かない"]

図4: 人向けのSEOは、書く前にこの3点を決めることから始まる。

特に技術系サイトでは、広い一般論 よりも 具体的な困りごと に寄せたほうが強いです。

たとえば、

• 「Windows 開発とは」
• 「C# とは」

のような巨大テーマに広く触るより、

• 「Windows の管理者特権が必要になるのはいつなのか」
• 「VBA はこれから使えなくなるのか」
• 「Media Foundation でカメラから画像を取ってくる方法」

のように、検索理由がはっきりしたテーマ のほうが、SEO 的にも商談導線的にも扱いやすいです。

3.2 AI で記事を量産すればよいわけではない

Google は、生成 AI の利用そのものを一律に否定していません。 一方で、価値を加えない大量生成コンテンツ は、scaled content abuse の観点からスパムポリシーに抵触しうると明示しています。¹⁸

この線引きは、実務でも軽く見ないほうがよいところです。

AI を使うなら、

• 構成案の整理
• 比較軸の洗い出し
• たたき台の作成
• 表現の圧縮 / 展開
• FAQ 候補の抽出

には向いています。

でも、次がないと弱いです。

• 自社なりの判断
• 実案件でよく出る論点
• 失敗パターン
• 具体的な前提条件
• 誰に相談が向いているか、向いていないか

つまり、AI を使うなら、原稿工数を減らすために使うのであって、価値の代わりにしてはいけない ということです。

flowchart TB
    accTitle: AIの使いどころと線引き
    accDescr: AIは構成案の整理やたたき台の作成には向いているが、自社なりの判断や実案件でよく出る論点、失敗パターンといった価値が加わっていないと弱く、価値を加えない大量生成コンテンツはscaled content abuseの観点からスパムポリシーに抵触しうることを示す図。
    a1["AIに任せてよいこと"] --> a2["構成案・比較軸・ たたき台・FAQ候補"]
    b1["人が足すべき価値"] --> b2["自社なりの判断・実案件の 論点・失敗パターン"]
    a2 --> c1["原稿工数を減らす 道具として使う"]
    b2 --> c1
    a2 -.-> c2["価値を加えない量産は スパムポリシー抵触リスク"]

図5: AIは工数削減の道具であって、価値の代わりにはならない。

3.3 ページの役割を分ける

SEO で成果が出にくいサイトは、ページの役割が混ざっていることが多いです。 技術系 B2B サイトなら、少なくとも次の 4 層に分けると整理しやすいです。

役割と導線を図にすると、こうなります。サービスページを真ん中に置き、記事と事例でその周りを囲む形です。

flowchart LR
    Q1["学習・比較の意図での検索<br/>例 WPF と WinForms の違い"] --> A["技術記事<br/>検索の入口をつくる"]
    Q2["相談先を探す意図での検索<br/>例 既存 Windows ソフト 改修"] --> S["サービスページ<br/>問い合わせを取る主役"]
    AD["Google 広告"] --> S
    A --> S
    A --> C["事例ページ<br/>本当に進められるかの証拠"]
    C --> S
    S --> F["問い合わせ / 会社情報<br/>最後の不安を減らす"]
    C --> F

図6: サービスページを真ん中に置き、記事と事例が周りから流し込む4層の導線。

矢印の向きが大事です。記事は事例とサービスページへ流し、事例はサービスページと問い合わせへ流す。逆に、サービスページから記事へ読者を送り返す導線を主にすると、せっかく相談意図で来た人を情報収集へ戻してしまいます。

1. サービスページ

問い合わせを取りにいく主力ページです。

例:

• Windowsアプリ開発
• 技術相談・設計レビュー
• 既存Windowsソフトの改修・保守
• 既存資産活用・移行支援

ここでは、 何を支援するのか、誰に向くのか、どんな進め方か、どんな案件と相性がよいか を明確にします。

2. 事例ページ

「本当にこの会社で進められそうか」を判断するための証拠です。

• どんな背景か
• 何が難しかったか
• 何を残し、何を変えたか
• 結果どうなったか

を出せると強いです。

3. 技術記事

検索流入の入口です。 ただし、PV のための記事 ではなく、将来の相談テーマに近い記事 を中心にします。

4. 問い合わせ / 会社情報

最後の不安を減らすページです。 実名、拠点、対応範囲、相談の入り口、相談時に必要な情報が分かると、転換しやすくなります。

3.4 内部リンクはかなり重要

Google は、リンクを ページ発見の手段 と 関連性の手がかり として使うと説明しています。¹⁹

そのため、技術記事を書いたら終わりではなく、

• 親となるサービスページへリンクする
• 関連事例へリンクする
• 関連する比較記事へリンクする
• 最終的に問い合わせや関連サービスへつなぐ

という流れを作る必要があります。

とはいえ、リンクを単に増やせばよいわけではありません。大事なのは、何のページに進むのかが分かるアンカーテキストで、文脈の中に自然に置くこと です。¹⁹

「こちら」「詳しくはこちら」ばかりより、

• 既存Windowsソフトの改修・保守
• 技術相談・設計レビュー
• COM / ActiveX を含む既存資産の段階移行

のように、進み先の意味が分かるリンクのほうが強いです。

flowchart TB
    accTitle: 内部リンクの置き方
    accDescr: Googleはリンクをページ発見の手段と関連性の手がかりとして使うため、技術記事から親サービスページや関連事例へつなぐ流れを作る必要があり、リンクは単に増やすのではなく、進み先が分かるアンカーテキストで文脈の中に自然に置くことが大事であることを示す図。
    l1["リンクはページ発見の手段 かつ関連性の手がかり"] --> l2["記事から親サービス・事例・ 比較記事へつなぐ"]
    l2 --> l3{"アンカーテキストは"}
    l3 -.->|"こちら・詳しくはこちら"| l4["進み先が分からず弱い"]
    l3 -->|"進み先の意味が分かる語"| l5["文脈の中で自然に効く"]

図7: 内部リンクは数ではなく、進み先が分かる置き方が効く。

3.5 タイトル、メタディスクリプション、URL は雑にしない

Google はタイトルリンクを自動生成しますが、<title> 要素を含む複数の情報源から判断しており、各ページに明確で簡潔なタイトルを付けること を推奨しています。¹³

また、スニペットはページ本文から自動生成されることが多いものの、ページをより正確に説明する場合は meta description が使われることがある とされています。さらに、Google は ページごとに固有の説明 を付けることを推奨しています。¹⁴

URL についても、Google は 分かりやすく論理的で、人間に理解しやすい構造 を推奨しており、 説明的な語を使うこと、audience の言語を使うこと、単語はハイフンで区切ること、不要なパラメータを減らすこと を勧めています。²⁰

実務では、次の線を守るだけでもかなり違います。

• ページごとに固有タイトルを付ける
• タイトルは何のページか一目で分かるものにする
• メタディスクリプションはページ固有にする
• URL は読める形にする
• 同じ内容を複数 URL で出さない

特にブログでは、記事タイトル、H1、meta description、一覧タイトル が微妙にズレていると、検索結果でもサイト内でも分かりにくくなります。

flowchart TB
    accTitle: タイトル・説明・URLで守る線
    accDescr: ページごとに固有のタイトルと固有のメタディスクリプションを付け、URLは読める形にし、同じ内容を複数URLで出さないという線を守るだけでもかなり違い、記事タイトル・H1・meta description・一覧タイトルがズレていると検索結果でもサイト内でも分かりにくくなることを示す図。
    t1["ページごとに固有の タイトルと説明を付ける"] --> t2["URLは読める形にする"]
    t2 --> t3["同じ内容を複数URLで 出さない"]
    t3 --> t4["検索結果でもサイト内でも 何のページか一目で分かる"]
    t1 -.-> t5["タイトル・H1・説明・ 一覧のズレは混乱のもと"]

図8: タイトル・説明・URLをページ固有にそろえるだけでも効果は大きい。

3.6 重複 URL と canonical を放置しない

Google は、同じ内容を複数 URL で見られる場合、代表 URL を canonical として選びます。 自分で canonical を明示しないと、Google 側が自動判断します。¹²

そのため、

• /page
• /page/
• ?utm_source=...
• 並び替えやフィルタ違い
• 大文字 / 小文字違い
• HTTP/HTTPS や www あり / なし の混在

のような状態は、意外とじわじわ効きます。

内部リンクもサイトマップも、自分が canonical にしたい URL に統一 しておくのが基本です。¹²¹⁵

flowchart TB
    accTitle: 重複URLとcanonicalの扱い
    accDescr: 同じ内容が末尾スラッシュ違いやパラメータ違いなど複数のURLで見られるとき、canonicalを自分で明示しないとGoogle側が自動で代表URLを選ぶため、canonicalを明示し、内部リンクもサイトマップもそのURLに統一するのが基本であることを示す図。
    c1["同じ内容が複数のURLで 見られる状態"] --> c2{"canonicalを 明示しているか"}
    c2 -->|"明示する"| c3["自分が決めた代表URLに 評価が集まる"]
    c2 -.->|"明示しない"| c4["Google側が自動で選ぶ"]
    c3 --> c5["内部リンクもサイトマップも 同じURLに統一する"]

図9: 代表URLは自分で決めて、リンクもサイトマップもそこへ揃える。

3.7 サイトマップと robots.txt を正しく使う

Google は多くのサイトを自動で発見できますが、サイトマップは 「どの URL を正規として見せたいか」 のヒントになります。Search Console から送信すれば、Googlebot がサイトマップを読んだ日時や処理エラーも見やすくなります。¹¹⁵

一方で、robots.txt は クロール制御のための仕組み であって、検索結果から消す仕組みではありません。Google も、検索結果に出したくないページは noindex やパスワード保護を使うべきだと説明しています。¹⁷

ここはかなり誤解されやすいです。

• クロールさせたくない → robots.txt
• 検索結果に出したくない → noindex / 認証
• スニペットの一部だけ制御したい → nosnippet / data-nosnippet / max-snippet

という切り分けです。¹⁴²¹

flowchart TB
    accTitle: robots.txtとnoindexの切り分け
    accDescr: robots.txtはクロール制御のための仕組みであって検索結果から消す仕組みではなく、クロールさせたくないならrobots.txt、検索結果に出したくないならnoindexや認証、スニペットの一部だけ制御したいならnosnippetなどを使うという切り分けを示す図。
    r0{"何をしたいのか"}
    r0 -->|"クロールさせたくない"| r1["robots.txt"]
    r0 -->|"検索結果に出したくない"| r2["noindex / 認証"]
    r0 -->|"スニペットだけ制御"| r3["nosnippetなどの指定"]
    r1 -.-> r4["robots.txtは検索結果から 消す仕組みではない"]

図10: 誤解されやすいrobots.txtは、目的別にnoindexや認証と使い分ける。

3.8 モバイルと表示速度は「別テーマ」ではない

Google は mobile-first indexing を使い、モバイル版の内容をもとにインデックスとランキングを行います。さらに、レスポンシブデザインを推奨しています。²²

見るべきは「スマホでも見える」かどうかだけではなく、

• モバイルでも主要コンテンツがある
• デスクトップとモバイルで内容がほぼ等価
• モバイルで noindex になっていない
• 主要コンテンツがユーザー操作しないと出ない形になっていない
• 画像や構造化データ、タイトル、説明も mobile 側にある

という点です。²²

また、Google は Core Web Vitals を 実世界のユーザー体験を測る指標 と位置づけ、良好な状態を強く推奨しています。²³

SEO のためだけに速度改善する、というより、広告でも自然検索でも離脱が減る基盤 として見るほうが実務的です。

flowchart TB
    accTitle: モバイルと表示速度の位置づけ
    accDescr: Googleはmobile-first indexingでモバイル版の内容をもとにインデックスとランキングを行い、Core Web Vitalsを実世界のユーザー体験を測る指標として良好な状態を推奨しているため、速度改善はSEOのためだけでなく広告でも自然検索でも離脱が減る基盤として見るのが実務的であることを示す図。
    m1["mobile-first indexing"] --> m2["モバイル版の内容で インデックスとランキング"]
    m3["Core Web Vitals"] --> m4["実世界のユーザー体験を 測る指標"]
    m2 --> m5["広告でも自然検索でも 離脱が減る基盤"]
    m4 --> m5

図11: モバイル対応と速度は、SEO専用の話ではなく流入全体の基盤。

3.9 構造化データは「魔法」ではないが、やる価値はある

Google は、構造化データをページ理解とリッチリザルトに使うと説明しています。 ただし、正しく書けば必ず表示されるわけではない とも明示しています。¹⁶²⁴

そのため、構造化データは 書けば勝ち ではなく、書くべきものを正しく書く のが重要です。

技術系 B2B サイトなら、少なくとも次が候補です。

• Organization 会社名、ロゴ、URL、連絡先、SNS など²⁵
• Article ブログ記事のタイトル、著者、日付、画像など²⁶
• LocalBusiness 実拠点や営業時間を前面に出す場合²⁷

ここでの注意点は明確です。

• そのページの 見えている内容 と一致させる
• 空ページや hidden content のためにマークアップしない
• Rich Results Test と URL Inspection で確認する
• structured data は eligible にするだけで、表示保証ではないと理解する

flowchart TB
    accTitle: 構造化データの正しい期待値
    accDescr: 構造化データはページ理解とリッチリザルトの手がかりになるが、正しく書けば必ず表示されるわけではなく、見えている内容と一致させ、Rich Results TestとURL Inspectionで確認し、eligibleにするだけで表示保証ではないと理解して使うべきであることを示す図。
    s1["構造化データを書く"] --> s2["見えている内容と 一致させる"]
    s2 --> s3["Rich Results Testと URL Inspectionで確認"]
    s3 --> s4["リッチリザルトの対象に なり得る（eligible）"]
    s4 -.-> s5["表示保証ではない"]

図12: 構造化データは「書けば勝ち」ではなく、正しく書いてeligibleにするもの。

3.10 Search Console で見て、次のページを決める

Google は Search Console の Performance レポートで、検索クエリ、ページ、国ごとの表示回数・クリック数など を見られると説明しています。²⁸

SEO は、書いた直後よりも、出たデータを見て直す ほうが効きます。

特に見るとよいのは、

• 表示は多いがクリック率が低いページ → タイトル / description / intent のズレを疑う
• クリックはあるが問い合わせに近づかないページ → CTA と内部リンクを疑う
• 関連クエリが増えてきたページ → 続編記事や比較記事を出す
• 重要サービスページの表示自体が少ない → 内部リンク、事例、周辺記事で補強する

という流れです。

flowchart TB
    accTitle: 出たデータで直すループ
    accDescr: SEOは書いた直後よりも出たデータを見て直すほうが効き、表示は多いがクリック率が低いページはタイトルや意図のズレを疑い、クリックはあるが問い合わせに近づかないページはCTAと内部リンクを疑い、関連クエリが増えたページは続編を出し、重要ページの表示が少なければ内部リンクや周辺記事で補強するという流れを示す図。
    d0["Search Consoleを見る"] --> d1["CTR低い→タイトルを疑う"]
    d0 --> d2["転換しない→CTAを疑う"]
    d1 --> d3["クエリ増→続編を出す"]
    d2 --> d4["表示少→内部リンクで補強"]
    d3 --> d0
    d4 --> d0

図13: SEOは書いて終わりではなく、データを見て直すループで効いてくる。

「クリック率が低い」は何 % からなのか

ここで必ず出てくる質問がこれです。

正直なところ、業種や検索語をまたいで通用する絶対的な閾値は、Google からは公表されていません。同じ CTR 3% でも、平均掲載順位が 1 位なら明らかに低く、9 位ならむしろ普通です。外から持ってきたベンチマーク値を当てはめると、たいてい誤診します。

代わりに、自サイトの中で相対比較して基準線を作る ほうが実用的です。Search Console の Performance レポートは、クエリやページごとに表示回数、クリック数、CTR、平均掲載順位を同時に出せます。²⁸

画面としては、左メニューの「検索パフォーマンス」から「検索結果」を開き、上部の指標カードで「平均 CTR」と「平均掲載順位」を表示に加えたうえで、下部の「ページ」タブを見ます。手順はこうです。

1. 期間を 3 か月程度に広げ、表示回数が一定数以上あるページだけ に絞る（表示回数が少ないと CTR は簡単に跳ねます）
2. 平均掲載順位でグループを作る（1〜3 位、4〜10 位、11 位以下など）
3. 同じ順位グループの中で、自サイトの CTR の中央値を出す
4. その中央値を明確に下回っているページを「低い」として調査対象にする

順位グループを分けるのが肝です。これをやらないと、「順位が低いから CTR も低いだけ」のページを、タイトルの問題だと勘違いします。

flowchart TB
    accTitle: 自サイト内でCTRの基準線を作る手順
    accDescr: 絶対的なCTRの閾値は公表されていないため、期間を3か月程度に広げて表示回数が一定数以上のページに絞り、平均掲載順位でグループを作り、同じ順位グループの中で自サイトのCTRの中央値を出し、それを明確に下回るページを調査対象にするという手順を示す図。
    e1["期間を広げ、表示回数が 一定数以上のページに絞る"] --> e2["平均掲載順位で グループを作る"]
    e2 --> e3["同じ順位グループ内で CTRの中央値を出す"]
    e3 --> e4["中央値を明確に下回る ページを調査対象にする"]
    e2 -.-> e5["順位グループを分けないと 順位のせいのCTR低下を誤診"]

図14: CTRの高低は外部の閾値ではなく、自サイトの順位グループ内で比べる。

同じ考え方は、逆側の判断にも使えます。「表示回数が多いのに、そのページが自社のどのサービスにもつながっていない」なら、内部リンクの問題です。CTR の数字を見る前に、そのページから次にどこへ行けるかを見たほうが早いこともあります。

3.11 AI Overviews / AI Mode の時代でも、やることは基本的に同じ

Google の最新ガイドでも、AI features に出るための 特別なスキーマや専用最適化は不要 で、既存の SEO ベストプラクティスがそのまま重要だとされています。²¹

AI 時代だからといって、

• 謎の AI 向けタグを足す
• AI 用の別ファイルを作る
• AI 要約だけを意識した不自然な文章にする

必要はありません。

むしろ Google の説明は逆で、

• crawl を許可する
• 内部リンクで見つけやすくする
• 重要コンテンツをテキストで持つ
• page experience を整える
• 構造化データを visible text と一致させる

といった基本を勧めています。²¹

また、AI features からの流入も Search Console の全体データに含まれます。²¹ したがって、SEO の見方自体を大きく変えるより、検索全体で役立つページを作る 方向のほうが自然です。

flowchart TB
    accTitle: AI時代のSEOでやること
    accDescr: AI featuresに出るための特別なスキーマや専用最適化は不要で、crawlを許可し、内部リンクで見つけやすくし、重要コンテンツをテキストで持ち、page experienceを整え、構造化データを見えるテキストと一致させるという既存のSEOの基本がそのまま重要であることを示す図。
    n1["AI向けの特別なタグや 専用ファイル"] -.-> n2["不要"]
    n3["既存のSEOの基本"] --> n4["crawl許可・内部リンク・ テキストで持つ"]
    n4 --> n5["page experienceと 構造化データの一致"]
    n5 --> n6["検索全体で役立つ ページを作る"]

図15: AI Overviewsの時代でも、やることは既存のSEOの基本と同じ。

3 章の要点

• 誰の、どの場面のためのページかを決めてから書く。ここが曖昧なページは、流入があっても問い合わせに届かない
• AI は原稿工数を減らすために使うのであって、価値の代わりにはできない
• ページの役割を サービス / 事例 / 記事 / 問い合わせ の 4 層に分け、記事から事例とサービスへ流す
• 内部リンクは「こちら」ではなく、進み先が分かるアンカーテキストで置く
• タイトル、meta description、URL、canonical はページ固有にする
• 出たデータで直す。CTR の高低は外部の閾値ではなく、同じ順位グループ内の中央値と比べて判断する

4. Google 広告のベストプラクティス

4.1 最初にやるのは「広告」ではなく「計測」

Google Ads の公式ガイドでも、まず重視されているのは 正確なコンバージョンデータをもとに自動入札を回すこと です。⁴¹¹

ここでいうコンバージョンは、技術系 B2B サイトなら単なる pageview ではありません。

たとえば、

• 問い合わせフォーム送信
• 資料請求
• 相談予約
• 電話発信
• 初回面談設定
• MQL / SQL 到達
• 受注見込みのあるオフライン転換

のように、事業にとって意味のある行動 を置く必要があります。

flowchart TB
    accTitle: コンバージョンに置くもの
    accDescr: 技術系B2Bサイトのコンバージョンは単なるページビューではなく、問い合わせフォーム送信や資料請求、相談予約、初回面談設定のような事業にとって意味のある行動を置く必要があり、それを土台に自動入札が回ることを示す図。
    v0["コンバージョンの定義"] -.->|"置かない"| v1["単なるpageview"]
    v0 -->|"置くべきもの"| v2["問い合わせ送信・資料請求・ 相談予約などの行動"]
    v2 --> v3["正確なコンバージョンデータ を土台に自動入札が回る"]

図16: 最初に決めるのは、事業にとって意味のある行動としてのコンバージョン。

さらに Google は、計測基盤として次を明示的に勧めています。

• 強い tagging foundation
• enhanced conversions
• Consent Mode
• conversion value の送信
• 自社にとっての source of truth を Google Ads へ取り込むこと

⁴⁶⁷

結局のところ、広告運用の土台は、

タグが正しく入っているか 同意管理と整合しているか 本当に見たい転換を計測しているか

です。

ここが弱いまま、キーワードや入札だけ触っても改善幅は小さいです。

flowchart TB
    accTitle: 広告運用の土台の3問
    accDescr: 広告運用の土台は、タグが正しく入っているか、同意管理と整合しているか、本当に見たい転換を計測しているかの3つであり、ここが弱いままキーワードや入札だけ触っても改善幅は小さいことを示す図。
    f1["タグが正しく 入っているか"] --> f2["同意管理と 整合しているか"]
    f2 --> f3["本当に見たい転換を 計測しているか"]
    f3 --> f4["ここが土台"]
    f4 -.-> f5["弱いままキーワードや入札を 触っても改善幅は小さい"]

図17: 最初にやるのは広告ではなく、この3問で計測を固めること。

4.2 enhanced conversions と Consent Mode は後回しにしない

Google は enhanced conversions を、計測精度を改善し、より強力な入札を可能にする機能 と説明しています。 これは、メールアドレスなどの first-party customer data をハッシュ化して送る仕組みです。⁶

また、Consent Mode は、ユーザーの同意状態を Google に伝え、タグの挙動を調整する仕組み とされています。 Consent Mode 自体が同意バナーを提供するわけではなく、自社のバナー / CMP と連携して動きます。⁷

現場では、この 2 つを「大企業向け」と見て後回しにしがちです。 でも、いまはむしろ逆で、小さいアカウントほど観測可能なデータを丁寧に積むこと が重要です。

flowchart TB
    accTitle: enhanced conversionsとConsent Modeの位置づけ
    accDescr: enhanced conversionsはメールアドレスなどのfirst-partyデータをハッシュ化して送り計測精度を改善する機能で、Consent Modeはユーザーの同意状態をGoogleに伝えてタグの挙動を調整する仕組みであり、どちらも大企業向けではなく小さいアカウントほど先に整えるべきであることを示す図。
    g1["enhanced conversions"] --> g2["ハッシュ化した first-partyデータを送る"]
    g3["Consent Mode"] --> g4["同意状態を伝えて タグの挙動を調整"]
    g2 --> g5["観測可能なデータを 丁寧に積む"]
    g4 --> g5
    g5 -.-> g6["小さいアカウントほど 後回しにしない"]

図18: この2つは「大企業向け」ではなく、小さいアカウントほど先に整える。

4.3 キーワードより先に、ランディングページを決める

Google 広告はキーワードの話に見えますが、実際には どの検索意図を、どのページへ送るか が先です。

Google も、ランディングページ体験を Quality Score の要素の 1 つとし、 ページの usefulness / relevance / navigation などが関係すると説明しています。さらに、最終 URL の landing page と display URL は同一ドメインである必要があります。⁸⁹

したがって、技術系 B2B サイトでは、まず次を決めるほうが先です。

• Windowsアプリ開発 を探している人はどのページへ送るか
• 既存Windowsソフトの改修 を探している人はどのページへ送るか
• 技術相談・設計レビュー を探している人はどのページへ送るか
• COM / ActiveX 移行 を探している人はどのページへ送るか

これを決めないまま広告を出すと、だいたい 全部ホームへ流す ことになります。 そして、その構成はかなり弱いです。

flowchart TB
    accTitle: キーワードより先にランディングページ
    accDescr: Google広告はキーワードの話に見えるが、実際にはどの検索意図をどのページへ送るかが先で、ランディングページ体験はQuality Scoreの要素でもあり、送り先を決めないまま広告を出すと全部ホームへ流すかなり弱い構成になることを示す図。
    h1["どの検索意図を どのページへ送るか"] -->|"先に決める"| h2["意図ごとに受け皿の ページが決まる"]
    h1 -.->|"決めないまま出稿"| h3["全部ホームへ流す 弱い構成になる"]
    h2 --> h4["LP体験はQuality Scoreの 要素の1つでもある"]

図19: 広告はキーワードより先に、意図と送り先ページの対応を決める。

4.4 広告グループは「検索意図」と「LP」で切る

細かすぎる分割も、雑すぎる分割も良くありません。 技術系 B2B なら、次のように 意図と LP をそろえる 切り方が扱いやすいです。

• Windowsアプリ開発系
• 既存ソフト改修系
• 技術相談 / 設計レビュー系
• 既存資産移行系

この切り方の利点は、次がそろうことです。

• 検索語句
• 広告文
• LP 見出し
• 事例
• 問い合わせ CTA

逆に、1 つの広告グループに

• Windows アプリ開発
• COM 移行
• 不具合調査
• VBA 連携
• 産業用カメラ

を全部入れると、何が刺さったのか見えにくくなります。

flowchart TB
    accTitle: 広告グループの切り方
    accDescr: 広告グループは検索意図とランディングページをそろえて切ると、検索語句・広告文・LP見出し・事例・問い合わせCTAがそろい、逆に異なるテーマを1つの広告グループに全部入れると何が刺さったのか見えにくくなることを示す図。
    i1["検索意図とLPで 広告グループを切る"] --> i2["検索語句・広告文・ LP見出しがそろう"]
    i2 --> i3["事例と問い合わせCTA まで一本の線になる"]
    i4["異なるテーマを 1グループに全部入れる"] -.-> i5["何が刺さったのか 見えにくくなる"]

図20: 広告グループは意図とLPの単位でそろえて切る。

4.5 Responsive Search Ads は「とりあえず 1 本」では弱い

Google は、各広告グループに少なくとも 1 本、Ad Strength が Good または Excellent の Responsive Search Ad を入れること をベストプラクティスとして案内しています。⁵

ただし、単に headline の数を埋めることが目的ではありません。

技術系 B2B なら、たとえば次の軸で variation を作ると強くなります。

• 誰向けか 例: 既存 Windows ソフトの改修に
• 何を解決するか 例: 全面刷新せず段階移行
• 何が強みか 例: COM / ActiveX / 32bit / 64bit に対応
• どう進めるか 例: まず設計整理から相談可能
• CTA 例: 技術相談はこちら

広告文は 検索語の言い換え にとどめず、相談する理由の圧縮版 として作るのがよいです。

flowchart TB
    accTitle: レスポンシブ検索広告のvariationの作り方
    accDescr: レスポンシブ検索広告は見出しの数を埋めることが目的ではなく、誰向けか・何を解決するか・何が強みか・どう進めるか・CTAという軸でvariationを作り、検索語の言い換えではなく相談する理由の圧縮版として広告文を作ると強くなることを示す図。
    j0["見出しの数を埋める"] -.-> j1["それ自体は目的ではない"]
    j2["variationの軸"] --> j3["誰向けか・何を解決するか"]
    j2 --> j4["何が強みか・どう進めるか・CTA"]
    j3 --> j5["相談する理由の圧縮版 としての広告文"]
    j4 --> j5

図21: RSAは軸を持ってvariationを作り、相談する理由を圧縮して伝える。

4.6 Smart Bidding は強いが、前提を外すと危うい

Google は Smart Bidding を、コンバージョンやコンバージョン値に最適化する自動入札 と説明しており、auction-time signals を使って入札を最適化するとしています。¹¹

また、Google のアカウント設定ベストプラクティスでは、broad match, Smart Bidding, responsive search ads の組み合わせ が推されています。⁴

ただし、ここで重要なのは順番です。

• コンバージョン定義が雑
• タグが壊れている
• LP が弱い
• 問い合わせの質が低い
• 何を価値とみなすか決まっていない

この状態で broad match を広く使うと、学習の材料が悪いまま自動化を強めることになります。

そのため、現実的には次の順で考えると崩れにくいです。

1. コンバージョンを定義する
2. タグと Consent Mode を整える
3. LP を整える
4. 高意図テーマでキャンペーンを始める
5. 検索語句を見ながら無駄を削る
6. そのうえで自動化を強める

flowchart TB
    accTitle: 自動化を強める前の順番
    accDescr: コンバージョンを定義し、タグとConsent Modeを整え、LPを整え、高意図テーマでキャンペーンを始め、検索語句を見ながら無駄を削り、そのうえで自動化を強めるという順番で考えると崩れにくく、計測が弱いままbroad matchを広げると悪い材料のまま自動化を強めることになることを示す図。
    o1["1. コンバージョンを定義"] --> o2["2. タグとConsent Mode を整える"]
    o2 --> o3["3. LPを整える"]
    o3 --> o4["4. 高意図テーマで始める"]
    o4 --> o5["5. 検索語句を見て 無駄を削る"]
    o5 --> o6["6. そのうえで 自動化を強める"]
    o1 -.-> o7["計測が弱いまま広げると 悪い材料で学習する"]

図22: Smart Biddingとbroad matchは、この順番を守ってから強める。

4.7 Search terms report は必ず見る

Google は search terms report を、広告を発火させた実際の検索語とその成果を知るレポート と説明しています。 さらに、creative や landing page の改善アイデアにも使えるとしています。²⁹

ここは広告運用の要所です。

このレポートを見ると、

• 思った通りの検索で出ているか
• 余計な検索に出ていないか
• LP の文言と検索意図がずれていないか
• 新しく切り出すべきテーマがないか

が見えてきます。

また、Search terms insights は語句をテーマや subtheme でまとめて見せてくれるため、需要のまとまり を見るのに向いています。²⁹

つまり広告は、集客手段であると同時に、需要調査の装置 でもあります。

flowchart TB
    accTitle: search terms reportの使い方
    accDescr: search terms reportでは広告を発火させた実際の検索語とその成果が分かり、思った通りの検索で出ているか、余計な検索に出ていないか、LPの文言と検索意図がずれていないか、新しく切り出すべきテーマがないかが見えるため、広告は集客手段であると同時に需要調査の装置でもあることを示す図。
    p1["search terms report を見る"] --> p2["実際の検索語と 成果が分かる"]
    p2 --> p3["余計な検索や 意図ずれを見つける"]
    p2 --> p4["新しく切り出すべき テーマを見つける"]
    p3 --> p5["広告は集客手段かつ 需要調査の装置"]
    p4 --> p5

図23: 検索語句レポートは広告運用の要所で、需要調査の装置にもなる。

4.8 Quality Score は「診断」に使う

Google は Quality Score を、広告品質を把握するための診断ツール と説明しており、 KPI ではなく、オークションの入力値でもない と明示しています。⁹

この位置づけは見落とされがちですが、大事なところです。

Quality Score を見る意味はあります。 ただし、それは 改善点の方向を見るため です。

見るべきは主に次です。

• expected CTR
• ad relevance
• landing page experience

⁹

Quality Score 自体を追いかけるのではなく、

• 広告文が intent に合っているか
• LP が役立つか
• 検索語に対して promise が合っているか

を直すための補助情報として使うのが自然です。

flowchart TB
    accTitle: Quality Scoreの正しい使い方
    accDescr: Quality ScoreはKPIでもオークションの入力値でもない診断ツールであり、expected CTR・ad relevance・landing page experienceを見て、広告文が意図に合っているか、LPが役立つかを直すための補助情報として使うのが自然であることを示す図。
    q0["Quality Score"] -.-> q1["KPIやオークション 入力値ではない"]
    q0 --> q2["診断ツールとして見る"]
    q2 --> q3["expected CTR / ad relevance / LP experience"]
    q3 --> q4["広告文とLPを直すための 補助情報に使う"]

図24: Quality Scoreは追いかける数字ではなく、直す場所を探す診断。

4 章の要点

• 順番は コンバージョン定義 → タグと Consent Mode → LP → キーワード / 検索語句 → 広告文 → 入札
• コンバージョンは pageview ではなく、問い合わせ送信や相談予約のような事業上の行動を置く
• enhanced conversions と Consent Mode は「大企業向け」ではない。小さいアカウントほど先に整える
• 広告グループは検索意図と LP でそろえて切る
• Smart Bidding と broad match は強いが、計測が弱いままだと悪い材料で学習する
• search terms report は運用の要所であり、同時に需要調査の装置でもある
• Quality Score は KPI ではなく診断ツール。見るのは expected CTR、ad relevance、landing page experience

5. SEO と Google 広告をどう連携させるか

SEO と Google 広告は、別チーム・別施策として分断されやすいです。 でも、実務で強いのは 同じ検索需要を両方から理解している状態 です。

5.1 広告で分かった需要を SEO に返す

Google 広告では search terms report がすぐ見えます。 そこで反応が良かった検索テーマは、SEO の記事やサービスページ強化の優先候補になります。²⁹

たとえば広告で、

• 既存 windows ソフト 改修
• activeX 移行
• windows アプリ 設計レビュー

が強いと分かったなら、SEO 側でも

• サービスページ見出し
• 事例タイトル
• 技術記事テーマ
• FAQ
• meta description

に反映しやすくなります。

flowchart TB
    accTitle: 広告で分かった需要をSEOへ返す
    accDescr: search terms reportで反応が良かった検索テーマは、SEO側のサービスページ見出し・事例タイトル・技術記事テーマ・FAQ・meta descriptionへ反映する優先候補になることを示す図。
    r1["search terms reportで 反応の良い語が分かる"] --> r2["SEOの優先候補になる"]
    r2 --> r3["サービスページ見出しや 事例タイトルへ反映"]
    r2 --> r4["技術記事テーマ・FAQ・ meta descriptionへ反映"]

図25: 広告で見えた需要は、SEO側の見出し・記事・FAQに返す。

5.2 SEO で育てたページが広告の成約率を支える

逆に、SEO で作ったページ群は、Google 広告でも効きます。

たとえば LP に、

• 関連技術記事
• 導入事例
• FAQ
• 代表者や会社情報
• 相談の進め方

があると、広告経由の訪問でも不安を減らしやすくなります。

SEO は無料流入のためだけのものではなく、広告の landing page experience と説得材料を強くする 資産でもあるわけです。

flowchart TB
    accTitle: SEO資産が広告を支える
    accDescr: SEOで作った関連技術記事・導入事例・FAQ・会社情報・相談の進め方がLPの周りにあると、広告経由の訪問でも不安を減らしやすく、SEOは無料流入のためだけでなく広告のlanding page experienceと説得材料を強くする資産でもあることを示す図。
    s1["SEOで育てたページ群"] --> s2["関連記事・事例・FAQ・ 会社情報"]
    s2 --> s3["広告経由の訪問でも 不安が減る"]
    s3 --> s4["landing page experience と説得材料が強くなる"]

図26: SEOで育てた資産は、広告の成約率を支える側でも働く。

5.3 Search Console と Google 広告で「同じテーマ」を見る

Search Console では、どんな query で表示され、どのページがクリックされたかを見られます。²⁸ Google 広告では、どんな検索語で広告が表示され、どれが conversion したかが見えます。²⁹

この 2 つを並べると、同じテーマについて

• SEO で強いのか
• 広告で強いのか
• 両方弱いのか
• サービスページより記事が先に評価されているのか

が見えます。

この比較は、次の優先順位を決めるのにかなり便利です。

flowchart TB
    accTitle: Search Consoleと広告で同じテーマを見る
    accDescr: Search Consoleではどんなqueryで表示されどのページがクリックされたかが見え、Google広告ではどんな検索語で広告が表示されどれがconversionしたかが見えるため、2つを並べると同じテーマがSEOで強いのか広告で強いのか両方弱いのかが分かり、次の優先順位を決めやすいことを示す図。
    t1["Search Console （query・ページ・クリック）"] --> t3["同じテーマを 並べて見る"]
    t2["Google広告 （検索語・conversion）"] --> t3
    t3 --> t4["SEOで強い / 広告で強い / 両方弱いが分かる"]
    t4 --> t5["次の優先順位が決まる"]

図27: 同じ検索需要の2つの見え方を並べると、優先順位が見えてくる。

6. 技術系 B2B サイトなら、何を主役にするべきか

技術系 B2B サイトは、EC やメディアとは勝ち方が違います。

検索ボリュームが大きい一般ワードよりも、

• 問題が深い
• 単価が高い
• 比較検討が長い
• でも検索数は多くない

というテーマが多いからです。

そのため、主役は サービスページ です。 記事は主役ではなく、サービスページを強くする周辺資産 として使うほうが噛み合います。

6.1 サービスページを最初に強くする

技術系サイトで多い失敗は、ブログ記事だけ増えて、サービスページが薄いことです。

でも実際に問い合わせが欲しいなら、最初に強くするべきなのは、3.3 の第 1 層に挙げたサービスページです。 つまり、今すぐ相談先を探している人が着地するページ です。

ここで必要なのは、

• 何を頼めるか
• どんな案件に向くか
• どんな進め方か
• 何を残し、何を変える考え方か
• 相談時に何を伝えればよいか

です。

flowchart TB
    accTitle: 最初に強くするのはサービスページ
    accDescr: 技術系サイトで多い失敗はブログ記事だけ増えてサービスページが薄いことであり、問い合わせが欲しいなら、今すぐ相談先を探している人が着地するサービスページを最初に強くするべきであることを示す図。
    u1["ブログ記事だけ増える"] -.-> u2["サービスページが薄いと 問い合わせに届かない"]
    u3["今すぐ相談先を 探している人"] --> u4["着地するのは サービスページ"]
    u4 --> u5["何を頼めるか・進め方・ 相性を明確にする"]

図28: 記事より先に、相談者が着地するサービスページを強くする。

6.2 事例ページは強い

技術系案件は、文章だけでなく 前例 がかなり効きます。

• 既存資産を捨てずにどう進めたか
• 32bit / 64bit をどこで越えたか
• 不具合調査をどう切り分けたか
• UI / 通信 / バックグラウンド処理をどう分けたか

のような話は、営業資料より事例のほうが伝わることが多いです。

SEO 的にも、事例は 固有情報 が多く、似たページになりにくいです。

6.3 ブログは「客寄せ」ではなく「判断材料」にする

技術記事は、PV を取りに行くより 相談の一歩手前の判断材料 に寄せるほうが強いです。

たとえばこんな役割分担です。

• 比較記事 例: WinForms / WPF / WinUI の選び方
• 判断記事 例: VBA は置き換えるべきか
• 問題解決記事 例: 管理者権限が必要になるのはいつか
• 実装記事 例: Media Foundation でカメラから画像を取る方法

このような記事は、SEO の入口になるだけでなく、 「この会社は表面的な話ではなく、実務の論点で考えている」と伝わります。

flowchart TB
    accTitle: ブログ記事の役割
    accDescr: 技術記事はPVを取りに行くより相談の一歩手前の判断材料に寄せるほうが強く、比較・判断・問題解決・実装の記事はSEOの入口になるだけでなく、実務の論点で考えている会社だと伝わることを示す図。
    w0["技術記事の狙い"] -.->|"寄せない"| w1["PVのための客寄せ"]
    w0 -->|"寄せる"| w2["相談の一歩手前の 判断材料"]
    w2 --> w3["SEOの入口になる"]
    w2 --> w4["実務の論点で考えている 会社だと伝わる"]

図29: 記事は客寄せではなく、判断材料として書くと入口と信頼の両方になる。

6.4 これを自社に置き換える手順

ここまでの説明も、次の 7 章も、例として comcomponent.com を使っています。 ただし、やること自体は業種が変わっても同じです。次の 4 ステップで自社版に置き換えられます。

ステップ 1: 提供しているものを、発注側の言葉で洗い出す

社内の呼び方ではなく、相談してくる人が使う言葉 で書き出します。ここで社内用語や製品コード名を使うと、以降の検索意図の仮説がまるごとずれます。

粒度の目安は 1 サービス = 1 つの強い相談意図 です。細かく割りすぎると受け皿ページが薄くなり、粗すぎると検索意図と噛み合いません。

ステップ 2: サービスごとに、検索意図の仮説を立てる

洗い出した各サービスについて、次の表を 1 枚ずつ埋めます。この時点では仮説でよく、正解である必要はありません。あとで search terms report と Search Console が答え合わせをしてくれます。²⁹²⁸

仮に業務用の在庫管理システムを作っている会社なら、「既存システムの改修」というサービスに対して、状況は「作り直す予算はないが、いまの業者が対応してくれない」、検索語は「在庫管理システム 改修 委託」「基幹システム 引き継ぎ 開発会社」あたり、という埋め方になります。

ステップ 3: 検索語を「相談意図」と「学習意図」に仕分ける

ステップ 2 で出した検索語を、2 章の分け方に沿って振り分けます。

判断に迷う語は、実際にその語で検索して 上位に出ているページの型 を見ると早いです。サービス紹介ページばかりなら相談意図、解説記事ばかりなら学習意図です。

ステップ 4: 足りないページを 1 つだけ決めて着手する

全部そろえようとすると、たいてい途中で止まります。ステップ 2 の表で「着地させたいページが存在しない」と書いた行のうち、いちばん相談意図が濃いもの 1 つ から作ります。

ここまで決まったら、9 章の 90 日プランにそのまま合流できます。

flowchart TB
    accTitle: 自社に置き換える4ステップ
    accDescr: 提供しているものを発注側の言葉で洗い出し、サービスごとに検索意図の仮説を立て、検索語を相談意図と学習意図に仕分け、足りないページを1つだけ決めて着手するという4ステップで自社版に置き換え、90日プランに合流できることを示す図。
    v1["ステップ1: 発注側の言葉で 提供物を洗い出す"] --> v2["ステップ2: サービスごとに 検索意図の仮説を立てる"]
    v2 --> v3["ステップ3: 相談意図と 学習意図に仕分ける"]
    v3 --> v4["ステップ4: 足りないページを 1つだけ決めて着手"]
    v4 --> v5["90日プランに合流"]

図30: 業種が変わってもやることは同じで、この4ステップで自社版になる。

7. comcomponent.com ならこう組む

ここからは、6.4 の 4 ステップを実際に 1 社へ当てはめるとどうなるかの例です。 自社に読み替えるときは、サービス名と検索意図の中身だけを差し替えれば、構造はそのまま使えます。

comcomponent.com は、すでに

• サービスページ
• 技術事例
• 技術ブログ
• お問い合わせ

という基本の構造を持っています。 この土台はかなり良いです。

ここから問い合わせにつなげるには、次の組み方が自然です。

7.1 まず、主力サービスごとに検索意図を固定する

サービスページを中心に、次のテーマを明確化します。

Windowsアプリ開発

取りたい検索意図:

• 新規で Windows ソフトを作りたい
• 装置連携ツールを作りたい
• 監視 / 通信 / 帳票を含む業務アプリを作りたい

技術相談・設計レビュー

取りたい検索意図:

• 方針整理だけ相談したい
• 実装前に設計を見てほしい
• 既存資産を残す / 包む / 置き換える判断がほしい

既存Windowsソフトの改修・保守

取りたい検索意図:

• 作り直しではなく改修したい
• 既存ソフトを延命したい
• 障害対応しながら少しずつ整えたい

既存資産活用・移行支援

取りたい検索意図:

• COM / ActiveX / OCX を含む構成を整理したい
• 32bit / 64bit 問題を越えたい
• 段階移行の橋を作りたい

このように、1 サービスページ = 1 つの強い相談意図 で見ると、SEO も広告もぶれにくくなります。

flowchart TB
    accTitle: 1サービスページ=1つの強い相談意図
    accDescr: 主力サービスごとに取りたい検索意図を固定し、1サービスページに1つの強い相談意図を対応させると、SEOも広告もぶれにくくなることを示す図。
    x1["主力サービスページ"] --> x2["取りたい検索意図を 1つに固定する"]
    x2 --> x3["SEOの見出し・記事の 束ね方が決まる"]
    x2 --> x4["広告の語群と 送り先が決まる"]
    x3 --> x5["SEOも広告もぶれない"]
    x4 --> x5

図31: 意図を1つに固定したサービスページが、SEOと広告の共通の軸になる。

7.2 記事はサービスページの周りに束ねる

ブログ記事は単発で増やすより、サービスページの周りに束ねます。

たとえば 既存資産活用・移行支援 を親にするなら、

• VBA はこれから使えなくなるのか
• ActiveX / OCX を今どう扱うか
• .NET へ移行する前に確認すること
• 32bit / 64bit 問題をどう切るか

のような記事群で囲うと、テーマのまとまりが出ます。

技術相談・設計レビュー を親にするなら、

• 管理者権限が必要な処理だけをどう分離するか
• 例外設計やログ設計をどう考えるか
• スレッド / ライフタイム / 子プロセス設計をどう整理するか

のように寄せられます。

この形にすると、記事単体では情報収集でも、サイト全体では このテーマに強い会社 と伝わります。

flowchart TB
    accTitle: 記事をサービスページの周りに束ねる
    accDescr: ブログ記事は単発で増やすのではなく、親になるサービスページの周りにテーマの近い記事群として束ねると、テーマのまとまりが出て、記事単体では情報収集でもサイト全体ではこのテーマに強い会社と伝わることを示す図。
    y1["親のサービスページ"] --> y2["テーマの近い記事群で 周りを囲う"]
    y2 --> y3["テーマのまとまりが出る"]
    y3 --> y4["サイト全体で「このテーマに 強い会社」と伝わる"]
    y1 -.-> y5["単発で記事を増やしても まとまりは出ない"]

図32: 記事は単発ではなく、親サービスページの周りに束ねる。

7.3 Google 広告は高意図ページだけから始める

広告は全テーマ同時に始める必要はありません。 むしろ最初は、問い合わせ意図が濃く、受け皿ページが強いテーマ だけに絞ったほうがよいです。

例としては、こんな語群です。

• Windows アプリ 開発 受託
• 既存 Windows ソフト 改修
• Windows 技術相談
• 設計レビュー Windows アプリ
• COM ActiveX 移行

これらはあくまで方向例ですが、共通しているのは 相談の意図がある ことです。

逆に、最初から

• C#
• WPF
• VBA
• Media Foundation

のような広すぎる語で広告を広げると、教育的クリックが多くなりやすいです。

flowchart TB
    accTitle: 広告はどの語群から始めるか
    accDescr: 広告は全テーマ同時に始める必要はなく、問い合わせ意図が濃く受け皿ページが強いテーマだけに絞って始めるのがよく、逆に広すぎる技術単語で最初から広げると教育的クリックが多くなりやすいことを示す図。
    z1{"最初に出す語群は"}
    z1 -->|"相談意図が濃く 受け皿が強い"| z2["絞って始める"]
    z1 -.->|"広すぎる技術単語"| z3["教育的クリックが 多くなりやすい"]
    z2 --> z4["成果を見てから 広げていく"]

図33: 広告の開始は、意図の濃さと受け皿の強さで絞る。

7.4 送る先はホームではなく、意図に合ったページ

問い合わせを増やしたいときほど、ホームにまとめたくなります。 でも Google 広告の観点でも、検索意図に合った landing page のほうが自然です。⁸⁹

したがって、広告の送り先は原則として

• サービスページ
• サービス特化 LP
• サービス + 事例をまとめたページ

のどれかに寄せるべきです。

flowchart TB
    accTitle: 広告の送り先の決め方
    accDescr: 問い合わせを増やしたいときほどホームにまとめたくなるが、検索意図に合ったlanding pageのほうが自然であり、広告の送り先は原則としてサービスページ・サービス特化LP・サービスと事例をまとめたページのどれかに寄せるべきであることを示す図。
    a0["広告の送り先"] -.->|"寄せない"| a1["ホームにまとめる"]
    a0 -->|"原則"| a2["サービスページ"]
    a0 -->|"原則"| a3["サービス特化LP"]
    a2 --> a4["サービス+事例を まとめたページも可"]

図34: 送り先はホームではなく、検索意図に合ったページへ寄せる。

7.5 お問い合わせまでの距離を短くする

技術記事の最後に、

• このテーマに近い相談はこちら
• 関連サービスはこちら
• 事例はこちら
• お問い合わせはこちら

を毎回置くと、入口から出口までの線が見えやすくなります。

comcomponent.com にはすでに お問い合わせ、技術事例、ブログ があるので、 記事 → サービス → 事例 → 問い合わせ の導線をさらに明確にしていくのがよいです。

8. よくある失敗

8.1 ブログだけ増やして、サービスページが弱い

検索流入は増えても、相談したい人が着地するページが薄いと、問い合わせに届きません。

8.2 AI で似た記事を大量に出す

量は増えても、検索意図ごとの差が弱くなり、価値を足していないページが増えます。Google のガイドとも相性が悪いです。¹⁸²

8.3 robots.txt で非公開にしようとする

robots.txt は検索結果から消す仕組みではありません。出したくないなら noindex か認証です。¹⁷

8.4 Google 広告をホームへ流す

検索意図と LP がずれ、CVR も learning も弱くなります。

8.5 コンバージョン計測が pageview に近い

問い合わせの質と無関係なシグナルで自動化すると、成果が見えません。⁴¹¹

8.6 Quality Score を KPI にする

Quality Score は診断用です。スコア自体を追いかけるより、ad relevance と landing page experience を直すほうが本筋です。⁹

8.7 Search Console と広告を別物として扱う

どちらも同じ検索需要の別の見え方です。 つながって見ないと、施策が重複したり、優先順位がぶれます。

9. 90 日でやること

全部を一気にやる必要はありません。 技術系 B2B サイトなら、最初の 90 日は次の順で十分です。

flowchart TB
    accTitle: 90日プランの流れ
    accDescr: 最初の90日は、1〜2週目に問い合わせの定義やサイトマップなどの土台を整え、3〜4週目に計測と広告の最小構成を作り、2か月目にサービスページにつながる記事や事例などSEOの支えを増やし、3か月目に広告とSEOのデータを行き来させて両者をつなぐという順で進めれば十分であることを示す図。
    n1["1〜2週目: 土台を整える"] --> n2["3〜4週目: 計測と広告の 最小構成を作る"]
    n2 --> n3["2か月目: SEOの支えを 増やす"]
    n3 --> n4["3か月目: 広告とSEOを つなぐ"]

図35: 90日は、土台→計測と広告→SEOの支え→連携の順で進める。

1〜2 週目: 土台を整える

• 問い合わせの定義を決める
• Search Console を確認する
• サイトマップと robots / noindex の整理をする
• 主力サービスページの title / description / CTA を見直す
• 広告に使う landing page を決める

3〜4 週目: 計測と広告の最小構成を作る

• Google Ads の conversion tracking を整える
• enhanced conversions を設定する
• Consent Mode を自社の同意管理と合わせる
• 高意図テーマだけで検索広告を始める
• search terms report を見始める

2 か月目: SEO の支えを増やす

• サービスページにつながる技術記事を 3〜5 本追加する
• 事例ページを増やす、または既存事例を強化する
• Organization / Article など必要な structured data を見直す
• 内部リンクを整理する

3 か月目: 両者をつなぐ

• 広告で反応のよかった語を記事や LP に反映する
• Search Console で表示されている query をもとに続編記事を作る
• 問い合わせに近いページの CTA を調整する
• 相談の質まで含めて conversion 定義を見直す

10. まとめ

SEO と Google 広告のベストプラクティスを一言で言うなら、 検索意図に合ったページを作り、その成果を正しく測り、両方のデータを行き来させること です。

SEO の基本は次のとおりです。どのガイドに基づく話かも並べておくので、原典を当たりたいときはここから辿ってください。

Google 広告の基本も同じように並べると、こうなります。

そして技術系 B2B サイトでは、記事を増やすこと自体 を目的にしないほうがよいです。

• まずサービスページを強くする
• 事例で信頼を補う
• 技術記事で入口を増やす
• 広告で高意図需要を刈り取る
• Search Console と Ads のデータで相互に強化する

この流れが、かなり再現性の高い進め方です。

flowchart TB
    accTitle: 再現性の高い進め方
    accDescr: まずサービスページを強くし、事例で信頼を補い、技術記事で入口を増やし、広告で高意図需要を刈り取り、Search ConsoleとAdsのデータで相互に強化するという、技術系B2Bサイトで再現性の高い流れを示す図。
    b1["サービスページを強くする"] --> b2["事例で信頼を補う"]
    b2 --> b3["技術記事で入口を増やす"]
    b3 --> b4["広告で高意図需要を 刈り取る"]
    b4 --> b5["Search ConsoleとAdsの データで相互に強化"]
    b5 -.-> b3

図36: 記事を増やすこと自体を目的にせず、この順で回すのが再現性の高い形。

11. 関連ページ

• Windowsアプリ開発
• 技術相談・設計レビュー
• 既存資産活用・移行支援
• 技術事例
• 技術ブログ
• お問い合わせ

12. 参考資料

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

SEOとGoogle広告はどちらを先にやるべきですか？

どちらか一方を選ぶものではなく、意図の違う検索を別々に取りに行くものです。SEOは立ち上がりが遅い代わりに蓄積しやすく、広告は早く立ち上がる代わりに出稿停止で止まります。実務的には、商談に近い高意図の検索は広告でも取り、周辺の学習・比較需要はSEOで拾う役割分担が現実的です。SEOは資産作り、Google広告は需要の刈り取りと仮説検証と見ると整理しやすいです。

Google広告を始めるとき最初にやるべきことは何ですか？

入札テクニックではなく計測の整備です。Google公式でも、正確なコンバージョンデータ、強いタグ基盤、enhanced conversions、Consent Modeが重視されています。コンバージョンは単なるページビューではなく、問い合わせフォーム送信や相談予約など事業にとって意味のある行動を置く必要があります。計測が弱いままキーワードや入札だけ触っても改善幅は小さく、broad matchやSmart Biddingの自動化も悪い材料で学習することになります。

AIで記事を量産すればSEOに効きますか？

効きにくいうえにリスクがあります。Googleは生成AIの利用そのものを否定していませんが、価値を加えない大量生成コンテンツはscaled content abuseの観点からスパムポリシーに抵触しうると明示しています。AIは構成案の整理やたたき台の作成には向いていますが、自社なりの判断、実案件でよく出る論点、失敗パターンといった価値が加わっていないと弱いです。原稿工数を減らすために使うのであって、価値の代わりにしてはいけません。

技術系BtoBサイトでは何を主役にすべきですか？

サービスページです。技術系B2Bのテーマは、検索数は多くなくても問題が深く単価が高いため、広く浅いアクセスより意図の濃い検索を取りに行くほうが自然です。記事はPV目的ではなく、サービスページを強くする周辺資産として親サービスページの周りに束ねます。広告の送り先もホームではなく、検索意図に合ったサービスページやサービス特化LPに寄せるべきです。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。