Search Consoleの共有linkはaccountの権限を渡さず修正対象を伝えるために使う

Search Consoleで見つけた問題を制作会社へ渡すときは、account全体の権限を先に渡すのではなく、どのreportの、どのissueを、どのURLについて直してほしいかを伝えます。reportの共有linkは、修正対象を同じ画面で確認するために使います。siteの所有者、設定変更をする人、公開内容を決める人を同じにする仕組みではありません。

Googleは1月8日、新しいSearch Consoleのreportで共有linkを作り、解決後には共有を止められると案内しました。Index Coverageなどで見つかったissueを、関係する人へ見せるための機能です。画面を見せることと、siteの設定を変更できる権限を渡すことは別に考えます。 Google Search Central Blog

共有linkで渡すものとaccountの権限で渡すものを分ける

共有linkで渡すのは、あるreportに表示された状態です。たとえばIndex Coverageで特定の理由に分類されたURL、sample URL、validationの進み方を、制作側と同じ画面で確認できます。画像をメールへ貼るよりも、対象となるissueを取り違えにくくなります。

一方、accountの権限を渡すと、reportを見る範囲だけでなく、siteの情報を継続して扱える状態になります。誰へ、どこまで、いつまで渡すかは、修正依頼とは別に決めます。短い調査だけを頼む相手へ、必要以上の情報を残す理由はありません。共有linkで足りるなら、まずそれを使い、作業に本当に必要な権限だけをあとから検討します。

ここで混同しやすいのは、共有した相手が問題を直せることと、問題の意味を一緒に確認できることです。reportを読むだけではserverの設定やtemplateを直せません。反対に、制作側が作業できても、そのURLを検索から読ませるべきか、古い内容として終えるべきかは、事業者側が決める必要があります。画面の共有は判断材料をそろえる手段であって、公開の責任を引き渡す手段ではありません。

reportだけでなくURLの扱いを一緒に渡す

共有linkを送る前に、対象URLの扱いを短く書きます。必要なのは、URLを残すか、別のpageへ移すか、検索から読ませないかです。reportにerrorと出ていても、終了したservice pageやtest pageなら、元へ戻すことが正解とは限りません。主なservice pageや問い合わせにつながるpageなら、読者が必要な情報へ進めるかを先に確認します。

たとえば、古いURLがsitemapに残り、Index Coverageで問題になっている場合を考えます。制作側へは、古いURLを残さない判断なのか、新しいURLへ案内する判断なのかを渡します。そのうえで、sitemap、本文の内部link、canonical、redirectのどこを確認するかを相談します。reportの理由だけを渡すと、URLを増やす修正と、不要なURLを整理する修正を区別できません。

依頼文は長くする必要はありません。「このURLは終了したpageなので、必要な移動先があるかを確認したい」「このURLは問い合わせの入口なので、browserで開ける状態へ戻したい」のように、URLの役割と期待する状態を一文で示します。続けて共有linkを渡せば、制作側はissueのsample URLや診断画面を見ながら、調べる場所を絞れます。

修正する人と確認する人を先に決める

Search Consoleのissueは、同じ人がすべて直すとは限りません。serverの応答、template、robotsの指定、sitemapの生成場所は制作側が調べます。URLを残すか、文章が正しいか、古い案内を消してよいかは、siteを運用する側が決めます。役割を決めずにreportだけを転送すると、相手は原因を探せても、どこまで直してよいかを判断できません。

修正後に確認する人も、依頼時に決めます。制作側は変更したURLと変更場所を伝え、事業者側は公開画面と問い合わせへの導線を開きます。その後、Search Consoleでissueを選び、必要ならvalidate fixを始めます。Googleはvalidationで対象URLを再crawl、再処理すると説明していますが、reportの更新を待つ間にも、読者が正しいURLへ進めるかは確認できます。

継続してreportを見ながら複数のissueを直す仕事では、共有linkだけで済まないことがあります。その場合も、最初に渡した共有linkを根拠に、必要な作業と必要な期間を確認します。たとえば毎月の確認まで頼むのか、一つの移転作業だけを頼むのかで、相手が見るべき範囲は変わります。権限を渡す判断を急がず、作業の終わりと確認者を決めてから扱えば、依頼が終わった後に見直す場所も明確になります。

共有linkは、修正が終わったら止めます。調査のために開いた共有を残し続ける必要はありません。誰がどのissueを確認したか、何を変更したか、公開画面を誰が見たかだけを手元に残せば、次の問題が出たときも同じ順序で判断できます。

最初に送るべきなのは、accountの情報でも、errorの画像だけでもありません。URLの役割、直したい状態、確認したいreportです。この三つを分けて共有すれば、制作側は必要な場所を調べられ、事業者側は公開の判断を手放さずに済みます。