SaaSのマーケティングページとドキュメントを一つのサイトで構築する方法

目標と対象：マーケティング＋ドキュメントを一つのサイトで

マーケティングページとドキュメントを兼ねたSaaSサイトには二つの役割があります：新しい訪問者に始めてもらうことと、既存ユーザーが成功できるよう支援することです。「1つの目的のための1サイト」として扱うと、通常どちらか一方に最適化され、もう片方が静かにパフォーマンスを落とします。

主目的を定義する

マーケティングページは訪問者を明確な次のステップ（トライアル開始、デモ予約、料金確認）へ導くべきです。ドキュメントはサインアップ後の摩擦を減らす：質問に迅速に答え、セットアップを導き、統合作業の障害を取り除くこと。

まずは計画会議で繰り返せる1文のゴールを書いてください。例えば：

「見込み客を獲得すると同時に、顧客がセルフでサポートできるようにする。」

サイトが誰に役立つか決める

ほとんどのSaaSサイトは複数のオーディエンスに対応します。それぞれ意図が異なります：

• 見込み客（Prospects）：適合性、実績、料金を探している
• トライアルユーザー：最初の成功（ファーストサクセス）を目指している
• 顧客：信頼できるハウツーやトラブルシューティングを必要としている
• 開発者：API、SDK、実装の詳細を評価している

もしページの対象を言えないなら、そのページは曖昧なコピーに流れてしまいます。

コアな成果を一覧化する（成功の定義）

成果はチームの焦点をページ数ではなく行動に向けます：

• もっと多くのサインアップやデモリクエスト
• 高いトライアル→有料の転換率
• より早い価値到達（セットアップ完了、最初のプロジェクト作成）
• セルフサービス増加、サポートチケットの減少

成功指標を設定する

毎月チェックする小さな指標群を選んでください：マーケティングのコンバージョン率、アクティベーション率、ドキュメント検索利用状況、上位の失敗検索、トピック別のサポートチケット数など。

所有権を早めに確定する

誰が執筆し、レビューし、公開するかを決めておきます。明確な所有権は古いドキュメントや一貫性のないプロダクトメッセージを防ぎ、複数チームで更新する際のローンチをスムーズにします。

情報アーキテクチャとURL構造

情報アーキテクチャは、両方のユーザー旅を明快に感じさせる方法です—ヘッダーナビがゴミ箱にならないように設計します。

少数の主要セクションから始める

ほとんどのチームは「マーケティング＋ドキュメント」を以下のトップレベルでカバーできます：

• /（ホームページ）
• /product（または /features）
• /pricing
• /customers（ケーススタディ、推薦文）
• /blog
• /docs

グローバルナビは初めての訪問者が期待する内容に集中させ、その他（セキュリティ、ステータス、変更履歴、パートナー、法務）はフッターや該当セクションに置きます。

ドキュメントをどこに置くかを決める：/docs か別サブドメインか

ほとんどのSaaSでは /docs にドキュメントをホストするのが最も簡単です。

同一ドメインの /docs

• 長所：ブランド体験が一貫、クロスリンクが簡単、SEOの恩恵を共有、分析が単純
• 短所：デザインやナビゲーションを調整しないとドキュメントが「別サイト」のように感じられる可能性がある

サブドメイン（例：docs.[your-domain]）

• 長所：ツール、権限、ビルドシステムを分離しやすい
• 短所：切り離された印象になりやすく、SEOの権威を分散しがちで、分析に追加設定が必要になることがある

ドキュメントが大規模で別チーム／別ツールで運用されると分かっている場合はサブドメインも合理的です。そうでなければ、/docs が安定したデフォルトです。

メニューを確定する前にユーザージャーニーをマップする

共通のパスを想定し、それらをサポートするURLとナビゲーションを用意してください。

マーケティングの例：

• / → /pricing → サインアップ

サポートの例：

• /docs → 特定の記事 → 関連トラブルシューティング → 必要なときだけサポートへ連絡

ナビゲーションには役割があります：

• グローバルナビはマーケティング発見（Product, Pricing, Customers, Blog, Docs）を担当。
• ドキュメントのサイドバーはタスク完了（Getting started, Guides, API, Troubleshooting）を担当。

安定するURL計画を作る

URLは約束です。後で変更するとブックマークやインバウンドリンクを壊し、信頼を失います。

実用的なアプローチ：

• 短く人が読めるスラッグを使う：/docs/sso のように、/docs/2025/07/sso-guide-final は避ける
• 人の思考に沿う場合にだけ深いネストを使う：/docs/integrations/slack はOK；5階層はNG
• スタイルを一つに：kebab-case が一般的（例：/docs/api-authentication）
• バージョン管理をするなら早めに方針を決める

構造を変更する必要が出たら、最初からリダイレクトを計画してください。クリーンなアーキテクチャと安定したURLは、SaaSサイトをナビゲートしやすく、保守しやすく、成長しやすくします。

最初に作るべきコアページタイプ

SaaSサイトで売りつつサポートもするには、最速で出すべきページ群は「それは何か？信頼できるか？次に何をすればいいか？」の3つの問いに答えるものです。

必須のマーケティングページ（まずこれを出す）

訪問者が期待する基本で、チームが頻繁に参照するものから始めます：

• ホームページ：一つの明確なバリュープロポジション、主要CTA（トライアルまたはデモ）、短い「仕組み」説明
• 機能（またはユースケース）：成果を平易に説明し、各機能を関連ドキュメントへリンクする
• 料金：プラン、含まれる内容、FAQ、調達に向けた詳細（請求、請求書、税）
• セキュリティ（信頼）：セキュリティ概要、データ取り扱い、適合性の主張（事実のみ）、ドキュメント要求方法
• お問い合わせ：営業／サポートの連絡手段と簡単なフォーム

各ページは一つの決断に集中させます。後で拡張できます。

ためらいを減らす信頼の構築要素

トライアルを始める前に人は証拠を探します。軽量の信頼シグナルを早めに置いてください：

• 顧客ロゴと短い推薦文（2–3件の強いものでも効果あり）
• ケーススタディ（一つのしっかりした事例は複数の曖昧な引用より強い）
• 連携（Integrations）ページで互換性を素早く確認できるようにする
• ステータスページへのリンク（例：/status）があると信頼感が上がる

コンバージョンに注力したページ（必要に応じて追加）

コアができたら、販売プロセスに合わせたページを追加します：

• デモ依頼（ハイタッチな営業向け）
• トライアル開始（セルフサーブ向けオンボーディング）
• 比較ページ（公平で具体的に書ける場合のみ）

これらのページは摩擦を取り除くこと：フォームは明確に、期待値（「1営業日以内に返信」）と次のステップを示します。

ドキュメントの必須要素（最初の「アハ」を支える）

ドキュメントは新規ユーザーの成功を早めるべきです：

• Getting started：インストール／セットアップ、最初のプロジェクト、基本概念
• Guides：一般的なワークフローとベストプラクティス
• API reference：APIがあるなら完全で検索可能に保つ
• Troubleshooting：既知のエラー、修正方法、サポート連絡方法

補完的なページ（基礎が安定したら追加）

基礎が安定したら、/changelog、任意のロードマップ、about、careers を追加します。透明性や採用に役立ちますが、初期ローンチの妨げにはなりません。

マーケティングページとドキュメントのためのデザインとUX

良いデザインは二面性を持ちます：マーケティングは説得して次のステップへ導き、ドキュメントは摩擦を減らして迅速に成功へ導きます。両方が一つのプロダクトとして感じられるようにするのがポイントです。

軽量なデザインシステムから始める

ページを作る前に小さなデザインシステムを定義します：タイポグラフィスケール、カラーパレット、余白ルール、そしてコアコンポーネント（ボタン、アラート、カード、タブ）。これでマーケティング側が「デザインされている」のにドキュメントが「デフォルト」のままになる、というミスマッチを防げます。

実用的には本文＋見出しで2–3のフォントサイズ、主要ブランドカラー1つ、中立的なボーダーや背景のスケールを決め、スペーシングは8px刻みなどで統一します。

再利用可能なセクション = 速いページ作成と一貫性

組み合わせて使える再利用セクションを作っておくと早くページを組めます：

• ヒーロ（バリュープロポジション＋主要CTA）
• 機能グリッド（3–6の利点）
• FAQ（サポート負荷を軽減）
• 比較表（評価を助ける）
• 最終CTA（トライアル、デモ、料金）

これらがスペーシングやタイポ、ボタンスタイルを共有していれば、コンテンツが増えてもサイトの一貫性が保てます。

ドキュメントを読みやすくする（特にコード）

ドキュメントUXは主に可読性です。明確な見出し階層、十分な行間、長文と広いコードブロックに耐えるコンテンツ幅を使ってください。コードブロックは横スクロール可能にして、読みづらく折り返されるのを避けます。短い導入、"始める前に" の注意、警告用のコールアウトでページを走査しやすくします。

アクセシビリティとモバイルファーストの確認

アクセシビリティをベースラインとして扱います：

• 文字とボタンに十分なコントラスト
• フォーカス状態の可視化と完全なキーボード操作
• 意味のある画像に alt テキスト（装飾的なものは省略）

モバイルではトップナビとドキュメントのサイドバーを早めにテストしてください。開閉や理解が難しいとユーザーはすぐ離脱します。

メッセージング、コピー、コンバージョンパス

良いSaaSサイトは製品を「説明する」だけでなく、読み手を好奇心から確信へ導きます。これは明確なメッセージ、シンプルなコピー、ページごとの意図に合ったCTAで作られます。

各ページの役割（とCTA）を定義する

執筆前に各ページでの成功を決めます。主要ページには主要CTA（最も期待する行動）と副次CTA（より低コミットの次ステップ）を持たせます。

例：

• ホーム：主要 Start free trial、副次 See a demo
• 機能ページ：主要 View pricing、副次 Read how it works
• 料金ページ：主要 Choose a plan、副次 Talk to sales

CTAの文言と配置を一貫させ、訪問者がページごとに学び直さなくて済むようにします。

ベネフィット重視で具体的に書く

顧客が気にする成果を先に示し、どうそれを提供するかを説明します。曖昧な主張（"ワークフローを合理化"）は具体的な結果（"オンボーディング時間を数日から数時間に短縮"）に置き換えます。

専門用語は必要なら使い、平易な言葉で定義を付けます。特に見出しやボタン文言は短い文が勝ちます。

信頼できる証拠を使う

重要な決定ポイント近くに証拠を置きます（機能、料金、サインアップ）。数値は検証できる場合のみ使い、文脈を示します：

• 「2,400チームに導入されています」（事実であれば）
• 「処理時間を32%短縮しました」（誰がいつのデータかを短く添える）

数字と人間味のある証拠（引用、ミニケース、ワークフローの実例）をバランス良く見せます。

料金の明瞭さをコンバージョン機能にする

わかりにくい料金はサインアップを妨げます。プラン名、主要な制限、アドオン、制限超過時の扱いを明示し、サポートに関するFAQ（セキュリティ、請求、キャンセル、サポート）を含めます。

マーケティングからドキュメントへ（迷路に落とし込まない）

機能の説明をする箇所には、最も関連するガイドへ直接リンクします："See how it works" → /docs/getting-started または /docs/integrations/slack。これにより信頼が築かれ、購買前の質問が減ります—同時に読者を次へ進め続けます。

使いやすいドキュメント構造とナビゲーション

良いドキュメントは「明白」に感じられます。秘訣は予測可能な構造と、各ページで常に答えるべき二つの問い：私はどこにいる？ と 次に何を読むべき？ です。

ユーザー意図に合ったサイドバーから始める

ドキュメントのサイドバーはカテゴリ数を少なく、平易なラベルで作ります。内部チーム名ではなくタスクや成果で整理してください。

一般的なトップレベルカテゴリ：

• Getting Started（セットアップ、最初の成功）
• Tutorials（エンドツーエンドのウォークスルー）
• How-to Guides（「チームを招待する」などの具体タスク）
• Reference（API、設定オプション）
• Explanations（概念や意思決定ガイド、仕組みの説明）

ラベルは製品の呼称に合わせてください。UI が "Workspaces" と呼ぶなら、ドキュメントでそれを "Projects" と呼ばないでください。

スクロールを減らすオンページナビゲーションを追加する

長いページには上部に目次を付け、読者が適切なセクションへジャンプできるようにします。ページ下部に Next/Previous リンクを追加して、セットアップやオンボーディングの流れを滑らかにします。

ガイドのテンプレートを使って馴染ませる

一貫性は機能です。次のような単一テンプレートを使ってください：

Problem → Steps → Expected result → Troubleshooting

このパターンで読者は速く走査でき、チームも新しい記事を書く際に構成を作り直す必要がなくなります。

ドキュメントを継続的に改善しやすくする

各ページに軽いフィードバックオプションを付けます：「Was this helpful?」とサポートへの明確なリンク（例：/contact や /support）。フィードバックはドキュメントを実際の疑問に合わせ続ける手がかりになり、フラストレーションを感じた読者が助けを探すのに迷わない逃げ道を提供します。

コンテンツワークフロー：壊さずに更新する

SaaSサイトは常に変わります：料金の微調整、新機能、ドキュメント修正、発表。目標は人間にとって更新しやすく、それでいてナビゲーション、検索、SEO が壊れないことです。

シンプルなコンテンツモデルを設定する

各ページタイプを構造化コンテンツとして扱います。Markdown/MDX を使うなら、ページをリスト、検索、表示できるようにフロントマターを揃えます。

よく使うフィールド：

• title（ページヘッダーに表示）
• description（meta とカード）
• tags または category（グルーピングとフィルタ）
• last_updated（ドキュメントの信頼性シグナル）
• sidebar_position（ドキュメントの順序）

一貫性があれば、メニューに出ない謎のページやリスト表示が崩れることを防げます。

みんなが従える編集ワークフローを使う

軽量なパイプラインでミスを減らします：

Draft → Review → Publish

ドラフトはブランチ（Git）やヘッドレスCMSで作成できます。レビューでは明瞭性、正確性、リンク／CTA が正しいか（例：/pricing や /docs）を確認します。

スクリーンショットではなくプレビューリンクでレビューする

貼り付けられたテキストやスクリーンショットで承認するのは避けましょう。ナビゲーション、モバイルレイアウト、クロスリンクの文脈でページを見られるプレビュ―リンクを使います。

一般的なオプション：

• プルリクエストプレビュー（PRごとの自動デプロイ）
• 本番を模したステージングサイト

スタイルガイドで一貫性を保つ

一度決めたことを書き留めます：声のトーン、見出し構造、コード例の書き方、スクリーンショットの取り方・更新方法。これにより複数人の寄稿でもドキュメントが統一されます。

明確な所有権（とエスカレーション）

誰が何を所有するかを決めます：

• マーケティングはマーケティングページを所有
• プロダクト／サポートはドキュメントを所有

ホームページやナビラベルなど共有ページの決定権（ティーブレーカー）も決めておくと変更が停滞しません。

マーケティング＋ドキュメントのためのSEO

マーケティングページとドキュメントが同一サイトにあると、権威を構築し内部リンクを共有しやすく、サブドメインで信号を分散するより楽になります。

ページごとの基本を整える

すべてのインデックス対象ページで基礎を守ります：

• 意図に合ったユニークなタイトルとメタディスクリプション（機能ページは売る、ドキュメントは説明する）
• 1つの明確なH1、続く H2/H3 は読み手の走査に沿わせる
• 説明的な内部リンク（"click here"は避ける）。例：機能ページからセットアップドキュメント /docs/getting-started へリンクし、/pricing へ戻す。

URLとリンクのシンプルルール：常に相対パスを使う（例：/pricing, /docs/api/auth）。これでステージングと本番の環境差による壊れを防げます。

マーケとドキュメント間の重複コンテンツを防ぐ

統合サイト最大のリスクは同じ説明を複数箇所で繰り返すことです（例：「SSOの仕組み」を機能ページとドキュメント両方で詳述する）。

重複が避けられない場合：

• 一方を“ソース・オブ・トゥルース”にして他方からリンクする
• 両方必要なら canonical タグで検索エンジンへ優先ページを指示する

使う価値がある構造化データ（schema）

正確に使えるものだけ追加します：

• 主要なプロダクトページに SoftwareApplication
• 本物のFAQセクションには FAQPage（マーケティングのフラフには避ける）
• ブログや長文ガイドには Article

トピッククラスタで収益につなげる

ブログで広い問いに答え、次のステップへ誘導するクラスタを作ります：

• ブログ：「SaaSアプリのSSO設定方法」→ /features/sso と /docs/sso/setup
• ブログ：「Webhookセキュリティチェックリスト」→ /docs/webhooks/security と /features/webhooks

この構造は検索順位とコンバージョンの両方を助けます—ドキュメントを営業文にしなくても済みます。

パフォーマンス、セキュリティ、プライバシーの基本

マーケティングページとドキュメントを混在させると、瞬時で信頼できる体験にする必要があります。小さな後退（重いスクリプト、新しいフォント、大きなスクリーンショット）が積み重なると影響は大きいです。

実際に意味のあるパフォーマンス目標

いくつかの測定可能な目標を毎リリースでチェックします：

• 高速読み込み：ミッドレンジのモバイルで LCP をおおむね 2–2.5 秒に
• レイアウト安定性：CLS を低く保つ（画像やバナーのスペースを予約する）
• 操作の滑らかさ：メインスレッドを長時間占有しない（ドキュメントページではシンタックスハイライトや検索ウィジェットがレンダリングをブロックすることがある）

実践的な最適化（高効果・低コスト）

ユーザーが最初にダウンロードするものを最適化します：

• 画像：WebP/AVIF などのモダンフォーマット、レスポンシブサイズ、ファーストビュー以外は遅延読み込み（ドキュメントのスクリーンショット多用時に特に重要）
• フォント：ファミリーとウェイトを絞り、font-display: swap を使い、可能ならセルフホスティングする
• スクリプト：分析、チャット、A/B テストなどは遅延実行。新しいタグを追加するときはパフォーマンス予算として扱う

静的アセットには長いキャッシュヘッダを付け、CDN を利用して配信することを検討してください。

絶対に外せないセキュリティ基本

• HTTPS を全ページで、HTTP → HTTPS のリダイレクトを設定
• 一般的なセキュリティヘッダ（HSTS、X-Content-Type-Options、Referrer-Policy）を追加。可能なら CSP を運用する
• 依存関係は最新に保つ（特にドキュメントツール、検索、ビルドパイプライン）
• プレビューURLやビルドログを公開しない。ステージングは認証で保護する

プライバシー：トラッカーを最小化する

必要な情報だけを収集します。少ないツールで解決できるならそちらを優先してください。

• クッキーバナーは（法域とトラッキング挙動によって）必要な場合のみ表示
• プライバシーに配慮した解析ツールを選び、ドキュメントにマーケティングピクセルを読み込ませるのは明確な理由がある場合のみに限定する

可用性と信頼のシグナル

軽量のモニタリングを入れ、ステータスページがあるならリンク（例：/status）を置きます。なければ少なくとも障害時の確認先（フッターのサポートページリンク）を用意して、何か壊れたときにユーザーが確認できる手段を示してください。

検索、分析、継続的改善

マーケティングページとドキュメントがあるサイトは決して「完成」しません。改善の最速手段は人々の実際の使い方を観察することです：何を検索するか、どこで詰まるか、どのページがサインアップを生んでいるか。

サイト検索を追加する（まずはシンプルに）

マーケティングページとドキュメントの両方をカバーするサイト全体検索をまず用意してください。単純な解決でも何もないより有益です—特にドキュメント依存が高いプロダクトでは。

導入後は検索挙動を定期的に確認し、証拠に基づいてチューニングします。最初の大きな改善点は「結果なし」のクエリに対応すること（欠落ページの追加、同義語の追加、見出しの改善など）。

ドキュメント特有の検索機能

ドキュメント検索はマーケティング検索と異なり、ユーザーはタスク志向で我慢が少ないため小さなUXが効きます：

• フィルタ（バージョン、製品領域、言語、"API" と "guides" の区別）
• 検索にフォーカスするためのキーボードショートカット（例：/ または Cmd/Ctrl+K）
• 結果のハイライト（見出しやスニペット内の一致語を表示）

ビジネスの問いに答えるイベントを追う

ページビューだけでは何が機能しているか分かりません。以下のようなイベントを追跡します：

• マーケティングページのCTAクリック
• サインアップの開始と完了
• ドキュメント検索（クエリ＋選択された結果）
• 「結果なし」検索や検索後の離脱

マーケ／サポートがデータを信頼できるよう命名を一貫させ、シンプルな内部ページにドキュメント化します（例：/docs/analytics-events）。

ダッシュボードとフィードバックループ

二つの観点で軽量なダッシュボードを用意します：

• マーケティング：上位のランディングページ → CTAクリック → サインアップ開始
• サポート：上位のドキュメントページ、上位検索クエリ、"結果なし"、検索後の高離脱ページ

そしてループを閉じます：繰り返し来るサポートチケットや検索をドキュメント更新、新しい例、改善されたトラブルシューティングに変えることで、ドキュメントは時間とともに自己修復的になり、サポート負荷を減らしコンバージョンを高めます。

ローンチチェックリストとメンテナンス計画

良いSaaSサイトのローンチは「公開して祈る」ではありません。顧客に先んじて壊れやすい点（リンク切れ、メタデータ欠落、サインアップリンクの不備）を検出するコントロールされたリリースと、マーケティングとドキュメントが陳腐化しないためのリズムを持ちます。

プレローンチチェックリスト（地味だが価値ある作業）

公開前にサイトの整合性とインデックス周りを一通り確認します：

• リンク切れ：サイトをクロールして 404 を修正（特に docs 間や docs→マーケ対象リンク）
• リダイレクト：変更・削除したURLには 301 を設定。"あとで直す" に頼らない—古いリンクはブックマークやメール、検索結果に残る
• サイトマップ：/sitemap.xml が存在し、インデックスさせたいマーケティングとドキュメントのページを含むか確認
• robots.txt：/robots.txt が適切にインデックスを許可／ブロックしているか（内部プレビュー等の非公開部分をブロック）

古いサイトから移行する場合は、旧URL → 新URL のマッピングをスプレッドシートにまとめ、リポジトリに保存して将来の変更で消えないようにします。

顧客が実際に使うフローをテストする

無作為にクリックするだけでなく、マーケとドキュメントをつなぐ実際の“ジョブ”をテストします：

• Pricing → signup：料金ページが速く読み込まれ、CTAが機能し、サインアップが完了し、確認メールが届くか
• Docs → contact support：読者が問題解決できない場合に迅速にヘルプにたどり着けるか（フォームやメールが動作するか）
• Search → article：検索が関連結果を返し、タイトルが読みやすく、選んだ記事が意図に合っているか

これらをリリースブロッカーと見なし、どれかが失敗したら即座に影響が出ます。

リダイレクト戦略（今後の変更も含めて）

リダイレクトは移行だけの話ではありません。SaaSサイトは常に進化します：機能名を変更し、ドキュメントを再構築し、製品ページを書き直します。

ルールは一つ：URLを削除する場合は (a) リダイレクトするか、(b) 本当に不要なら 410 を返す のいずれかにする。ドキュメントでは通常リダイレクトが適切です。

将来を見据えた URL ポリシー（例えば、バージョン番号をURLに入れるのは本当にバージョン管理する場合だけにする）を合意しておくと、後のリファクタが小さくなります。

リリース計画：発表、監視、素早く修正

ローンチ当日は軽量な計画を用意します：

1. 発表（メール、SNS、アプリ内）— サイトが検証済みであることを確認してから
2. 監視：分析、サインアップファネルのドロップオフ、404、サーチコンソールのインデックス状況を見る
3. 素早く修正：サインアップ、主要なドキュメント、上位ランディングページに影響する問題を優先的に対処

可能なら最初の24–48時間はホットフィックスの体制を維持しておくと安心です。

ローンチ後のメンテナンス頻度

継続的な劣化を防ぐためのシンプルな周期：

• 月次SEOレビュー：サーチコンソールのインデックスエラー、表示回数はあるがクリック率が低いページ（タイトル/メタの見直し）をチェック
• 四半期ごとのドキュメントクリーンアップ：古いスクリーンショットを削除、セットアップ手順がプロダクトと一致しているか確認、上位閲覧ドキュメントを明確にする

ウェブサイトはプロダクトの表面です。継続的に改善を出し、その影響を測定してください。