2025年7月13日·2 分
SaaSのマーケティングページとドキュメントを一つのサイトで構築する方法
SaaSのマーケティングページとドキュメントを一つのサイトで計画、構築、公開する方法。情報設計、SEO、高速パフォーマンス、更新ワークフローまでを解説します。
SaaSのマーケティングページとドキュメントを一つのサイトで計画、構築、公開する方法。情報設計、SEO、高速パフォーマンス、更新ワークフローまでを解説します。
マーケティングページとドキュメントを兼ねたSaaSサイトには二つの役割があります：新しい訪問者に始めてもらうことと、既存ユーザーが成功できるよう支援することです。「1つの目的のための1サイト」として扱うと、通常どちらか一方に最適化され、もう片方が静かにパフォーマンスを落とします。
マーケティングページは訪問者を明確な次のステップ（トライアル開始、デモ予約、料金確認）へ導くべきです。ドキュメントはサインアップ後の摩擦を減らす：質問に迅速に答え、セットアップを導き、統合作業の障害を取り除くこと。
まずは計画会議で繰り返せる1文のゴールを書いてください。例えば：
「見込み客を獲得すると同時に、顧客がセルフでサポートできるようにする。」
ほとんどのSaaSサイトは複数のオーディエンスに対応します。それぞれ意図が異なります：
もしページの対象を言えないなら、そのページは曖昧なコピーに流れてしまいます。
成果はチームの焦点をページ数ではなく行動に向けます：
毎月チェックする小さな指標群を選んでください：マーケティングのコンバージョン率、アクティベーション率、ドキュメント検索利用状況、上位の失敗検索、トピック別のサポートチケット数など。
誰が執筆し、レビューし、公開するかを決めておきます。明確な所有権は古いドキュメントや一貫性のないプロダクトメッセージを防ぎ、複数チームで更新する際のローンチをスムーズにします。
情報アーキテクチャは、両方のユーザー旅を明快に感じさせる方法です—ヘッダーナビがゴミ箱にならないように設計します。
ほとんどのチームは「マーケティング＋ドキュメント」を以下のトップレベルでカバーできます：
グローバルナビは初めての訪問者が期待する内容に集中させ、その他（セキュリティ、ステータス、変更履歴、パートナー、法務）はフッターや該当セクションに置きます。
ほとんどのSaaSでは /docs にドキュメントをホストするのが最も簡単です。
同一ドメインの /docs
サブドメイン（例：docs.[your-domain]）
ドキュメントが大規模で別チーム／別ツールで運用されると分かっている場合はサブドメインも合理的です。そうでなければ、/docs が安定したデフォルトです。
共通のパスを想定し、それらをサポートするURLとナビゲーションを用意してください。
マーケティングの例：
サポートの例：
ナビゲーションには役割があります：
URLは約束です。後で変更するとブックマークやインバウンドリンクを壊し、信頼を失います。
実用的なアプローチ：
構造を変更する必要が出たら、最初からリダイレクトを計画してください。クリーンなアーキテクチャと安定したURLは、SaaSサイトをナビゲートしやすく、保守しやすく、成長しやすくします。
SaaSサイトで売りつつサポートもするには、最速で出すべきページ群は「それは何か？信頼できるか？次に何をすればいいか？」の3つの問いに答えるものです。
訪問者が期待する基本で、チームが頻繁に参照するものから始めます：
各ページは一つの決断に集中させます。後で拡張できます。
トライアルを始める前に人は証拠を探します。軽量の信頼シグナルを早めに置いてください：
コアができたら、販売プロセスに合わせたページを追加します：
これらのページは摩擦を取り除くこと：フォームは明確に、期待値（「1営業日以内に返信」）と次のステップを示します。
ドキュメントは新規ユーザーの成功を早めるべきです：
基礎が安定したら、/changelog、任意のロードマップ、about、careers を追加します。透明性や採用に役立ちますが、初期ローンチの妨げにはなりません。
良いデザインは二面性を持ちます：マーケティングは説得して次のステップへ導き、ドキュメントは摩擦を減らして迅速に成功へ導きます。両方が一つのプロダクトとして感じられるようにするのがポイントです。
ページを作る前に小さなデザインシステムを定義します：タイポグラフィスケール、カラーパレット、余白ルール、そしてコアコンポーネント（ボタン、アラート、カード、タブ）。これでマーケティング側が「デザインされている」のにドキュメントが「デフォルト」のままになる、というミスマッチを防げます。
実用的には本文＋見出しで2–3のフォントサイズ、主要ブランドカラー1つ、中立的なボーダーや背景のスケールを決め、スペーシングは8px刻みなどで統一します。
組み合わせて使える再利用セクションを作っておくと早くページを組めます：
これらがスペーシングやタイポ、ボタンスタイルを共有していれば、コンテンツが増えてもサイトの一貫性が保てます。
ドキュメントUXは主に可読性です。明確な見出し階層、十分な行間、長文と広いコードブロックに耐えるコンテンツ幅を使ってください。コードブロックは横スクロール可能にして、読みづらく折り返されるのを避けます。短い導入、"始める前に" の注意、警告用のコールアウトでページを走査しやすくします。
アクセシビリティをベースラインとして扱います：
モバイルではトップナビとドキュメントのサイドバーを早めにテストしてください。開閉や理解が難しいとユーザーはすぐ離脱します。
良いSaaSサイトは製品を「説明する」だけでなく、読み手を好奇心から確信へ導きます。これは明確なメッセージ、シンプルなコピー、ページごとの意図に合ったCTAで作られます。
執筆前に各ページでの成功を決めます。主要ページには主要CTA（最も期待する行動）と副次CTA（より低コミットの次ステップ）を持たせます。
例：
CTAの文言と配置を一貫させ、訪問者がページごとに学び直さなくて済むようにします。
顧客が気にする成果を先に示し、どうそれを提供するかを説明します。曖昧な主張（"ワークフローを合理化"）は具体的な結果（"オンボーディング時間を数日から数時間に短縮"）に置き換えます。
専門用語は必要なら使い、平易な言葉で定義を付けます。特に見出しやボタン文言は短い文が勝ちます。
重要な決定ポイント近くに証拠を置きます（機能、料金、サインアップ）。数値は検証できる場合のみ使い、文脈を示します：
数字と人間味のある証拠（引用、ミニケース、ワークフローの実例）をバランス良く見せます。
わかりにくい料金はサインアップを妨げます。プラン名、主要な制限、アドオン、制限超過時の扱いを明示し、サポートに関するFAQ（セキュリティ、請求、キャンセル、サポート）を含めます。
機能の説明をする箇所には、最も関連するガイドへ直接リンクします："See how it works" → /docs/getting-started または /docs/integrations/slack。これにより信頼が築かれ、購買前の質問が減ります—同時に読者を次へ進め続けます。
良いドキュメントは「明白」に感じられます。秘訣は予測可能な構造と、各ページで常に答えるべき二つの問い：私はどこにいる？ と 次に何を読むべき？ です。
ドキュメントのサイドバーはカテゴリ数を少なく、平易なラベルで作ります。内部チーム名ではなくタスクや成果で整理してください。
一般的なトップレベルカテゴリ：
ラベルは製品の呼称に合わせてください。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）を確認します。
貼り付けられたテキストやスクリーンショットで承認するのは避けましょう。ナビゲーション、モバイルレイアウト、クロスリンクの文脈でページを見られるプレビュ―リンクを使います。
一般的なオプション：
一度決めたことを書き留めます：声のトーン、見出し構造、コード例の書き方、スクリーンショットの取り方・更新方法。これにより複数人の寄稿でもドキュメントが統一されます。
誰が何を所有するかを決めます：
ホームページやナビラベルなど共有ページの決定権（ティーブレーカー）も決めておくと変更が停滞しません。
マーケティングページとドキュメントが同一サイトにあると、権威を構築し内部リンクを共有しやすく、サブドメインで信号を分散するより楽になります。
すべてのインデックス対象ページで基礎を守ります：
URLとリンクのシンプルルール：常に相対パスを使う（例：/pricing, /docs/api/auth）。これでステージングと本番の環境差による壊れを防げます。
統合サイト最大のリスクは同じ説明を複数箇所で繰り返すことです（例：「SSOの仕組み」を機能ページとドキュメント両方で詳述する）。
重複が避けられない場合：
正確に使えるものだけ追加します：
ブログで広い問いに答え、次のステップへ誘導するクラスタを作ります：
この構造は検索順位とコンバージョンの両方を助けます—ドキュメントを営業文にしなくても済みます。
マーケティングページとドキュメントを混在させると、瞬時で信頼できる体験にする必要があります。小さな後退（重いスクリプト、新しいフォント、大きなスクリーンショット）が積み重なると影響は大きいです。
いくつかの測定可能な目標を毎リリースでチェックします：
ユーザーが最初にダウンロードするものを最適化します：
font-display: swap を使い、可能ならセルフホスティングする静的アセットには長いキャッシュヘッダを付け、CDN を利用して配信することを検討してください。
必要な情報だけを収集します。少ないツールで解決できるならそちらを優先してください。
軽量のモニタリングを入れ、ステータスページがあるならリンク（例：/status）を置きます。なければ少なくとも障害時の確認先（フッターのサポートページリンク）を用意して、何か壊れたときにユーザーが確認できる手段を示してください。
マーケティングページとドキュメントがあるサイトは決して「完成」しません。改善の最速手段は人々の実際の使い方を観察することです：何を検索するか、どこで詰まるか、どのページがサインアップを生んでいるか。
マーケティングページとドキュメントの両方をカバーするサイト全体検索をまず用意してください。単純な解決でも何もないより有益です—特にドキュメント依存が高いプロダクトでは。
導入後は検索挙動を定期的に確認し、証拠に基づいてチューニングします。最初の大きな改善点は「結果なし」のクエリに対応すること（欠落ページの追加、同義語の追加、見出しの改善など）。
ドキュメント検索はマーケティング検索と異なり、ユーザーはタスク志向で我慢が少ないため小さなUXが効きます：
ページビューだけでは何が機能しているか分かりません。以下のようなイベントを追跡します：
マーケ／サポートがデータを信頼できるよう命名を一貫させ、シンプルな内部ページにドキュメント化します（例：/docs/analytics-events）。
二つの観点で軽量なダッシュボードを用意します：
そしてループを閉じます：繰り返し来るサポートチケットや検索をドキュメント更新、新しい例、改善されたトラブルシューティングに変えることで、ドキュメントは時間とともに自己修復的になり、サポート負荷を減らしコンバージョンを高めます。
良いSaaSサイトのローンチは「公開して祈る」ではありません。顧客に先んじて壊れやすい点（リンク切れ、メタデータ欠落、サインアップリンクの不備）を検出するコントロールされたリリースと、マーケティングとドキュメントが陳腐化しないためのリズムを持ちます。
公開前にサイトの整合性とインデックス周りを一通り確認します：
古いサイトから移行する場合は、旧URL → 新URL のマッピングをスプレッドシートにまとめ、リポジトリに保存して将来の変更で消えないようにします。
無作為にクリックするだけでなく、マーケとドキュメントをつなぐ実際の“ジョブ”をテストします：
これらをリリースブロッカーと見なし、どれかが失敗したら即座に影響が出ます。
リダイレクトは移行だけの話ではありません。SaaSサイトは常に進化します：機能名を変更し、ドキュメントを再構築し、製品ページを書き直します。
ルールは一つ：URLを削除する場合は (a) リダイレクトするか、(b) 本当に不要なら 410 を返す のいずれかにする。ドキュメントでは通常リダイレクトが適切です。
将来を見据えた URL ポリシー（例えば、バージョン番号をURLに入れるのは本当にバージョン管理する場合だけにする）を合意しておくと、後のリファクタが小さくなります。
ローンチ当日は軽量な計画を用意します：
可能なら最初の24–48時間はホットフィックスの体制を維持しておくと安心です。
継続的な劣化を防ぐためのシンプルな周期：
ウェブサイトはプロダクトの表面です。継続的に改善を出し、その影響を測定してください。
まず、両方の成果を含む1文のゴールを書きます。例：「見込み客を獲得すると同時に、顧客がセルフでサポートできるようにする。」その後、各ページに主な役割を割り当てます：
多くの統合サイトは少なくとも以下の4つのグループを対象にします：
ページごとに対象が名前で言えないなら、そのページのスコープを再設計してください。
トップレベルを少数に絞り、その他はフッターへ移します：
/（ホーム）/product（または /features）/pricingほとんどのSaaSでは**/docs**にドキュメントを置くのがデフォルトとして最もシンプルです：
ドキュメントが別のツールチェーンや権限で大規模に運用されるなど、明確な理由がある場合のみサブドメインを検討してください。
URLは約束です：
/docs/sso）/docs/integrations/slack は OK、5階層は NG）ドキュメントをバージョン管理する可能性があるなら、早めに方針を決めてください。
サイトで最初に答えるべき問いは「それは何か？信頼できるか？次に何をすればいいか？」です。
最小限のマーケティングページ：
最小限のドキュメント：
必要に応じて選んでください：
一般的なハイブリッドは、ドキュメントを Markdown/MDX にして、マーケティングの構造化部分は CMS フィールドで管理する方法です。
各主要ページにプライマリCTAとセカンダリCTAを持たせ、文言と配置を一貫させます：
決定ポイント近くにロゴや引用、ケーススタディなどの証拠を配置してためらいを減らします。
ドキュメントは予測可能な構造とテンプレートが鍵です：
共通テンプレート（例：Problem → Steps → Expected result → Troubleshooting）を使えば、どのページも馴染みやすくなります。
成果に結びつく行動を計測します：
月次で確認し、繰り返し出る検索やサポートチケットをドキュメント更新に繋げていきます（例：機能ページ → /docs/getting-started、そして /pricing へ戻す）。
/customers/blog/docsグローバルナビはマーケティング発見を優先し、ドキュメント用のナビはドキュメントサイドバー（Getting started, Guides, API, Troubleshooting）に置きます。