Search ConsoleのIndex Coverage reportはbeta画面を待たずURLの正本とsitemapを確認する
公開日： 執筆：佐藤
Search Consoleで新しいIndex Coverage reportが使えるかどうかと、siteのURLを整える仕事は別です。Googleは8月1日、新しいSearch Consoleの二つのbeta機能を一部の利用者へ順に提供すると案内しました。Index Coverage reportはindexed pageの数、indexされない理由、例となるpage、sitemapの送信を扱う予定です。しかし、beta画面が見えないからといって、URLの正本、sitemap、公開pageの確認を後回しにする理由にはなりません。
reportは、問題を見つけるための入口です。reportに何も出ていないことと、siteのURLが正しいことは同じではありません。まず、会社が公開したいpageを決め、そのpageが正しいURLで開き、menu、本文、sitemapが同じURLを指す状態を作ります。画面の提供時期に合わせて作業を始めるのではなく、Googleへ渡す前の情報をそろえます。
betaへ入れることとindexを確認できることを分ける
Googleが案内したIndex Coverage reportは、新しいSearch Consoleのbeta機能です。提供は少数の利用者から始まり、すべてのaccountで同じ時期に見えるものではありません。画面が見えないことをsiteの不具合と決めず、画面が見えたことをindexの保証とも考えません。
説明用の仮例として、会社案内、サービス紹介、問い合わせpageの三つを公開したsiteを考えます。担当者が新しいreportを開けない場合でも、三つのURLをbrowserで開き、page title、本文、link先、HTTP responseを確認できます。XML sitemapを使っているなら、そこに三つの正しいURLが載っているかも確認できます。reportは、この確認の代わりではありません。
反対に、reportにpageの数が出た場合でも、その中に古いURL、仮公開のpage、重複した内容が混ざっていないかは別に見ます。数を増やすことが目的ではなく、読者と検索engineへ残したいpageを決めることが目的です。indexされることと、公開を続けるべき内容であることを混同しません。
Search Consoleのaccountへ入れる人も確認します。制作会社だけが見られる状態では、問題を見つけたあとに会社側が何を確認し、どの修正を承認するかが分かりません。accountの権限を渡す作業と、sitemapやpageを直す作業は別です。会社側には、対象domain、主なURL、sitemapの場所、更新を頼む先を残します。
sitemapはURLの正本が決まってから送る
XML sitemapは、公開したいURLの一覧を渡すためのfileです。新しいreportにsitemap送信の入口があるとしても、fileの中身が古ければ、送信する場所だけ替えても意味がありません。まず、site内で使うURLをそろえます。
確認する順序は、次のようにすると混乱を減らせます。
- 公開を続けるpageと、公開しないpageを分ける。
- 同じ内容へ複数のURLがある場合は、読者へ案内するURLを一つ決める。
- menu、本文、canonical、sitemapで、そのURLを同じように使う。
- sitemapを送ったあとも、公開画面とreportを別に確認する。
たとえば、example.jp/service/とexample.jp/service/index.htmlが同じ説明を表示するとします。どちらを正本として案内するかを決めずにsitemapへ両方を入れると、情報を増やしただけで判断は残ります。先に正本URLを決め、menuや本文のlinkもそちらへそろえます。転送やcanonicalが必要かは、URLの使われ方とserverの状態を確認して別に決めます。
sitemapへURLを載せる人と、pageを公開する人が違う場合は、変更の連絡方法を決めます。新しいサービスpageを公開したのにsitemapへ入れない、削除したpageをsitemapに残す、といったずれは、どちらか一方の作業だけを見ていても気付きにくいからです。更新日、URL、公開か非公開か、確認した人を一行で残せば、次の更新で比較できます。
reportの理由は修正依頼へそのまま渡さない
Index Coverage reportは、indexされない理由をgroupごとに見せ、例となるpageや修正の手掛かりを示すことを目指しています。そこで表示された語を、そのまま制作会社への依頼文にしてはいけません。どのURLで起きているのか、読者へ残すpageなのか、表示とlinkはどうなっているのかを先に確かめます。
仮に、reportで複数のpageが一つの問題としてまとめられたとします。似たエラー名でも、あるpageは公開を続けるべきで、別のpageは古い資料かもしれません。全URLへ同じ修正を入れる前に、URLごとに「残す」「移す」「公開を終える」を決めます。reportの分類は調査の入口であり、事業の判断を代わりにするものではありません。
AMP fixing flowも同じです。GoogleはAMP issueを根本原因ごとに示し、修正後の確認と再取得の進行を扱う仕組みを案内しました。AMPを使っていないsiteまでAMPの修正を始める必要はありません。使っているpageで問題を見つけた場合だけ、通常pageの内容、AMP pageの内容、修正したmarkup、確認したURLを分けます。
画面上で修正の確認を始められても、実際のpageを読んだ人に必要な内容が残っているかは別です。errorを消すことだけを目的にすると、画像、見出し、link、問い合わせの導線を削ってしまうことがあります。技術的な修正と、読者へ渡す情報を残す仕事を、一つのチェックにまとめません。
画面が変わっても確認記録を会社側へ残す
Search Consoleの画面やreportは変わります。画面の名称や位置を覚えるだけでは、担当者が替わったときに作業を引き継げません。重要なのは、どのdomainを確認するのか、どのURLを正本とするのか、sitemapはどこにあるのか、問題が出たとき誰が判断するのかを会社側に残すことです。
制作会社へreportの確認を頼むなら、受け取る内容を決めます。問題の名称だけではなく、対象URL、見つけた日、公開を続けるか、直す内容、確認した画面を受け取ります。会社側は、その依頼と結果をURL一覧へ戻して確認します。分析を委託することと、公開するURLの決定まで任せきることは別です。
最初の一手は、公開したいpageを三つ選び、正本URL、site内のlink、sitemapを横に並べることです。三つがそろっていなければ、beta reportを待つ前に直す仕事があります。reportが使えるようになったら、その確認記録をもとに、例となるpageと理由を調べます。
関連記事
