SaaSの検索集客で申込が商談に変わらない理由｜トライアル前3つの確認

結論から書く。SaaSの検索集客で流入が問い合わせに変わらない最大の理由は、記事が「機能の説明」で止まっていて、無料トライアルを申し込む前に読み手が確認したい3つのこと ―― 自社のデータで動くのか、社内の誰の承認が要るのか、やめるときどうなるのか ―― に答えていないことだ。この3つは検索で必ず調べられるが、多くの記事では触れられていない。

この記事は、従業員50〜500名規模のBtoB SaaS企業で、オウンドメディアからのリード獲得を担当している方と、その予算を承認するマーケティング責任者に向けて書いている。記事の本数は増えているのに、トライアル申込や商談の数が伸びない、という状況が想定読者だ。以下では前提を一次資料で確認し、記事にすべき確認事項を選ぶ判定表と、リードの価値を計算する式を置く。

導入側の前提はどう変わっているか

道具を入れること自体は、すでに珍しくなくなっている。総務省の調査では、自社の何らかの業務で生成AIを利用していると回答した日本企業の割合は86.4％で、2024年度調査の55.2％から大きく上昇した。一方、生成AI活用による業務変革について「組織的な取組はない」と回答した割合は約3割弱と、比較対象の3か国より高い。出典：総務省「令和8年版 情報通信白書（概要）」（2026年7月24日公表）https://www.soumu.go.jp/main_content/001082851.pdf

読み取れるのは、導入の可否より「導入した後に業務が組み替わるか」で判断されるようになった、ということだ。だから記事に必要なのは機能一覧ではなく、既存の業務フローのどこが変わり、誰が何を判断するようになるのかの説明になる。

検索側の実測は無料で取れる。Google Search Console はGoogleが無料で提供しているサービスで、検索パフォーマンス（表示回数・クリック数）、インデックス登録の状況、セキュリティ上の問題の通知、自サイトへのリンク、構造化データの誤りを確認できる。出典：Google Search Console ヘルプ「Search Console の概要」https://support.google.com/webmasters/answer/9128668?hl=ja 検討側がどの言葉で自社を見つけているかは、ここで確認できる。

記事は増えるのに申込が伸びない場面

実際に起こりうる状況を5つ挙げる。

• 機能名で記事を作っている状態：自社の機能名を見出しにした記事が並ぶ。ところが検討側はまだ機能名を知らないため、その言葉で検索しない。表示回数そのものが立たない。
• 導入後の業務が書かれていない状態：何ができるかは書いてあるが、導入したあと誰の仕事がどう変わるかが書かれていない。読み手は社内で説明する材料を得られず、稟議に進めない。
• データ移行と連携に触れていない状態：既存システムからどうデータを持ってくるか、どの形式で出せるかが分からない。情報システム部門の確認で止まり、トライアルまで到達しない。
• 解約時の扱いが書かれていない状態：やめるときデータをどう取り出せるかが分からない。決裁者にとっては契約前に必ず確認する点なので、書いていない時点で候補から外れることがある。
• トライアル申込だけを目標にしている状態：申込数は増えたが商談化しない。トライアルで何を確かめればよいかを記事に書いていないため、触っただけで終わる。

5つに共通するのは、検討側が社内で説明するための材料を渡していない点だ。

トライアル前3つの確認｜何を記事にするか

検討側が申し込む前に確認する事項を、適合・承認・出口の3つに分けて整理する。ここではこれをトライアル前3つの確認と呼ぶ。この3つを書くと、申込の質が変わる。

確認	検討側が知りたいこと	書き方	書かないと起きること
適合	自社のデータと業務フローで動くのか	前提となるデータの形式と、必要な準備を工程順に書く	触ってみて合わず、そのまま離脱する
承認	社内の誰の承認が要るのか、何を説明すればよいか	情報システム・法務・決裁者それぞれの確認事項を並べる	担当者が社内で説明できず稟議が止まる
出口	やめるときデータをどう取り出せるか	エクスポートできる形式と、契約終了後の扱いを書く	決裁者の確認で候補から外れる

検討段階によって、読まれる記事は変わる。

検討段階	検討側の状態	効く記事	測る指標
課題の認識	今の業務の何が問題か言語化している	課題の切り分け方を示す記事	表示回数
手段の比較	ツールを入れるか、人を増やすかを比べている	選択肢ごとの向き不向きを比べる記事	クリック数
導入の判断	社内の承認を取りに行っている	トライアル前3つの確認に答えた記事	商談化率

書き方の粒度は、次の基準で揃える。曖昧なままだと、社内説明の材料にならない。

ありがちな書き方	検討側から見た状態	改善後の書き方
簡単に導入できます	何を準備すればよいか分からない	導入前に必要なデータと作業を工程順に並べる
各種システムと連携	自社の環境が含まれるか読めない	連携できる方式を具体名で書き、確認手順を添える
セキュリティも安心	情報システム部門の確認に使えない	データの保管場所とアクセス制御の考え方を書く
すぐに効果が出ます	稟議で説明する根拠にならない	効果が出る経路を式で示し、自社の数字を入れられる形にする
いつでも解約可能	データがどうなるか分からない	エクスポートできる形式と、契約終了後の保管期間を書く

社内で確認する人ごとに、必要な情報は違う。記事を1本に詰め込まず、誰向けかを決めて書き分ける。

確認する人	気にしていること	渡すべき情報	渡さないと起きること
現場の担当者	今の作業がどう変わるか	導入前後の業務フローの違いを工程順に並べる	導入の必要性を自分の言葉で説明できない
情報システム	既存環境と繋がるか、データはどこにあるか	連携方式とデータの保管場所、アクセス制御の考え方	確認のやり取りが往復して商談が長引く
法務・購買	契約条件と、やめるときの扱い	エクスポートできる形式と契約終了後の保管期間	契約直前で差し戻される
決裁者	投じた費用がどう戻るか	費用が戻る経路を式で示し、自社の数字を入れられる形にする	稟議の場で判断材料が足りず先送りになる
既存の利用部門	今使っている道具とどう併存するか	置き換える範囲と、併用したままにする範囲を分けて書く	社内の別部門から反対が出て止まる

着手の手順は次のとおりだ。上から順に実施する。

1. 直近の商談で、検討側から最初に聞かれた質問を10件書き出す
2. Search Console で、表示回数はあるのにクリックされていないクエリを抽出する
3. 質問とクエリが重なる箇所を、3つの確認のどれに当たるかで分類する
4. 最も多い確認から1本書く。対応できない範囲も併記する
5. トライアルで何を確かめればよいかを記事の中に書く
6. 公開後、申込の質と商談化率が変わったかを記録する

3つの確認を自社に当てはめると、たとえば次の3つのパターンに分かれる。

• パターンA：申込は増えるが商談化しない状態。触っただけで終わる利用者が多い。トライアルで何を確かめるかを書いていない可能性が高いので、確認手順を記事に含める。
• パターンB：情報システム部門で止まる状態。現場は前向きだが、連携とセキュリティの確認で進まない。承認の記事を先に用意する。テーマの束ね方はピラーページ戦略が土台になる。
• パターンC：機能名の記事ばかりの状態。表示回数そのものが立っていない。この場合は課題側の言葉で書き直す。全体設計はBtoBのSEO戦略で扱っている。

リードの価値はどう計算するのか

計算経路は「流入 × 申込率 × 商談化率 × 受注率 × 年間契約額」だ。SaaSは継続課金なので、単月ではなく年間契約額で見る。

経路1（受注側）：月間流入（人）× 申込率（％）× 商談化率（％）× 受注率（％）× 年間契約額（円）＝ 月間の獲得額。仮に月間流入2,000人、申込率2.0％、商談化率30％、受注率20％、年間契約額120万円と置くと、2,000 × 0.02 × 0.3 × 0.2 × 1,200,000 ＝ 月288万円。

経路2（商談化率の改善）：同じ前提で商談化率が30％から35％になると、2,000 × 0.02 × 0.35 × 0.2 × 1,200,000 ＝ 月336万円。申込数を増やすより、申込の質を上げるほうが動く金額が大きい場面は多い。

経路3（判断）：経路1と経路2の差を、記事制作の工数と比べる。3つの確認に答える記事は申込数を減らすことがあるが、商談化率が上がるなら金額としては増える。数値はすべて仮置きなので、自社の実測値に置き換えてほしい。導線の検証はCRO Copilot の活用で扱っている。

よくある質問

機能紹介の記事は書かなくてよいのですか

必要だが、検索からの入口にはなりにくい。検討側はまだ機能名を知らないため、その言葉で検索しない。機能紹介は指名検索で来た人向けに置き、検索からの入口は課題側の言葉で作る。

解約時の扱いまで書くと不利になりませんか

ならないことが多い。決裁者は契約前に必ず確認するため、書いていないと確認のやり取りが増えるか、候補から外れる。書いてある側のほうが、比較段階で残りやすい。

トライアル申込数を目標にしてよいですか

単独の目標にはしないほうがよい。触っただけで終わる申込が増えても商談は増えない。申込数と商談化率を並べて見て、両方が動いているかで判断する。

情報システム部門向けの記事は必要ですか

導入の判断に関わるなら必要だ。連携方式、データの保管場所、アクセス制御の考え方は、現場担当者では答えられないことが多い。記事にしておくと、担当者がそのまま社内に転送できる。

競合との比較記事は書くべきですか

書く場合は、他社について確認できない事項を断定しない。各社の機能と料金は変動するため、公式サイトで確認する前提にしたうえで、判断軸だけを示すのが安全だ。

導入事例が少ない段階では何を書けばよいですか

事例の代わりに判断材料を書く。どんな前提のときに向き、どんな場合は合わないかを条件で示せば、検討側は自社に当てはめて判断できる。数の少ない事例を無理に並べるより、条件を明示するほうが比較段階で効く。

価格ページと記事はどう役割を分けますか

価格ページは金額そのもの、記事は「何で金額が変わるか」を担当する。利用人数、データ量、必要な連携の数といった変動要因を記事側で説明しておくと、検討側は価格ページを見る前に自社の概算を立てられる。

問い合わせフォームの項目は増やすべきですか

増やすと申込は減る。ただし商談化率は上がることがあるため、件数ではなく商談化率で判断する。項目を増やす前に、記事側で3つの確認に答えているかを見直すほうが効果が読みやすい。

本数を増やせば流入は増えますか

課題側の言葉で書けているなら増える。機能名の記事を増やしても表示回数は立たないため、本数と流入が比例しない。増やす前に、既存記事が課題側の言葉になっているかを確認する。

まとめ｜まず1つの確認だけ書く

SaaSの検索集客で先に作るべきなのは、機能説明ではなくトライアル前に確認される事項への回答だ。適合・承認・出口の3つのうち、直近の商談で最も多く聞かれたものから1本書く。そしてトライアルで何を確かめればよいかを記事に含める。申込数は減ることがあるが、商談化率が上がれば金額としては増える。

ここまでのトライアル前3つの確認で、申込は増えるが商談化しない、情報システム部門で止まる、機能名の記事ばかりで表示回数が立たない、のいずれか1つでも当てはまるなら、記事を増やす前に自社サイトの現状を一度まとめて見たほうが早い。無料のSEO診断では、表示回数はあるのにクリックされていないクエリの一覧、記事ごとの流入と申込の結び付き、他記事から1本もリンクされていない記事の一覧、そしてテーマごとのハブ候補を出す。申し込み時に自社サイトのURLと、直近の商談で最初に聞かれた質問のメモを用意しておくと、初回のやり取りだけで最初に書く確認が決まる。