Search Consoleのproperty setは複数siteを足す前に比較する単位を決める

Search Consoleのproperty setへ複数siteを入れる前に、それらを一つの目的として見る理由を決めます。property setは、desktop site、mobile site、appなど、複数のpropertyを一つのgroupとして検索でのclickと表示回数を確認するための機能です。domainが同じ会社のものだからといって足し合わせると、どのsiteが検索で選ばれたかを見失います。

property setを作る目的は、管理画面のpropertyを片付けることではありません。検索から来る人を、複数の入口を含めて見たい場合に使います。数字を一つにまとめると、全体が増えたか減ったかは見やすくなります。その代わり、どのsite、どのpage、どの端末が変わったかは見えにくくなります。全体を見る画面と、原因を調べる画面を最初から分けます。

Googleの公式案内は、Search Consoleのproperty setで、siteとappを含む複数propertyをgroup化し、Google Searchでのclickとimpressionを一つのreportで確認できると説明しています。property setのreportは全体を見るためのものです。個別propertyの問題、URL構成、device別の表示を確認する作業まで置き換えるものではありません。

同じ検索目的を果たすpropertyだけをまとめる

property setへ入れる候補は、単に運営者が同じかではなく、検索した人に対して同じ事業上の目的を果たすかで選びます。siteの名前やdomainの末尾が似ていることは、まとめる理由になりません。読者が何を探し、どの行動へ進むかが近いかで判断します。

たとえば、会社案内siteとonline shopが別domainでも、同じ商品を調べる人へ同じ購入導線を出しているなら、全体の検索での見え方を確認する理由があります。一方で、company informationを探す人と商品を買う人では、必要なpageと成果が違います。全体の数字だけでは、どちらを直すべきか決められません。

desktop siteとmobile siteを分けている場合も、同じ内容を別の表示へ届けているのかを確認します。片方だけに商品情報があり、もう片方は問い合わせの案内だけなら、同じ目的を果たしているとは言い切れません。appを加えるときも、siteを読む人とappを使う人が同じ行動へ進むかを考えます。まとめる理由を一文で書けないpropertyは、個別に残します。

複数事業を持つ会社では、全体の数字が大きいsiteに、別事業の小さなsiteの変化が埋もれます。property setの数を少なくするためにまとめると、検索流入の増減を知っても、誰が対処するかが決まりません。事業、担当、成果の単位が違うなら、property setも分けます。

property setの数字と個別propertyの数字を分けて読む

property setは、全体のclickやimpressionが増えたかを見る入口になります。改善作業では、個別propertyへ戻り、URL、query、device、pageを確認します。全体が下がったという知らせと、どこを直すかという判断は、同じreportだけで済ませません。

1. まとめて見たい事業上の目的を一つ書く。
2. その目的へ関係するsite propertyとapp propertyを列挙する。
3. 各propertyのURL、主な検索意図、担当者、成果を記録する。
4. property setでは全体のclickとimpressionを確認する。
5. 変化があったときは、個別propertyへ戻り、どのsiteとpageが動いたか調べる。
6. propertyの追加と削除、目的の変更を記録する。

一つのproperty setで数字が増えても、問い合わせ、申込、購入のどれが増えたかは別に確認します。Search Consoleの検索dataと、site内のconversion dataを同じものとして扱わないことが必要です。全体reportを作る人と、各siteを直す人が違う場合は、propertyの担当を明らかにします。

たとえば、property setのclickが減ったときは、最初に個別propertyのclickとimpressionを見ます。特定のsiteだけが減ったのか、複数siteで同じ変化が起きているのかを分けます。次に、pageとqueryを見て、どの検索意図の入口が変わったかを調べます。そこまで分けなければ、全体の数字が下がったことだけを理由に、関係のないsiteのpageを直すことになります。

全体のreportを上層の確認に使い、個別propertyを実務の確認に使う方法もあります。その場合は、全体reportを見る人が、変化を見つけたあと誰へ渡すかを決めます。各siteの担当者は、受け取った変化を個別propertyで確認し、pageや内容を直す必要があるか判断します。数字を一つにすることは、責任を一つにすることではありません。

propertyを足す前に管理範囲を確かめる

property setへpropertyを追加するには、対象propertyを扱える状態である必要があります。外部の制作会社や広告運用者がSearch Consoleを管理している場合も、site側でどのaccountがどのpropertyを所有し、担当が変わったときにどう引き継ぐかを確認します。

ここで確認するのは、accountに入れるかどうかだけではありません。propertyの対象URL、どのsiteを表すpropertyか、所有を確認できる人、連絡を受ける人、個別propertyを残す理由を記録します。domainを管理する人とSearch Consoleを見る人が違うことはあります。それでも、担当が替わったときにpropertyを確認できなければ、検索の変化を追えなくなります。

property setの目的が変わった場合も、入れたpropertyをそのままにしません。会社siteへ採用siteを追加した後、採用の担当と成果が別になったなら、同じgroupで見る意味を見直します。propertyを追加した日、外した日、まとめる理由を残しておけば、数字の範囲が変わったときに以前のreportと取り違えにくくなります。

propertyをまとめる作業と、domainやappの所有を外部へ渡すことは別です。reportの都合でpropertyを追加する前に、対象URL、Search Consoleの権限、連絡先、個別propertyを残す理由を記録します。最初は比較したい目的が一つのpropertyだけでも構いません。複数の入口を一つに見なければ判断できないときに、property setを使います。