クロールが届き、正しい情報を渡せているか:robots.txt、Cloudflare、レンダリング、古いURL
記事の冒頭で筆者のLoren Baker氏は、ローカルページは、その情報にアクセスできない、描画できない、あるいは信頼できないAIシステムからは可視性を得られないと書き、Darren Shaw氏の次の発言を引いています。
You cannot be surfaced in AI responses if the AI can’t even access your website.
日本語にすると「AIがそもそもあなたのサイトにアクセスすらできないなら、AIの回答に表示されることはない」という内容です。Baker氏は、新しいFAQを追加したりサービスページの文章を書き直したりする前に、クローラーがそのページに到達できることと、そこで見つかる事業者情報が正確であることの2つを確認する必要があると述べています。
Russ Jeffery氏が勧めるのは、ページが発見されうるかどうかを決める基本的な設定——robots.txtファイル、noindexディレクティブ、セキュリティ設定、サイトマップ、コンテンツの描画方法——から始めることです。Jeffery氏自身、noindexタグを外し忘れたままサイトを公開したことがあると認めており、後から直すのは最初から正しくやるよりはるかに長い時間がかかる、と述べています。またrobots.txtそのものについても、規約を守るクローラーに向けた指針としての方針にすぎず、鎖の中のやや弱い輪だとして、本当に非公開にすべきコンテンツはサーバーまたはアプリケーションのレベルで制限すべきだとしています。
Shaw氏がもう一つの障害として挙げるのがCloudflareです。
Cloudflare often blocks AI crawlers by default,
日本語にすると「Cloudflareは既定でAIクローラーをブロックしていることが多い」という内容です。多くの事業者は、自社のウェブ制作者やホスティング事業者がそれを有効にしたことを知らないとされ、Shaw氏はAIクローラーをブロックしていたShopifyのサイトで原因がCloudflareだった例を挙げています。対処法は、Cloudflareが使われているかを確認したうえで設定を見直すことです。両氏とも、すべてのクローラーをブロックする既定値を、パブリッシャー向けに作られた方針が全員に適用されたものだと捉えています。TimeやThe New York Timesのようなパブリッシャーならクローラーに対価を払わせたい場合もあるが、世界中の小規模事業者はクローラーをブロックしたいとは思っていない、という整理で、Jeffery氏はこれをa bad default by them.(彼らによる悪い既定値だ)と呼んでいます。
描画についてJeffery氏は、JavaScriptのレンダリングがここ数年で後退したと述べています。GoogleはJavaScriptを実行し、この点では今もうまくやっている一方で、新しいAIシステムの多くはそうではない、という見方です。
ChatGPT doesn’t have their own index, they don’t take the time to actually index and save pages within their infrastructure,
日本語にすると「ChatGPTは自前のインデックスを持っておらず、自社のインフラの中でページを実際にインデックスして保存するという手間をかけていない」という内容です。Jeffery氏の助言は、重要なコンテンツをサーバーサイドレンダリング(サーバー側でHTMLを組み立てて返す方式)でHTMLレスポンスに載せ、フレームワークが処理してくれたはずだと思い込まずに確認することです。同氏はこれを標準で行うか選択肢として提供している例としてWordPressとNext.jsを挙げ、より大きなリスクはクライアントサイドのJavaScriptに強く依存した、新しく生成されたサイトから来る可能性があるとしています。Shaw氏も、小規模事業者の多くがClaude CodeのようなツールでReactを多用したサイトを生成しているとしてIf you’re just vibe coding a website, they’re usually pretty bad, and I would just pay attention to that,(サイトをただバイブコーディングで作っているだけなら、たいていかなり出来が悪いので、そこには注意を払ったほうがいい)と述べる一方、大多数の事業者はこれを心配する必要はないとも言い添えています。Duda、WordPress、Wix上のサイトはすでに描画済みのHTMLを返しているためで、やるべき作業は、クローラーが何を受け取っているかの確認と、ウィジェットで読み込まれるレビューのカルーセルのように、重要な文章がJavaScriptの実行後にしか現れない箇所の洗い出しだとされています。なおJeffery氏は、Cloudflareがオプションとして推しているというページのマークダウン版について、今それが必須だとは言わないとし、それに依存しているAI検索エンジンはまだ見つけられていないとしています。
クロールが届いても、情報が誤っていては意味がありません。Baker氏は、AI Overviewsのファクトチェックで時々見つける問題として、「-old」「-new」「/home」「v2」といったラベルが付いた孤立・重複URLを挙げています。リニューアルの際に制作者がページを複製し、元のページをインデックスから外さないまま残したもので、古い電話番号や住所がそのまま載っていることがあります。顧客がナビゲーション経由でそこへ到達することはめったにありませんが、クローラーは到達します。Shaw氏の言葉ではthe AIs would grab it.(AIはそれを拾ってしまうだろう)です。壊れたページだけを探す技術監査では見落とすため古いバージョンも探す必要があるとされ、Baker氏はプラットフォームを問わずクロールを実行し、これらの接尾辞を持つURLで絞り込み、そのいずれもインデックス可能でない状態にすることを推奨しています。
スキーマの評価は3者で割れた:効果、維持コスト、FAQスキーマ
Baker氏は、スキーマがパネルで唯一意見の割れたトピックであり、その割れ方こそが有用な部分だと書いています。Baker氏自身は肯定的で、Googleビジネスプロフィールのデータ項目をすべてサイトのスキーマに反映させており、そうしたサイトはローカルパックでも通常のオーガニック検索でも可視性が高まるように見えるとしています。ただしランキング要因とは見ておらず、検証(バリデーション)のためのツールだと位置づけています。一方、Shaw氏は懐疑的です。
I’ve never seen any noteworthy study that said, if you do schema, your traditional rankings will go up or your AI visibility will go up.
日本語にすると「スキーマを実装すれば従来の順位が上がる、あるいはAIでの可視性が上がると述べた、注目に値する研究を私は見たことがない」という内容です。Shaw氏はJake Hundley氏による詳細なテストに言及し、そこでは何も見つからなかったとしています。同氏が価値を認めているのは曖昧性の解消で、表に入った製品データは構造化データとして表現されると曖昧さがなくなり、ページのレイアウトから読み取るよりクローラーが解析しやすくなるという説明です。Jeffery氏は中間に立ち、You totally should do it,(絶対にやるべきだ)としたうえで条件を一つ付けています。スキーマはウェブサイトとGoogleビジネスプロフィールに並ぶ第3の事業者データの情報源であり、最悪のケースはそれが古びることだ、という条件です。
リスクは維持にあります。Shaw氏は、2017年に構築され制作者がスキーマを追加したサイトで、2025年にオーナーが刷新した際にスキーマが一切触られなかった例を挙げました。存在を知らなかったRankMathの設定の中にスキーマがあったためです。Jeffery氏も、クライアントがページ上の電話番号を更新する一方でGoogleビジネスプロフィールとの同期を設定していないために、マークアップに古い番号が生きたまま残るパターンをDudaで見ているとして、これは最適化の問題というよりmore of a process problem(どちらかというとプロセスの問題)だと述べています。Shaw氏はBaker氏の「検証ツール」という捉え方に同意し、Googleビジネスプロフィールのすべてのデータ項目をスキーマにマッピングするというアイデアに強く関心を示して、それを行うツールを作りたいと述べました。Jeffery氏は、Dudaにはすでにそうしたツールがあると答えています。実務上の原則は、スキーマを更新プロセスに含めるべきもう一つの事業者データの情報源として扱うことで、住所、電話番号、サービス、対応エリアを変更したら、その事実が載っているすべての場所を確認する運用になります。
視聴者のTodd Vaughn氏からは、Googleがリッチリザルトを廃止した今もFAQやQ&Aのスキーマに意味はあるのか、という質問が出ました。Shaw氏の回答はI wouldn’t call it important. I would say it’s helpful for sure(重要だとは言わない。役に立つことは確かだと言う)で、回答がJavaScriptによって挿入されている場合には有効だとしています。そうでない場合、LLMはページを大きなテキストのマークダウンファイルに削ぎ落とすため、スキーマでマークアップされページ上にも表示されているFAQは、同じものが二度現れるだけになるという説明です。記事末尾のKey Takeaways(筆者Baker氏によるまとめ)でも、スキーマは証明された順位上の見返りがない維持のコミットメントであり、維持されていないマークアップこそがパネルの挙げた唯一の有害なシナリオだったと整理されています。
AI向けのサービスページに何を書くか:クエリファンアウト、ネガティブレビュー、主語を社名に
Shaw氏のリサーチは「AIは何を気にするのか」という、機械そのものへの問いから始まります。作業例は配管業者の給湯タンク修理のページで、すでにSEO向けには最適化済み、これからAI可視性のために二巡目の改善をかけるという設定です。Shaw氏はGoogleのAsk Maps(Mapsのデータに接地したGemini)、あるいはGeminiやClaudeに直接、そのページに何を載せるべきかを尋ねます。返ってくる答えは予想どおりで、They’re always going to tell you pricing,(AIは必ず価格を挙げてくる)に加えて、信頼の証、レビュー、事例です。Jeffery氏はここに資格・認定と対応エリアを加えています。
2つ目の手順がクエリファンアウト——利用者の1つの入力から、AIが自分で複数の検索を走らせる挙動です。Shaw氏はMark Williams-Cook氏のqueryfan.comを使うとしています。挙げられている例は、利用者がチャットボットに「昨夜給湯タンクが壊れた、早く修理したい、予算は厳しい」と伝えるケースで、これに答えるためAIは自前の検索を一式実行します。
It takes your one prompt and turns it into 10 other prompts.
日本語にすると「あなたの1つのプロンプトを、10個の別のプロンプトに変える」という内容です。その10個の検索こそがページのよくある質問だというのがShaw氏の主張で、ページがそれらのうち多くに関連性を持つほど、元のプロンプトへの回答で引用される可能性が高まるとしています。Jeffery氏はもっと手をかけない情報源として、事業者本人に顧客がいつも何を尋ねてくるかを聞くことを挙げ、答えがイエスであれノーであれ、とにかく答えを持っている必要があると述べています。消費者はより多く、そして大きく異なる内容を検索しており、より長いクエリで検索し、より頻繁に追加の質問をしているというのが同氏の見立てで、技術者が資格を持っているか、特定のエリアに対応しているか、緊急の依頼に対応できるかといった質問が想定されています。同氏が挙げた印刷会社の例は「297gsmの用紙にA1サイズで印刷できますか」で、その答えがサイトのどこにもなければ、AIが拾って答えに使えるものは何もないとされています。
もう一つの材料が、競合のネガティブレビューです。Shaw氏のお気に入りのリサーチ用プロンプトは、Googleビジネスプロフィールのデータに接地しているという理由でAsk Mapsで実行されます。
For plumbers in my city, please analyze their reviews and tell me the most common pain points that people are complaining about in negative reviews.
日本語にすると「私の市の配管業者について、そのレビューを分析し、ネガティブレビューで人々が不満を述べている最も一般的な痛点を教えてほしい」という内容です。事業者はその懸念に対して、自社が裏付けられる正確な約束をもってサービスページ上で直接応えられます。顧客が尋ねる前に不安に答えるためコンバージョンの助けになり、同時にAIシステムに、その事業者が約束する体験についての明示的な証拠を与えることになる、と記事は説明しています。Shaw氏が挙げた例は、いつも時間どおりに伺う、家を自分の家のように扱う、家を汚さないよう靴に専用のカバーを履く、作業後は片付ける、といった文言です。効果の見立ては分けて語られており、コンバージョンについては間違いなく価値があると確信を示す一方、AIへの効果についてはAIの回答でわずかな優位を与えるかもしれない、と留保が付けられています。
AIがページをどれほど字義どおりに読むかについて、Shaw氏はこう述べています。
You can basically say any BS numbers you want on your webpage, and AI will cite it.
日本語にすると「ウェブページには基本的に、好きなだけでたらめな数字を書くことができ、AIはそれを引用する」という内容です。実際には220件のレビューしかないのに5つ星レビューが10,000件あると書けば、AIは10,000という数字を繰り返すとされています。ただし結論は数字を盛れという話ではありません。
The takeaway is not to fudge your numbers. The takeaway is to put those words on your page.
日本語にすると「学ぶべきは数字をごまかせということではない。学ぶべきは、その言葉をページに載せろということだ」という内容です。ウィジェットで読み込まれるレビューのカルーセルは、JavaScriptであるがゆえにモデルから読めません。だからこそ、レビューが何件で、評価がいくつで、どの賞を受けたのかを文章として書く、というのがShaw氏の主張です。記事末尾のKey Takeawaysでも、証拠は数字と社名を添えて文章で書く必要があるとして、Johnson Plumbing is rated 5.0 across 500 reviewsという書き方が例示されています。
そのブランド名の扱いが、視聴者のCody Anderson氏によるセマンティックトリプル(主語・述語・目的語の3つ組で意味を表す考え方)についての質問への回答につながります。Shaw氏はこれをa hard yes.(強い意味でのイエス)と呼びました。ほぼすべての小規模事業者のサイトで見かける問題は、文章が「we」と書くばかりで、その主体を名指ししないことです。We are experts at hot water tank repairではクローラーがその主張を結び付ける先がありませんが、Johnson Plumbing Denver are experts at hot water tank repairならある、という説明で、価格についても同じように社名を主語にするとされています。理由は、ロボットはある意味で愚かなので、ページ側が主語を明示しなければならないというものです。これに対してJeffery氏は、その時点でロボットのために書いていることになる、どうすれば不自然にならないようにできるのか、と読みやすさの観点から反論し、Shaw氏もすべての段落をそれで始められるわけではないと認めてIt’s a sprinkling.(それは振りかける程度のものだ)と述べています。ブランド名を使うのはAIに最もエンティティと結び付けてほしい箇所——中核となるサービス、価格、差別化要因、評価——に限り、それ以外では「we」を使うとしています。
記事は最後に、ローカル担当チームがまず監査すべき5項目を挙げています。
・クロール制御:robots.txt、noindexディレクティブ、セキュリティヘッダー、CloudflareのAIクローラー設定を確認する
・描画済みHTML:重要なコンテンツが、クライアントサイドのJavaScriptを必要とせずに現れることを確認する
・古いURL:古い事業者情報を露出している重複・孤立・アーカイブ済みのページを見つける
・構造化データ:スキーマを、実際に見えているページとGoogleビジネスプロフィールと突き合わせる
・顧客の証拠:実際の質問とレビューのテーマにもとづいて、正確な回答、証拠、FAQ、信頼情報を追加する
Baker氏は、ローカルのAI可視性はアクセスと正確性から始まるとし、クローラーが信頼できるコンテンツを取得できるようになったら作業は細部へ移る——具体的な回答、維持された構造化データ、テキストとして書かれた顧客の証拠、そして人間なら決して読まないがAIは読む、網羅的なサービス情報である、とまとめています。
現場への意味(編集部の見解)
ここからは編集部の整理です。最初に確認するのはコンテンツではなく到達性、という記事の順序は日本の現場にもそのまま当てはまります。Jeffery氏が挙げたrobots.txt、noindexディレクティブ、セキュリティ設定、サイトマップ、描画方法は、いずれも制作会社やホスティング事業者の側で設定されがちで、サイト運営の担当者が把握していないことがあります。Shaw氏がCloudflareについて述べた「事業者は自社のウェブ制作者やホスティング事業者がそれを有効にしたことを知らない」という指摘は、外部に構築を委託しているケースが多い日本の実店舗サイトでも同じ形で起こりうる話です。ここからは編集部の推測ですが、標準設定のまま長年運用され、担当者の交代で設定の経緯が誰にも分からなくなっている例は少なくないはずで、その場合はまず誰が何を設定したのかを洗い出すこと自体が最初のタスクになります。出典はこの点に触れていません。
古いURLの問題は、確認の優先度が高いわりに見落とされやすいと編集部は考えます。Baker氏が挙げた「-old」「-new」「/home」「v2」という接尾辞は日本のサイトにもそのまま当てはまりますが、日本語環境ではリニューアル時期を示す年号を含む命名など、別の形が使われることもあるでしょう。ここも編集部の推測で、出典が挙げているのは前述の4種類のラベルだけです。確実に言えるのは、Baker氏が示した手順——クロールを実行し、疑わしい接尾辞で絞り込み、いずれもインデックス可能でない状態にする——が、ツールを問わず実行できる範囲の作業だという点です。電話番号や住所が古いまま残っているページは、AIにとって単なる余剰ページではなく、誤った事実の供給源になります。
スキーマについては、3者の立場が違うまま社内に共有するのが誠実だと編集部は考えます。3人が一致しているのは、維持されていないスキーマが害になりうるという点だけです。ここからは編集部の判断ですが、更新プロセスが確立していない段階で複雑なスキーマを大量に実装すると、数年後に「誰も存在を知らない古い事業者情報」を抱えることになります。Shaw氏が挙げた、RankMathの設定の中に忘れられたスキーマが残っていたという例は、プラグインでスキーマを出力している日本のWordPressサイトでも起こりうる形です。実装の範囲は、更新時に確実に見直せる範囲に収めるのが現実的でしょう。
ページに何を書くかで、編集部が実務に持ち帰る価値が最も高いと考えるのは、Shaw氏の「その言葉をページに載せろ」という結論です。レビュー件数や評価、受賞歴が外部ウィジェットの中にしかない状態は、日本のローカルサイトでもよく見かけます。ただしShaw氏が同時に強調しているとおり、数字を盛るという話では一切ありません。実際の件数と評価をテキストとして書くという話です。社名を主語に据えて「(社名)は◯◯件のレビューで評価◯◯」と書くことは、不自然にならない範囲で可能でしょう。Shaw氏自身が「振りかける程度のもの」と述べ、中核サービス、価格、差別化要因、評価に限って使うとしている点も参考になります。
クエリファンアウトとネガティブレビュー調査は、どちらも顧客が実際に何を知りたいかを機械の側から逆算する手法で、日本語圏でもツールを変えれば同じ発想で実行できると編集部は見ています。ただし、Ask Mapsやqueryfan.comが日本語・日本の市場でどう動作するかについて、出典は何も述べていません。手法の考え方だけを取り出し、手元で使える手段に置き換えて試すのが妥当です。Jeffery氏が挙げた「事業者本人に、顧客がいつも何を尋ねてくるかを聞く」という最も低コストな手段は、ツールの有無にかかわらず今日から実行できます。
まとめ
・Search Engine Journalが2026年9月21日、Loren Baker氏が司会を務めたSEJ Liveセッションのまとめとして、Whitespark創業者のDarren Shaw氏とDudaのRuss Jeffery氏によるローカルページの作り方の議論を公開した
・Jeffery氏はrobots.txt、noindexディレクティブ、セキュリティ設定、サイトマップ、描画方法の確認から始めるよう勧め、Shaw氏はCloudflareが既定でAIクローラーをブロックしていることが多く、事業者がそれを知らない場合があると指摘している
・Jeffery氏はJavaScriptのレンダリングがここ数年で後退したとし、ChatGPTは自前のインデックスを持たないと述べたうえで、重要なコンテンツをサーバーサイドレンダリングでHTMLレスポンスに載せ、実際に確認することを勧めている
・リニューアル時に残った「-old」「-new」「/home」「v2」などのURLが古い電話番号や住所を抱えたままだと、Shaw氏の言葉では「AIはそれを拾ってしまう」。Baker氏はクロール監査でこれらを探し、インデックス可能でない状態にすることを推奨している
・スキーマの効果については3者の見解が割れており、Shaw氏は順位やAI可視性が上がるという注目に値する研究を見たことがないと述べ、Jeffery氏は条件付きで「絶対にやるべきだ」とし、Baker氏は検証ツールとして肯定している。一致しているのは、維持されないマークアップが有害だという点である
・ページの内容については、クエリファンアウトで洗い出した質問をFAQにすること、競合のネガティブレビューから痛点を調べて正確な約束で応えること、レビュー件数や評価をウィジェット任せにせず文章で書くこと、重要な箇所では「we」ではなく社名を主語にすることが挙げられている
よくある質問
Q1: AIに見つけてもらうために、まず何を確認すればよいですか?
Loren Baker氏は、新しいFAQを追加したりサービスページの文章を書き直したりする前に、クローラーがそのページに到達できること、そこで見つかる事業者情報が正確であることの2つを確認する必要があると書いています。Russ Jeffery氏はrobots.txt、noindexディレクティブ、セキュリティ設定、サイトマップ、コンテンツの描画方法から始めるよう勧め、Darren Shaw氏はCloudflareが既定でAIクローラーをブロックしていることが多く、制作者やホスティング事業者が有効にしたことを事業者が知らない場合があると指摘しています。記事末尾の監査項目でも、クロール制御が最初に挙げられています。
Q2: スキーマは結局やるべきなのでしょうか?
この点は3人の見解が割れています。Darren Shaw氏は、スキーマで従来の順位やAI可視性が上がると述べた注目に値する研究を見たことがないとし、Jake Hundley氏の詳細なテストでも何も見つからなかったと言及しつつ、曖昧性の解消には価値を認めています。Russ Jeffery氏は「絶対にやるべきだ」としたうえで、スキーマがウェブサイトとGoogleビジネスプロフィールに並ぶ第3の事業者データの情報源であり、最悪のケースは古びることだと条件を付けています。Loren Baker氏はランキング要因ではなく検証ツールとして肯定しています。記事のKey Takeawaysでは、維持されていないマークアップがパネルの挙げた唯一の有害なシナリオだったとまとめられています。
Q3: サービスページに載せる質問はどう洗い出せばよいですか?
Darren Shaw氏は、Ask Maps(Mapsのデータに接地したGemini)やGemini、Claudeに直接、そのページに何を載せるべきかを尋ねる方法を挙げています。返ってくるのは価格、信頼の証、レビュー、事例で、Russ Jeffery氏はここに資格・認定と対応エリアを加えています。次にShaw氏はMark Williams-Cook氏のqueryfan.comを使ったクエリファンアウトを挙げ、AIが1つのプロンプトを10個の別のプロンプトに変えるとして、その検索群こそがページのよくある質問だと述べています。Jeffery氏はさらに低コストな手段として、事業者本人に顧客がいつも尋ねる内容を聞くことを挙げ、答えがイエスでもノーでも、とにかく答えを持っている必要があるとしています。
出典:How To Build Local Pages AI Systems Can Find And Trust(Search Engine Journal、Loren Baker氏、2026年9月21日)https://www.searchenginejournal.com/how-to-build-local-pages-ai-systems-can-find-and-trust/588097/
