ヘルプセンターの作り方 AI検索に正しく参照される公開設定・記事の型・更新運用

「CSVの取り込み方を教えて」「請求書の宛名を変えるには」。製品の使い方を、検索の代わりにChatGPTやGoogleのAIモードへ聞く人が増えています。

このとき、AI検索が根拠にしやすいページの一つが、各社のヘルプセンター（使い方ガイドやナレッジベース）です。

ところが中小企業のヘルプセンターには、ログインしないと読めない、手順がスクリーンショットだけ、どのプランの話か書いていない、画面が2年前のまま、といった問題がよくあります。

これでは、AIが読めないか、読めても古い手順や別のプランの手順を答えてしまうおそれがあります。

この記事は、SaaSやアプリ、機器の使い方ガイドを運用しているWeb担当者とサポート担当者に向けて、ヘルプセンターを作り直す手順を6つのステップで説明します。

よくある質問ページの作り方は、別の記事「BtoB中小企業のFAQページの作り方と育て方」にあります。

ここでは、手順記事の集まりとしてのヘルプセンター全体の設計と運用に絞ります。

Googleの公式文書は、2026年10月17日に開いて確かめた内容です。記事の型や公開範囲の決め方は、筆者の提案として分けて書きます。

先に結論 ヘルプセンターで直す順番

結論を、公式に言えることと、筆者の判断に分けて並べます。

論点	公式に言えること	筆者の判断
ログインの要否	Googleは、ログインが必要なページをクロールしないと説明している	一般的な使い方は、ログインなしで公開する
AI機能への表示	Googleの最新ガイドは、検索の技術要件を満たすことと、Search ConsoleでAI機能に含まれていることを挙げている	特別な仕掛けより、読める状態の確認が先
記事の型	決まった型は公式にない	対象プラン・バージョン・更新日を全記事の必須項目にする
古い手順	Googleは、代わりのないページの削除に404か410、移転に301を勧めている	更新・統合・削除の3つに振り分ける
Google以外のAI検索	ヘルプセンターに絞った説明は、今回は確かめていない	公開された文字の手順が土台になる前提で設計する

読める状態を先に確かめる

最初に確かめるのは、ログアウトした状態で記事が読めるかどうかです。

読めないページは、検索エンジンにもAI検索にも届きません。

型と更新日を全記事で揃える

記事が数百本になると、書き手ごとの判断に任せたままでは、プランやバージョンの書き漏れが出ます。

全記事で守る型を決め、対象プランと最終更新日を必須にします。

古い手順を残さない

古い記事が公開されたままだと、いまはできない操作が回答に使われるおそれがあります。

リリースのたびに、影響する記事を洗い出す流れを作ります。

AI検索はヘルプセンターをどう使うのか

まず、Googleの公式の説明を確認します。そのうえで、Google以外について言えることの範囲を整理します。

Googleの公式ガイドが挙げる条件

Googleは「生成AI機能向けにウェブサイトを最適化する」というガイドで、AIによる概要やAIモードに表示される条件を説明しています。

条件は、ページがインデックスに登録されていること、検索でスニペットを表示できること、検索の技術要件を満たしていることです。

このガイドの日本語版は、最終更新日が2026年10月9日でした。この版には、Search Consoleの検索の生成AI機能にサイトが含まれている必要がある、という記述もあります。

経緯と中身は、別の記事「生成AI機能向けのサイト最適化ガイド」で読み解いています。

同じガイドは、AI向けの特別な最適化や、llms.txtのような新しいファイルは要らないとも書いています。

読めないページは回答の材料にならない

Googleの技術要件には、アクセスにログインが必要なページはGooglebotがクロールしない、とあります。

Googleのガイドは、AI機能に表示される条件にインデックスへの登録を挙げています。登録されないページは、この条件を満たしません。

Google以外は確かめきれていない

ChatGPTやPerplexityなどが、ヘルプセンターをどう扱うかを個別に説明した公式文書は、今回は確かめていません。

誰でも読める公開ページに、正確な手順が文字で書かれていることが共通の土台になる、というのは筆者の推測です。

保証されない点も押さえる

Googleのガイドは、要件を満たしても、クロール・登録・表示が保証されるわけではないと明記しています。

ヘルプセンターを整える目的は、読まれない原因を減らすことです。表示を約束させる方法は、公式には示されていません。

全体の流れ 6つのステップ

進める順番は、公開範囲の確認、記事の単位の設計、共通の型、リンク、古い手順の整理、問い合わせ記録からの追加です。

各ステップで何をして、どこで確かめるのかを表にまとめます。

ステップ	やること	確かめる場所
1 公開範囲	ログインなしで読めるか、robots.txtとnoindex、本文の置き方を確かめる	ログアウトした状態、ページのソース
2 単位とカテゴリ	1記事1タスクにして、目的別に分類する	記事の一覧
3 共通の型	対象プラン・バージョン・更新日・用語を揃える	編集画面のテンプレート
4 リンク	前後の記事、例外の記事、カテゴリのトップをつなぐ	記事のソース
5 古い手順	更新・統合・削除に振り分ける	最終確認日の一覧
6 問い合わせ記録	多い質問と、記事のない質問を拾って足す	問い合わせの記録

どのステップも、特別な道具は要りません。ログアウトした状態のブラウザと、Search Consoleと、記事の一覧表があれば進められます。

ステップ1 公開範囲とクロールできるかを確かめる

最初に、ヘルプセンターが検索エンジンから読める状態かを確かめます。ここが閉じていると、後の工夫はどれも届きません。

ログインなしで読めるか

Googleの技術要件には、一般公開されているページのうち、Googlebotがクロールできるページだけをインデックスに登録する、とあります。

アクセスにログインが必要なページは、Googlebotがクロールしないと説明されています。

製品の画面の中にだけヘルプがある場合や、会員サイトにログインしないとマニュアルが読めない場合は、公開ページを読むAI検索がその内容を参照できません。

公開する情報を3つに分ける

ヘルプの内容を、公開の考え方ごとに3つに分けます。区分と考え方は、筆者の提案です。

区分	例	公開の考え方
一般の使い方	初期設定、各機能の操作手順、よくあるエラーの対処	ログインなしで公開する
契約者向けの詳細	管理者向けの高度な設定、連携の技術資料	原則は公開を検討し、競合への配慮が要る部分だけ閉じる
公開しない情報	社内の対応手順、個別の契約条件、セキュリティ上の手順	公開しない

一般の使い方まで閉じているなら、見直す価値があります。購入前の人が「この製品で〇〇はできるか」をAIに聞いたとき、根拠になるのは公開されたヘルプ記事だからです。

robots.txtで巡回を止めていないか

robots.txtは、サイト全体の巡回ルールを書くファイルです。ヘルプセンターのパス（/help/など）や、サブドメイン全体を巡回禁止にしていないかを確かめます。

サブドメインで運用している場合は、そのサブドメイン自身のrobots.txtを開きます。

Googleの技術要件のページには、robots.txtでGooglebotをブロックするとクロールはされないが、URLが検索結果に表示される可能性がある、とあります。

AIクローラー別の書き方は、別の記事「robots.txtでAIクローラーを制御する方法」にあります。

noindexが付いていないか

noindexは、ページをインデックスに登録しないよう指示するルールです。書き方は2通りあります。

方法	書く場所	向いている場面
metaタグ	ページのhead内に <meta name="robots" content="noindex"> を置く	通常のHTMLの記事
X-Robots-Tag	HTTPレスポンスヘッダーに X-Robots-Tag: noindex を返す	PDFなど、HTML以外のファイル

公開したい記事に、公開前の設定のままnoindexが残っていないかを確かめます。記事のソースを表示して、robotsのmetaタグを探すのが簡単です。

Googleのドキュメントでは、noindexを有効にするには、robots.txtでブロックせず、クローラーがページに届くようにする必要がある、とされています。

つまり、検索結果から外したい記事は、robots.txtで塞がずにnoindexを使い、クロールは許可しておきます。効かない条件の詳細は、別の記事「noindexの書き方と効かない条件」にあります。

外部のヘルプデスク製品を使う場合の確認項目

外部のヘルプデスク製品やナレッジベース製品でヘルプセンターを作っている場合、検索エンジン向けの設定は、製品の既定値に左右されます。

仕様は製品ごとに大きく異なります。ここでは確認項目だけを挙げるので、具体的な設定は、利用中の製品の公式ヘルプで確かめてください。

製品ごとに確かめる8項目

確認項目	なぜ確認するか	確認方法
公開範囲の既定値	閲覧がログイン利用者に限られている場合がある	管理画面の公開設定を見る。ログアウトした状態で記事を開く
noindexの既定値	noindexが付く設定の場合がある。公開前の設定が残ることもある	記事のソースでrobotsのmetaタグを探す
ドメイン	提供元のドメインのままか、自社のサブドメインを使えるかで、運用が変わる	製品の独自ドメインの設定項目を見る
描画の方式	本文をJavaScriptで後から読み込む作りだと、実行しないボットに本文が届かない	後述の手順でページのソースを確かめる
robots.txtの編集	製品側のrobots.txtを変更できるかは製品による	サブドメインの/robots.txtを開いて内容を見る
サイトマップ	記事一覧のXMLサイトマップを自動で出せるか	製品のヘルプを読む。/sitemap.xmlを開く
記事のURL	記事ごとに固定のURLがあり、タイトルを変えても変わらないか	記事を編集する前後でURLを比べる
移行時の扱い	製品を乗り換えたとき、旧URLから新URLへ転送できるか	製品の移行に関するヘルプを読む

ドメインの考え方

Googleの検索エンジン最適化スターターガイドは、サブドメインとサブディレクトリのどちらを使うかについて、ビジネス上意味があればどちらでも構わないと説明しています。

提供元のドメインのままだと、AIが内容を自社の公式情報と結びつけにくくなるかどうかは、公式には示されていません。

筆者の判断としては、自社のドメインの配下で運用し、自社サイトのトップやフッターからリンクしておくと、どの会社の公式ヘルプかが人にも機械にも分かりやすくなります。

Search Consoleのドメインプロパティは、すべてのサブドメインとプロトコルのデータを含みます。自社のサブドメインで運用していれば、同じプロパティで状況を確認できます。

提供元のドメインで運用している場合は、自社のプロパティでは見られません。製品側が出す情報を確かめます。

本文が最初のHTMLに入っているかを確かめる

JavaScriptで後から読み込んでいないか

Googleは、JavaScriptを実行してページを描画しますが、描画はクロールとは別の段階で行われると説明しています。

また、ボットによってはJavaScriptを実行できないものもあるため、サーバー側のレンダリング（プリレンダリング）も有効な方法として検討するよう書かれています。

ページのソースで確かめる手順

次の手順で、記事の本文が最初に返されるHTMLに入っているかを確かめます。

1. ブラウザで記事を開き、右クリックから「ページのソースを表示」を選びます。
2. 表示されたソースの中で、記事本文の一文を検索します。
3. 見つかれば、本文は最初のHTMLに入っています。
4. 見つからず、空の枠と大量のスクリプトだけなら、本文はJavaScriptで後から読み込まれています。

Googleから見える姿を確かめる

Googleがどう見ているかは、Search ConsoleのURL検査ツールで、描画後のHTMLを確かめられます。

JavaScriptの文書にも、描画後にもコンテンツを認識できるかを、URL検査ツールなどで確かめるよう書かれています。

ステップ2 記事の単位とカテゴリを設計する

読める状態が確認できたら、記事をどの単位で作り、どう分類するかを決めます。

1記事1タスクにする

ヘルプ記事の基本単位は、利用者がやりたいこと1つです。

機能名で1ページにまとめると、作成・送付・取り消し・宛名変更が1ページに混ざり、読む人も答えの根拠を探しにくくなります。

機能単位の記事（避けたい）	タスク単位の記事（目指す形）
請求書機能について	請求書を作成する
	請求書の宛名を変更する
	送付済みの請求書を取り消す
	請求書をPDFでダウンロードする

Googleの最新ガイドは、AIがコンテンツを理解しやすいように細かく分割する必要はない、と書いています。

ここでの分け方は、読む人が1つの目的をその記事だけで終えられるようにするためです。AI向けに細切れにする意図はありません。

タイトルは利用者の言葉に近づける

タイトルは、「〇〇を△△する」「〇〇できないときの対処法」のように、利用者が質問する言葉に近づけます。

社内でしか通じない機能名や開発中のコード名は、タイトルに使いません。画面に表示される名前と、利用者がやりたいことの両方を入れます。

細かくしすぎない

分けすぎて1記事が2〜3行になるなら、近い操作はまとめて構いません。

目安は、1つの目的がその記事だけで完了するかどうかです。

カテゴリは利用者の目的で分ける

カテゴリは、利用者の目的で分けます。社内の部署や開発チームの分け方は、利用者には関係がありません。

カテゴリ	入れる記事の例
はじめに	アカウントの作成、初期設定
日々の操作	作成・編集・送信など、主要な機能ごとの手順
管理者向け	ユーザーの追加、権限、プランの変更
連携とデータ	取り込み、書き出し、外部サービスとの連携
困ったとき	エラー、ログイン、よくあるトラブル
料金と契約	支払い方法、解約

URLと階層を整える

Googleのスターターガイドは、似たトピックのページをディレクトリにまとめることと、わかりやすいURLを使うことを勧めています。

たとえば /help/invoices/change-recipient のようなURLなら、人が見ても内容が分かります。

階層は2段程度にとどめ、どの記事にも、トップから数回のクリックでたどれるようにします。この段数は筆者の提案です。

ステップ3 全記事共通の型を決める

ここでは、1本ごとの手順の書き方より前に、ヘルプセンター全体で決めておくルールを扱います。

型を決める

記事ごとに書き方がばらばらだと、読む人も、読む仕組みも、必要な情報を探しにくくなります。次のような型を決めて、全記事で揃えます。

項目	書く内容
タイトル	〇〇を△△する
冒頭の1〜2文	この記事で何ができるか。できないことも含めた結論
対象	プラン、アプリのバージョン、対応機種、必要な権限
最終更新日	内容を確認した日
事前に必要なこと	あれば書く
手順	番号付きのリスト
結果	操作のあとにどうなるか
うまくいかないとき	よくある原因と対処
関連記事	次にやること、似た操作

型は、編集画面のテンプレートに登録しておくと、書く人が変わっても崩れにくくなります。

対象プラン・バージョン・権限を必須にする

AI検索の回答には、別のプランの手順や、古いバージョンの手順が混ざるおそれがあります。

記事が数百本になることも珍しくないので、次の項目は、書き手の判断に任せず、全記事の必須項目にします。

項目	書き方の例	必要な理由
対象プラン	全プラン、または「スタンダードプラン以上」	上位プラン限定の機能を、他のプランの人が試して迷わないようにする
対象の環境	iOS版、Android版、パソコンのブラウザ版。機器なら機種名とファームウェアのバージョン	画面が違う手順を取り違えないようにする
必要な権限	管理者のみ	権限がない人の問い合わせを減らす
最終更新日	2026年10月15日のように、ページ上に表示する	古い手順かどうかを、人も機械も判断できるようにする

日付の示し方

Googleの公開日に関するドキュメントは、ユーザーに表示される日付をページに載せて目立つ位置に置き、「公開日」や「最終更新日」のようなラベルを付けるよう勧めています。

構造化データで日付を書く場合は、datePublishedやdateModifiedを使い、表示している日付と一致させます。

更新日は、内容を確認して修正したときにだけ変えます。

Googleの「役に立つコンテンツ」の自己評価には、内容を実質的に変えずに、新しく見せるために日付を変えていないかを問う項目があります。

画面の表記と用語を揃える

画面名やボタン名は、実際の表示どおりに書くのが基本です。ヘルプセンター全体では、次の2つを決めておきます。

• 表記のルール：ボタン名をかぎかっこで囲むか、メニューのたどり方を「設定」から「請求書」へ、のように書くか
• 用語集：「宛名」「送り先」「あて先」のような揺れを1つに決め、画面の文言と合わせる

Googleの開発者向けドキュメントのスタイルガイド（英語）は、手順を番号付きで書くことを勧めています。各手順の最初の文に動作を示す動詞を入れることと、画面上の要素を太字で示すことも勧めています。

日本語のヘルプでは、自社の文体に置き換えて使えます。画面の文言を変えるときは、ヘルプ記事も同時に直す流れを作っておきます。

画像と構造化データの方針

スクリーンショットは補助にとどめ、手順は必ず文字で書く、という方針をヘルプセンター全体のルールにします。

Googleの「AI機能とウェブサイト」のページ（日本語版の最終更新日は2025年12月31日）は、重要なコンテンツをテキスト形式で提示するよう書いています。画像にはalt属性（代替テキスト）を付けます。

手順を表すHowToの構造化データのリッチリザルトは、2023年9月13日にパソコンでの表示も終わり、Google検索では表示されなくなりました。

Googleの生成AI向けガイドは、AI機能のために構造化データは必要ない、とも書いています。まずは本文のHTMLで、見出し・番号付きリスト・表を正しく使うことが先です。

ステップ4 記事どうしをリンクでつなぐ

ヘルプセンターは、記事どうしのつながりで使いやすさが大きく変わります。人にとっても、クローラーにとっても同じです。

リンクはaタグとhrefで作る

Googleのリンクに関するドキュメントによると、Googleがリンクをクロールできるのは、通常、href属性を持つa要素の場合です。

クリックで動くだけのボタンや、JavaScriptだけで移動する仕組みでは、リンク先を見つけてもらえない場合があります。

アンカーテキストを記事名にする

アンカーテキストは、リンクとして表示される文字のことです。Googleは、良いアンカーテキストを、内容が具体的で、適度に簡潔で、リンク元とリンク先の両方に関連があるものだと説明しています。

「こちら」「詳しくはここ」と書かず、リンク先の記事名を書きます。画像をリンクにする場合は、alt属性がアンカーテキストとして使われます。

つなぎ方の4パターン

つなぎ方	例	狙い
前後の記事	「アカウントを作成する」の最後に「初期設定をする」へのリンク	作業の続きを迷わせない
例外の記事	「宛名を変更する」から「送付済みの請求書を取り消す」へのリンク	条件が違う人を正しい記事へ送る
カテゴリのトップ	含まれる記事の一覧と、短い説明を載せたページ	孤立した記事をなくす
関連記事の欄	型の最後に、似た操作を2〜3本並べる	読み終えた人の次の行動を示す

クローラーはサイト内検索の窓に入力しません。検索窓やチャットボットだけに頼らず、リンクで全記事にたどれる構造を用意してください。

サイト全体の点検は、別の記事「AI検索対策の自己診断チェックリスト」でできます。

ステップ5 古い手順を放置しない

製品が更新されるたびに、ヘルプセンターには古い手順が残りがちです。

古い記事が公開されたままだと、いまはできない操作が回答の材料になるおそれがあります。

記事の状態で扱いを分ける

状況	対応	返すステータス
画面や手順が少し変わった	同じURLのまま本文を更新し、最終更新日を変える	200
機能が新しい機能に置き換わった	新しい記事に内容を統合し、旧URLから新しい記事へ転送する	301
機能が廃止され、代わりもない	記事を削除する。必要なら「提供終了のお知らせ」を別に残す	404か410
旧バージョンの利用者がまだいる	記事を分け、タイトルと冒頭に対象バージョンを明記する	200

最後の行の対応は、筆者の提案です。新バージョンの記事から、旧バージョンの記事へ相互にリンクします。

ステータスコードの使い分け

Googleのクロールエラーに関するドキュメントは、ページが削除されていて、同様のコンテンツを含む代替ページがない場合は、404か410を返すよう説明しています。

ページが移動されている場合や、明確な代替ページがある場合は、301で転送します。

まとめて転送しない

Googleのサイト移転に関するドキュメントは、多数の元のURLを、関連性の低い1つのURL（新しいサイトのホームページなど）へ転送することを避けるよう書いています。

このような転送は、ユーザーに混乱を与え、soft 404（存在しないのに200を返しているとみなされるエラー）として扱われる場合もある、と説明されています。

転送の種類の違いは、別の記事「リダイレクトとGoogle検索」にまとめています。

見直しの仕組みを作る

仕組み	内容	担当の例
リリースノートの欄	「影響するヘルプ記事」の欄を設け、リリースのたびに更新対象を洗い出す	製品の担当者
記事一覧の列	「最終確認日」と「担当者」の列を持つ	サポートの担当者
定期の総点検	半年に1回など、決まった周期で全記事を確認する	サポートの責任者

この3つの仕組みと周期は、筆者の提案です。人数が少ない会社は、アクセスの多い記事から順に確認します。

ステップ6 問い合わせの記録から記事を増やす

どの記事を書くかは、問い合わせの記録から決めます。社内の想像で決めると、実際に聞かれることとずれます。

記録から拾う手順

1. 直近3〜6か月の問い合わせ（メール・チャット・電話のメモ）を集めます。
2. 内容を「やりたいこと」の単位でまとめ、件数を数えます。
3. それぞれに対応するヘルプ記事があるかを確かめます。
4. 次の表に従って対応を決めます。

件数と記事の有無で判断する

件数	記事	対応
多い	ない	新しい記事を書く
多い	ある	記事が見つけにくいか、分かりにくい。タイトル・冒頭・リンクを見直す
少ない	ない。ただし回答に時間がかかる	手順記事にして、サポートの負担を減らす
少ない	ある	現状のまま。定期の総点検で確認する

利用者の言葉を取り入れる

問い合わせの文面には、利用者が実際に使う言葉が残っています。「宛名」「送り先」「あて先」など、文面に出てくる言葉を、記事のタイトルや冒頭に取り入れます。

AI検索への質問も、同じような言葉になると考えられます。これは筆者の推測です。

個人情報を混ぜない

記録を使うときは、個人名や契約内容などの個人情報が、記事に混ざらないようにします。

事例として載せる場合は、特定の人が分からない形に書き換えます。

よくある失敗

失敗	起きること	直し方
製品の初期設定のまま公開している	公開範囲やnoindexが既定値のままで、検索エンジンから見えない	製品の公式ヘルプで既定値を確かめ、ログアウトした状態で記事を開く
テスト中の巡回禁止を外し忘れている	ヘルプセンター全体がクロールされない	robots.txtを開いて、Disallowの行を確かめる
同じ手順が複数の記事にある	片方だけ更新され、内容が食い違う	手順は1か所に書き、他の記事からはリンクで案内する
製品を乗り換えて旧URLを放置した	旧URLが404になり、リンクも切れる	対応する新しい記事へ、301で転送する
日付だけを新しくしている	更新日が信用されなくなる	内容を確認して修正したときだけ、更新日を変える

チェックリスト

公開と技術

• ログアウトした状態で、すべての一般向けの記事が読める
• robots.txtで、ヘルプセンターのパスやサブドメインを巡回禁止にしていない
• 公開したい記事に、noindexが付いていない
• 外部製品の公開範囲・noindex・ドメイン・描画方式・サイトマップを、公式ヘルプで確かめた
• ページのソースに、記事の本文が含まれている
• Search Consoleで、主要な記事がインデックスに登録されている
• 記事ごとに固定のURLがあり、意味の分かる単語が入っている

記事の型

• 1記事1タスクで、タイトルが利用者のやりたいことになっている
• 全記事共通の型があり、編集画面のテンプレートに登録している
• 対象プラン・バージョン・必要な権限・最終更新日を、全記事に書いている
• 表記のルールと用語集があり、画面の文言と一致している
• 手順が文字で書かれ、画像は補助になっている。画像にはalt属性がある

構造と運用

• カテゴリが利用者の目的で分かれ、カテゴリのトップページがある
• 全記事に、リンクでたどり着ける
• リンクの文字が、リンク先の記事名になっている
• 廃止や統合をした記事を、404か410、または301で処理している
• リリースのたびに、影響する記事を洗い出す流れがある
• 問い合わせの記録から、追加や改善をする記事を定期的に決めている

よくある質問

Q. ヘルプセンターは、サブディレクトリとサブドメインのどちらがよいですか？

ログインなしで読めて、クロールできる状態なら、どちらでも大きな問題はありません。Googleも、ビジネス上意味があればどちらでも構わないと説明しています。

自社のドメインの配下で運用し、自社サイトからリンクして、公式のヘルプだと分かるようにしておくのが筆者のおすすめです。外部製品が独自ドメインに対応しているかは、製品の公式ヘルプで確かめてください。

Q. 契約者限定の情報は、すべて公開すべきですか？

すべてを公開する必要はありません。セキュリティに関わる手順や、個別の契約の情報は、非公開のままにします。

一方、一般的な操作の手順まで閉じていると、AI検索で「この製品では〇〇できない」「情報が見つからない」と答えられる原因になりえます。公開しても困らない手順は、できるだけ公開することをおすすめします。

Q. チャットボットを入れていれば、ヘルプ記事は少なくてもよいですか？

おすすめしません。チャットボットの会話は、通常、誰でも読める固定のURLを持たないため、検索エンジンが読む公開ページにはなりにくいと考えられます。

これは筆者の推測です。

チャットボットの元になる手順は、ヘルプ記事として公開しておくと、人にも検索エンジンにも使えます。

Q. AI検索のために、構造化データを入れたほうがよいですか？

Googleの生成AI向けガイドは、AI機能のために構造化データは必要ない、と書いています。特別なschema.orgのマークアップも要りません。

入れる場合は、ページに表示している内容と一致させます。手順を表すHowToは、Google検索のリッチリザルトとしては表示されなくなっています。

Q. 更新日は、毎月変えたほうがよいですか？

変える必要はありません。内容を確認して、手順を直したときにだけ変えます。

Googleの自己評価の項目には、実質的な変更がないのに日付を変えていないかを問うものがあります。

まとめ

ヘルプセンターをAI検索に正しく参照してもらうために、特別な仕掛けは要りません。やることは3つです。

1. 読める状態にする：ログインなし、クロール可能、本文が最初のHTMLにある。外部製品なら公開範囲・noindex・ドメイン・描画方式を確かめる
2. 揃えて設計する：1記事1タスク、目的別のカテゴリ、全記事共通の型、表記と用語の統一、記事どうしのリンク
3. 古くしない：リリースと連動した見直し、古い記事の更新・統合・削除、問い合わせの記録からの追加

今日できる点検

まずは、ログアウトした状態で自社のヘルプセンターを開き、主要な記事を5本選んで、次の表で確かめます。

確かめること	見る場所	問題があったとき
ログインなしで開けるか	ログアウトした状態のブラウザ	公開範囲の設定を見直す
noindexが付いていないか	ページのソースのhead内	外部製品の設定か、テンプレートを直す
本文が最初のHTMLにあるか	ページのソース	描画の方式を製品の公式ヘルプで確かめる
対象プランと最終更新日があるか	記事の冒頭	テンプレートに必須項目を足す
古い手順が残っていないか	製品の最新の画面と比べる	更新・統合・削除に振り分ける

ページを増やしても問い合わせが来ないなら、原因はページの外にあります。その場合は、下の入口からご相談ください。