Search Consoleのproperty setsは見るreportを決めてからsiteを足す

Search Consoleのproperty setsは、見るreportを決めてからsiteを足します。複数のsiteやappをまとめれば、全体が期待どおりに動いているか、どこに外れ値があるかを追えます。ただし、setの合計は原因を示しません。異常を見つけたら、必ず個別propertyへ戻ります。

Googleは12月、verified propertyをproperty setへ加え、mobile usability、AMP、rich cards、hreflangの確認にも使えるようにしたと案内しました。これは、複数のpropertyを同じ問題として扱う機能ではありません。比較の入口を一つにする機能です。

propertyをまとめる目的は、reportの数を減らすことではありません。たとえばHTTPS移行では、HTTPとHTTPSを別々に開くだけでは、移行全体で何が変わったかを追いにくいことがあります。setで全体を見ると、どのpropertyを次に開くべきかを選びやすくなります。一方で、URLのエラーやAMP markupの問題を直すときは、setの合計ではなく、そのpageを持つpropertyへ戻ります。

同じ運用者が管理しているpropertyでも、比較する理由がなければ一つのsetへ入れません。たとえば会社siteと採用siteは同じbrandでも、読者、問い合わせ、直す担当が違う場合があります。数字が同時に動いたとしても、同じ原因とは限りません。setを作る前に、何を同じ期間、同じreportで見たいのかを一文にします。

property setで見る変化と個別propertyで調べる原因を分ける

property setで先に見るのは、複数のsiteにまたがる変化です。個別propertyで見るのは、修正する場所です。この二つを混ぜると、数字は見えても次の作業が決まりません。

説明用の仮例として、HTTP siteとHTTPS siteを移行期間だけ同じproperty setへ入れる場合を考えます。setで全体の変化を追えば、移行の前後を一つの流れとして見られます。しかし、mobile usabilityの問題が出たときに、HTTPとHTTPSのどちらが原因かは分かりません。setで変化を見つけ、個別propertyでURL、reportの内容、実装の変更箇所を確かめます。

この仮例でHTTPSのpropertyだけに問題が見えたら、すぐにHTTP側の設定を替えません。まずHTTPS propertyを開き、問題が出たURL、発生した期間、直前に替えたtemplateやredirectを確認します。HTTPとHTTPSで同じpageを見ているつもりでも、canonical URL、resourceの読み込み、mobile用の出力が違う場合があります。全体の変化を見た場所と、実装を直す場所を分けます。

国別siteをまとめる場合も同じです。全体としてmobile usabilityの問題が増えたように見えても、一つの国のthemeだけを直した結果かもしれません。言語、URLの構成、担当者、公開時期が違うpropertyを同じ原因として扱うと、関係のないsiteまで変更することになります。setで見つけた外れ値は、国別propertyで期間とURLを確認してから対応します。

まとめる前に比較する範囲を紙に書く

propertyを追加するときは、URLの近さではなく、同じ判断に使うかどうかで決めます。国別site、brand別site、mobile site、appをまとめる場合でも、比較する目的が違えば別のsetにします。

この表に、見るreport、確認する期間、異常が出たときに確認する人も並べます。たとえばAMPの確認なら、setで変化を見た後に、AMPを実装したpropertyと担当者へ戻る流れを決めます。数字を共有する相手と、修正を依頼する相手は同じとは限りません。

propertyを追加する前に、ownerを確認します。setへ入れられるpropertyでも、修正を依頼できる人や公開判断をする人が分からなければ、問題を見つけても作業が止まります。数字を読むための権限と、theme、markup、server設定を変更する権限は別です。誰がreportを見て、誰がURLを調べ、誰が変更を承認するかを残します。

setの名前も、何を比べるためのものか分かるようにします。「Search Consoleまとめ」のような名前では、HTTP/HTTPSの移行を見るのか、国別siteを見るのか、appを含めるのか分かりません。目的と対象を短く含めれば、後から追加するpropertyが同じ判断に使えるかを確認できます。名前は便利な分類のためでなく、比較条件を忘れないための記録です。

外れ値を見つけた後の確認順を決める

setに入れたpropertyの一つだけが悪化して見えたら、まずそのpropertyを単独で開きます。次に、同じ期間のreportを確認し、対象となるpageやmarkupを絞ります。ここで初めて、実装を変えた日、作業した人、再確認する日を記録します。

最初からsetの合計だけで結論を出すと、問題のないsiteまで修正対象にしてしまいます。反対に、個別propertyだけを見続けると、複数siteに共通する変化を見逃します。全体を見る場面と、原因を確かめる場面を分けることがproperty setsの使い方です。

外れ値を確認するときは、問題の数だけで優先順位を決めません。問い合わせや購入につながる重要なpageで問題が出ているのか、更新したばかりの一部pageに限られるのか、複数propertyに同じ種類の問題があるのかを見ます。影響が大きいpropertyから確認し、必要なら共通templateや共通のserver設定を調べます。setの数字を使っても、修正する単位はURL、template、propertyごとです。

修正後は、最初に問題が見えた個別propertyを再確認します。set全体の表示が変わらなくても、対象URLの問題が解消している場合があります。反対に、一propertyを直しても別のpropertyに同じ問題が残ることがあります。setへ戻る確認と、個別propertyでの再確認を一組にすれば、全体の傾向と修正結果を混同せずに済みます。

所有確認できる範囲や管理者が曖昧なpropertyは、急いでsetへ入れません。数字を見られることと、修正を決められることは別です。追加前に、誰が確認し、誰が実装を直し、誰が結果を受け取るかを決めておくと、reportが増えても作業が止まりません。

外部のSEO担当や制作会社へ確認を頼む場合は、setの画面だけを共有して終わらせません。対象のproperty、見るreport、比較する期間、問題が出たときに開くURL、修正できる人を渡します。集計を見せる仕事と、site側の内容やmarkupを直す仕事は別です。数字をまとめる機能を使っても、siteの所有と更新責任まで一つになるわけではありません。

最初の一手は、property setで見たいreportを一つ選び、異常が出たときに戻るpropertyと確認順を決めることです。