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

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

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

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

この記事では、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 広告は需要の刈り取りと仮説検証 と見ると整理しやすいです。

この記事の知識マップ

この記事は、技術系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 で拾う。この役割分担が、一番現実的です。

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

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

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

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

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

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

ここが曖昧だと、

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

が増えます。

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

たとえば、

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

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

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

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

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

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

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

AI を使うなら、

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

には向いています。

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

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

つまり、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

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

1. サービスページ

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

例:

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

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

2. 事例ページ

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

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

を出せると強いです。

3. 技術記事

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そのため、

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

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

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

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

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

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

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

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

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

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

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

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

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

という点です。²²

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

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

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

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

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

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

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

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

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

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

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

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

特に見るとよいのは、

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

という流れです。

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

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

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

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

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

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

順位グループを分けるのが肝です。これをやらないと、「順位が低いから 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 の見方自体を大きく変えるより、検索全体で役立つページを作る 方向のほうが自然です。

3 章の要点

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

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

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

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

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

たとえば、

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

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

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

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

⁴⁶⁷

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

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

です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. そのうえで自動化を強める

4.7 Search terms report は必ず見る

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

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

このレポートを見ると、

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

が見えてきます。

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

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

4.8 Quality Score は「診断」に使う

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

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

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

見るべきは主に次です。

• expected CTR
• ad relevance
• landing page experience

⁹

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

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

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

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

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

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

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

たとえば LP に、

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

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

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

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

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

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

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

が見えます。

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

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

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

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

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

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

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

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

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

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

ここで必要なのは、

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

です。

6.2 事例ページは強い

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

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

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

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

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

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

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

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

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

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 日プランにそのまま合流できます。

7. comcomponent.com ならこう組む

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

comcomponent.com は、すでに

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

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

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

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

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

Windowsアプリ開発

取りたい検索意図:

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

技術相談・設計レビュー

取りたい検索意図:

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

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

取りたい検索意図:

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

既存資産活用・移行支援

取りたい検索意図:

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

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

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

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

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

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

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

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

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

のように寄せられます。

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

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

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

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

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

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

逆に、最初から

• C#
• WPF
• VBA
• Media Foundation

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

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

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

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

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

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

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 日は次の順で十分です。

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 のデータで相互に強化する

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

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