製品ドキュメントとナレッジベース

製品ドキュメントはマーケティングの付録ではなく、導入率、サポート負荷、営業効率の最前線です。静的ファーストな EmDash サイトでは、ドキュメントをコードとして扱えます。小さなファイル、明示的な frontmatter、レビュー可能な差分、Cloudflare Pages への高速デプロイです。だからこそこのハブは、エバーグリーンなガイド、移行プレイブック、プラグイン/テンプレートのディレクトリ、リリース連動の更新を一貫した情報設計で提供しています。

このパターンが有効な理由

検索エンジンもユーザーも、構造化を評価します。インストール、FAQ、移行、利用ガイドが独立したルートとして提供され、1 枚のランディングページに埋もれていなければ、問い合わせ前に自己解決されやすくなります。MDX は長文説明の可読性を保ちつつ、必要箇所でコンポーネント埋め込みも可能です。見出しと frontmatter が安定したプレーンファイルにあることで、AI 支援編集も機能しやすくなります。

具体的な導入ステップ

1. 最小限のドキュメントセットを定義する。 Getting Started、デプロイ、FAQ、そしてユーザーが繰り返しつまずく「難所」トピック（例：WordPress 移行やプラグイン導入）を優先公開します。その他は後回しで構いません。

2. ルート命名規約を決める。 /docs/...、/faq/...、/plugins/... のような予測可能なパスを使い、ナビゲーション、検索、分析を解釈しやすくします。タイトルと説明の一貫性は検索結果のスニペット改善にも有効です。

3. 検索を早期に組み込む。 軽量なサイト内検索でも重複質問は減らせます。主要な入口ページはトップページとフッターから到達できるようにします。

4. リリースのリズムで運用する。 機能リリースと同じマージタイミングで該当ドキュメントを更新します。上級ユーザー向けに「何が変わったか」の短いメモも維持します。

5. 計測して整理する。 四半期ごとに離脱の多いページとサポート記録を確認します。流入はあるのに直帰率が高いページは、導入文を書き直し、具体例を追加します。

例：ドキュメントスプリント

1 日目：既存ヘルプ記事を監査し、インストール、設定、移行、トラブルシュートに分類。2 日目：重要 5 記事を MDX に移行し、コードブロックや callout は共通コンポーネント化。3 日目：関連ガイド間の内部リンクを追加。4 日目：公開し、変更履歴で告知。5 日目：フィードバックを収集し、分かりにくい見出しを修正。

CMS ランタイム機能を追加するタイミング

非エンジニアが Git なしで編集する必要がある時、認証付きワークフローが必要な時、またはメディア運用がリポジトリ管理の範囲を超えた時に、EmDash のフルランタイムを導入します。それまでは静的公開でコストを抑えつつ、高いレビュー品質を維持できます。

成果

検索しやすく信頼できるドキュメント基盤を、製品成長に合わせて拡張できます。ナレッジベースを放置された wiki 化させずに運用できます。