#AskGooglebot:UGCとSEO、robots.txtやレンダリングとクロールバジェットの関係についてQ&Aまとめ
2020年12月7日
SEO

Google ウェブマスターYouTubeチャネルでJohn Mueller氏がウェブマスターからもらった質問に答えていく#AskGooglebotのQ&Aシリーズ(旧#AskGoogleWebmasters)が配信されています。

この記事では2020年5月以降配信されたSEO関連の5つのQ&Aを日本語に訳してお届けします。(2020年1月~4月のQ&Aも和訳しております。)

1.ユーザー生成コンテンツ(UGC)について

Q: ページのランキングに影響する要素の中にコンテンツの関連性と品質があります。その評価はユーザー生成コンテンツ(UGC)にも適用されますか?

A: UGCの種類には様々あって、ページ下部にあるユーザーコメントや、やり取りからページ全体がユーザーに生成されるまで幅広いです。

Googleはウェブマスターに生成されたコンテンツとユーザーに生成されたコンテンツを判別しません。誰に生成されようが、ウェブマスターが公開することを決めたコンテンツとして、評価し、ランキングに利用します。

UGCが多いサイトの場合、そのコンテンツが自社の基準に相応しいものであることを確認すると良いです。

簡単な対策の1つは、すべてのUGCにデフォルトでnoindexタグを設置、インデックスから除外し、品質が良いと判断したコンテンツだけnoindexタグを外し、インデックス対象にすることです。どれぐらいの品質であればインデックス対象とするかはウェブマスターの判断になります。

例えば、ある口コミサイトで他のユーザーがその口コミをどう評価しているかという情報を持つサイトではそのような情報が品質の判断に役立つかもしれません。

また、ユーザーが記載したリンクについて、ウェブマスターは基本的に保証できないと思います。UGCのリンクであることをGoogleに見せるために、そのリンクにrel=”ugc”の属性を設定すると良いです。

2.robots.txtで特別なファイル形式をブロック

Q: *.css、php.iniや.htaccessをrobots.txtでブロックすべきですか?

A: いいえ、それは良くないです。いただいたファイル形式ごとに説明します。*.cssをブロックすると、すべてのCSSファイルをブロックすることになります。各ページを正しくレンダリングするために、GoogleがCSSファイルにアクセスできることが必要です。

例えば、ページがモバイルフレンドリーであるかの判断にも必要不可欠です。CSSファイル自体は基本的にインデックスされませんが、クロールできる状態にするべきです。php.ini はPHPの環境設定ファイルです。ロックされるか特別な場所に置かれて、誰にもアクセスできない状態にするべきものです。

誰もアクセスできない場合、Googlebotもアクセスできないため、robot.txtでブロックする必要はありません。.htaccessはデフォルトで外部からアクセスできない特別な設定ファイルです。他のロックされているファイル同様に、元々アクセスできない状態のはずなのでrobots.txtでブロックする必要はありません。

最後に、他サイトのrobots.txtファイルを流用することは推奨しません。自社サイトでクロールしてほしくないページ群を特定して、そのページだけブロックすると良いです。

3. 「.jobs」ドメインを利用すれば求人関連の検索でヒットしやすくなるか

Q: 「.jobs」ドメインを利用すれば、求人関連の検索でヒットしやすくなりますか?

A: このようなトップレベルドメインについて良く聞かれます。

結論から言うとNoです。トップレベルドメインにキーワードが含まれてもランキングに影響しません。興味あるキーワードで検索してみてください、上位に表示されているウェブサイトのトップレベルドメインにキーワードが含まれていないと思います。キーワードがURLにすら入っていないサイトが多いと思います。それがGoogleの仕様です。

ドメイン名にキーワードが入っているからと言って、他のサイトより関連性が高いとは限りません。そのため、ドメイン名にキーワードを含める必要はありません。また、企業が進化することがあり、今提供しているサービスに依存するドメインより長期的に使えるドメイン名を選んだ方が良いでしょう。

例えば、青いウィジェットを提供していてbestbluewidgets.comというドメイン名にしていると、赤いウィジェットも提供しはじめたときにドメインをどうしますか?ドメイン名、トップレベルドメインのキーワードを気にするのではなく、長期的に使っていけるウェブサイトを作ることを意識しましょう。

4.307リダイレクトの処理

Q: GooglebotはHSTS・307リダイレクトをどう処理しますか?

A: 簡単にいうと、処理していません。307リダイレクトは本当のリダイレクトではありません。HTTPSのウェブサイトの場合、HSTSを使うことができます。

HSTSはユーザーにページのHTTPS版のみ使用するように指示します。そのため、ユーザーがHTTPのURLを入力したり、HTTPのリンクをクリックしても、ブラウザがHSTSを覚えて、URLのHTTPS版を返します。Chromeでは307リダイレクトがあったように表示されますが、厳密にはリダイレクトが発生していません。

GooglebotはURLを白紙状態でクロールしていますので、HSTSリストを維持せず、HTTPのURLがあればそのHTTP URLにアクセスします。そのURLにHTTPSへのリダイレクトが設定されていれば、そのリダイレクトをフォローします。結論、Googlebotは307を認識しません。それで特に問題もありません。

5. レンダリングとクロールバジェット

Q: WRS(ウェブ レンダリング サービス)の多用はクロールバジェットに影響しますか?

A: まずは定義から説明します。ユーザーが見たままのページをインデックスするために、Googleはブラウザと同じようにページをレンダリングしますが、WRSがそのための仕組みです。クロールバジェットとは、クロール中にサーバー負荷をかけすぎないために、サーバーへのリクエストを制限するための仕組みです。

ほとんどのWebサイトではGoogleが充分なURL数をクロールできますので、クロールバジェットを気にする必要はありません。

明確な閾値はないですが、クロールバジェットを気にするべきなのはURLが数十万以上ある大規模サイトだと思います。クロールバジェットでは、サーバーが特定の期間内に処理できるリクエスト数が自動的に判断されて、随時調整されます。

サーバー速度が落ちたり、エラーが増えたりすると、クロールバジェットが制限されます。

レンダリングのために、GoogleがJavaScriptファイル、CSSファイル、画像、動画などの埋め込みコンテンツ、またページ内に使用されているAPIのサーバーレスポンスにアクセスできる必要があります(コガン注:つまり、HTML以外のリクエストもクロールバジェットにカウントされます)。

Googleはページをレンダリングするためのリクエスト数を減らすために、キャッシュを使っていますが、ほとんどのページではレンダリングが1つのHTMLのリクエストのみでは済みません。

大規模サイトではページをレンダリングするのに必要な埋め込みリソース数を削減することでクロールに役立ちます。更に、ユーザーに対しての表示速度を上げる効果もありますので、クロールにもユーザーエクスペリエンスにもメリットがあります。

#AskGooglebotシリーズが今後も続きそうでしたら、また和訳していこうと思いますのでご興味ある方はチェックしてください!

採用情報はこちら