2023年6月に米国現地(英語圏)で実施されたEnglish Google SEO office hoursについて、フォローアップ記事が出ましたので、毎度のように和訳してご紹介します。今回は全部で22個質問がございます。そのうちの前半11個のご紹介です。残りは次回の記事でご紹介します。世界共通の疑問が多いので、英語圏の皆さんがどんなところで疑問を抱いているのか等も確認しながらご参考ください。
質問と回答
2023年6月GoogleSEOオフィスアワーの議事録です。毎度のことながら内容に関して何かあればGoogle Search Centralのヘルプコミュニティへ質問しましょう。今回ご紹介するのは、全22質問のうちの11個です。まず和訳した質問と回答をご紹介します。
1．canonicalリンクを使用しているにもかかわらず、シンジケート版がGoogle Discoverに表示されてしまうのはなぜでしょうか？
John：Bethからの質問です。「私たちは、コンテンツがシンジケートされることを許可しています。しかし、canonicalリンクを使用しているにもかかわらず、シンジケート版がGoogle Discoverに表示されることが何度もあります。どうすればこれを避けることができるでしょうか？」
これはタイムリーなトピックですね。Googleでは最近、シンジケートされたコンテンツに関するガイダンスを更新し、コンテンツシンジケーションについて触れるようにしました。link rel=canonicalは正規化を助けるシグナルであり、ヒントとなります。コンテンツがシンジケートされ、そのシンジケート版が検索にまったく表示されないようにしたい場合は、シンジケート版にもnoindex robots metaタグが含まれていることを確認してください。これにより、Google検索に表示されるのをブロックしつつ、ユーザーが普通にページにアクセスできるようになります。
2．異なるTLDを持つ2つのドメインが、同じキーワードで同じ国をターゲットにするのは問題ないでしょうか？
Gary：Sagarからの質問です。「異なるTLDを持つ2つのドメインが、同じキーワードで同じ国をターゲットにすることは問題ないのでしょうか？」
私の直感では、同じ内容のドメインが2つもあると、ユーザーを混乱させるのではないかと思います。ポリシーの観点では、これは検索結果の操作と思われるかもしれませんので、私ならGoogleのスパムポリシーを確認してみます。
3．LighthouseのJavaScriptエラーは、ページの評価やランキングに影響を与えますか？
Martin：Arndの質問です「セキュリティ脆弱性を持つフロントエンドJavaScriptライブラリにおけるLighthouseのJavaScriptのエラーは、ページの評価やランキングに影響を与えるでしょうか？」
Arndさん、ご質問ありがとうございます。いいえ、一般的にランキングに影響を与えることはありません。しかし、セキュリティのエラーや問題を無視するのは良くないことですので、できるだけ早くご修正ください。
4．Googlebotに対してWebページの特定のセクションだけをクロールブロックするにはどうすれば良いですか？
John：Seanが質問しています。「GooglebotにWebページの特定のセクションをクロールしないようにするにはどうすれば良いでしょうか？私たちの商品ページには『よく一緒に購入されている商品』というセクションがあります。このセクションには、私たちのWebサイトの大きな部分ではない補足情報なので不要に感じています。」
結論から言うと、HTMLページ上の特定セクションをクロールブロックすることはできません。しかし、似たようなものとして、data-nosnippet HTML属性を使用して検索スニペットにテキストが表示されないようにする方法と、robots.txtによってソースがブロックされているiframeやJavaScriptを使用する方法があります。ブロックされたiframeやJavaScriptファイルを使用することは、読み込みや評価ができずクロールやインデックスの問題を引き起こす可能性があるため、一般的に良いやり方とは言えません。今回の対象コンテンツがページ間で横串に利用されているだけの話なら、特段心配する必要はありません。重複している箇所だからといって、Googlebotに対してわざわざクロールブロックする必要はありません。
5．サイトマップを送信しましたが、検索結果に表示されません。なぜでしょうか？
Gary：匿名の質問です。「サイトマップを送信したのですが、検索結果に表示されません。」
サイトマップ内に記述されているURLのことを指しているのだと思われますが、あくまでもサイトマップは検索エンジンにコンテンツの所在を伝える手段であって、それ以上でもそれ以下でもないことを覚えておいてください。サイトマップで提供したURLに対してクロールを保証するものでもなければインデックスされることを保証するものでもありません。どちらもコンテンツの品質と、インターネット上での相対的な人気度によります。
6．構造化データのエラーがGoogleでは表示されるのにschema.orgではなぜ表示されないのでしょうか？
Martin：Coreyの質問です。「構造化データのエラーをGoogleでは表示してくれるのに、schema.orgでは表示されないのはなぜでしょうか？Google Search Consoleでは、フィールド“returnFees”に無効なenum値のエラーが表示されていますが、schema.orgのテストではエラーなしと表示されています。アドバイスをお願いします。」
Coreyさん、ご質問ありがとうございます。schema.orgは、構造化データのデータ型と属性を定義する、オープンでベンダーに依存しないエンティティです。しかし、Googleはベンダーとして、Google検索のリッチリザルトなどの機能で構造化データを使用するために、いくつかの属性やタイプに特定の要件を要する場合があります。そのため、schema.orgでは一部の属性を省いたり、属性に何らかの値を使用したりするだけでも問題ありませんが、Googleなどのベンダーは、schema.orgから提供された構造化データを使用して実際に機能や商品データを強化するために、より具体的な要件を設けているからでしょう。
7．HSTSなどのセキュリティヘッダーを統合することは、ランキングに影響しますか？
John：Arndからの質問です。「HSTSなどのセキュリティヘッダーの統合は、Google検索のランキング付けに影響を与えるのでしょうか？」
いいえ、HSTSヘッダーは検索に影響しません。このヘッダーは、ユーザーにHTTPSバージョンに直接アクセスするよう伝えるために使用され、HTTPSバージョンへのリダイレクトと一緒によく使用されます。Googleは、正規化と呼んでいるプロセスを使用して、クロールとインデックスに最も適したページのバージョンを選択します。そのため、HSTSに使用されるようなヘッダーでは判断しません。もちろん、これらのヘッダーを使用することはユーザーにとって素晴らしいことです。
8．Googleは、最新のXMLサイトマップとそれまでのXMLサイトマップを比較するのでしょうか？
Gary：Billからの質問です。「Googleは、現在のXMLサイトマップと以前のXMLサイトマップを比較して、何が新しくなったか、何がサイトから削除されたか等を確認しているのでしょうか？」
絶対的な答えとしては「イエス」です。前回クロールした時からサイトマップが変更されていないのに再処理することはありません、しかしリソースを無駄にしないためのソフトウェア最適化は行います。URL要素やlastmodなど、サイトマップの何かを変更するとすぐに、サイトマップは再び解析され再処理されます。しかし、そのURLは確実にクロールされるわけではなく、他のURLと同様に品質評価判断の対象として検知されます。また、サイトマップからURLを削除しても(おそらくもう存在しないから削除するのでしょうが)、自動的にインデックスから削除される訳ではなく、またURL記載が無くなることでクロールの優先順位が上がってすぐに削除されるわけでもありません。
9．XMLサイトマップとHTMLの違いは何ですか？Search Consoleでエラーメッセージが表示されるのですが。
John：Maro Samyからの質問です。XMLサイトマップとHTMLの違いは何ですか？また、Search Consoleで“あなたのサイトマップはHTMLページであるようです。代わりにサポートされているサイトマップ形式を使用してください”と表示された場合の解決方法は何ですか？」
これは、XMLファイルとHTMLページの両方にほぼ同じ名前を使用したことによる残念な結果です。HTMLサイトマップはユーザーにとって便利なもので、より高度なサイト内ページ地図のようなものです。一方、XMLサイトマップはクローラーのためだけのもので、ロボットのために作られたファイルです。個人的な意見で言うならば、HTMLサイトマップは、Webサイトのナビゲーションがあまりにも分かりにくいことの裏返しでもあるので、サイトマップページを作る代わりに、サイトのナビゲーション自体を修正したほうが良いかもしれません。
10．Googleは、解析エラーがある構造化データをどのように扱っているのでしょうか？
Gary：Animeshからの質問は「解析エラーが発生した構造化データをGoogleはどのように扱うのでしょうか？」
特に何もしません。構造化データが解析されないと、そこに含まれる可能性のある情報を抽出できないので、無視されるだけです。
11．URLに数字を含めることはSEOに不利ですか？URLに数字を含めるのは良くないことなのでしょうか？
John：「URLに数字を含めることはSEOに不利なのでしょうか？URLに数字を入れるのは良くないことなのでしょうか？」
いいえ、URLに数字を入れるのは悪いことではありません。数字を使ったり、文字を使ったり、非ラテン文字を使ったり、必要であればUnicodeを使ったりしても良いです。URLの中で唯一避けたいのは、ページを訪れるたびに変わる一時的な識別子です。これはクロールが非常に難しく混乱を招きます。
今回は前半部分にもかかわらず、面白い情報がありました。
ひとつは、2．の質問で、まぁ当たり前の話ですが…1つのキーワードに対して2つに分かれたドメイン(サイト)を使って施策するのは良いのでしょうか、という内容でした。Google側の回答としては「ポリシーに抵触してそうだし(おそらくドアウェイページになるのでは)、オススメしません」とのことでした。
また、これも当たり前ですが、4．の質問に対する回答から気を付けるべき点もございました。「見せたくないコンテンツをクローラーブロックしたいなら、robots.txtでdisallow設定したURLから配信しているコンテンツをiframeで呼び出して掲載するやり方なら、結果的にそうなるよ。褒められたやり方ではないけど。」とGoogle側は言っています。逆に言えば、そもそもrobots.txtでクロールさせないようにしているサイトやドメインから配信しているiframeやJavaScriptが自分のサイトページに無いか確認したほうが良いでしょう。クロールを阻害しているiframeやJavaScriptがあった場合、その部分だけGoogleは空白箇所としてレンダリングするので、ページとしては充分に評価してくれません。気を付けたほうが良いですね(これは数年前に結構起こった問題でGoogleも警鐘を鳴らしていた内容です)。
8．と9．の質問に対するGoogleの回答も興味深いです。XMLサイトマップが更新されたら、(エネルギーの節約のために)更新された部分を中心に検知するけど、検知したからと言ってクロールやインデックスを保証するものではないよ、あくまでもクロールやインデックスの判断対象に乗るだけだよ、とのことです。また「HTMLサイトマップが必要だと思うなら、それはナビゲーションやユーザー導線に問題があるからかもしれないので、ナビゲーションを見直すと良いよ」というのも適切な解釈だと思いました。
あとは11．の回答のように、URLは何でも良いけど動的なもの(訪れる度に毎回変わるURL)はやめてね、とのことでした。私個人としては、複雑なパラメータ付きURLもオススメできません。あと、Google AnalyticsではURLファイル名で表示されるので、内容が分かりやすいファイルURLの方が管理しやすいと思います。
質問内容よりもGoogleの回答の“ちなみに”が面白い
今回のＱ&Ａを見る限り、質問は多少稚拙でも、Googleの回答から派生したGoogle側からの情報が興味深い内容を孕んでいますね。特にジョン・ミューラー氏の話は分かりやすいし、ご本人も慣れている感じがしますね。
というわけで後半に続きます。
