2026年3月5日公開のGoogle検索オフィスアワーでは、URLの設計やサーチコンソールのデータ異常、構造化データの活用、インデックス登録に関する挙動など18件の質問にGoogleが回答しています。
本記事では各質問に対するGoogleの回答と、当社の見解をあわせて解説します。
テキスト検索結果画像の制御
ECサイトを運営しております。
商品名で検索した際のスニペットに、対象商品ではなく関連商品の画像がサムネイルとして表示されることがあります。サムネイル画像を対象商品にしたく、対象商品の画像URLを<meta name=”thumbnail”>で指定し、関連画像に<span data-nosnippet>をしていますが、それでも関連商品の画像が表示されることがあります。
解決策やより良い方法があればご教示いただけますと幸いです。
Googleの回答
こういった件、よく質問される内容なんですけども、テキスト検索結果画像を制御することはできません。なのでこちら、公式ブログ貼っておりますが、公式ドキュメントに記載がある通り最適化するにはGoogle画像検索SEOベストプラクティスを参照してください。
いつもならここで終わっている内容ではあるんですけども、つい先日ですね、ちょうど収録をしている2日ぐらい前に、メタデータを使用して、最優先画像を指定するのセクションがこちらのドキュメントに追加されております。
つまり、スキマドットオルグのプライマリーイメージオブページプロパティを指定することで、またはOGイメージメタタグを使用することで、優先画像を選択することが出来ます。なんで、更新されております。日本語でももうすでに更新されておりますが、詳しくはこちらのメタデータを使用して優先画像を指定するの箇所ドキュメントをご一読いただけたらいいかなと思います。
当社の見解
テキスト検索結果に表示される画像をGoogleが完全にコントロールすることはできませんが、現在は構造化データとog:imageメタタグを使って優先表示させたい画像をGoogleに伝える方法が公式に案内されています。
具体的には、schema.orgのprimaryImageOfPageプロパティで対象商品の画像URLを指定する方法と、og:imageメタタグで指定する方法の2つです。ECサイトであれば、商品ページごとにその商品のメイン画像を明示的に指定しておくことが現実的な対応になります。
ただし、これはあくまで優先画像をGoogleに伝えるための手段であり、必ずその画像が採用されるという保証ではありません。Googleが最終的にどの画像を表示するかは検索システムが判断します。
質問者が試みていた<meta name=”thumbnail”>やdata-nosnippetは公式に推奨された方法ではないため、効果が出なかったと考えられます。まずはprimaryImageOfPageとog:imageメタタグの設定を優先してください。
Search Console レポートで異なるステータス
sitemapで送信しているURLがSearch Console上で「検出-インデックス未登録」に振り分けられています。
しかし、URL検査で確認すると、「URLがGoogleに認識されていません」となっています。Search Console上の表示が誤っているだけなのか、あるいは実際には認識されていない、sitemapの状態が適切ではないなど、実装に問題があるのでしょうか？
Googleの回答
担当者に確認してみたところ、回答が得られまして、ツールによって使用するソースが異なり、更新頻度も異なるため、それらの間で矛盾が生じることもありますが、通常時間の経過とともにそれらの違いはなくなりますということでしたので、しばらく時間を置いてから再度レポートを確認していただけたらなと思いました。
当社の見解
サーチコンソールのインデックスカバレッジレポートとURL検査ツールは、参照しているデータのソースと更新タイミングが異なります。そのため、両者の表示が一致しないケースはGoogleの仕様によるものであり、必ずしも実装に問題があるわけではありません。
まずは数日から1週間程度時間を置いて、両者の表示が一致するかどうかを確認してください。時間の経過とともに解消されることがほとんどです。
ただし、長期間ステータスが変わらない場合は別の問題が考えられます。サイトマップのURLが正しく記述されているか、対象ページがnoindexになっていないか、クロールを妨げるrobots.txtの設定がないかを順に確認してください。
リンク否認ツールを使用する際のプロパティ
運営しているサイトは、スパムリンク対策として以前からリンク否認を実施しております。
今後もリンク否認を継続するにあたり、否認リンクのリストをSearch Console上でアップロードする対象（プロパティ）は、
- 現行ドメインのプロパティのみにアップロードする。
- 現行ドメインに転送済みの過去ドメインのプロパティにもアップロードする
どちらの方針が正しいのですか。過去ドメインに向けられたスパムリンクが現存している可能性もあり、そのリンクのネガティブな影響が、転送先の現行ドメインに波及することはありますか？
Googleの回答
簡単な回答なんですけども、リンク否認リストは現行のドメインのSearch Consoleのプロパティのみにアップロードしてください。なので、今回でいうところの1つ目の選択肢になっております。
リダイレクトが正しく設定されていれば、Googleはリンクシグナルを新しいドメインに転送します。過去のドメインにアップロードする必要はありません。
当社の見解
リンク否認ファイルのアップロード先は現行ドメインのプロパティのみで問題ありません。旧ドメインのプロパティに別途アップロードする必要はありません。
301リダイレクトでリンクシグナルが現行ドメインに引き継がれる仕組みと同様に、否認も現行ドメイン側でまとめて処理できます。旧ドメイン宛てのスパムリンクが気になる場合は、現行ドメインの否認リストに含めて登録しておけば対応できます。
なお、Googleは現在スパムリンクの影響を自動的に無視する精度が上がっており、よほど大量・悪質なスパムリンクでない限りリンク否認の効果は限定的とも言われています。否認作業を継続すること自体は問題ありませんが、過度に工数をかける優先度は高くありません。
トップではなく下層ページが上位表示される
ECサイトを運営しています。
各商材のカテゴリ単位でカテゴリトップページがあり、その下層にユーザーに有益と考えられる記事を公開しています。カテゴリトップページには、他のページへの導線が集約されており、単一キーワードでの検索では下層ページより有益と考えられるのですが、複数のカテゴリで、トップページではなく、下層の「とは」や「選び方」ページが上位に表示されます。
カテゴリトップページが上位表示しない理由として、何らかのペナルティが考えられると思うのですが、内部リンクが多すぎたり、パンくずのアンカーリンクがずばり商材カテゴリ名になっていたりすることは影響しますか？
Googleの回答
こちらもですね、よくあるご質問の1つかなと思っております。
でですね、トップページではなく、とはや選び方などの下層の具体的な情報ページが表示されている場合、Googleはユーザーの検索意図に対してより詳細な情報を含む下層ページの方が、現時点ではより短期性クエリに対するより関連性が高いと判断している可能性があります。
当社の見解
カテゴリトップページではなく下層ページが上位表示される場合、ペナルティではなくGoogleの検索意図の判断によるものがほとんどです。内部リンクの多さやパンくずのアンカーテキストが原因で順位が下がることは、通常考えにくいです。
単一キーワードで検索するユーザーが「カテゴリの概要を知りたい」のか「具体的な情報を知りたい」のかによって、Googleが上位に出すページは変わります。「とは」や「選び方」ページが上位に表示されているということは、そのキーワードで検索しているユーザーの意図が具体的な情報を求めている方向に傾いているとGoogleが判断しているということです。
カテゴリトップページを上位表示させたい場合は、ペナルティ対策よりも検索意図の見直しが先決です。カテゴリトップページが狙うキーワードと、実際にそのキーワードで検索するユーザーが求めている情報が一致しているかどうかを確認してください。一致していなければ、カテゴリトップページのコンテンツを検索意図に合わせて見直すことが現実的な対応です。
「公開 URL をテスト」が利用できない
Search Consoleの「URL検査」にて、ページがインデックスされにくいため、「公開URLをテスト」で問題がないかを確認しようとしましたが、特定のページで「エラーが発生しました」と表示され、テストを実行できませんでした。
あわせて、「インデックス登録をリクエスト」も実行できませんでした。特に、アクセスブロックはしておらず、ページスピードも著しく遅いわけではないのですが、「公開URLをテスト」が利用できない要因として、どういったことが考えられますでしょうか？
Googleの回答
具体的なサイト情報が添えられていたために状況確認することができました。
現在は問題が解決しているようでした。一般的に公開URLをテストでエラーが発生する場合、Googlebotがコンテンツを完全に取得、レンダリングできていない可能性が高いです。
なんで、トップページと特定のドメイン配下が別のシステムで動いているようなサイトでしたので、その場合、その特定のドメイン配下のコンテンツをホストしているサーバー側で何らかの理由、例えば、ファイアウォールだったり、リクエストのブロック、タイムアウトなど考えられると思います。
そういった理由によりGooglebotのアクセスが制御されていないか、サーバーのログを確認することで問題が解決する見通しが立つことが多いかなと思います。
当社の見解
「公開URLをテスト」でエラーが発生する場合、アクセスブロックやページスピードではなく、GooglebotがページのコンテンツをサーバーからURL正常に取得できていないことが主な原因です。
特に確認すべきはサーバーのログです。Googlebotからのリクエストがファイアウォールに弾かれていないか、タイムアウトが発生していないかをサーバーログで確認してください。自社で管理しているサーバーであれば確認しやすいですが、外部のシステムやサービスを組み合わせて運用している場合は、それぞれのサーバー側の設定も確認対象になります。
インデックスされにくいページがある場合、robots.txtやnoindexの設定確認に目が向きがちですが、サーバー側でGooglebotのアクセスが正常に通っているかどうかを確認対象に含めてください。
サイト内の全ページがインデックスされない
新規リリースした海外向けサブドメインサイトで、約400ページのすべてのページがインデックスされた後、徐々にインデックス数が減少し、最終的に「クロール済み – インデックス未登録」でインデックスから除外されました。
sitemapエラーやhreflang未設置が解消されていないため、インデックス登録に影響している可能性があります。一度すべてのページがインデックスされている事から、クロールリングに関する問題ではなく、公開URLテストも正常なので、レンダリングの問題でもないように思うのですが、考えられる対応策などありますか？
Googleの回答
担当チームに確認しましたけども、こちらも一般的に新規コンテンツをインデックスするには、時間がかかりますと。またクロール済み – インデックス未登録のステータスとのことなので、コンテンツの有用性であったり、品質の向上に注力していただけると良いかなと思っております。
また、サイトマップエラーやhreflang未設置を解決することにも引き続き取り組んでいただき、問題が残るようでしたらお知らせください。
当社の見解
一度インデックスされた後に「クロール済み – インデックス未登録」へ移行するケースは、Googleがコンテンツを再評価した結果、品質や有用性が基準を満たさないと判断したことが主な原因です。海外向けサイトで400ページがインデックスされた後に除外される場合、ページ数に対してコンテンツの質が追いついていない可能性があります。
優先して対応すべきはGoogleの回答にある通りコンテンツの品質向上ですが、あわせてサイトマップエラーとhreflangの未設置も早めに解消してください。hreflangは海外向けサイトでGoogleが言語と地域を正しく判断するために必要な設定であり、未設置のままでは適切な評価を受けにくくなります。
技術的な問題を解消したうえで、各ページがそのページにしかない情報を提供できているかを見直すことが現実的な対応です。
クロール済み – インデックス未登録
取引先のSEO会社より、「クロール済み – インデックス未登録」が多すぎるとサイト全体が低品質とみなされ、サイト全体のランキングが上がらない要因と言われています。
「クロール済み – インデックス未登録」が多すぎるとサイト全体が低品質とみなされるという情報は本当でしょうか？
Googleの回答
クロール済み – インデックス未登録はGooglebotがページをクロールしたものの、検索結果に表示するほど十分な価値がないと判断された状態を示しています。
このステータスが多いことはGoogleがコンテンツの大部分をインデックスしない決断をしたことを意味しますが、一方でサイト全体が低品質としてアルゴリズムによる手動対策を受けているわけではありません。
こういった場合、引き続き個々のページの有用性だったり、品質の向上に注力いただくのが良いかなというのが我々の回答になります。
当社の見解
クロール済み – インデックス未登録が多いことでサイト全体が低品質とみなされるかどうかについては、Googleは明確に否定していません。サイト全体への手動対策の対象にはならないと回答していますが、それはあくまで手動対策の話です。
当社の経験では、このステータスが多いホームページは全体的に検索順位が上がりづらい傾向があります。Googleがコンテンツの大部分をインデックスしない判断をしているという事実は、サイト全体の評価と無関係とは言い切れません。
対応の基本は個々のページの有用性と品質の向上です。インデックスされないページが多い場合は、内容の薄いページを統合するか、そのページにしかない情報を加えて差別化することを検討してください。
複数のカテゴリページが重複判定される
ECサイトを運営しています。
カテゴリページでデザインやメインの紹介テキストが完全に異なっているにもかかわらず、Search Consoleで「重複しています。Googleが正規ページを選択しました」として、意図したカテゴリページがインデックスから除外されるケースが多発しています。
これは、共通するナビゲーションやヘッダー・フッターなどのボイラープレート要素の比率が高いことが原因でしょうか？あるいは、画像の読み込み遅延に見られるようなサーバーの応答速度の不安定さが、Googlebotのクロール時にコンテンツ取得を不完全にし、その結果として重複判定やインデックス除外につながる可能性はありますか？
Googleの回答
結論として、質問者さんのおっしゃっていることどちらも起こりうる現象だと思います。ECサイトのカテゴリページで重複判定が多発する場合、ご指摘のボイラープレートの比率が高いことが一因であることは十分可能性があるかなと思います。特に、ECサイトでは商品リストやファセットナビゲーションの変更だけで、ユニーク性が低いと判断されることがあります。
そして他にもですね、サーバー応答の不安定さなんかはコンテンツの取得自体を不完全にしたり、結果として重複判定を招く可能性も考えられます。ユニーク性を強調するためには、主要なコンテンツにユニークなテキスト要素を確実にHTMLの早い段階で読み込ませることが有効となってきます。
今回の件に直結するかは分かりませんが、Eコマースサイトに関するベストプラクティスなどもこちらの公式ドキュメントございますので、ぜひこのGoogle検索でEコマースサイトを見つけやすくするためのおすすめの方法なんていうドキュメントもご一読いただけると参考になる箇所もあるかもしれません。
当社の見解
ECサイトのカテゴリページは、ヘッダー・フッター・ナビゲーションなどの共通要素が占める割合が高くなりやすく、カテゴリごとに固有のコンテンツが少ないとGoogleから重複と判断されやすい構造です。デザインやメインテキストが異なっていても、HTML全体に占めるユニークなコンテンツの比率が低ければ重複とみなされることがあります。
Googleの回答にある通り、ユニークなテキスト要素をHTMLの早い段階に配置することが有効です。カテゴリの説明文や選び方のポイントなど、そのカテゴリにしかない情報をページ上部に充実させることを検討してください。
サーバー応答の不安定さについては、Googlebotがコンテンツを完全に取得できない場合にも重複判定が起きることがあります。画像の読み込み遅延が常態化しているようであれば、サーバー環境の見直しも合わせて対応してください。
表現の揺れがある検索クエリの取り扱い
Google検索におけるメンズエステの取り扱いに関して質問します。
「メンズエステ」と「メンズエス」という2つのワードですが、集客、求人ともに違う検索結果になります。一般的にはあまり違いはありませんが、Googleは別のワードという認識なのでしょうか。また「メンズエス」でしか表示されなくなった場合、「メンズエステ」関連のワードでも再度表示させることは可能なのでしょうか。
Googleの回答
具体的なクエリに関する事はお答えできませんが、一般的にGoogleはクエリの理解に基づいて、ユーザーにとって最適なものを返すように努めております。
当社の見解
Googleの回答は具体的な言及を避けた内容ですが、「メンズエステ」と「メンズエス」は表記が異なる別のクエリとしてGoogleが処理している可能性が高く、検索結果が異なること自体は不自然ではありません。
「メンズエステ」関連のキーワードで表示させたい場合は、ページ内のテキストに「メンズエステ」という表記を適切に含めることが基本的な対応です。Googleはページのコンテンツをもとに検索意図との関連性を判断するため、狙いたいキーワードの表記がページ内に存在しないまま上位表示を実現することは難しいです。
また、集客と求人で検索結果が異なるのは、それぞれの検索意図が異なるためGoogleが別々の判断をしていると考えられます。集客向けと求人向けでページを分けて、それぞれのページに対応するキーワードを含めた構成にすることが現実的な対応です。
イベントの構造化データのグローバル対応
Googleのイベント検索機能に関して、現状日本のサポートはなく、今後追加される予定でしょうか？
Googleの回答
こちら、公式ドキュメントに記載がある通り、Googleのイベント検索機能をご利用いただける地域は世界中に広がっています。現状は日本地域、日本語は対応しておりませんが、利用可能な地域と言語に関する記述がございます。特定の言語に関する具体的なタイムラインなどはまだお知らせできることはありません。
こちらも質問の一部として記述はされていたように記憶しているんですが、リッチリザルトのテストで有効であってもサポートされていない地域での検索結果は表示されません。公式ドキュメントのご利用可能な地域と言語の箇所をご確認いただけると良いかなと思います。
当社の見解
日本語・日本地域ではGoogleのイベント検索機能が現時点で対応していないため、イベントの構造化データを実装してもリッチリザルトとして検索結果に表示されません。リッチリザルトテストで有効と表示されても、日本からの検索では反映されない点に注意が必要です。
対応予定のタイムラインはGoogleから公表されていないため、現時点では構造化データの実装を優先課題にする必要はありません。将来的な対応に備えて実装しておくこと自体は問題ありませんが、日本国内での集客を目的としているのであれば、他の施策に工数をかける方が現実的です。
URL 設計
URLパスについては、昔は意味のない文字列やエンコードされた文字列、複雑なディレクトリ構造がSEOに悪影響を与えると聞きましたが、今でもそうでしょうか。REST APIのように、リソースを明確に表すようにURLを設計するとSEOに効果がありますか？
また、パスが日本語の場合、URLエンコードされたものとそうでないもの、別ページと認識されますか？
Googleの回答
シンプルな回答としては、理解しやすいパスはユーザーとクローラーの双方にとって有益です。で、REST APIのようにリソースを明確に示すURL設計は、URLの理解を助けますし、間接的に役立つかなと思います。
日本語パスについては、URLエンコードされているかどうかにかかわらず、Googleは同じページとして認識します。とはいえ、正規化された、つまり一貫したURLの使用を推奨しております。
当社の見解
意味のない文字列や複雑なディレクトリ構造がSEOに直接悪影響を与えるかどうかについては、現在のGoogleはURLの構造だけで検索順位を大きく変動させることはありません。ただし、URLがページの内容を反映したわかりやすい構造であることは、ユーザーとGooglebotの両方にとって好ましい状態です。
日本語パスについては、URLエンコードされたものとそうでないものをGoogleは同じページとして認識します。ただし、サイト内で表記が混在するとGoogleが別URLとして処理するリスクがあるため、どちらかに統一して運用してください。
実務的な観点では、日本語URLはSNSでシェアされた際にエンコードされた文字列が露出して見栄えが悪くなるケースがあります。新規でURL設計を行う場合は、英数字でページの内容を表したURLにしておく方が無難です。
JavaScript SEO の基本を理解する
おそらくこちらの方は英語でドキュメントを見ているいらっしゃる方かなと思いますが、Google Search CentralのUnderstand the JavaScript SEO basicsに関する質問になります。
Use robots meta tags carefullyの章で、When Google encounters the noindex tag, it may skip renderingと記載がありましたがここで書かれているrenderingとは何のレンダリングを示すのでしょうか？初期のDOM構築は含まれますか？
Googleの回答
noindexタグはGooglebotがHTMLのヘッドセクションを解析した際に検出されます。このタグを検出した場合、GoogleはリソースのフェッチやJavaScriptの実行、本格的なレンダリングをスキップする可能性があります。
なんで、初期のDOM構築はnoindexタグ自体を読み取るために必要であるため、通常は実行されます。初期のDOM構築は含まれますかに対する回答としては通常は実行されますということですね。
当社の見解
Googlebotはページを処理する際に、まずHTMLを取得して初期のDOMを構築し、その段階でnoindexタグを検出します。noindexタグが見つかった場合、その後のJavaScriptの実行や本格的なレンダリングをスキップする可能性があります。
実務上の注意点として、noindexをJavaScriptで動的に挿入している場合は、Googlebotが初期のDOM構築時にタグを検出できないため、意図した通りに機能しない可能性があります。noindexはHTMLのheadセクションに直接記述しておくことが確実な対応です。
head 内への iframe タグ記述
自社JSライブラリ、またはSNS等サードパーティJSライブラリにより、iframe等本来body内に記述するタグがhead内に追加されることがあります。このときiframeが追加された箇所でheadタグが終了したとみなされ、それ以降のhead内の記述が無視される可能性があると、過去Googleより発言があったと記憶しております。
ただ実際には、iframe以降のtitleタグやlink rel=canonicalタグなどは効いているようにも見受けられます。特にサードパーティライブラリ起因の場合改修困難な可能性を考えており、本件の緊急度はどうでしょうか？
Googleの回答
あらゆる問題において対処する問題の優先順位というのは、ビジネス課題だったり、その置かれている状況によるとも思うので、その観点について私たちから何かコメントできることは限られているかなと思います。
という前提で話しますが、URL検査ツールでこれらの重要なタグが正しく認識されていることを確認できているのであれば、緊急度は高くないかもしれません。
で、今回実際には、タイトルタグやcanonicalタグは効いているように見受けられますということなんで、もしかしたら緊急度はそれほど高くないのかもしれませんが、ただ依然としてHTMLの健全性のために修正は推奨されます。
当社の見解
URL検査ツールでtitleタグやcanonicalタグが正しく認識されていることが確認できているのであれば、即座に対応が必要な問題ではありません。Googleの回答にある通り、緊急度は高くないと判断できます。
ただし、HTMLの構造としてheadセクション内にiframeが挿入される状態は正しくないため、サードパーティライブラリの改修が可能であれば対応しておくことが望ましいです。特にcanonicalタグが意図通りに機能していない場合は重複コンテンツの問題につながるため、定期的にURL検査ツールで確認する習慣を持っておいてください。
Googlebot 訪問時のリダイレクトの挙動
誤った実装が行われて、GooglebotのIPアドレスで訪問した時のみ別のURLにリダイレクトがされます。このようなケースでGooglebot訪問時のリダイレクトの挙動を調査する方法を教えてください。
この場合、Search ConsoleのURL検査でリダイレクト元URLを調査した場合、リダイレクト先のURLが検査され、かつ、リダイレクトがされたこと自体が通知・表示されない仕様だと思います。
また巨大サイトのため「ページのインデックス登録」の「ページにリダイレクトがあります」には膨大なURLが記録されており、ここで特定URLは調査不可能でした。
Googleの回答
GooglebotのIPアドレスでのみリダイレクトが発生するケースを調査する、最も確実な方法としてはサイトのサーバーログを確認して、Googlebotのユーザーエージェントに対するサーバーの応答ヘッダーを直接確認することに立ってます。
または、コードベースだったりとか、データベースで、ハードコードをされてる可能性のあるIPアドレス、またはファイアウォールCDNルールを調べてみることなんかも有効かなと思いますので、ぜひそのあたり確認していただけると良いのかなと思います。
当社の見解
GooglebotのIPアドレスに対してのみリダイレクトが発生するケースは、クローキングに該当する可能性があります。意図的な実装でない場合も、Googleからはユーザーとは異なるコンテンツを見せているとみなされるリスクがあるため、早めに原因を特定して解消することを優先してください。
調査の手順としては、まずサーバーログでGooglebotのユーザーエージェントに対するレスポンスを確認することが最も確実です。あわせてコードベースやデータベースにGooglebotのIPアドレスがハードコードされていないか、CDNやファイアウォールのルールに該当する設定がないかも確認してください。
URL検査ツールではリダイレクトの発生自体が通知されないため、この問題の調査には不向きです。サーバーログの確認を起点に原因を絞り込んでください。
更新した記事内容が検索結果に反映されない
記事タイトル、ディスクリプション、内容の大幅な更新を行いました。
他の記事は全て、検索結果上でタイトルやディスクリプションが更新されているにもかかわらず、この記事だけ更新されずに約1ヶ月間が経ちます。
スパム被リンク対策のために否認ツールを使用、合わせて新規URL作成後に301リダイレクトなど、様々な施策を試しました。大幅な変更を加えましたが、いまだに検索結果画面が変わる兆しは見られません。
Googleの回答
具体的なクエリやサイト情報が添えられていたので、こちらも情報を確認することができました。
問題を解決するために新規URLでコンテンツを作成して、以前のURLからリダイレクトの設定を行っているとのことでした。私の環境で検索結果を確認したところ、こちらのリダイレクトは、すでに解除されていて、代わりに新しく新規URLコンテンツを作成しているように見受けられました。
またその最新のURLに関しては検索結果内の上位に表示されておりました。なんで、こちらは問題を解決したということでしょうか？301リダイレクトを正しく実装できていないと、問題が生じる場合が多いです。
一般的なコメントになりますが、公式ドキュメント、リダイレクトとGoogle検索に関するドキュメントはこちらにございます。
当社の見解
タイトルやディスクリプションの更新が検索結果に反映されない場合、まず確認すべきはGooglebotがページを正しく再クロールできているかどうかです。サーチコンソールのURL検査ツールでクロール済みの日時を確認し、更新後にクロールされていない場合はインデックス登録のリクエストを送ってください。
今回の質問者は新規URLへの301リダイレクトという対応を取りましたが、Googleの回答にある通り301リダイレクトの実装が正しくできていないと問題が生じます。リダイレクトを設定した場合は、実際にリダイレクトが機能しているかをURL検査ツールで確認することが必要です。
なお、タイトルやディスクリプションはGoogleが検索意図に合わせて書き換えて表示するケースがあります。更新内容がそのまま反映されない場合でも、必ずしも問題があるわけではありません。
検索結果に記事の最新更新日を反映する
CTR改善を目的に検索結果に記事の最新更新日を反映したいです。
現在、metaタグ、h1には更新日の記載はありません。どうしたらいいですか？
Googleの回答
ウェブページが更新または公開されたとGoogleが推定した日付を検索結果に反映させたいという旨のご質問だと理解しました。
でですね、え、設定方法は、詳しくは公式ドキュメント、Google検索で署名日に影響を与えるというドキュメントを参考にしていただけたら、記述の方法が分かるかなと思いますので、ぜひご一読ください。
当社の見解
検索結果に更新日を反映させる最も確実な方法は、Article構造化データにdateModifiedを記述することです。あわせてdatePublishedも含めておくことが推奨されています。
ページ内に更新日のテキストを目立つ場所に記載する方法もGoogleは参照しますが、構造化データの方が明示的にGoogleへ伝えられるため優先して対応してください。
ただし、更新日を検索結果に表示するかどうかの最終判断はGoogleが行います。構造化データを実装しても必ず表示されるわけではない点は理解しておいてください。CTR改善を目的とするのであれば、更新日の表示に頼るよりもタイトルやディスクリプションの改善の方が効果が出やすいケースも多いです。
Search Console BigQuery エクスポート
Search ConsoleのBigQueryエクスポートデータについて、検索結果に自社サイトのリンクが複数のページにわたって表示されるクエリにおいて、表示回数、平均順位を計算したいです。
例えば、aaaという検索クエリで、1ページ目の1位にaaa.com/abc_1.htmlというページが表示され、2ページ目の15位にaaa.com/abc_2.htmlというページが表示される状況で、ユーザーが2ページ目まで表示させる検索が1回発生した場合、searchdata_site_impressionを使ってaaaクエリの表示回数、平均順位を求めた時にどうなりますか？
Googleの回答
前提ですけど、BigQueryエクスポートにはsearchdata_site_impressionでプロパティ別に集計するものとsearchdata_url_impression、URL別に集計するものと2つのテーブルが含まれております。
2つのリンクが表示可能な場合、サイトインプレッションの方には1インプレッション、URLインプレッションの場合には2インプレッションが表示されます。
平均計算順位の計算方法に関しては、こちらに貼ってありますテーブルのガイドラインとリファレンスを参照していただけたら詳しく参照していただけたらいいんですけども、この場合、質問者さんがご理解いただいている通り、searchdata_site_impression、プロパティ別に集計するものを参照していらっしゃるので、aaaクエリの表示回数は1、平均順位は1になります。
当社の見解
この質問はBigQueryエクスポートの仕様に関する技術的な内容であり、データ分析担当者向けの情報です。
サーチコンソールの通常のパフォーマンスレポートでは確認できない粒度のデータを扱う場合にBigQueryエクスポートが使われますが、テーブルの種類によって集計の単位が異なる点は混乱しやすいポイントです。
サイト単位で集計するsearchdata_site_impressionでは、同一クエリで複数ページが表示されても表示回数は1カウントになります。URL単位で集計するsearchdata_url_impressionでは表示されたURL数分カウントされます。目的に応じてどちらのテーブルを参照するかを明確にしたうえで集計してください。
サーチコンソールのタイムゾーン
検索パフォーマンスはカリフォルニア州の現地時間で表示されていると明記があります。
ページのインデックス登録やクロールの統計情報など、それ以外の各種ダッシュボードも、カリフォルニア州現地時間の表記ですか？
Googleの回答
公式ドキュメントに記載あります通り、24時間表示を選択するとデータはお住まいの地域の現地時間で、現地時刻で表示されます。ローカルタイムゾーンはブラウザの設定に基づきます。そのほかのオプションでは日付は全て太平洋時間PTで表示されます。記述がありますので、そちら参考にしてくださ。
え、より詳しくは公式ドキュメントのこちらパフォーマンスレポートのタイムゾーンのセクションをご確認いただけるともう少し詳しく書いてあります。
当社の見解
サーチコンソールのタイムゾーンについては、24時間表示を選択した場合はブラウザのタイムゾーン設定に基づいたローカル時間で表示されます。それ以外の表示形式では太平洋時間で表示されます。
日本からサーチコンソールを利用している場合、データの日付がずれて見えることがあります。特に日をまたいだデータを確認する際は、太平洋時間と日本時間の差異を意識しておくと集計ミスを防げます。
なお、Googleの回答はパフォーマンスレポートについての言及であり、インデックス登録やクロール統計など他のダッシュボードのタイムゾーンについては明確な回答がありませんでした。詳細は公式ドキュメントで確認してください。
