#AskGoogleWebmasters：Google ウェブマスターQ&Aシリーズ 2019年分の日本語まとめ

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

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

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

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

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

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

• SEOを目的したリンク交換
• 広告
• ユーザー投稿内リンク

上記のようなリンクには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タグ（大体１つ以外全部非表示）を良く見かけます。皆の扱い方がバラバラです。また<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をまとめています。

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

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