Search ConsoleのIndex CoverageはURL数を追う前に修正するpageと原因を分ける

Search ConsoleのIndex Coverageでerrorやwarningを見つけたら、indexされたURLの数を増やす前に、そのURLを検索から読ませるべきか、何が原因か、誰が直すかを分けます。errorがあるURLをすべて復旧する必要はありません。削除したpage、公開してはいけないpage、代表URLではないpageまで同じように直すと、siteの入口が増えて管理できなくなります。

Googleは1月8日、新しいSearch ConsoleでSearch Performance、Index Coverage、AMP status、Job posting reportを提供すると案内しました。Index Coverageでは、indexされたURL、warning、indexされない理由を確認できます。issueを開くとsample URLと診断toolへのlinkが出て、修正後にはvalidate fixを選べます。reportは修正の順序を決める入口であり、URLを一括で公開する命令ではありません。 Google Search Central Blog

errorの名前よりURLの役割を先に見る

同じerrorでも、URLの役割が違えば対応は変わります。古い商品pageが消えたなら、代わりの商品へ案内するか、終了した内容として残さないかを決めます。test pageや管理用pageなら、indexされないことが意図どおりの場合があります。問い合わせpageや主なservice pageが開けないなら、読者が必要な情報へ進めないため優先して調べます。

最初にsample URLを一件開き、browserで読む画面とreportの理由を比べます。本文が表示されないのか、URLが移ったのか、robotsの指定があるのか、sitemapだけに古いURLが残っているのかを分けます。error名だけで設定を替えると、必要なURLまで止めることがあります。

sitemapは修正対象を絞るために使う

Googleは、sitemapを送るとIndex Coverageでその一覧に絞って確認できると案内しています。sitemapはURL数を多く見せるためのfileではありません。検索へ出したい正本URLを渡し、そのURLが正しく処理されているかを見るために使います。

たとえば、記事のURLを変更して古いURLをsitemapへ残している場合を考えます。reportでindexされない理由を見ても、古いURLを直すべきなのか、sitemapから外すべきなのかを先に決めなければなりません。新しいURLが本文、内部link、canonical、sitemapでそろっているなら、古いURLを増やすより代表URLの確認を優先します。

制作会社へ修正を依頼する場合は、reportの画像だけを渡しません。対象URL、URLの役割、残すか消すか、正本URL、公開後に確認する人を伝えます。制作側はserver、template、sitemap、redirectなどを調べられます。事業者側は、そのpageを検索から読ませる理由と内容の正しさを決めます。

同じ理由のURLをまとめて直す前に一件で確かめる

reportに同じ理由のURLが並んでいても、いきなり一括で設定を替えません。sample URLを開き、そのURLへ至る内部linkをたどり、公開画面の内容とserverが返す状態を確かめます。一件で原因を説明できれば、同じ作りのURLをどこまで調べるか決めやすくなります。説明できないまま一括でredirectやrobotsを替えると、別の目的で残しているpageまで同じ扱いになります。

たとえば、sitemapに入っているURLだけが問題なら、まずsitemapを作る場所と更新の手順を確認します。本文のlinkが古いURLを指しているなら、sitemapだけを直しても読者とGooglebotは古い入口へ進みます。canonicalの指定が代表URLと違うなら、URLを増やす前に本文のlink、canonical、sitemapの三つを同じURLへそろえる必要があります。原因ごとに触る場所が違うため、reportの理由と修正するfileを一対一で考えます。

確認した一件は、URL、reportの理由、公開画面で見た状態、変更する場所を短く残します。この記録があれば、次のURLで同じ作業を繰り返すべきか、別の原因として扱うべきかを判断できます。修正を急ぐときほど、問題の名前ではなく、どの入口が読者をどこへ連れていくかを確かめます。

validate fixの前に直した範囲を記録する

Googleは、issueを修正した後にvalidate fixを選ぶと、対象URLを再crawl、再処理すると説明しています。validationを始める前に、何を直したかを残します。URLを移したのか、本文を戻したのか、sitemapを直したのか、robotsを変更したのかで、公開後に見る場所が違うからです。

急ぐerrorでも、複数の設定を一度に替える前に、対象URLと変更内容を一行で記録します。修正後は、公開page、status、内部link、sitemapの順に確認します。reportが更新されるまで待つ間も、読者がbrowserで正しいpageへ進めるかは確認できます。

最初の一手は、Index Coverageのissueからsample URLを一件選び、「このURLは検索から読むべきpageか」と決めることです。必要なpageなら原因を調べ、不要なpageなら正本URLを混ぜないようにします。Index CoverageはURLの数を競うreportではありません。読者が必要なpageへ進める入口を、理由を持って保つためのreportです。