Googleがページを検出できるよう手助けする～Googlebotがコンテンツへとアクセスできることが正確な評価の大前提～

インターネットの世界にどれだけの数なWebサイトが存在するかは正確な情報を当社は持ち合わせておりませんが、膨大な数のWebサイトが存在していることだけは理解できます。そして、それらのWebサイトの全てをGoogleが把握しているわけではないこともまず間違いありません。
これから皆さんに「Webサイトをネットの世界に公開したとしても、自動的にGoogleの検索結果にWebサイトがヒットするわけではない」という大前提をお伝えしたいと思います。

その前に、皆さんはGoogleの検索エンジンの大雑把な仕組みについて考えたことがありますでしょうか。
本ページが読者として想定しているWebサイトオーナーの皆さんのなかには、「Googleで検索をするとき、Googleが皆さんの必要としている情報を、インターネットの世界の隅々まで探しに出かけ、その結果を瞬時に検索結果画面に表示してくれている」とイメージされている方がおられるかもしれません。

実際にGoogleが行っていることは、事前に「クローラ」と呼ばれるプログラム（ロボットやスパイダーなど）によって、世界中のWebコンテンツの情報を検出し、内容を把握した上でサーバー内に整理していて（この作業をインデキシングと言います）、検索時にはこのインデキシングされた情報（インデックス）から最も検索者が望んでいると思われる情報を選び出し検索部（サーチャーといいます）に提供するという仕組みになっています。

つまり、ユーザーがGoogle検索を行った際の検索結果は、ネットの世界のコンテンツから探し出されているわけではなくて、Googleが作成しているインデックスの中から探し出されているであり、逆に言えばGoogleにインデキシングされていないWebサイトは検索にヒットしないということになります。

そうすると、GoogleのクローラによってWebサイトが検出されインデキシングをしてもらうということが検索結果にヒットする為の第一歩になるわけです。

Googleのクローラのうち、主要なクローラが「Googlebot」と言われるプログラムで、私たちの業界でも「Googleのクローラ」＝「Googlebot」と捉えている人が多いほどGooglebotはクローリングにおいて重要な役割を果たしています（クローラの種類と役割についてはこちらを参照）。

クローラ（動画の中ではスパイダーと呼んでいます）の役割とインデックスのイメージについては、Googleが公開している「How Search Works」という動画が分かり易いので是非お手透きの時に是非見てみてください。

そして、そのGooglebotが情報を取得しに行くメインルートが「Googleが既知のページからのリンクを辿るルート」であり、サブルートが「Googleに送信されたサイトマップファイルに記載されたURLに読みに行くルート」になります。

「Google がページを検出できるよう手助けする」とは、概ねGooglebotが情報を取得しに行くこの2つのルートの確立と、Googlebotがページを検出しやすい環境を作り上げることを意味しています。

それでは、具体的な内容を個別に見ていきましょう。

前述のように、「Googleが既知のページからのリンクを辿る」ためには、サイト上のすべてのページが、Googleが検出可能な別のページからのリンクでアクセスできる必要があります。

つまり、どんなに良いコンテンツを制作してインターネット上にアップしていても、そのサイトに対してGoogleが検出可能な別のページからリンクがされていなければ、Googlebotが情報を取得しに来ることが困難になります（XMLサイトマップの送信という別の方法については後述します）。

また、リンクを張ってもらう場合には、参照リンクに遷移先のページ（ターゲットページ）に関連するわかりやすいテキストを設定することをGoogleは求めています。
バナー等の画像の場合には、alt に代替テキストを設定します。

遷移先のページの情報をテキストまたは代替テキストで端的に記載することで、Googlebotはより正確な情報を取得しやすくなると言われており、これは「Googlebotがページを検出しやすい環境を作り上げる」ことに繋がります。

なお、2007年頃から、SEO業界では、テキストリンクの方がSEO面で効果があり、画像リンク（と代替テキスト）はできるだけ避けるべきと比較的強く言われておりましたが、当社としては現時点（2019年11月執筆中）では、画像リンクを選択しても代替テキストを設定していればそれほど意識する必要はない（あっても些細な差であり、その差は徐々に縮小している）と考えています。

ウェブマスターガイドラインの精読という面で言うと、以前のガイドラインでは「わかりやすい階層とテキストリンクを持つサイト構造にします。各ページには、少なくとも1つの静的なテキストリンクからアクセスできるようにします。」と記載されていた表現が、2016年のガイドラインの改正時に、「テキストリンクを持つ構造」から「リンクでアクセスできること」というように「テキスト」という限定が消え、「ターゲットページに関連するテキストまたは alt 属性（画像の場合）のいずれか」と画像リンクが明記されるようになりました。

また、Googleは各種の画像認識サービスを公表・実践し始めています。
これはGoogleの画像認証技術が年々向上していることを示していると同時に、Googleは画像も重要なコンテンツとして評価対象に考えているという当たり前の事を再確認できます。
この先端画像認証技術がGooglebotに搭載されているかどうかについてのソースは現時点で未確認ですが、当社としては、技術の実装方向性としてはそうなってくるのが自然であり、これによりテキストリンクと画像リンクの格差は時と共に縮まっていくとことから、「現時点ではあまり気にする必要はない」と考えています。

なお、「リンクがクロールされるようにするには、リンクの形式が href 属性が指定された ＜a＞ タグである必要があります。」
これはWeb制作会社のマークアップエンジニアであれば当然の事ですし、皆さんがWordPressを利用しておられて管理画面から記事を投稿する際に「リンクの挿入」を行うと自動的にhref 属性が指定された ＜a＞ タグになるくらいあたりまえのことですので、それほど意識をする必要はなく、あくまで念のために記載されているものであると思います。

まず、このガイドラインを精読するにあたり、前段と後段で「サイトマップ」の定義が異なることを理解する必要があります。

（1）前段の「サイトマップ ファイル」（XMLサイトマップ）について

前段のサイト上の重要なページへのリンクを含んだ「サイトマップ ファイル」とは、サイトのウェブページのリストを指定して、Google や他の検索エンジンにサイトのコンテンツの構成を伝えるファイルを指し、いくつかのファイル形式がサポートされていますが（サイトマップの形式についてはSearch Consoleヘルプの「サイトマップの形式」欄を参照）、通常はXMLという形式が利用されていることから、この記事では前段の「サイトマップ ファイル」のことを「XMLサイトマップ」と呼ぶこととします（Web業界でも通常はそう呼ばれています）。

確かに、Googleによれば「サイトの各ページが適切にリンクされていれば、Google のウェブクローラは通常、サイトのほとんどのページを検出できます」。
しかしながら、「サイトのサイズが非常に大きい」場合や、「サイトにどこからもリンクされていない」場合、「サイトが新しく、外部からのリンクが少ない」場合などにサイトのクロールを改善する手段として、XMLサイトマップはGoogleのインデキシングに役に立つことがSearch Consoleヘルプに明記されています（Search Consoleヘルプの「サイトマップが必要かどうか」欄を参照）。

XMLサイトマップの送信は、サブルートである「Googleに送信されたサイトマップファイルに記載されたURLに読みに行くルート」の確立そのものにあたります。

なお、XMLサイトマップの送信はSearch Consoleより行いますが、その詳細なやり方については本記事では割愛させていただきます（Search Consoleヘルプの「サイトマップの作成と送信」ページを参照）。
本記事が読者と想定しているWebサイトオーナーの皆さんからすると難しそうに思えるかもしれませんが、ご利用されているWeb制作会社の担当者さんに「GoogleへのXMLサイトマップの送信をお願いします」と依頼すれば、まず問題なく意味が通じる程度には基本的な事項ですので、ご安心ください。

（2）後段「サイトマップ ページ」（HTMLサイトマップ）について

これに対して、後段の「サイトマップ ページ」とは、Webサイトのなかに独立したページとして存在するサイトマップのページあるいはよくフッター内に設置されているサイトマップを指します。
通常はHTMLでWebサイト内のサイトマップが制作されていることから、この記事では後段の「サイトマップ ページ」のことを「HTMLサイトマップ」と呼ぶこととします（Web業界でも通常はそう呼ばれています）。

このHTMLサイトマップについては、以前（2010年頃）はGoogle自体がSEO上推奨していた時代もありました。先ほどの「How Search Works」でも熱く語ってくれているMatt CuttsさんがHTML形式のサイトマップについて「検索エンジンにも有効」と述べていたのです（下記動画参照）。

しかし、「なぜ」検索エンジンにも有効なのかの根拠については、よくよく聞いて考えてみるとHTMLサイトマップによって、メインルートである「Googleが既知のページからのリンクを辿るルート」が確立されることが重要な根拠であったと当社は考えています（ページランクの配分も理由の一つに挙げられていますが、これもメインルートが確立していないとできません）。

そうだとすれば、前述のように、現在ではHTMLサイトマップがなくても「サイトの各ページが適切にリンクされていれば、Google のウェブクローラは通常、サイトのほとんどのページを検出でき」るようになっていることから、最近ではWeb業界では「HTMLサイトマップはSEOの面ではそれほど気にする必要はない」と考えられています。

GoogleのJohn Muellerさんが、2015年に上記のようにGoogle+で発言されたことで、HTMLサイトマップはSEOの面で必須ではないことが一気に認知されるようになりましたが、ユーザーの利便性を高める為に設置するのであれば有用であることも付記しておきます。

ここで言う「1ページのリンク」とは、Webサイト内の1ページに設定する他のページへのリンク（「発リンク」と呼びます）のことを指します。

発リンクが膨大にあるとファイルサイズも大きくなることから、特に一昔前のGooglebotとインデックスシステムでは処理できないケースがありえました。
そこで、Google がページを検出できるよう手助けするための技術的なルールとして、あくまで一定の目安として発リンク数の制限をかけていたことに起源を持つルールと言われています。冒頭の分類で言えば【Googlebotがページを検出しやすい環境を作り上げる】ためのルールということですね。

このルールに関しては、以前のガイドラインでは「ページのリンクの数を適切な数 (100 未満) に抑えます。」とされていたものが、「1ページのリンクを妥当な数に抑えます。」と変更され、2016年のガイドライン改正時に「1ページのリンクを妥当な数に抑えます（最大で数千個）。」と追記されるに至りました。

この発リンクに関するガイドラインの変遷理由については割愛しますが、現在ではGooglebotとインデックスシステムの処理能力の問題はほぼなく、「実際には、今は心配しなくていい」とされています（詳細はGoogleのMatt Cuttsさんのyoutube動画を参照）。

このように、普通にサイトを制作する範囲内では最大数千個の発リンクを設定することは考えられませんので気にする必要性はほぼありませんが、上記動画でも触れられているようにGooglebotやインデックスの技術上問題がないからといって、むやみに発リンクを大量に設定すれば、スパムと認定されるようなリンクページと捉えられかねない点には注意が必要です（この「スパムと認定されるようなリンクページ」については「品質に関するガイドライン」の精読コラムにて後ほど記載したいと思います）。

この記述を簡単に説明するのは難しいのですが、皆さんと一緒に精読してみましょうという本コラムの目的に則り出来るだけ分かり易く簡潔に説明できるよう頑張ってみたいと思います（技術者の方々から見ると言葉足らずになっているかもしれませんがご容赦ください）。

皆さんもWebサイトのURLの冒頭が「http://」や「https://」となっていることに気づかれていらっしゃるのではないでしょうか。実は、これは「http」という通信プロトコル（ネットワーク上での通信に関する規約）を使用することを表しているのです。

例えば皆さんが当社のコーポレートサイトのトップページを見ようとして「https://tane-creative.co.jp/」といったリンクをクリックする（あるいはURLを直接入力する）とします。
この場合、httpプロトコルに従って当社のコーポレートサイトのトップページが格納されているサーバに対して「taneCREATIVEのトップページの情報を見たい」というHTTPリクエストが送られます。
このHTTPリクエストは「HTTPリクエストライン」「HTTPリクエストヘッダ」「HTTP リクエストメッセージボディ」の3パートから成り立っており、その「HTTPリクエストヘッダ」にはIf-Modified-Since（もし修正されていたら）というフィールドがあって、ここに日付を指定すると、サーバーは最後にリソースが変更された時刻が指定された時刻より後の場合にのみ、リクエストされたリソースを送り返します。

つまり、「Google が前回サイトをクロールした日付」を指定して、リクエストを送ると「後にコンテンツが変更されたかどうかがウェブサーバーから Google に通知され」、更新されていない時はブラウザキャッシュを利用して高速表示を行い、更新されたときだけコンテンツをダウンロードしに行くことで「帯域幅や負荷を軽減できる」ということですね。

こう考えるとWebサーバーがIf-Modified-Since HTTP ヘッダーに適切に対応していることは大変重要になるように思えるかと思いますし、表示速度が高速になることはSEO上価値がありますので実際に重要なのですが、この記事を読んでおられるWebサイトオーナーさんが利用されている今時のレンタルサーバーであれば通常はIf-Modified-Since HTTP ヘッダーに適切に対応していますので、この項目も基本的事項を念のために記載しただけで、それほど意識しなくても大丈夫だと思います。

robots.txtとは、サイトを巡回するクローラの動作をコントロールするために記述するテキストファイルのことで、例えばWebサイトのトップページからリンクで訪問できないXMLサイトマップのパスをクローラに伝える為に利用することもありますが、通常はWebサイト内の一定のファイルへの巡回を制限するために利用します。
具体的な例としては、Googleによれば「検索結果ページ」の他、「無限カレンダースクリプトをクロールさせないような場合」と記載されており、おそらくはJavaScript等で組まれたカレンダーで「次の月」のページに遷移すると無限にページが生成されるようなカレンダーページのことを指していると思いますが、こういった無限にページが生成できるサイトをクローラが巡回しに行くのはクローラに負荷をかけるためrobots.txtファイルによってクローラのクロールを制限してあげることが推奨されています。
冒頭の分類で言えば【Googlebotがページを検出しやすい環境を作り上げる】ためのルールに当たります。

なお、このrobots.txtファイルは、大規模なWebサイトの最適化についても重要な役割を有していますが、それは次のコラムである「「Google がページを理解できるよう手助けする」を精読してみる」（執筆が終わりましたらリンクを貼ります）にて解説したいと思います。

この部分は表示形式からもわかるように、サイトが Google に認識されるようにする方法という手段の面から上記の内容を補足説明している箇所になります。

繰り返しになりますが、クローラであるGooglebotが情報を取得しに行くメインルートは「Googleが既知のページからのリンクを辿るルート」であり、このルートを確立するために「必要なあらゆるサイトにあなたのサイトが公開されたことを通知」することをGoogleはオススメしています。
色々な外部サイトからリンクを貼ってもらいましょうということですね。

また、クローラであるGooglebotが情報を取得しに行くサブルートは「Googleに送信されたサイトマップファイルに記載されたURLに読みに行くルート」であり、このルートを確立するために「Google にページのクロールをリクエスト」する（XMLサイトマップを送信する）ことをGoogleはオススメしています。

当社では、ウェブマスターガイドラインの読み込みはディレクターとエンジニアであればほぼ必須事項とされていますが、それはホワイトハットSEOのチームを標榜していることと、当社代表が「言葉の定義と理解」について異常なほど気にしていることが原因であって、通常はそこまで読み込むことはしないと思います。

Webサイト制作は、単価が安く、日々時間に追われまくっている業界で、今やインフラとなったインターネットの仕組みも含めて完璧にそれらを理解できるわけはないのです（心の叫び！）。
しかもその仕組み時間の経過とともに変化していくものですし、テクノロジーが進化すればするほど我々制作会社も詳細を理解せずともそのテクノロジーを利用できるようになってきています。

私たちにできることは、せいぜい自分たちに可能な範囲において、せめてテクノロジーの本質だけは理解しようと努めることと、出来る限り自分の手で試してみるという地道なことだけなのではないかと日々自問しているのが現状です。

皆さんの利用されているWeb制作会社の担当者さんでも、「If-Modified-Since HTTP ヘッダー」を直ぐには説明できない可能性は十分あることをご理解いただき、やさしい目をもってWeb制作会社さんに接して頂けますと幸いです。