#AskGoogleWebmasters:Google ウェブマスターQ&Aシリーズ 2019年分の日本語まとめ
2020年01月24日
SEO

Google ウェブマスターYouTubeチャネルが最近たくさんの動画シリーズを配信しており、2019年7月からJohn Mueller氏がウェブマスターからもらった質問に答えていく#AskGoogleWebmastersのQ&Aシリーズが配信されています。

こちらの記事では2019年に配信されたSEO関連の14つのQ&Aを日本語に訳してお届けします。
※「ホットドッグってサンドイッチ?」という質問は割愛していますが、Mueler氏の解釈を見たい方はYouTubeの元動画をご覧ください。

外部へのリンクにSEO的メリットがあるか

Q:他サイトへのリンク配置はSEOの観点から良いか良くないか、どちらですか?

A:他サイトへのリンク設置はユーザーに役立つ良いことです。リンクを設置することでユーザーが追加情報を調べるのに役立ち、コンテンツのソースの確認、コンテンツがユーザーニーズに応えていることかを確認することにも利用できます。

以下のリンクの種類はユーザビリティのためのものではないので注意が必要です。

上記のようなリンクにはrel=”nofollow”の追加をおすすめします。

役立つ他サイトに自然なリンクを設置するのは悪いことではなく、また特別な対応も特に不要です。

Google サーチコンソール内のボイスサーチデータについて

Q:ボイスサーチデータ(音声検索)はサーチコンソールでどのように表示されますか?

A:ボイスサーチはいくつかの種類があります。例えば、声をテキストサーチのキーワード替わりに使うケースがあります。その場合、声を使いますが普通のウェブサーチと同じです(アユダンテ:最終的に検索窓にテキストとして表示され、通常通り検索される、という意味です)。そのため、他のクエリと同じようにサーチコンソールの通常レポートに表示されます。
それと異なるのはGoogleアシスタントなどに質問して、結果のページ内テキストスニペットが読み返されるケースです。その場合、そのページにアクセスをしやすくするためにユーザーのモバイルデバイスに結果ページのURLを送ります。そのテキストスニペットのインプレッション数などのデータは現在サーチコンソールに表示されません(こちらの機能リクエストはきていますが)、他の機能リクエストと同じように定期的に確認して、ウェブマスターにより役立つ機能を優先しています。サーチコンソールで見たい機能があれば、ユースケースを含めてサーチコンソール内からフィードバックを送ってください。

GooglebotがクライアントサイドJSリダイレクトを認識できるか

Q:Google Evergreen ChromiumがクライアントサイドのJavaScriptリダイレクトを認識できますか? Google サーチコンソールでクライアントサイドJSリダイレクトがかかっているページのインデックス申請ができません。

A:背景を説明すると、GoogleはGooglebotを利用してウェブをクロールし、クロール可能になっていて検索結果に出せるページを見つけています。ユーザーが実際にブラウザでページを表示する際に、どのような表示になるかを理解するために、その作業の一部をGoogle Chromeで行っています。2019年の前半まではChromeの古いバージョンを使っていましたが、最近は最新のバージョンを使うようになり、随時自動的にバージョンアップしています。自動的にバージョンアップされるブラウザは「エバーグリーンブラウザ」とも呼ばれます。そのため、Evergreen Googlebotというのは現在のChromiumレンダリングエンジンを利用していて、皆さんのマシンに入っているChromeと似ているものになります。
リダイレクトを設定している場合、リダイレクト先URL、またはそのリダイレクト先URL内のコンテンツをインデックスしてほしいというシグナルになります。Googleは様々なJavaScriptリダイレクトを理解し、サーバーサイドリダイレクトと同様に解釈しています。JavaScriptリダイレクトはJavaScriptをベースにしているサイトで良く使用されますが、Googleはそのようなサイト自体をサポートするように注力しているのです。
ただし、リダイレクト元のURLをインデックス申請するのはあまり意味がありません。なぜなら、リダイレクトが、リダイレクト先のURLをインデックスするべきと示しているためです。そのため、インデックスしてほしいURLをインデックス申請するか、それよりもGoogleが自動的にそのURLをインデックスできる状態にしておくようにすることをおすすめします。例えば、ちゃんとサイト側からリンクされていれば、そのURLが通常のサイトクロールでも発見されます。サイト内変更がいち早く発見されるようするにはサイトマップを利用するのも良いです。

nofollowリンクが被リンクとしてカウントされるか

Q:nofollowリンクは被リンクとしてカウントされますか?確実にnofollowされているURLがサーチコンソールのリンクレポートに表示されていますが。

A:rel=”nofollow”が設定されているリンクは認識しますが、いわゆる「シグナル」は渡しません。基本的にリンク元からリンク先にPageRankを渡さないのです。ただし、そのリンクはやはりユーザーがサイトを訪れる際に利用するかもしれませんので、サーチコンソールで他のリンクと同様に表示するようにしました。
同じく、リンクの否認ツールを使えばシグナルが渡されなくなりますが、リンクは引き続きレポートに表示され続けます。

モバイルファーストインデックスのオプトイン・オプトアウト

Q:ウェブマスターがモバイルファーストインデックス(MFI)移行を申請できる機能の予定はないですか?レスポンシブ対応していないサイトの場合、モバイルサイトの方がSEO対策できていると思われる場合があります。

A:MFIとはウェブサイトをスマートフォンに似たようなユーザーエージェントを利用してインデックスしていくプロセスです。Googleは数年前にほとんどのユーザーが現在スマートフォンを利用していることに気づいてMFIに取り組み始めました。MFIはモバイルフレンドリーとは違って、モバイル版が存在しないサイトでもスマートフォンのGooglebotで問題なくクロールされ引き続きデスクトップ版がインデックスされる場合があります。将来的にサーチ結果のすべてのウェブサイトにMFIを使用することが目的です。ユーザーが引き続き探しているものを見つけることができるようにしたいため、また、サイト側の調整が必要な場合に必要な時間を設けるために、時間をかけて移行しています。ほとんどのサイトは問題なくMFIでインデックスできているようです。
現在、サイトが移行できそうかどうかを確認し、準備が整っているようであればMFIに移行しています。サイトを移行して良いかどうかの判断では、モバイルとPCのサイトを比較して、構造化データや画像を含むコンテンツがちゃんと入っているかを確認しています。
将来的にすべてのサイトをMFIに移行したいため、オプトイン・オプトアウト機能を提供する予定はありません。

MFIについてもっと知りたい方は以下のリンクを確認してください。

新Google サーチコンソールでrobots.txtを確認する方法

Q:新Googleサーチコンソールでrobots.txtを確認することができず、旧バージョンに切り替える必要があります。この機能はいつ頃新サーチコンソールに移行されますか?

A:一部のレポートはまだ旧サーチコンソールから新サーチコンソールに移行中で、この動画を見ているタイミングによっては既に移行された機能もあるかもしれません。
機能を単純にコピーするのではなく、再検討してどの課題に対する機能を追加すべきか、その課題をツール内で解決させる必要がまだあるか、もうさほど重要な課題でなくなったか、他の良い解決策がないかなど検討しています。そのため、まだ少し時間がかかってしまう可能性があります。メジャーな機能の追加は事前発表するのではなく、できた段階で発表するケースが多いです。現段階では、旧サーチコンソールを使っても問題ありません。

正規URLの選定基準

Q:様々なテクニックを使うことでGoogleに優先してほしいページを提示することができますが、Googleが異なるページを正規(デフォルト)として選択する場合があります。違うページが選択される理由を教えてください。

A:背景を話すと、同じコンテンツに対して複数のURLを持つケースが多く見られます。例えば、www有無、Topページで/index.htmlが存在するや、大文字小文字で同じコンテンツが分散されていることはよくあります。そもそもその複数のバージョンが発見されないことが理想なので、サイト内で1つのバージョンに統一化してリンクを設置することをおすすめしています。ただ現実的にはやはり同じコンテンツに対して複数のURLが発見される場合が多いです。検索の観点からは、そのバージョンをすべてインデックスする意味はなく、1バージョンを選択します。
Googleが正規化するURLを選ぶ際に、①サイトがどのバージョンを優先したいかと、②ユーザーにどのバージョンが役立ちそうかを考慮しています。
サイトがどのページを優先したいかを確認する場合、rel canonicalの設定、リダイレクト、サイト内リンク、サイトマップファイル内のURLを参考にし、また、HTTPS配下であることと「綺麗」なURLを優先しています。各URLのバージョンでこれらの要素を確認して、全要素がより揃っているものを選択します。サイトオーナーとして検索に表示させたいURLの希望があれば、そのURLがサイト全体を通して利用され、他バージョンがそもそも発見されないようにすると良いです。また、上記のカノニカルシグナルも矛盾しないことを確認してください。一貫した実装であればあるほど、優先したいURLが選択される可能性が高まります。
もし意図と異なるURLが選択された場合でも、単純にそのURLが検索結果に表示されるだけで、ランキングは変わりません。そのためどのURLを表示したいかはあくまでも希望の問題です。もし優先したいURLがあれば、そのURLをGoogleにわかりやすく優先すべきものとして提示してください。特に希望がなかった場合は気にする必要はなく、異なるURLが表示されたとしてもサイトに悪影響はありません。

JSON-LD構造化データの設置場所

Q:JSONの構造化データを<head>内にではなく、<body>の下部に配置しても良いですか?多くのサイトで問題なく動作しているようです。

A:JSON-LDはGoogleに構造化データを認識させる一つの方法であり、その他にMicrodataとRDFaがあります。RDFaは既存のHTMLタグに追加属性でデータを連携可能にするHTML5の拡張です。MicrodataはHTMLコンテンツ内に構造化データをネストするためのオープンコミュニティのHTML標準機能です。RDFaと同様に、HTMLタグ属性を利用しています。JSON-LDはそれと違って、<head>または<body>のscriptタグ内に埋め込まれるJavaScript記述です。このマークアップはユーザーに表示されるテキストとインターリーブされないため、ネストされるデータ項目が出しやすいです。JSON-LDは先程言った通り、<head>か<body>のどちらかに存在しても問題ありませんので、応えは「はい」になります。
また、JavaScriptで挿入しても問題ありません。

AJAXクロールと#!URLについて

Q:#!AJAXクロールの現状について教えてください。リダイレクトの設定をどうすれば良いですか?

A:昔の話をすると、JavaScriptが始まった頃、2009年にAJAXクロールのスキーマを提案していました。Webは1989年に発明されたのでまだ30年しか経過していなくて、10年前というのはその1/3、Webの世界においてかなり昔の話ですが、まだそのスキームを使っている人がいるようです。そのスキーマーは数年はいい具合に動作してきましたが、時間が立つと不要になってきました。検索エンジン、少なくともGoogleはほとんどのページをブラウザ同様にレンダリングできるようになりました。また、クロールとレンダリングのために特別のChromeのバージョンを使っています。結論から言うと、#!URLでGoogleのために特別に対策することはありません、GoogleがそのURLを直接レンダリングしてみます。URLが変わる場合に、リダイレクトのためにJavaScriptを利用するべきです。#以降のものはサーバーに送信されるのではなくブラウザ側で処理されるため、サーバーサイドリダイレクトは使えません。リダイレクトを設定すれば、Googleが#!URLを再処理していく中でリダイレクトを見つけて、フォローします。

サーバー移転とSEOの関係

Q:サーバー移転を行う予定ですが、過去に大問題になった経験があります。SEOを維持するために何に注意すべきですか?

A:基本的に、単純にサーバーを変えるだけでそれ以外のものはすべて維持するのであれば、Googleのシステムにとっては大きな影響はありません。それ以外のすべて、例えばURL、コンテンツ、CMSが維持されることが重要です。単純に異なるIPアドレスでホスティングされる同じウェブサイトになります。
そのような移転で1つだけ良く課題になりえるのは、Googlebotが新しいサーバーに応じてクロールスピードを調整することです。こちらはクロールのし過ぎでサーバーに問題を起こさないように自動的に調整されるものです。そのため、サーバーが変わった際、クロールスピードが一時的に制限され、サーバー上問題ないか確認された後、結果的にサーバー上で問題なくサイトの最新版を検索結果に出せるのに適切なクロールスピードまで上がっていきます。こちらのプロセスは完全に自動化されているため、特別な対応などは不要です。
また、サーバー移転のガイドもありますので、詳細をもっと知りたければ確認して、更に質問があればサーバー移転を多く経験しているウェブマスターフォーラムのユーザーに聞いてみてください。

SEOとアクセシビリティのための複数H1タグの扱い方

Q:アクセシビリティと見出しタグの扱い方について明確な回答がほしいです。ウェブ上に良く複数のH1タグ(大体1つ以外全部非表示)を良く見かけます。皆の扱い方がバラバラです。また<main>タグなども。

A:答えはシンプルです。Googleのシステム観点からは複数のH1タグを持っていても問題ありません。ウェブで良く見かけるパターンです。見出しタグはページ内の各パーツの文脈を理解するのに使用していますので、わかりやすい見出しがページの解釈に役立ちます。ただし、我々は実際にウェブ上の多くのコンテンツがセマンティックに構造化されていない状況の中で動いています。ユーザーにとってはさほど違いがなく、構造化されていてもされていなくてもユーザーの質問に対して応えるコンテンツになっている可能性があります。Googleのシステムのこだわりもさほど強くなく、HTMLをそのまま解釈します。H1が一つでも、複数でも、セマンティックHTMLがないコンテンツでも対応しています。
結論から言うと、このテーマについて検討する際、SEO最優先で取り組むべきではありません。ユーザーを重視し、コンテンツのアクセシビリティのために複数のh1見出しや他のHTML要素を使っても、SEOの足は引っ張りません。

構造化データプロパティ(Googleデベロッパーサイト vs Schema.org)

Q:構造化データマークアップを行う際、Googleデベロッパーヘルプ通りに実装しないといけないのか(必須、推奨プロパティを含む)、Schema.orgの他のプロパティも使って良いですか?

A:構造化データがリッチリザルトのため、またコンテンツの理解のために使われています。リッチリザルトのために、ページ内に正しい構造化データを利用し、Googleのポリシー通りの実装になっている必要があります。リッチリザルトが表示されなかったとしても、構造化データマークアップを利用していることで良いページであることを理解できますのでそのメリットもあります。(アユダンテ:「構造化データマークアップされているから良いページだと判断される」ような言い方をしていますが、「構造化データマークアップされているからページをより良く理解できる」、の言い間違いではないかと思います)
また、適切な構造化データマークアップを使用しているだけでは必ずしもリッチリザルトが採用されるとは限らないです。
結論から言いますと、特定のリッチリザルトを狙っている場合、そのための正しい実装に注意すべきです。それと別に、機械に解釈されやすい情報として他の構造化データを提供するのも良いです。その実装で目に見える結果がないかもしれませんが、関連検索で表示されるのに役立つ可能性はあります。

SEO担当がサイト速度について知るべきこと

こちらのエピソードでは、ウェブトレンドアナリストのMartin Splitt氏(MS)をゲストとし、サイト速度に関する複数のQAをまとめています。

Q:検索結果でランキングを向上させるための理想的なページ速度は何ですか?

MS:我々はページを「とても良い」か「かなり悪い」のようにカテゴリ化しています。なので、決まった閾値はなく、大まかなカテゴリしかないです。(Muller氏へ)それはどのデータに基づいていますか?

John Mueller(JM):ラボのデータで理論的な速度を計算しているのと(アユダンテ:シミュレーションしているという意味かと思います)、実際にページを見たユーザーのデータを使っています。その実際のデータはChromeのユーザーエクスペリエンスレポートに似ています。

MS:ということは、仮定のデータと実質的なデータがあるということですね。発表できる閾値はないですが、ユーザーのためにサイト速度を速くすることを推奨します。

Q:Test My Siteツールの結果が良くて、GTmetrixレポートのスコアも高かったとします。その場合Google PageSpeed InsightsスコアはSEOの観点からどれぐらい重要ですか?

MS:(Muller氏へ)SEOでベストのツールは何ですか?

JM:我々は複数の要素を複数のツールで計測しているので、紛らわしいですね。基本的に、ツールによって計測方法が少し異なります。それぞれのツールを使い、スピードアップのために簡単に改善ができそうな項目を見つけていくことをおすすめしています。

MS:そうですね、またツールごとの目的も異なると思います。例えば、Test My Siteは誰でもが大まかな状況を掴めるようなハイレベルツールで、GTmetrixはもっと技術的なツールで、PageSpeed Insightsはその中間ぐらいだと思います。レポートを見せたい相手によってツールを使い分けると良いかもしれません。なので、簡単に改善できそうな項目の特定と、経営層なのか他のマーケティング担当なのか技術者か、誰を説得したいかによってツールを使い分けると良いです。

Q:#devtools Audits (v5.1.0)でほぼ空なページをテストして、大体は全項目が最小限の結果(0.8ms)が出てFID(First Input Delay)が20msと出ますが、たまにはTTI(Time to Interactive)、FCIとFIDでもっと悪い結果が出るときがあります。同じページで同じコードですが、その理由は何ですか?

MS:FIDはFirst Input Delay(アユダンテ:ユーザーの操作が行われてから反応が返ってくるまでの時間)、TTIはTime to Interactive、ページをはじめて操作できる時間、FCIはFirst CPU Idle、CPUでJavaScriptや他の終わっていない処理がもう残っていない時間という意味です。

JM:同じページ、同じコード、別の数値が出るということですね、その原因は何ですか?

MS:まず、この計測は完璧なわけではありません。なので、もし0.8msと20msの間でしたら、20msは0.8msよりはかなり遅いですが、それでもとても短い時間です。1フレームに10msぐらいかかり、20msは悪くないですね、計測に常に何かしらのノイズは見られると思います。また、この指標にあまり注力しすぎないようにしてください。例えばメインスレッドでCPUが一分や20秒動いているなどのわかりやすい問題があったら、そこは調査をしないといけませんが、20msだったら大丈夫だと思います。

Q:ページ速度が良いかどうかを決めるのにどの指標を見れば良いですか?PageSpeed InsightsなどのツールのスコアよりFCPやFMPのような指標に注力するべきか、またその理由は何ですか?

MS:ここは答えづらく、回答は「サイトによります」になってしまいます。例えば、コンテンツを読むだけのサイトであまり操作が必要でなければ、First Meaningful Paint(アユダンテ:ファーストビューの主要なコンテンツが表示されるまでの時間)またはFirst Contentful Paint(アユダンテ:ナビゲーション後ブラウザがDOMからコンテンツの最初のビットをレンダリングするまでの時間)がFIDやTTIよりも重要だと思います。でももしインタラクティブなウェブアプリでユーザーにすぐに操作できるようにしなければならない場合、インタラクティブな指標の方が重要かもしれません。
また、スコアはシンプルすぎます。

JM:各指標で異なるものを計測して、ユーザーがページをアクセスした際の体験を把握しようとしています。スコアで簡単に大まかな状況を確認することができるかもしれませんが、必要な詳細が見えません。

MS:(スコアは)大まかな見積もりしか出していません。「このページのスコアは5です」、その意味は何ですか?そのため、大体のパフォーマンスをスコアで確認して、各ツールが提供する詳細な指標でどこに課題があるか、どこを改善すべきかを確認するのに良いです。

JM:サイト速度がかなり複雑で、適切なアクションを取るのに何を計測しているかの把握からはじめないといけないですね。Googleが特定の数値を発表していないのはその理由ですか?

MS:そうです。スピードはシンプルに1つの数値にはできず、要素がたくさん入っています。例えばチャットアプリでペイントがすごく早かったとしても、操作できるまで20秒もかかると、速くないですよね。逆にブログ記事の下部にあるお問い合わせフォームを10秒以内に使えるようにする必要もないですよね?これらを1つの数値として表現できるかと言うと、できないですね。難しいです。

JM:サイト速度は難しいですね。今後もっと簡単になると思いますか?

MS:おそらくもっと簡単になると思いますが、今後も1つのスコアに対して最適化すれば良いだけのレベルにはならないと思います。

JM:じゃあ今後も上級者は細かい指標に注力してmsを数え続けて、他の人はもっと大まかな概要を見続けて、一緒にページ速度を上げていくんですね。

MS:また、ブラウザも速度を上げて、スピードをもっと理解しやすくするのに工夫していると思いますが、基本的に自分のサイトと自分のユーザーに対して何が重要かを自分で理解するようにしないといけません。

よくあるSEOに関する質問まとめ

Q:301と302リダイレクトの違いは何ですか?

A:どちらもリダイレクトですが、301は永続的なリダイレクトであるため、Googleが最終URLを登録します。302は一時的なリダイレクトのため、再度リダイレクト元URLを確認しに来ます。可能ならば、適切なリダイレクトを使ってください。ただ、SEOのことはさほど気にしなくても大丈夫です。

Q:404と410の違いは何ですか?

A:どちらも、ページが存在しないことを宣言しています。理論上、410は404より少し早く効く可能性がありますが、実際は同じように処理されます。

Q:タイトルタグとmeta descriptionの最適な長さは何ですか?

A:指定の長さはありません。訴求力があり、ユーザーに役立つユニークなものにしてください。検索結果にページを最適に表示できるように、ユーザーが探している情報を含めてください。

Q:タイトルタグに記号を使ってもいいですか?

A:もちろんです。誤解を招く記号は表示させないようにしていますし、記号で検索するユーザーもあまりいないと思いますが、記号を使っても大丈夫です。

Q:URL内のキーワードは影響ありますか?

A:URL内のキーワードはさほど影響がないですが、CMS運用しているとURLにキーワードを含めるのは簡単で、可能であれば使っても良いと思います。ただ、使っていなくても問題ありません。
ただし、画像ファイルではキーワードを活用しています。例えばcute-robot.gifはimage-1138.gifよりかなり良いです。

Q:.phpと.html、どちらが良いですか?

A:どちらでも大丈夫です。また、他にも大きな変更をしない限り、わざわざどちらかにURLを変更することをおすすめしません。

Q:順位を向上させる秘密は何ですか?

A:申し訳ないですが、秘密はありません。技術的に強いベースを持ち、素晴らしいコンテンツを提供することからスタートしましょう。例えばクッキーと同じように、信頼できるパティシエに良い材料を使って作ってもらい、他のクッキーとは違う特別なものができると良いですよね。良い技術で最高なコンテンツを作って目立ち、長期的に誇りを持てる明らかにベストなものを作ると良いです。クッキーは重さで評価されないのと同様に、Googleのアルゴリズムは例えばページ内の文字数をカウントしません。素晴らしいものとしてレコメンドされたいなら、素晴らしいものを作ってください。

#AskGoogleWebmastersシリーズが今後も続くようなので、今後2020年のQ&Aもまとめて和訳していこうと思います。

採用情報はこちら