2025年8月7日公開のGoogle検索オフィスアワーでは、ハッシュタグ検索機能の現状やサブドメインのファビコン表示、ビッグワードでの掲載順位下落、robots.txtにおけるエンコード文字の扱いなど9件の質問にGoogleが回答しています。
本記事では、それぞれの回答内容とあわせて当社の見解を解説します。
ハッシュタグをつけた検索機能
昨年リリースされた「ハッシュタグ検索」機能の現状について確認させてください。
ハッシュタグ検索の公開をきっかけに、オウンドメディアに投稿する記事には「#占い」のようなキーワードを記載するようにしました。去年はハッシュタグ検索経由の流入もあったのですが、ここ最近は#を先頭に付けたクエリで検索しても専用の結果自体が表示されません。
機能終了についてのアナウンスを見つけられなかったのですが、現在もハッシュタグ検索機能は稼働しているのでしょうか？とのことです。
Googleの回答
興味関心ありがとうございます。
担当チームに確認しましたが、現状お答えできる範囲としましては、ハッシュタグをつけて検索すると以前とは違う検索結果になるかと思います。Google検索では常にユーザーにとって有益で分かりやすい検索結果が提供できるようアップデートをしていますとのことでした。
当社の見解
ハッシュタグ検索は2024年6月に日本限定で導入された機能で、現在も廃止のアナウンスは確認できません。ただしGoogleの回答にある通り、表示される検索結果の仕様は継続的に更新されており、以前表示されていた専用ブロックが特定のクエリでは表示されなくなるケースは十分に起こり得ます。
これは機能自体の終了ではなく、表示条件やアルゴリズムの調整によるものと考えられます。ハッシュタグ経由の流入が減少したとしても、記事にハッシュタグを付けること自体に大きなデメリットはないため、無理に外す必要はありません。
通常検索での評価に影響しない範囲で、これまで通り関連性の高いハッシュタグを記事内に含めておくことをおすすめします。
サブドメインのファビコンが表示されない
運営しているサイトの一部コンテンツは、サブドメインにて展開しています。ここ数週間、サブドメイン配下のコンテンツのみ、SERPs上でファビコンがうまく表示されないケースが散見されます。
該当サブドメインコンテンツのURL設計は以下のようになっており、トップページ（ホームページ）がサブドメイン直下ではなく、特定のディレクトリとなっている状態です。
このような設計は、サブドメインのファビコン表示が不安定となる原因として考えられますでしょうか？また、対処方法があればご教示いただけますと幸いです。
Googleの回答
具体的なサイトの情報が添えられていなかったため、サイト構造を正しく理解していると良いのですが、質問内容からはガイドライン上でもお伝えしているようにサポートされない、サブディレクトリレベルのホームページのように見受けられました。
そのためにうまく表示されてないケースがあったとしても、仕様通りのように思いますがいかがでしょうか。
ファビコンは少し厄介なことがあったりするので、こちらのガイドラインに従って、できるだけ正確に作成することをお勧めしております。
当社の見解
Google公式ドキュメントでは、ファビコンがサポートされるのはドメインレベルとサブドメインレベルのホームページのみとされており、サブディレクトリレベルのホームページは対象外と明記されています。
つまり、サブドメインを使っていても、そのトップページがサブドメイン直下ではなく特定のディレクトリ配下にある場合は、サブディレクトリのホームページと同じ扱いになり、ファビコンが仕様上サポートされません。
今回のケースはURL設計そのものが原因である可能性が高く、表示を安定させたい場合は、サブドメインのルート直下にトップページを配置する構成へ見直すことが根本的な対処法になります。
ビッグワードにて掲載順位が下落した
弊社のサービスサイトトップページがあるビッグワードで長らく自然検索の10位前後に位置していましたが、4月末から順位が低下傾向にあり最近は100位外になっています。
日本でも有数の認知度、利用者を誇る企業・サービスだと考えていますが、弊社より企業規模が小さく、一部地域でしか営業していないようなサイトが複数（多数と言ってもいい水準）上位にあがってきています。ユーザー観点で見ても違和感のある検索結果になっている印象です。
当方のサイト状況を確認しましたが、インデックスや各種エラーなど問題ない状況でして対策に苦慮しています。何か見落としていることがあれば対策したく、この状況で見るべき観点などありましたらアドバイスいただけますと幸いです。
Googleの回答
具体的なサイトやクエリの情報が添えられていたために、状況を確認することができました。
これはですね、技術的には問題ありませんが、そのような一般的なキーワードで上位にランクインし続けるのは難しいことをお伝えしております。
つまりですね、過去に検索結果上位に表示されたサイトが、今後も上位に表示され続けることは保証できません。つまり、ウェブサイト、そしてユーザーの期待値は非常にダイナミックに変化しているために、現在ある位置にランクインしているからといって、何もせずずっとその位置にとどまれるとは限りません。
ご理解いただけますと幸いです。
当社の見解
大企業サイトが一般的なビッグワードで上位を維持し続けられない背景には、検索結果全体の変動が大きくなっている事情があります。実際に2026年に入ってからも大規模な順位変動が複数回観測されており、一部地域や商用調査系のキーワードでは上位圏内でも入れ替わりが起きやすい状況が続いています。
企業規模や知名度が検索順位に直接影響するわけではなく、Googleは検索クエリごとにユーザーの意図を満たす内容かどうかを評価しています。地域名を含むクエリであれば、営業エリアが限定されていても情報の専門性が高いホームページが優位になることがあります。
順位を戻すためには、上位表示されている競合ページの構成や網羅性を確認し、自社ページに不足している視点を補うことが現実的な対応になります。
ナレッジパネルの情報が更新されない
昨年4月にブランド名が変更となり、サイトのタイトルなども変更いたしました。新しいブランド名で検索した際、タイトルリンクなどは問題なく新ブランドで表示されております。しかし、ナレッジパネルの「詳細」や「クチコミ」といったところを選択すると、検索欄では古いブランド名で検索されている状態になってしまいます。
で、質問内容としてはこちらの3点。
Googleからいまだに新ブランド名で認識されていないのでしょうか？
この問題を改善するために、Search Consoleのリンクリポートに表示されている質の低いサイトに関しては否認ツールで否認した方が良いのでしょうか？
ドメインが古いブランド名に関連する略称ですが、それも影響しているのでしょうか？
Googleの回答
ご質問ありがとうございます。こちらに関しても具体的なサイトの情報が添えられていたために状況を確認することができました。
私の環境で確認してみたところ、プロフィールの更新は完了しているように見受けられました。なので、問題はすでに解決したと思いますがいかがでしょうか。
基本的にはですね、Googleマイビジネスの問題だと考えております。で、Googleビジネスプロフィールガイドラインに従う必要があると思いますが、反映されるまで、時間がかかるかもしれません。
一般的にナレッジパネルの情報は、Googleマイビジネス、そしてWikipediaなど、名前が掲載されている全てのシステムを徹底的に確認することが重要となってきます。またですね、ナレッジパネルに関しては所有者としてので編集することも可能となっております。
解決しているように見られましたので、各質問には細かくお答えしませんが、いずれにしてもこういったケースで否認ツールを利用して否認しても、効果がないことはお伝えしておこうかなと思います。
当社の見解
ナレッジパネルの情報は、公式サイトやGoogleビジネスプロフィール、Wikipediaなど複数の情報源をもとに自動生成されているため、ブランド名を変更した場合はすべての情報源で表記を統一する必要があります。一部の情報源だけ更新すると、古い名称と新しい名称が混在し、ナレッジパネル内の項目ごとに表示が食い違う状態が生じやすくなります。
否認ツールは、自サイトに向けられた低品質な被リンクの評価を無効化するための機能であり、ナレッジパネルの表示内容そのものには影響しません。Googleの回答にもある通り、否認ツールを使ってもこの問題の解決にはつながらないため、対応の優先順位としては情報源の統一と、ナレッジパネル上の「情報の修正を提案」機能を使った申請の方が有効です。
ページがインデックスされない
Search Consoleで「クロール済み – インデックス未登録」になっているページを「URL検査」から確認したところ、「参照元サイトマップが検出されませんでした」という結果でした。
しかし、送信したサイトマップを確認したところ該当ページは、サイトマップに含まれていました。そこでインデックス登録をリクエストを改めて行いました。
このページ以外にも、サイトマップに掲載されているのに参照元サイトマップが検出されませんでしたで参照元サイトマップが検出されませんでしたになっているページが多数あります。原因は、どこにあるのか、ご教授いただければ幸いです。
Googleの回答
具体的なサイトの情報が添えられていました。
その上でですね、今回の質問はサイトマップに関する問題、ご質問ということではなくて、クロール済み – インデックス未登録のページを解消して、インデックス登録させたいという胸のご質問かなと理解したので、そのように答えていきます。
この場合、ページインデックス登録レポートのヘルプページを確認していただくのが良いかなと思いました。
このステータス、つまりクロール済み – インデックス未登録のステータスは、ページがGoogleによりクロールされましたが、インデックスには登録されていないことを意味しています。文字通りなんですけど。
でですね、この場合、今後インデックス登録される可能性がありますが、登録されない可能性もあります。このURLのクロールのリクエストを再送信する必要はありませんとドキュメント内にも記載がございますので、このようにしてください。
またですね、クロール済み – インデックス未登録のステータスなので、サイトマップに登録しても効果意味は特にありません。というのもですね、クロール済みなのでGoogleはすでにそのURLを知っているからということになっております。いかがでしょうか。
当社の見解
「参照元サイトマップが検出されませんでした」という表示は、そのページがサイトマップ以外の経路、たとえば内部リンクなどを通じてすでにGoogleに発見されていたことを意味しており、サイトマップの送信自体に問題があるわけではありません。
クロール済み – インデックス未登録のステータスである以上、原因はサイトマップではなくページの内容側にあると考えられます。該当ページが多数ある場合は、コンテンツの重複や情報の薄さがないかを確認し、独自性のある情報を加えることが根本的な対応につながります。
インデックス登録のリクエストやサイトマップの再送信を繰り返しても、状況の改善にはつながりにくい点に注意が必要です。
robots.txt でエンコード文字を使用
運営しているサイトで、URLにカンマ（,）を含む場合はクローラーのアクセスをブロックしたいと考えており、robots.txtにもブロックするための記述を行っています。
カンマ（,）を含むURLをrobots.txtでDisallowした場合、%2C（カンマのエンコード）を含むURLもDisallowされますか？
Googleの回答
担当チームにも確認して、コメントをもらうことができました。
で、曰くですね、robots.txtではエスケープされた文字は、透過となっておりますけども、RFCによるとこのように記述されておりまして、つまりrobots.txtのパス要素において、カンマは予約済みの文字ではありません。
ちなみに予約済みの文字はスペースとハッシュの2点、2つの文字のみで、こちらはエンコードする必要がありますというように記述されております。
なのでですね、カンマはパスにおいて不自然な要素であり、CMS、他のクローラー、robots.txtパーサー、あとはですね、ユーザーにもちょっと混乱をさせる可能性がありますので、こういったURLは、つまり混乱を招く可能性のある文字というのはたとえ技術的には有効であったとしても、使用しないことをお勧めしております。
あとたまに皆さんも経験される方かなと思うんですけども、例えばソーシャルメディアだったりチャットアプリに、URLを貼り付けた場合など、自動的に正しくリンクされなかったりするケース、リスクっていうのが、あるかなと思うんですけど、そういったリスクを負うべきではないかなと我々のチームでは考えております。
当社の見解
Google公式ドキュメントによると、robots.txtのパス要素には7ビットASCII以外の文字をUTF-8文字、またはRFC 3986に従い%記号でエスケープされたUTF-8文字として指定できるとされています。
この仕様に沿えば、カンマとそのエンコード表記である%2Cは実質的に同じ文字として扱われる可能性が高く、カンマを含むパスをDisallowで指定した場合、%2Cを含むURLも同様にブロック対象となると考えられます。
ただしGoogleの回答にもある通り、カンマ自体はURLのパスとして予約されていない不自然な文字であり、CMSや他のクローラーでの解釈にばらつきが生じるリスクがあります。robots.txtの記述だけに頼るのではなく、そもそもURL設計の段階でカンマのような特殊文字を避け、ハイフンなど標準的な区切り文字を使う運用にしておくことをおすすめします。
Googlebot のダウンロードサイズが減少
クロールの統計情報を確認したところ、弊社サイトでは2025/5/8からbotのDLファイルサイズが激減していました。なお、クロールのリクエスト数は大きく変わっていません。開発に質問したところ、該当日付付近で影響しそうな変更は一切行っていないとの回答でした。
内部変更無しに、ここまで急にDLファイルサイズのみが減ることはありえるのでしょうか？
極端に減っているのでネガティブな影響がないか不安なのですが、このようなケースのアプローチ方法についてアドバイス頂けますと幸いです。ちなみに、本現象は目的別の更新のみに起こっており、検出ではDL数の減少は起こっていませんでした。
Googleの回答
こちらも担当チームに確認してきました。
で、曰くですね、検索結果に表示されるサイトの更新やインデックス化に問題がないのであれば、これは問題ではありませんとのことでした。クローラーはですね、効率的に動作するように設計されているため、以前よりもクローラーのアクセス回数が減っている場合でも、ページがクロールされている可能性があります。
またクロールされるページ数が以前とほぼ同じであれば、クロールタイプが変化したとしても心配する必要はないでしょうとのことでした。もし懸念がある場合は、サーバーログを直接確認したりとか。あとは、そうですね、そこから詳細な情報を取得することをお勧めしております。
周期値だけを見て判断するのは、今回は避けるべきかなというようなコメントを、担当チームからいただいております。
当社の見解
クロールリクエスト数が変わらずダウンロードサイズだけが減少する現象は、サイト側の変更がなくても起こり得ます。Googlebotはページのキャッシュ状況やレスポンスの効率性に応じてダウンロード量を調整しており、同じページを取得していても圧縮効率やキャッシュの利用状況によって転送量が変動するためです。
重要なのは、検索結果でのホームページの更新やインデックス登録に実害が出ているかどうかです。クロールされるページ数自体が維持されているのであれば、ダウンロードサイズの減少だけを見て対応を急ぐ必要はありません。
懸念が残る場合は、サーチコンソール上の数値だけで判断せず、サーバーログでGooglebotのアクセス状況を直接確認することが確実な方法です。
AI 機能のためにマークアップするべきか
構造化マークアップとGemini AI Overviewに関する質問です。
今までは構造化マークアップは検索順位に対して影響を与えないとの話でしたが、昨今、Gemini AI Overviewに自社の情報を取り上げられるために構造化マークアップが大事と聞きます。
今までは、リッチリザルトできれいに表示されることや、Google Merchant Centerに自社商品の情報を取り上げるために構造化マークアップを入れるものと考えていたのですが、上記AI Overviewに取り上げられるためにも、構造化マークアップは入れたほうが良いでしょうか？
Googleの回答
具体的なサイトの情報が添えられておりました。
で、まずは一般的な話をしますが、一般的にマークアップはGoogleがコンテンツをよりよく理解するのに役立ちますと。そのためいくつか実装するのは、基本的には良い考えのように思います。
しかし、今回いただいたサイトというか、構造化マークアップする際のノート見ましたが、構造化データで商品などを表示するための要件を満たせない場合は使用されません。またですね、卸売り市場のように、一般ユーザーが購入できない商品をショッピング結果に表示するのは、少し不自然なように感じました。
当社の見解
構造化データは検索順位を直接押し上げる要素ではなく、あくまでGoogleがコンテンツの内容を正確に理解するための補助的な情報です。従来通り、リッチリザルトでの表示やGoogle Merchant Centerでの商品情報反映といった実利的な効果を目的に実装するのが基本的な考え方です。
Googleの回答にもある通り、構造化データは実態を正しく伝えるためのものであり、要件を満たさない情報を無理に表示させることはできません。一般ユーザーが購入できない商品やサービスをショッピング結果に表示させようとするなど、実態と合わないマークアップは避け、自社が提供できる情報の範囲で正確に実装することが基本方針になります。
デスクトップページもインデックスは必要か？
例えばexample.comとexample.com/spなど、PC用URLとSP用URLが異なっている場合、両方のパターンのURLをインデックスさせる必要はあるのでしょうか？片方がインデックスされていれば万全の状態なのでしょうか？
Googleの回答
こちら具体的なURLが添えられておらず、一般的なご質問として届いておりましたので、こちらとしても一般的なご質問として回答していきます。
で、回答ですが、多くのユーザーは依然としてデスクトップ端末からウェブサイトにアクセスしているかと思います。でですね、デスクトップ版がインデックス登録されない場合などは、デスクトップユーザーは検索結果でサイトを見つけることができず、トラフィックの減少につながります。なので、どちらのパターンもURLをインデックスさせる必要はあるかと思います。
さらにですね、画面サイズの関係で、例えばデスクトップ版にはより多くの情報が表示される場合などもありますので、こういった場合検索エンジンの理解度向上にも寄与する可能性がありますね。
そうですね。このようなモバイルファーストインデックス関連の質問に関しては、こちらの公式ページ、モバイルサイトとモバイルファーストインデックスに関するおすすめの方法という公式ページありますので、こちらをぜひ参考にしていただけると良いかなと思いました。
で、この中にも触れておりますが、私たちとしては比較的設定ミスの少ないレスポンシブデザインを推奨しております。
当社の見解
PCとSPでURLを分けている場合、現在のモバイルファーストインデックスではモバイル版のコンテンツが評価の基準となるため、PC版だけをインデックスさせても評価は反映されません。一方でGoogleの回答にもある通り、デスクトップ利用者が検索結果に到達できなくなるため、両方のURLをインデックスさせておく必要があります。
PCとSPでURLを分ける運用は、rel=”alternate”やrel=”canonical”の設定漏れといった人的ミスが起こりやすく、評価の分散につながるリスクもあります。これから制作やリニューアルを行う場合は、URLとコンテンツを一本化できるレスポンシブデザインを採用することで、こうした管理の手間やミスのリスクを避けられます。
