Webmaster Tools APIはクロールエラーの取得とサイト修正を分けて運用する
公開日： 執筆：佐藤
Webmaster Tools APIでクロールエラーを取得しても、サイトの問題は直りません。APIは、エラーの推移と例を集め、確認済みの項目を修正済みとして扱うために使います。DNS、server、robots.txt、リンク、redirect、サイトマップを直す作業は、サイト側で別に行います。
運用の順序は、エラーを分類し、具体的なURLを調べ、サイトを修正し、取得結果を確認し、最後に修正済みとする流れです。修正済みという表示を、修理そのものと混同しないでください。
APIで取得できる情報と修正作業を分ける
Webmaster Tools APIの更新に関する公式説明では、クロールエラーの時系列と、種類ごとのエラー例を取得できます。個々のクロールエラーを修正済みとする操作もできます。
同じAPIでは、サイトとサイトマップの一覧、サイトマップごとの警告数、エラー数、登録済みURL数も扱えます。しかし、取得した数字から原因が自動で確定するわけではありません。エラーの種類とURLを、server設定、サイト内リンク、redirect、サイトマップの内容へ照合します。
| APIで行うこと | サイト側で行うこと |
|---|---|
| エラーの推移を取得する | 発生開始日に行った変更を調べる |
| 種類ごとのエラー例を取得する | URLの応答とリンク元を確認する |
| サイトマップの警告とエラーを取得する | 送信したURLを修正する |
| エラーを修正済みとする | 原因を直し、再確認できる状態にする |
APIの取得結果は調査票の入口です。取得日時、site、エラーの種類、sample URL、担当者、確認結果を保存すると、同じURLを何度も最初から調べずに済みます。
Site ErrorsとURL Errorsで担当を分ける
Crawl Errorsの公式説明では、問題をSite ErrorsとURL Errorsへ分けています。
Site Errorsは、DNS、server connectivity、robots.txtの取得に関わる問題です。GooglebotがURLを要求する前の段階で止まるため、個別ページより先に確認します。DNS管理者、server管理者、サイト管理者の誰が調べるかを決め、発生期間と設定変更を照合します。
URL Errorsは、DNS、接続、robots.txtの段階を通過した後、個別URLの取得で起きる問題です。エラー例のURLを開くだけでなく、HTTPの応答、サイト内のリンク元、サイトマップへの記載、redirect先を確認します。
サイト全体の障害と一つのURLの問題では、優先順位も担当も違います。APIから同じ形式で取得しても、一つの修正手順へまとめないでください。
時系列は発生した日とサイト変更を照合する
クロールエラーの時系列は、増減した時点を見つけるために使います。エラーが増えた日付が分かったら、その前後に行ったURL変更、template変更、server移転、robots.txt変更、サイトマップ更新を調べます。
時系列だけでは、どのURLが原因か分かりません。種類ごとのエラー例を取り出し、一つのURLで応答とリンク元を確認します。一例で原因を決めず、同じ種類から複数の例を見て、共通する変更があるかを探します。
たとえば、削除したページへの古いサイト内リンクが残っているとします。これは説明用の仮例です。リンク先URLだけを修正済みとして一覧から外しても、古いリンクは残ります。リンク元を直すか、対応するページがあるなら適切なredirectを設定します。
修正済みはGoogleの処理を変えない
Webmaster Tools APIで個々のクロールエラーを修正済みとしても、それによってGoogleの処理は変わりません。修正済みは、確認した項目を一覧から整理するための操作です。
サイトの問題が残っていれば、Googlebotが再び取得したときにエラーが現れます。したがって、次の確認を終えてから修正済みとします。
- 対象URLの現在のHTTP応答を確認する
- 必要なサイト内リンクを直す
- redirectする場合は最終URLまで確認する
- サイトマップに不要なURLが残っていないか確認する
- 修正内容と確認日時を記録する
なくなったページをすべて別ページへredirectすればよいわけではありません。代わりになる内容がなければ、削除したページには404または410を返す公式案内に従い、存在しないことを応答で示します。エラー一覧をゼロにすることより、利用者と検索エンジンへ正しい状態を返すことを優先します。
APIの権限と修正責任を別に管理する
APIを動かす認証情報と、サイトを修正する権限は別です。クロールエラーを取得できる担当者が、DNSやserverを変更できるとは限りません。反対に、制作会社がサイトを直せても、Webmaster Toolsの所有権やAPIの認証情報まで預ける必要はありません。
運営側は、Webmaster Toolsの所有者、APIを動かす仕組み、取得結果の保存場所、サイト修正の担当者を記録します。制作会社を変更しても、エラー履歴と所有権を引き継げる形にしてください。
最初の一手は、APIから一種類のエラー例を取得し、sample URLを一つ選ぶことです。そのURLのHTTP応答とサイト内リンクを確認してから、自動化する範囲を広げます。
関連記事
