ヘルプページが検索で埋もれる原因と対策｜問い合わせを減らす導線

「ヘルプに書いてあるのに、同じ質問が毎週届く」「問い合わせを減らしたいが、どこから直せばよいのか分からない」——サポートとマーケの間で落ちやすい課題です。原因は文章の分かりにくさだけではありません。そのページが検索で見つけられる状態になく、問い合わせるほうが早いと判断されています。この記事では、埋もれる原因を6つに分けて、本体のサイトとつなぎ直す順序を整理します。

同じ質問が毎週届く

サポート部門の負荷は、質問の難しさよりも同じ質問の繰り返しで決まります。1件の回答に5分かかる質問が週に10件届けば、月に3時間以上が同じ説明に消えます。担当者が2人なら、その分の時間が別の業務から奪われます。

この状態で最初に持ち上がる案が、回答テンプレートの整備です。返信の時間は短くなりますが、届く件数そのものは減りません。負荷の原因が受信の量にあるなら、受信を減らす手を打たないと状況は変わりません。

受信を減らす手段が、顧客が自分で答えを見つけられる状態を作ることです。カスタマーサポートの分野では、これをセルフサービスと呼びます。Zendeskは、同社のヘルプセンター機能を使ったセルフサービス型のサポートの導入でメールによる問い合わせが57パーセント減少した事例を紹介しています。

ただし、記事を用意すれば自動的にそうなるわけではありません。顧客が困ったときに最初に開くのは自社のヘルプセンターではなく検索エンジンです。検索して出てこなければ、記事の存在は認識されません。

この記事では、サポートコンテンツの検索面と本体サイトとの導線に絞って扱います。記事の文章をどう書くかではなく、書いた記事が見つかる状態になっているかという部分です。文章の質を上げる前に、そもそも表示されているかを確認する必要があります。

ヘルプ記事は存在していた

実際に調べてみると、ヘルプ記事が用意されていないケースは少数です。多くの場合、記事はすでに存在しています。数年前にサポート部門が整備し、そのまま運用されているという状態です。

問題は、その記事がマーケティング側の視界に入っていないことです。サイトの分析レポートに含まれておらず、Search Consoleのプロパティにも登録されていないという状況が珍しくありません。数字がないため、機能しているかどうかも分かりません。

確認は簡単にできます。実際に顧客が使うであろう言葉で検索して、自社のヘルプ記事が出てくるかを見るだけです。製品名と操作名を組み合わせた語を5つほど試せば、状況の見当がつきます。

多くのサイトでは、この確認で3つのパターンのどれかに当たります。他社の解説記事が上に出ている、自社の本体サイトの別ページが出ている、そもそも自社のドメインが1件も出てこないのいずれかです。

3つ目に当たった場合、原因は記事の内容ではありません。クロールやインデックスの段階で止まっているか、検索エンジンから見て本体サイトとつながっていない状態です。ここから、原因を6つに分けて確認していきます。

原因1：別サブドメインで本体と切れている

ヘルプセンターは、専用のツールで運用されることが多く、その場合はhelpやsupportで始まる別のサブドメインに置かれます。本体サイトとは別のURLで動くため、検索エンジンからは別の領域として扱われます。

SEOの観点では、サブドメインは親ドメインとは独立したサイト領域として扱われ、サブディレクトリは親ドメインの一部として認識されるとされています。Googleは公式にはサブドメインが不利になるとは言っていませんが、実務では本体より評価が上がりにくいという指摘もあります。

実際に問題になるのは、評価の理屈より運用の切れ目です。本体サイトからヘルプセンターへのリンクがフッターの1行だけ、という構造になっていることがよくあります。クロールの経路が細く、記事が増えても回りません。

さらに、Search Consoleの登録が別になる点も見落とされます。サブドメインは別プロパティとして登録しないと、表示回数もクリック数も見えないためです。登録していなければ、数字がないのは当然です。

外部ツールの標準ドメインをそのまま使っている場合は、自社のドメインの外に出ています。この状態では検索の成果が自社サイトの資産として積み上がりません。多くのツールは独自ドメインの割り当てに対応しているため、まず設定を確認してください。

移設を検討する場合は、URLの転送が必須になります。既存の記事のURLが変わると、それまでの検索の評価と外部からのリンクが切れます。記事ごとに旧URLから新URLへ転送をかけるところまでを移設の作業に含めてください。件数が多い場合は、閲覧の多い記事から優先します。

原因2：noindexのまま公開されている

2つ目の原因は設定です。ヘルプセンターの構築中にnoindexを付け、公開後に外し忘れているケースが実際にあります。設定は画面のどこにも表示されないため、気づかれません。

確認の方法は3つあります。ページのソースにnoindexの記述がないか、robots.txtでクロールが止まっていないか、Search ConsoleのURL検査ツールでインデックスの状態がどうなっているかです。この3点を見れば原因が絞れます。

外部ツールで運用している場合は、ツール側の設定にも検索エンジンへの公開のオンとオフの項目があります。初期値が非公開になっているツールもあり、意図せず検索の対象外になっていることがあります。管理画面の設定を確認してください。

あわせて注意したいのが、robots.txtとnoindexの順序です。robots.txtでクロールを止めていると、後からnoindexを外しても状態がすぐには変わらないことがあります。まずクロールを通す設定に戻してください。

サブドメインが検索結果に出ない原因としては、DNSの設定の誤り、robots.txtでのクロール拒否、Search Consoleの未登録、インデックス登録のリクエストの未実施、noindexの設定の誤りが挙げられています。いずれも記事の内容とは無関係で、設定の確認だけで判別できます。

原因3：ログインの内側にある

3つ目の原因は、ヘルプ記事が認証の内側にあることです。契約者向けの情報を扱うため、ログインしないと読めない設計になっているケースです。

この設計自体は間違いではありません。契約内容や管理画面の詳細は、外部に公開すべきでない情報を含みます。問題は、公開できる内容と公開できない内容を分けずに、全部を内側に置いてしまうことです。

分ける基準は、その情報が検討中の見込み客にとって有用かどうかです。製品の基本的な使い方、対応している形式、よくあるエラーの意味などは、公開しても不都合が少ない情報です。むしろ検討の段階で読まれることに価値があります。

公開の効果は問い合わせ削減だけではありません。導入前の顧客が使い方を確認できると、検討の段階での不安が減るという効果もあります。営業が説明していた内容の一部を、記事が代わりに担います。

実務としては、記事に公開と非公開の区分を設けて運用します。ツール側で記事ごとに公開範囲を指定できる場合が多く、既存の記事を1本ずつ振り分けるだけで済みます。全記事を見直す必要はなく、問い合わせの多い上位から着手すれば十分です。

原因4：1問1答が薄すぎる

4つ目の原因は記事の中身です。検索の対象になっていても、1問1答が数行しかない記事は、検索結果で上位に出にくくなります。

薄くなる理由は、記事の作り方にあります。問い合わせへの返信文をそのまま記事にすると、前提を共有している相手向けの短い文章になります。検索から来る人はその前提を持っていません。

必要なのは、質問の前後を補うことです。どういう状況でこの質問が出るのか、操作の手順はどうなるのか、うまくいかない場合は何を確認するのかまで書きます。1本あたり数百字から千字程度が現実的な水準になります。

あわせて、顧客が使う言葉に合わせる必要があります。社内の正式な機能名で書かれた記事は、顧客の言葉で検索されたときに出てこないためです。Zendeskも、顧客がよく使う言葉を用いて分かりやすい文章を本文に構成することが効果的だと説明しています。

画面の画像や短い動画も有効です。操作の手順は文章だけでは伝わりにくく、画像があるだけで問い合わせが減ることがあります。ただし画面の更新に追随する運用が必要になるため、変わりにくい部分から入れてください。

記事の形式も揃えておきます。質問、前提となる状況、手順、確認する点、それでも解決しない場合の連絡先という並びを型にすれば、書く側の負担も下がります。型があると、サポート担当が回答の合間に1本ずつ追加していく運用が回るようになります。

原因5：内部リンクがない

5つ目の原因はリンクの構造です。ヘルプ記事どうし、そして本体サイトとの間にリンクがないと、クロールも回遊も起きません。

ヘルプセンターのツールは、記事をカテゴリの一覧に並べる構造を持っています。一覧からは各記事にリンクされていますが、記事から記事へのリンクは自動では生成されません。関連する記事へのリンクは手で入れる必要があります。

本体サイトとの間のリンクは、さらに抜けやすくなります。本体からヘルプへはフッターの1行だけ、ヘルプから本体へはロゴのリンクだけという状態が標準的です。この細さでは、検索エンジンから見て2つのサイトはほとんど独立しています。

効果が出やすいのは、機能を説明しているサービスページとヘルプ記事を相互に結ぶことです。サービスページに操作手順の記事へのリンクを置くと、検討中の読み手にも役立つという副次的な効果もあります。

記事側からも本体に戻す導線を置きます。記事の末尾に、関連する記事とサービスページ、そして解決しない場合の問い合わせ先を並べるのが基本の形です。この3点セットをテンプレートにして、記事を追加するときに必ず入れる運用にしてください。

原因6：更新が止まっている

6つ目の原因は運用です。ヘルプ記事は一度作れば終わりという扱いになりやすく、製品が変わっても記事が変わらない状態が生まれます。

止まる理由は担当の構造にあります。記事を書いたのはサポート部門で、製品の変更を知るのは開発部門、検索の数字を見るのはマーケティング部門という分かれ方をしています。誰の担当でもない状態になります。

古い記事が残ると、問い合わせは減るどころか増えます。記事に書いてある手順どおりに操作できないという問い合わせが、新しい種類として発生します。読まれているからこそ起きる問題です。

更新の起点は2つ用意します。1つは製品のリリースに合わせた見直し、もう1つは問い合わせが来たときに該当記事を必ず開くという習慣です。後者は追加の工数がほぼかかりません。

記事ごとに最終更新日を表示しておくと、読み手も判断できます。更新日が2年前の記事は、内容が正しくても信頼されにくくなります。棚卸しの対象を選ぶときの手がかりにもなります。

サポートとマーケが別々に動いている

ここまでの6つの原因は、技術的にはどれも数時間で確認できるものです。それにもかかわらず放置されるのは、部門の境目に落ちているからです。

サポート部門の目標は問い合わせへの対応品質と時間であり、検索の順位は評価の対象になりません。マーケティング部門はサイトの流入を見ていますが、ヘルプセンターのドメインは分析の対象に入っていません。両方から外れています。

この構造から生まれる失敗は決まっています。

• ヘルプのドメインがSearch Consoleに未登録：表示回数もクリック数も分からず、改善の起点が作れません
• 問い合わせの多い質問が記事になっていない：ログを持つ部署と記事を作る部署が別のため、需要が伝わりません
• 本体サイトの改修でヘルプへのリンクが消える：制作の要件に入っておらず、リニューアルのたびに切れます
• 記事の更新の担当が決まっていない：製品の変更が記事に反映されず、古い手順が残り続けます

対処は組織の再編ではなく、担当の1行を決めることです。誰がSearch Consoleを見て、誰が記事の追加を判断するかを決めるだけで、上の4つはほぼ解消します。月に1度の30分の確認で足ります。

会議の場も1つ用意します。問い合わせの上位10件をサポートが持ち込み、記事化の優先順位をその場で決めるという形が実務的です。

担当を決めるときは、記事を書く人と検索の数字を見る人を分けても構いません。サポートが内容を書き、マーケティングが表示回数と検索された語を持ち込む形でも回ります。重要なのは、どちらの立場からも見えていない期間を作らないことです。ここから先は、対策の中身に入ります。

対策1：需要のある質問を拾う

最初の対策は、どの質問を記事にするかの決め方です。思いついた質問を書くのではなく、需要が確認できている質問から着手します。

拾い先は社内にあります。次の4つを見れば、需要のある質問はほぼ揃います。

• 問い合わせのログ：直近3か月のメールとチャットを質問の種類で分類する
• サイト内検索の語：本体サイトとヘルプセンターの両方の検索キーワードを見る
• ヘルプセンター内の検索で結果が0件だった語：記事がない質問がそのまま出る
• 営業と導入支援の担当が繰り返し説明している内容：記録に残っていない需要が拾える

3つ目が最も見落とされます。ヘルプセンター内で検索されたが該当記事がなかった語は、需要があって供給がない質問そのものです。Zendeskは、同社のヘルプセンター機能でキーワード検索の傾向や実際に参照された記事を分析できると説明しています。

拾った質問は件数の多い順に並べます。上位10件で問い合わせ全体の半分を占めることが多く、そこから着手すれば効果が早く出る傾向があります。全部を記事にしようとすると終わりません。

分類の作業は、生成AIに下ごしらえをさせると短縮できます。数百件の問い合わせ本文を渡して質問の種類ごとに分類させ、人が分類名を整える流れです。件数の集計まで済ませてから、記事化の判断を人が行ってください。

拾った質問は一覧にして残してください。記事にした質問と、まだ記事がない質問を同じ表で管理すると、次に書くものがその場で決まります。件数と最終確認日の2列を足しておけば、需要が変わったときにも並べ替えるだけで優先順位が入れ替わります。

対策2：記事の粒度を決める

2つ目の対策は粒度です。1記事に何を書くかの単位が揃っていないと、検索でも社内の運用でも扱いにくくなります。

基本の方針は、1つの質問に1記事です。複数の質問を1記事にまとめると、検索結果に表示されたときに求めている答えが含まれているか分かりにくくなります。個別の質問ごとにページを持たせてください。

例外は、手順が連続している場合です。初期設定の1から5までのように順番に実施する内容は、1記事にまとめたほうが読み手にとって分かりやすくなります。分割の基準は、読み手の作業が1回で完結するかどうかです。

逆に分割すべきなのは、よくある質問を1ページに詰め込んだ形式です。20問が1ページに並んだFAQは、個別の質問では検索に出にくい傾向があります。件数の多い質問から順に、独立したページに切り出してください。

タイトルの付け方も粒度に含まれます。顧客が検索する言葉をそのままタイトルにするのが最も確実です。設定変更の方法という抽象的な見出しではなく、通知メールの送信先を変更する方法のように具体的に書いてください。

対策3：本体サイトと相互リンクする

3つ目の対策は、本体サイトとヘルプセンターを結び直すことです。技術的な難しさはなく、リンクを増やすだけで状況が変わります。

本体からヘルプへは、3か所に置きます。グローバルのナビゲーション、機能を説明しているサービスページの本文、そして問い合わせフォームの手前です。3か所目は、問い合わせを減らす効果が最も直接的に出ます。

フォームの手前に置くリンクは、質問の種類ごとに分けると効果が上がります。よくある質問を3つから5つ並べ、それぞれの記事に直接リンクする形にします。フォームを開いた人の一部が、送信せずに解決します。

ヘルプから本体へは、記事の末尾に置きます。関連記事、関連するサービスページ、解決しない場合の問い合わせ先の3点をテンプレートにする運用にしてください。記事を追加するときに毎回入るようになります。

あわせて、サイトマップの送信も確認してください。ヘルプセンターのXMLサイトマップを、そのドメインのSearch Consoleのプロパティに送信します。外部ツールの場合はサイトマップが自動生成されていることが多く、URLを確認して送るだけで済みます。

• ヘルプが別ドメインの場合、Search Consoleは別プロパティとして登録する。登録がなければ数字は見えない
• 本体サイトのリニューアルの要件に、ヘルプへのリンクの維持を明記する。改修のたびに切れやすい

置き場所をどう決めるか

これから整備する場合、あるいは移設を検討する場合の置き場所の判断を整理します。検索からの流入を重視するかどうかで結論が変わります。

置き場所	検索での扱い	向いている状況
本体のサブディレクトリ	本体サイトの一部として扱われる	検索からの流入を増やしたい
自社の別サブドメイン	別のサイト領域として扱われる	本体とCMSや権限を分けたい
外部ツールの標準ドメイン	自社ドメインの外に出る	運用の手間を最小にしたい
ログインの内側	検索の対象外	契約者限定の情報を扱う

検索面だけで見れば、1行目が最も有利です。本体サイトの一部として扱われるため、既存の評価の恩恵を受けやすくなります。ただし本体のCMSで記事を管理する必要があり、サポート部門が更新しにくくなる場合があります。

2行目は、運用の分離と検索面の折り合いを取る選択です。専用ツールの使いやすさを保ちながら、自社ドメインの中に置けます。多くのツールが独自ドメインの割り当てに対応しているため、実務ではこの形が選ばれやすくなります。

3行目は避けたい選択です。外部ツールの標準ドメインに置くと、検索の成果が自社の資産として残らないためです。すでにこの状態なら、独自ドメインへの移行を検討してください。

4行目との併用も一般的です。公開できる記事はサブディレクトリやサブドメインに、契約者限定の情報はログインの内側に置くという二層構造にします。記事ごとに公開範囲を指定できるツールなら、同じ管理画面で運用できます。

移設の判断では、労力と効果を並べてください。記事が数十本なら移設は数日の作業ですが、数百本あれば転送の設定だけで相当な工数になります。件数が多い場合は、閲覧の多い上位の記事だけを本体側に作り直し、残りは現状のまま運用する折衷案も選べます。

問い合わせ削減の効果を測る

整備した後は、効果を数字で確認します。ここを飛ばすと、次の記事を作る優先順位が決められません。

工程5の指標について、Zendeskはセルフサービススコアをヘルプセンターのユーザー数をチケットを作成したユーザー数で割った値として説明しています。4対1という比率は、セルフサービスを利用した4人のうち1人が問い合わせを送ったという意味になります。

なお、自己解決したかどうかを正確に測ることはできません。顧客は解決できたことを企業に報告しないため、完全な把握は原理的に難しいと同社も説明しています。比率の推移を見る指標として扱ってください。

工程4は、部門をまたぐ数字になります。記事を整えたカテゴリの件数だけを見ると、他の要因の影響を受けにくいため、全体の件数より判断しやすくなります。新機能のリリースで別の質問が増えても、比較が崩れません。

報告の形も決めておきます。問い合わせ件数の推移とヘルプ記事の閲覧数を同じ1枚に並べれば、記事を増やした月と件数が減った月の関係が見えます。部門をまたぐ施策では、この1枚が継続の判断材料になります。数字がなければ、整備の工数は次年度に確保できません。

ミニ用語解説

サポートコンテンツの検索面を扱うときに出てくる用語を整理します。部門をまたぐ議論では、言葉の定義がずれていることが原因で話が進まなくなります。

議論でずれやすいのは、セルフサービススコアと自己解決率です。前者は比率として計算できますが、後者は顧客が申告しないため正確には測れません。目標として置く場合は、計算できる前者を使ってください。

noindexも誤解されやすい用語です。検索結果に出さない設定であり、URLを知っている人のアクセスは防げないため、社外に出せない情報は認証の内側に置く必要があります。

用語の定義は、社内の1ページにまとめておくと会議が短くなります。サポートとマーケティングと開発の3部門が同じ言葉で話せる状態を作ることが、この整備の前提になります。

まとめ

ヘルプ記事が読まれない原因は、書き方より前に検索で見つからないことにあります。別サブドメインで本体と切れている、noindexのまま公開されている、ログインの内側にある、1問1答が薄すぎる、内部リンクがない、更新が止まっている。この6つを順に確認すれば、原因はほぼ特定できます。

対策の中心は3つです。問い合わせログとサイト内検索から需要のある質問を拾い、1つの質問に1記事の粒度で書き、本体サイトと相互にリンクする。とくに問い合わせフォームの手前によくある質問へのリンクを並べる施策は、問い合わせの削減に最も直接効きます。

最初にやることは確認です。顧客が使うであろう言葉で5つ検索して、自社のヘルプ記事が出てくるかを見てください。1件も出てこなければ、Search Consoleにそのドメインが登録されているかを確認するのが次の一手になります。記事を増やすのはその後で構いません。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。