がとらぼ

INTAA.NET

新年度からウェブサイトの管理担当者に就任された方はそろそろGoogle Search Consoleには慣れましたでしょうか？
または、個人でブログなどを始められたばかりの方でおっかなびっくりでSearch Consoleに挑もうとしている方もいるかと思います。
今回は初心者のための何をどうするかのメモ。

既に自分のウェブサイト側でサイトマップを出力するようにしているとします。サイトマップは検索エンジンなどに見せる用の「お品書き」のようなものです。人間の閲覧者向けのサイトマップとは違うので勘違い無く。
まずは「うちのウェブサイトのサイトマップはここにありますよ」というのをサーチコンソールに伝えなければなりません。
左列のメニューから「サイトマップ」をクリックする。
「新しいサイトマップの追加」に自分のウェブサイトのサイトマップのURLを記入する。 「送信」を押す。
このサイトマップの追加及び送信は過去に行っている場合は不要。一度登録すると後は自動的に繰り返し取得されます。
Search Consoleでは基本的にユーザーが何かを行って、Googleがリクエストを処理して、その結果が出るまで数時間〜1ヶ月ほどかかることがあります。「サイトマッブの送信」は比較的速く処理されますが、それでもボタンを押してすぐではありません。 数日後に(上の画像の赤の破線部分を)確認してみて、ステータスが「成功しました」になっていればOK。過去にサイトマップを送信した場合は、「送信」と「最終読み込み日時」も確認する。特に、「最終読み込み日時」は少なくとも数日以内であること。これが1ヶ月以上も前だと最近にサイトマップが取得されていないということなので何かがおかしいと判断するべき。
上の画像ではサイトマップが2つ登録されているが、これはかなり以前の非HTTPs時代に登録されたのとHTTPs化してからのが両方表示されているから。

サイトマップを送信したらすぐにクローラーがサイトを巡回してインデックスに登録してくれるわけではない。数日〜1ヶ月ほど放置してからインデックス化の状態を確認する。

左列で「カバレッジ」をクリックする。
右列の「ステータスの種類」は最初は「エラー」だけが選択された状態になっている。エラーがゼロ件だと下部の「詳細」(上の画像の破線の四角部分)は表示無し。何かエラーがあると詳細にも表示されるが、普通はカバレッジでエラーというのは無い筈。
「ステータスの種類」は他に「有効(警告有り)」「有効」「除外」がある。新米ウェブサイトの管理者としてはこの3つが気になる部分の筈。(次へ)

「有効(警告有り)」「有効」をクリックして表示対象にし、逆に「エラー」は非表示対象にした。
普通にいう「インデックス化」(検索エンジンに登録された状態になる)は下部の「詳細」(上の画像の破線の四角部分)の「有効」且つ「送信して登録されました」の行。この行の右端のページ数が自分のウェブサイトの公開済の記事数と等しいのが理想。なお、理想的な状態でも若干はブレることがある。
「インデックス登録されましたが、サイトマップに送信されていません」は日本語的には意味不明だが、要するに「サイトマップに載ってなかったけど勝手にインデックス登録しました」ということ。これは余計なお世話。記事一覧とかジャンル別一覧とかその類が登録されてたりする。重複コンテンツに繋がる可能性があるのであまり望ましくはないが必死で無くさなければならないというほどでもない。
ステータスが「警告」で「robots.txtによりブロックされましたが、インデックスに登録しました」はこれは書かれている通り。robots.txtは自分のウェブサイトでインデックスして欲しくない(またはその逆の)URL,ディレクトリなどを書くもの。本来は検索エンジンはrobots.txtに書かれた「希望」を汲んでインデックス化するのが筋だが、これは義務ではない。その結果「インデックスするなという希望は無視して、勝手にインデックスしたよ」というのがこれ。これはウェブサイトの管理者としては「フザケンナ」っていう感じ。

ステータスの種類の「除外」だけを表示対象にした。
「がとらぼ」では今年に入ってからWordPressの新しいテーマを作ってそれを適用したりその他諸々の内部的な変更を行ったのだが、その過程で「カバレッジ」の「除外」を確認するのをサボってたので大量に溜まっている。この多くはURLを確認してrobots.txtでdisallowの対象にすると解消する筈。

この数年はPCよりむしろモバイルで閲覧する方が多いのかしら。ウェブサイトは画面の狭いモバイル端末で適切に表示されることが求められるようになっている。Search Consoleでもモバイル端末で適切な表示ができないページがあると通知してくるほど。しかも判定が厳しい。
左列で「モバイルユーザビリティ」をクリックする。
ページ数が多いウェブサイトだとエラーが数件あるのはあたりまえ。自分のウェブサイトのページに問題があるのであれば「なるはや」で改善しなければならない。
ただし、2018年頃から頻発する「テキストが小さすぎて読めません」や「クリック可能な要素同士が近すぎます」はクローラーがスタイルシート(CSS)のファイルを読むのに失敗した場合に起こるエラー。ネットワークがとんでもなく遅いとか不安定でCSSファイルを取得できなかったなら納得もできるのだが、何の問題がなくても発生する。不調なgooglebotが混じってるだけじゃないのかしら？ これら以外にもときどき一時的にエラーとして報告されるものがあるが、Google側の問題であれば暫くすると(Google側で不具合が解決されると)エラーではなくなるみたい。

1つ前の画像の「詳細」のリストの「クリック可能な要素同士が近すぎます」をクリックした状態。
その問題があるとされるページのURL一覧が表示される。URL一覧の各行はクリックすると状態の詳細が表示されるか、または情報がないか。これは次で。
報告されている問題が自分のサイト側に原因があって、それが報告されているURL一覧の全てで解決完了したら「修正を検証」ボタンを押す。再検証を受け付けたというメール通知がGoogleから来る。これも再検証を受け付けてすぐにGoogleがやってくれるものではない。1日〜1ヶ月ほど待たされるので気長に待つ。再検証が始まったときと検証が終わったときに再びメールで通知される。
「修正を検証」ボタンは1度押すと新たに同内容のエラーが発生するまで暫く押せなくなるので修正が完了するまでは迂闊に押さない方が良い。(ただし、ボタンを押したときに即時の簡易検証が実行されて、これが通らないと再検証には移行しない)

エラーのURL一覧から1つをクリックした状態。ここでは「ライブページをテスト」が表示されている。ボタンを押すと。Googleが取得したキャッシュではなく、リアルタイムで自分のサイトのそのページに対して「モバイルフレンドリーテスト」が実行される。全てのURLでライブページでエラーが発生しなくなるようにするのがウェブサイト管理者の仕事。ただし、前述のようにGoogleの判定がおかしいこともあるので全てをウェブサイト管理者が修正できるわけではない。

この画像の例では「モバイルフレンドリーテスト」は一応合格している。つまり致命的に悪い部分は無い。ただし、「ページの読み込みに関する問題」という警告が表示されている。これは内容の確認をした方が良い。
上の画像の赤い枠の部分をクリックする。

上の例では「ページが部分的に読み込まれました」という警告が幾つか。日本語的には「ページを構成する要素の一部が読めませんでした」の方が良い？
で、下部の詳細を見ると「ステータス」の部分に「Googlebotがrobots.txtによってブロックされています」になっているが、これは本来はページの表示には関係ない部分の筈。というか、インデックス用のクローラーはrobots.txtを無視してインデックスするのにインデックス化に関係ないモバイルフリンドリーテストのクローラーがrobots.txtの意向を重視するの何で？
しかも、上の画像の例ではそのrobots.txtのリンクを見るとdoubleclock.net(Adsenseの広告のホスト)のrobots.txtなので、相当意味がわからない。 この場合は自分のサイトに問題があるわけではないので放置でOKというかそうするしかない。

この2年ほどはAMPも重要になってきている。AMP対応したページを用意しておくと、Googleのクローラーがそのページを検証して、AMPページとして合格ならGoogleのAMPキャッシュに登録してくれる。モバイルでググったときに検索結果の上位にイナズママーク付きの検索結果が表示されるのがそれ。AMPキャッシュはGoogleのサーバにあって閲覧者にはそれが表示されるので高速。AMP対応は全部手書きコードでやってるようなところは大変だろうが、例えばWordPressでは通常のページをAMPページに変換して出力するプラグインなどがあるので比較的簡単に対応できる。(といっても難しい部分がないわけではない)
WordPressの管理者で勘違いしている人がいるようだが、WordPressでAMPのページを表示するのは必ずしも高速なわけではない。通常のページを表示する処理に加えてAMP用のタグに変換したりするので常識で考えれば当然。ただしAMP用には簡素なテーマ(テンプレート)を使うだとか、キャッシュを利用するだとかの条件で変わってくる。
Search ConsoleではAMPエラーの発生の有無をよく見ておくのが良い。(AMP対応しないなら関係ないが)
左列で「AMP」をクリックする。
ステータスの種類で「エラー」があるのは望ましくない。AMPの場合は「エラー」はそのページがAMPキャッシュされないことを意味するので重大な問題となる。また、AMP以外と同じく、問題に対処してもすぐにGoogleが検証してくれるわけではないので数日から1ヶ月程度かかる。その間はAMPキャッシュされない。 WordPressでは簡単にAMP対応できるようでいてそうではないので、中にはAMP対応したつもりだったが全てエラーになっていたということもあるみたい。これではAMP対応になっていない。(大抵は「ブラウザで表示できれば良い」ではないということが解っていない)
上の画像の例では2018年末から1月下旬にかけてAMPのエラーが解消していったが、1月末頃にWordPressの新規テーマ作成でAMP用のテンプレートも新規でフルスクラッチしたら、その過程で大量にAMPエラーになってしまった。それが再検証でエラーが0件になったのが1ヶ月後の3月初旬。3月中旬に再びエラーがドカッと発生しているが、これはGoogle側の問題だったようで、数日で解消している。

• Googleはすぐに実行してくれない
• Googleは意外と頻繁に間違う
• メッセージの意味を理解する
• 問題を切り分ける
• 自分のサイト側の問題は「なるはや」で解決する
• AMPも頑張ろう