SaaS の海外展開:プロダクト主導の成長と SEO 構造をどう組み合わせるか
1. SaaS の海外展開 SEO における 3 つの構造的な問題
問題 1:インデックス可能な資産が少なすぎる
典型的な SaaS サイトのページ構成:
| ページの種類 | 数 | インデックス状況 |
|---|---|---|
| ホーム | 1 | ✅ |
| 料金ページ | 1 | ✅ |
| 機能一覧ページ | 1 | ✅ |
| 会社概要・お問い合わせ | 2 | ✅ |
| ブログ記事 | 20〜80 | ✅ |
| プロダクトの実質的なコンテンツ | すべて | ❌ ログインの壁の内側 |
問題の形は明快です。プロダクトの価値はすべてログインの壁の内側にあり、検索エンジンや AI から見えるのはマーケティングページだけです。
成功している SaaS サイトと比べると、ページ構成はまったく異なります:
| ページの種類 | 先行 SaaS の典型的な数 | 検索インテント |
|---|---|---|
| 機能ページ(1 機能 1 ページ) | 20〜60 | “YY 向け XX ソフトウェア” |
| ユースケースページ(業界・職種別) | 15〜100 | “[industry] 向け YY ツール” |
| 連携ページ | 50〜500 | “[产品A] + [产品B] 連携” |
| テンプレート・リソースページ | 100〜5,000 | “[用途] テンプレート” |
| 比較ページ | 5〜40 | “[竞品] の代替 / 比較” |
| ドキュメントと API ドキュメント | 200〜5,000+ | “[具体操作] のやり方” |
| 変更履歴の項目 | 継続的に積み上がる | “[功能] リリース” |
この差は構造的なものです。「コンテンツの書き方が悪い」のではなく、そもそもページがそれだけ存在しない。
問題 2:コンテンツとプロダクトの乖離
よくあるのは、ブログでは業界トレンドや成長の方法論、チームの話を書いていて、製品ページでは「機能一覧 + アイコン3つ + ひと言のキャッチコピー」を書いている。この2つがつながっていない。
その結果はこうだ。ブログは流入を集めるが、その流入は製品と自分の関係を見つけられない。ある読者が「2026年のB2Bマーケティングトレンド」の記事を読んでも、その記事には「うちの製品がどの工程で役に立つのか」を教える一文がない。だから読み終わったらそのまま離れてしまう。
正しい構造は双方向の接続:
| 方向 | やり方 |
|---|---|
| コンテンツ → 製品 | 各記事は関連する段落の中で、対応する機能ページやユースケースページ(料金ページへ直接飛ばすのではない) |
| 製品 → コンテンツ | 各機能ページは「この機能でどんな課題を解決したか」の事例やチュートリアルにリンクする |
問題3:料金ページと比較ページがない、または質が低い
料金に関する検索は、SaaSカテゴリで最も検索需要が集中する部分のひとつだ。よくある検索の形は次のとおり。
- “[product] の料金”
- “[product] の無料プラン”
- “[product] と [competitor] の比較”
- “[competitor] の代替”
ところが多くのSaaSの料金ページは価格表が1枚あるだけで、比較ページは完全に欠けている。検索需要が最も明確なユーザー層を自ら手放している。
2. PLGに必要な「インデックス可能な資産」とは
プロダクト主導型成長の核心的な仕組みは「まず無料で使ってもらう」ことだが、ユーザーがまずあなたを見つけ、理解してこそ、登録に至る。だからPLGの土台は、構造化された一連の公開ページだ。
| 資産の種類 | ページの形 | 対応する検索意図 | 優先度 |
|---|---|---|---|
| 機能ページ | 1機能につき1ページ。スクリーンショット、利用シーン、適用範囲を含む | 「XXの機能があるツール」 | P0 |
| ユースケースページ | 業界別 / 役割別 / シーン別 | 「[行业]向けの[品类]」 | P0 |
| 連携ページ | 1連携につき1ページ | “[A] + [B] 連携” | P0 |
| 比較ページ | 競合との比較、alternative | 「代替手段」 | P1 |
| テンプレート・リソース集 | ダウンロードまたはコピーできるテンプレート | “[用途] テンプレート” | P1 |
| ドキュメントと API | 利用ドキュメント、SDK、サンプル | “[具体操作] のやり方” | P1 |
| 変更履歴 | バージョンごとの項目 | “[功能] リリースノート” | P2 |
| 料金と費用の説明 | プランごとの解説 + FAQ | “料金 / コスト” | P0 |
なかでも連携ページとテンプレートライブラリは、最も過小評価されている2種類だ。
| 資産 | 価値が高い理由 | 構築の難しさ |
|---|---|---|
| 連携ページ | 各連携の背後には提携先のユーザー層がいて、検索意図も非常に強い(ユーザーはすでに2つのツールをつなぎたいと決めている) | 製品側のサポートとビジネス側の連携が必要 |
| テンプレートライブラリ | 1ページあたりのコストが低く、プログラムで拡張でき、「特定の課題を解決したい」ユーザーを直接受け止められる | コンテンツ制作の仕組みが必要で、低品質なページを大量に作りやすい |
3. プログラムによるページ生成の境界
連携ページ、テンプレートライブラリ、ユースケースページの3種類は、本質的にすべてプログラムで生成できる。だが、プログラムによるSEOには、きわめて明確な境界がある。ページはユーザーにとって本当に役立つものでなければならない。
あるプログラム生成ページを作るべきかどうかは、3つの問いで判断する。
| 確認する問い | 不合格のサイン |
|---|---|
| このページ自体に独立した価値があるか? | 競合の名前を差し替えても、内容が一言も変わらない |
| ユーザーがこの語で検索するとき、このページを探しているのか? | 検索意図とページ内容のずれ |
| このページだけを見せられたら、友達に紹介しますか? | 中身がなく、テンプレートの決まり文句ばかり |
対照的な2つのやり方:
| やり方 | 結果 |
|---|---|
| 300の連携ごとに1ページずつ作り、各ページに「できること・設定方法・注意点・使用例の流れ」を載せる | ロングテールの流入が着実に積み上がり、ユーザーが本当に使える |
| 「XX + YY」のページを3000個生成し、中身は一文だけ | 低品質コンテンツと判定され、サイト全体の評価が下がる |
おすすめの規模とペース:1年目は50〜150ページ手作業で確認済みのものプログラムで生成するページ(連携・テンプレート・ユースケース)は、コンテンツとコンバージョン率が機能するのを確認してから拡大を検討する。1ページあたりのコンバージョン率を検証する前に、まとめて生成してはいけない。
4. 料金ページ:SEOだけでなく、コンバージョンの中核
SaaSにおける料金ページの立場は特殊です。検索の入口であり、意思決定のポイントであり、営業ツールでもあります。だからこそ、デザインは「見た目」だけで考えてはいけません。
機能が一通りそろった料金ページには、通常6つのブロックがあります:
| ブロック | 役割 | よくある不足 |
|---|---|---|
| 料金プラン表 | 「いくらか」に直接答える | 「お問い合わせください」とだけ書き、価格を一切公開しない |
| 各プランの機能差 | 「どのプランを選ぶべきか」に答える | 違いの説明があいまい(「より多くの機能」) |
| 課金方式の説明 | 「どう計算するか」に答える(席数 / 従量 / 年払い) | 小さな文字でひっそり書く |
| 費用に関するよくある質問 | 「超過したらどうなる」「返金できるか」に答える | まったくない |
| 無料 / トライアルの説明 | 最初の一歩のハードルを下げる | 表現があいまい |
| 社会的証明 | 顧客ロゴ、評価、データ | ロゴの壁だけ |
「価格を公開すべきか」という問題について:SEOの観点では、価格を公開すると明確な検索需要の流入を大量に獲得でき、AIにも直接引用されます(AIが「XXはいくらか」と答えるとき、引用できるのは公開情報だけです)。営業の観点では、価格を公開しないことで交渉の余地を残せますが、無効な問い合わせが増えます。折衷案は、最初のプランとプラン間の違いを公開し、エンタープライズ版は「お問い合わせください」として残すことです——検索流入を獲得しつつ、大口顧客との交渉余地も残せます。
5. SaaSがGEOで持つ天然の強み
SaaSというカテゴリには、AI引用の最適化において他のカテゴリにない強みがあります:プロダクトの内容がもともと構造化されている。
| 強み | 説明 |
|---|---|
| ドキュメントがもともとQ&A構造になっている | 「Xのやり方」というドキュメントは、そのままFAQ構造です |
| バージョンと更新に明確なタイムスタンプがある | 更新履歴が「鮮度」のシグナルになる |
| 連携関係が明確なエンティティ関係になっている | 「AがBと連携」は、AIが推薦を組み立てるときの強い関係です |
| 価格と機能の境界が明確 | そのまま引用できる判断材料 |
AI引用のための具体的な3つの施策:
- 機能ページを「そのまま抜き出せる」形式で書く。各ページの冒頭に40〜60字の事実文を置く:この機能が何をするか、誰に合うか、どんな制限があるか。例えば「自動承認フロー:最大5段階の承認に対応し、金額・部門・プロジェクト種別で条件を設定可能。組織をまたぐ承認には非対応。」——注目すべきは制限を書き出すこと、AI とユーザーのどちらにとっても、境界情報のほうが重要です。
- 比較ページは客観的であるべきです。「私たちのほうが優れている」と書いても引用される価値はありません。「私たちは A、B、C ができ、D の場面では相手に劣る」と書いてこそ、引用される価値が生まれます。AI は「XX と YY はどちらが良いか」と答えるとき、具体的な違いを示しているコンテンツのほうを信頼します。一方的な宣伝ではなく、ということです。
- 更新ログは書き続けます。これは最も見落とされやすい高価値な資産です。AI にとっての役割は製品が継続的に進化していることを示すこと、検索にとっての役割は新しいコンテンツを生み続けることです。バージョン更新のたびに 100〜300 字書くことをおすすめします。何を変えたか、なぜ変えたか、どのユーザーに影響するか。
六、優先順位と 12 か月の進め方
| フェーズ | 重点 | 完了の目印 |
|---|---|---|
| 1〜2か月目 | 料金ページのリニューアル + 機能ページ(主要 10 機能) | 料金ページは 6 ブロック構成、機能ページは 10 ページ公開 |
| 第 3〜4 か月 | ユースケースページ(業界別 + 役割別、10〜20 ページ) | 各ページにシナリオ、適用条件、フロー例を掲載 |
| 第 5〜6 か月 | 連携ページ(主要 30 連携)+ 比較ページ(主要 5 競合) | 各ページに設定手順と適用範囲を掲載 |
| 第 7〜9 か月 | ドキュメントと API ドキュメントの構成最適化 + 更新ログの仕組みづくり | ドキュメントが検索で見つかり、更新ログが継続的に生まれる状態 |
| 第 10〜12 か月 | テンプレート集 / リソース集(50〜150 ページ) | 各ページに独自の価値があり、テンプレート的な決まり文句がない |
| 継続 | 内部リンクの仕組み(コンテンツ ↔ 機能 ↔ ユースケース) | 各機能ページにコンテンツからの被リンクが最低 3 本 |
実行の原則がひとつあります。まず「検索意図が最も明確な」ページから作ることです。機能ページ、料金ページ、比較ページ、連携ページの 4 種類は検索意図が最も明確で(ユーザーは自分が何を求めているか分かっています)、コンバージョン率はブログ記事よりはるかに高くなります。ブログの価値は新規獲得と権威づけにあり、コンバージョンの主力ではありません。
FAQ よくある質問
| 階層 | 指標 | 観察期間 |
|---|---|---|
| 構成 | インデックスされたページ数、ページ種別ごとのカバー率 | 毎月 |
| トラフィック | 非ブランド語の自然流入、ロングテール語のカバー数 | 毎月 |
| 検索意図 | 料金ページ / 比較ページ / 連携ページの自然流入比率 | 毎月 |
| コンバージョン | ページ種別ごとの登録転換率 | 四半期ごと |
| 結果 | 自然流入がもたらす MRR 比率 | 半年ごと |
最後に
SaaS の海外展開で SEO を行うとき、最もよくある失敗はこれをコンテンツマーケティングとして扱ってしまうことです。ブログを大量に書き、業界インサイトを多く発信しても、製品の実態はログインの壁の内側に留まっています。
SaaS の構造上の強みはまさにここにあります。製品内の機能、連携、ユースケースの一つひとつが、そのままページになれるのです。これらのページに必要なのは創作ではなく、整理です。すでに製品内に存在するものを、公開されインデックスされ、引用され、判断材料になる資産に変えること。
だからこの取り組みの出発点は「何を書くか」ではなく、もっと根本的な問いです。私たちの製品にあるのに、まだ公開ページに出ていないものは何か?その答えはたいてい長く、そこにこのサイトの伸びしろがある。
