Google Indexing APIは公開予定のpilotを待たず更新URLの導線を整える

Google Indexing APIが発表されても、公開中のsiteの更新作業を止める必要はありません。Googleはreal-timeの情報を扱うpublisher向けに、夏の後半からpilotを始める予定だと案内しています。利用できる対象、申込み方、通常のsiteでの使い方はまだ決まっていません。今できるのは、更新したpageへ利用者とcrawlerが到達できる状態を整えることです。

新しいAPIは、公開の判断を代わりにしてくれません。何を公開するか、どのURLを代表にするか、古い情報をどう扱うか、利用者がどこから読めるかは、APIの前に決めることです。更新した情報が検索結果へ早く届くことを期待しても、公開page自体が分かれていれば、読者も管理する人も迷います。

GoogleのSearchに関する案内は、freshなevent情報を探す利用者とpublisherを結ぶため、contentをcrawlしてindexするまで待たずにindexingを促すGoogle Indexing APIを紹介しています。同時に、pilotの開始は夏の後半を予定している段階です。

APIの予定と今日の公開作業を分ける

新しい仕組みの発表を、すぐに使える運用手順と混同しないでください。pilotが始まる前に、誰が対象になるかも、どのURLへ使えるかも決められません。APIを使う前提で更新手順を組み替えると、現在必要な確認が後回しになります。pilotへ参加できるかどうかと、今日のpageを正しく公開できるかどうかは別の問題です。

たとえば、イベント告知を更新する場合でも、公開するURLが決まらないままAPIだけを待っても、知らせる対象がありません。古い告知を残すか、同じURLを更新するか、新しいURLを作るかを先に決めます。そのURLへsite内からlinkし、site mapにも代表URLを入れます。

公開予定日が近い情報ほど、URLの扱いを先に決めます。告知文を修正するたびに別のURLを作ると、どれが最新の案内か分かりません。一方、内容が別の催しや別の日程なら、同じURLを使い続けると古い案内を読んだ人が混乱します。URLを決める基準は、APIが通知できるかではなく、利用者がどの情報を読むべきかです。

更新URLを一つに決める

情報を急いで出すと、同じ内容が複数のURLに残りやすくなります。mobile用の別URL、印刷用page、古い告知、test pageが混ざると、どのURLを知らせるべきかが曖昧になります。更新のたびに、公開する代表URLを一つ決めてください。

1. 公開する内容と代表URLを決める。
2. page上の日時、本文、画像、link先を確認する。
3. 関連する一覧pageや上位pageから代表URLへlinkする。
4. XMLサイトマップに代表URLを含める。
5. browserで公開URLを開き、利用者が到達できるか確認する。
6. 更新日時、変更内容、確認者を記録する。

公開後に確認するのは、URLが開くことだけではありません。title、本文、公開日時、画像、関連linkが、更新した内容と一致しているかを見ます。イベント告知なら、日時、場所、参加条件、受付方法が古いまま残っていないかを確認します。掲載担当と内容の承認者が違う場合は、誰が最終確認をしたかも残します。

一覧pageから代表URLへlinkするときは、link文言も確認します。「お知らせ」のような一般的な文言だけでは、読者は何が更新されたか分かりません。イベント名、更新内容、日付など、一覧を読む人が選べる情報を出します。site mapはcrawlerへURLを伝えるための一覧ですが、利用者へ内容を説明する一覧の代わりではありません。二つの役割を混同しません。

この手順は、APIが使えるようになった後にも残ります。APIは更新内容の承認、URLの選択、pageの公開確認を代わりに行うものではありません。

indexされる時刻を約束しない

Google Indexing APIの発表は、すべてのpageが即時に検索結果へ出るという約束ではありません。Googleはpilotを予定していると案内している段階です。公開直後の問い合わせや参加受付が重要なpageでは、検索結果だけに頼らず、既存のメール、SNS、広告、既存顧客への案内など、事業で使える連絡手段を別に考えます。

検索から見つけてもらうことと、期限までに必ず知らせることも別です。たとえば、明日までの受付を知らせたい場合は、検索結果へ表示される時刻を前提にした案内だけでは足りません。すでに連絡できる人へ知らせる方法、siteのtop pageや一覧から案内する方法、問い合わせを受ける方法を合わせます。APIの有無で、期限のある連絡の責任を置き換えません。

更新を急ぐほど、test pageや下書きURLを外へ出さないことも確認します。公開する代表URLだけを、一覧、関連page、site mapへ入れます。公開しないURLが検索や共有で見つかると、利用者は古い内容や未確定の内容を読むことになります。更新日時と変更内容を記録しておけば、誤りを見つけたときにどのURLを直すかも分かります。

最初の一手は、次に更新するpageについて代表URLを一つ書き出し、そのURLが一覧pageとXMLサイトマップに入っているか確かめることです。新しい仕組みを待つ前に、公開情報そのものを迷わず確認できる状態にします。新しいAPIは、正しいURLと公開導線があって初めて検討できる道具です。