• 2023年1月の米オフィスアワーより②

2023年1月の米オフィスアワーより②

前回の続きです。2023年1月に米国本国で行ったEnglish Google SEO office hoursについて、フォローアップ記事が出ていましたので、和訳してご紹介します。全部で28個の質問を前編14個と後編14個の2回に分けてご紹介しています。

質問と回答

2023年1月GoogleSEOオフィスアワーの議事録です。前編は初歩的な内容でしたが、後編は少し込み入った内容もありそうです。ちなみに、内容に関して何かあればGoogle Search Centralのヘルプコミュニティへ質問するようお願いします。この記事の最後に私の感想等も記載しておきます。

モバイル版をGoogleに表示させるにはどうしたら良いでしょうか?
Lizzi:マテウスからの質問です。Google Search Consoleは、私のWebサイトにモバイル版があるにもかかわらず、全てのページを見ずに一部はデスクトップ版のほうを見ているようです。どうすればGoogleにモバイル版を表示させることができますか?とのことです。
モバイルファーストインデックスに関するドキュメントに、確認事項のリストがありますので、そのチェックリストとトラブルシューティングのセクションをご確認ください。つまり、デスクトップとモバイルのバージョンで同じコンテンツを提供し、ユーザーとGoogleの両方がそれぞれのバージョンにアクセスできる状態にあるか確認することです。それでも問題が解決しない場合は、フォーラムに投稿して、モバイルフレンドリーにもかかわらず表示されない該当ページを見てもらうようにしてください。
 

同名の競合他社のソーシャルアカウントが表示されるのはなぜか?
John:アンソニーからの質問です。私の会社のソーシャルメディアアカウントが検索結果に表示されなくなりました。今は同じ名前の競合他社だけが表示されている状態です、とのことです。
同じ名前で展開している状況なのであれば、そもそもあなたのサイトがどれかを見つけることは難しいですよね、Googleにもユーザーにも、検索クエリに対してどちらが適切なサイトなのかが明確に分かりません。どちらも同じ名前で呼ばれているがゆえに、本質的には最適な結果とも言えます。アカウント名でサイトを見つけてもらいたいのであれば、その名前が明確に識別できる文字列であり、他に使用されていない独自のアカウント名にしたほうが良いでしょう。
 

URL削除がうまくいかない理由は何でしょうか?
Gary:ルーからの質問です。コンテンツ削除ツールを使って承認されたのに、なぜ私のURLはまだGoogleの検索結果に表示されているのでしょうか?この状況を何とかしていただけませんでしょうか、とのことです。
URL削除ツールの反映は非常に高速です。通常、数時間以内に指定されたURLを検索結果から削除します。URL削除ツールによって承認されたURLが削除されなかったと思われる場合は大抵、間違ったURLを指定してしまったことが考えられます。実際の検索結果をクリックし、本当に指定したURLかどうかご確認ください。検索で表示されるのと同じURLでしょうか? 違うURLを指定しているようであれば、もう一度そのURLの削除リクエストを行ってください。
 

サービスサイトで使用すべき構造化データは?
John:私たちのWebサイトで扱うのは固定価格ではないサービスです。内容次第で見積もりが異なります。このようなサービスの場合、商品の構造化データを使用する際に無効な項目となってしまうのですが、どのように修正すれば良いのでしょうか?とのことです。
ご質問内容に関しては、ローカルビジネスの場合、ローカルビジネスの構造化データを見ることをオススメします。こちらでサービスの価格帯を指定することもできます。このマークアップ方法についての詳細は、検索デベロッパーのドキュメントに情報があります。
 

なぜ私のコンテンツはインデックスされないのでしょうか?
Gary:匿名の質問です。私たちの比較的健全でコンテンツが豊富な国営サイトが繰り返しインデックス解除され、代わりに古い404のサブドメインやサブディレクトリが再インデックスされてしまうのですが、その理由は何ですか?とのことです。
サイトのURLが分からないと正確な回答はできませんが、古いサブドメインやサブディレクトリ内の全URLを検知していないせいでそれらのURLがまだ検索に表示されているかもしれません。もし、その国営サイトが希望するキーワードで表示されないだけでなく、Googleのインデックスから落ち続けていることが確証できれば、それは技術的な問題と品質の問題の両方の兆候である可能性があります。Google検索セントラルコミュニティから、あなたのサイトに何が起きているのか質問投稿すると良いでしょう。
 

古いURLや移動したURLを検索に引っかからないようにすることはできますか?
John:アレックスからの質問です。301リダイレクトで大量のコンテンツを移動した場合、古いURLをインデックスから削除するよう申請する必要があるのでしょうか? リダイレクトから10年経った今もGoogleは古いURLをクロールしているのです、とのことです。
いいえ、移動したURLの再インデックス化や削除を依頼する必要はありません。これは時間の経過と共に自動的に行われます。あなたがクロールとして捉えているのは、あくまでもGoogleのシステムがあなたのコンテンツが元々他のURLにあったことを認識しているだけです。そのため、ユーザーが古いURLを特定して検索した場合にそれを表示することがありますが、これは何の問題でもありません。このような場合、修正しなければならないことは何もありません。Search ConsoleでURLを確認すると、リダイレクトを使用している時の正規URLが移動していることまで確認できます。要するに、これらの古いURLを直接検索窓に入力した時に表示されるからと言って気にする必要はありません。
 

Search Consoleの所有権の変更は検索に影響するのか?
Gary:アヴァーニより、Search Consoleの所有権や検証コードを変更することで、Webサイトのインデックスに影響するか、とのことです。
Search Consoleでサイトを検証したり、検証コードや方法を変更しても、インデックスやランキングには全く影響しません。Search Consoleが提供するデータを使用してサイトを改善することで、検索でより良い結果を得られる可能性はありますが、それ以外では検索に全く影響しません。
 

翻訳したコンテンツがGoogleに表示されないのはなぜか?
John:アランからの質問ですが、2ヶ月ほど前に、自分のWebサイトに別の言語版を追加しました。しかしGoogle検索で翻訳されたバージョンを見つけることができません。その理由は何でしょうか?とのことです。
Webサイトに別の言語を追加する場合、やらなければならないこと、追加すべき作業があります。まず大事なのは、言語毎に別々のURLを用意する必要があります。URLにパラメータを追加する程度の些細な作業かもしれませんが、その言語に特化して繋がる各URLを用意する必要があります。システムによっては、同じURLのコンテンツを自動的に入れ替えるものもあります。ただし、これは検索エンジンには機能しません。自動的に入れ替える場合でも、検索エンジンに機能させたければ別々のURLを用意するのです。それと、もうひとつ重要なことは、各言語版へのリンクを用意することです。理想的な方法は、各言語版からそのページの他の全ての言語版にもリンクできるようにすることです。そうすれば、ユーザーも検索エンジンも、その言語版を簡単に見つけることができます。それらのページへの内部リンクがないと、Googleはその存在を知らないかもしれません。そして最後に、hreflangアノテーションを使用することでして、それはページ間の関係性を教えてくれる素晴らしい手段です。とはいえ、これはどちらかというとおまけのようなもので、必須ではありません。複数の言語バージョンを使用するサイトについては、開発者向けドキュメントで詳しく説明されています。
 

画像URLの階層の深さはランキングに影響しますか?
Lizzi:サリーからの質問です。画像URLの階層の深さはランキングに影響しますか? また、画像のsrcsetやサイズコードをHTMLに追加することは、画像のランキングに影響しますか?とのことです。
画像URLの深さが3階層であろうと5階層であろうと、それはあまり重要ではありません。それよりも重要なのは、あなたのサイトにとって意味のある管理構造を使うことであり、それによって画像を何らかの論理的なパターンで整理しやすくなりますし、ファイル名を説明的にするようになるでしょう。例えば、/photos/dog/havanese/Molly.pngというディレクトリを切るのは意味があるかもしれませんが、ハバニーズの写真が大量にない場合は、/photos/Molly-Havanese-dog.pngとするだけでも良いかもしれません。srcsetやサイズコードについては、画像管理上、必要であれば追記ください。特にレスポンシブ画像の場合、画像の種類を把握するために、これらのコードを追加しても良いでしょう。ご参考になれば幸いです。
 

hreflang分類の一部が崩れるとどうなるのでしょうか?
Gary:匿名の質問ですが、hreflangが上手に作成できていなかったり、クラスタにnoindexや別の正規表現が含まれていたりすることによって、hreflang分類の扱いに違いがあるのでしょうか?とのことです。
これは難しい話題ですね。hreflang分類は、検証できたhreflangリンクによって形成されています。ここでの検証とは、hreflang間の相互リンクを意味します。hreflangリンクが検証できなかった場合、そのリンクは単に分類として扱われません。分類は他のリンクがどうあれ、検証できたもので作成されます。その分類のうちのリンクのひとつがnoindexであった場合、それは分類対象にはなりません。
 

サイト全体のフッターリンクは良くないのでしょうか?
Lizzi:サイトをデザインした企業へのリンクやCMS元を表示するサイトワイドなフッターリンクはSEO上有害なのでしょうか?とのことです。
通常、そのリンクが「Made by Squarespace」のような、Webサイトのテーマに付随する定型的なものであれば、心配する必要はありません。リンク内容を自由に記載できる場合は、このようなタイプのリンクにはnofollowを追加すると良いでしょう。また、その際にアンカーテキストが適切なものであることもご確認ください。例えば、「Made by the best Florida SEO」のように、キーワードを多用したリンクでないことが重要です。
 

サイト移転のスピードを上げるには?
Gary:モハメドからの質問ですが、Webサイトのドメイン名を変更したため、Search Consoleで移転リクエストを行いました。この理解を早く進めるためにはどうしたら良いでしょうか?これは私にとって、とてもとても重要なことなのです、とのことです。
これは良い質問です。最も重要なことは、古いURLが新しいサイトにリダイレクトされていることを確認することです。これは、サイト移転に最も大きな好影響を与えます。Search Consoleのサイト移動リクエストは提出すると良いものではありますが、それがなくても古いURLを新しいものにリダイレクトし、それらが適切に動作していれば、サイト移転は上手に進むはずです。詳しくは、お好きな検索エンジンで「Google サイト移転」などと検索し、サイト移転に関するドキュメントをご覧ください。
 

m-dot site(モバイル版サブディレクトリがあるサイト)で、デスクトップ版とモバイル版を連携させるにはどうしたら良いですか?
Lizzi:ニルトンからの質問です。今のところ、私のサイトはレスポンシブではありません。デスクトップ版とモバイル専用サブディレクトリサイトがあります。ドキュメントには、サイトオーナーが行う必要がある処理として、canonicalとalternateに関連することが書かれています。そこで質問ですが、デスクトップ版にcanonicalを入れる必要があるのでしょうか? ドキュメントではあまり明確に表記されていません、とのことです。
ご意見ありがとうございます。ぜひドキュメントで明確化するようにします。デスクトップ版のURLは常に正規のURLで、m.版はそのURLの代替バージョンです。ですから、デスクトップ版では、自分自身を指すrel=canonicalと、m.版を指すrel=alternateが必要です。そして、m.版のページには、そのページのデスクトップ版を指すrel=canonicalだけが必要です。お役に立てれば幸いです。
 

EXIFデータの重要性は?
Gary:サガーより、ECサイトや画像が重要な役割を果たすWebサイトにおいて、SEOの観点からEXIFデータはどの程度重要なのか、とのことです。
まあ、これは簡単な質問です。私はこういう簡単な質問がとても好きです。答えは、Googleは今のところEXIFデータを何の役にも立てていません。現在使用している唯一の画像データ、つまりメタデータはIPTCだけです。

引用)Google SEO Office Hours|Search Centralより和訳

 

今回は面白い質問が多かったです。まず多言語対応をGoogleに知らせたければ、URLをそれぞれの言語で生成することを明言していること、またサイト移転やページ検知に最も手っ取り早いのはページ単位の正確なリダイレクトであること、だと。ユーザーエージェントに合わせてダイナミックサービングで言語を振り分けてもGoogle検索にはうまく伝えられないのかもしれません。また、Googlebotにもユーザーにも強制的に切り替わるリダイレクトが一番ページ移動には有効なのでしょう。この2点について確証的な見解を得られたのは、私にとっては有益でした。

他にも画像のEXIFデータは不要なので、少しでもアップする際の画像容量を減らすために、IF情報は削除しても良い(IPTCは読み込むため、入れられるIPTC情報は入れたほうが良い)ことが確証できましたね。まぁ、上級者なら知っていたことなのでしょうが、改めて理解できました。

大抵は設定ミス?

今回のオフィスアワーを見ていると、込み入った質問は「設定を確認して、それでも不具合が出ているならフォーラムやコミュニティへ」か「そもそもの仕様はこうです」で回答している印象を受けます。まぁ、アルゴリズムの機能や仕様に関しての質問が多ければそういう回答しかできないのだと思いますが…。でもせっかくGoogleの中の人ならもう少し突っ込んで回答してくれると面白いのですが…ポジショントークというものがあるかもしれません。
また、実際問題、記述ミスや設定ミスに起因した質問も多かったりすると思いますので、回答もマンネリ化してしまうのかもしれませんね。まぁ、ChatGPTなどの新興勢力もありますし、今後はAIやコンテンツ性質に関する質問や回答が増えたり、個人見解をぶつけ合ったりできると良いですね。とはいえ、やはりそれもGoogleの言質として捉えられると副作用が生じてしまいますし…難しいところです。

オフィスアワーは基本を振り返る「おさらい演習」として確認すると良いかもしれません。

カテゴリー

新着記事

人気記事

過去記事