貴サイトの上位検索クエリの変化(゚∀゚)キタコレ!!

以前に下記記事でSearch Consoleで「上位に急上昇した検索クエリー」の通知メールの内容を書きましたが、それと似ような感じで「上位検索クエリーの変化」という内容の通知メールが届きました。たぶん初めて見た気がします(´ヘ`;)ウーム…

今回届いた「貴サイトの上位検索クエリの変化」の内容は下記になります。

貴サイトの上位検索クエリの変化

●●● の所有者様
最近、貴サイトへのアクセスに結び付く Google 検索の上位検索クエリに変化が生じたことが、Search Console により検知されました。この変化を把握しておくことは、サイトの所有者の方にとって有用と考えられます。

貴サイトの上位検索クエリの 2020/05/04から 2020/05/10の週におけるパフォーマンスを以下に示します。

クエリ: ●●●
貴サイトの検索クエリ中 1 位
43,115 回表示
サイトの総表示回数の 22.51%(これまでの週の more than0.113%)
クエリ: ●●●
貴サイトの検索クエリ中 2 位
18,662 回表示
サイトの総表示回数の 9.74%(これまでの週の more than0.084%)

下記のリンクから、検索における貴サイトのパフォーマンスをより詳しく確認できます。

とのことです。
リンク先を飛ぶと Search Console のレポートで確認できるようです。

「上位に急上昇した検索クエリー」と「上位検索クエリーの変化」の違い

「上位に急上昇した検索クエリー」は元々検索結果に表示されていなかった、または表示されていたけど殆どクリックされていなかったものが、急激にクリックされるようになった事を知らせる通知。

「上位検索クエリーの変化」は、元々上位に表示されていたクエリーに変化があったことを知らせる通知。
変化というのがミソっぽくて、恐らく上昇時、下降時にも通知が来るんじゃないかな~と予想。
確かに既に上位クエリーだったものが、上がった場合、下がった場合どちらであろうと変化がある場合には気になりますよね(゚д゚)(。_。)(゚д゚)(。_。) ウンウン

Google さんъ(゚Д゚)グッジョブ!!

今回は上昇だったので特に何もする必要もないかもしれませんが、もし下降だった場合の通知だったらどう対処するべきなんですかね?ぐっぐるさん(/ω・\)チラッ

前々から気になったけど、貴サイトって呼ばれるのってめっちゃ違和感があるw
あまりこの単語を聞いたことないせいかもしれないけど・・・一般的には良く利用される単語なのかな?
やば、引き込まりニートがバレちゃう(; ・`д・´)

そろそろ今回のコアアップデートの影響も落ち着いてきた感じ。
アクセスが増えたせいなのかアプリ版Google Analyticsのレポートでサイトによって8時間ぐらいの遅延が発生している(´;ω;`)ウッ…

Search Console上でのAMPのパフォーマンス情報が減る?|д゚)チラッ

Search Console の 拡張の項目にある AMP をみたらお知らせマークみたいがのあって確認してみたら下記のような内容でした(´ヘ`;)ウーム…

Google 検索の更新情報Google 検索で、サイトのデータに影響を与える可能性のあるイベントが発生しました。詳細を見る4月12日(日)

詳細を見るのリンク先では次のような内容が書かれていました。

2020年4月12日以降
AMP、モバイルユーザビリティ、速度、すべてのリッチリザルトレポート
これらのレポートは、Search Consoleでのパフォーマンスを向上させるために、少数のページをカバーするように変更されました。このため、これらのレポートで追跡されるアイテムとページの数が減少する場合があります。この変更は検索結果には影響せず、Search Consoleのデータレポートにのみ影響します。

AMPレポートの精度を上げるために、少数のページだけをレポートに出すっていう事かな?(´ヘ`;)ウーム…

念のために各レポートの推移を見てみるけど特にそこまで変更なかった( ´∀`)bグッ!

ただ恐らく別問題だとは思うけど、 画像検索結果の AMP と、画像検索AMPストーリーの表示回数とかが激減してたw
何か仕様でも変わったのか・・・?(´;ω;`)ブワッ

AMPインデックス数

パフォーマンスレポートのウェブ AMP 通常の検索結果

パフォーマンスレポート のウェブ AMP 記事

パフォーマンスレポート のウェブ AMP: ストーリー

パフォーマンスレポートの画像 画像検索結果の AMP

パフォーマンスレポートの画像 AMP ストーリー

Google 検索で上位に急上昇(゚∀゚)キタコレ!!

Search Consoleから最近は色々な通知が来るようになってるような・・・?

そのうちの1つに下記があるようです。自分は初めて受信した気がします。

貴サイトのページの 1 つが ●●● の Google 検索で上位に急上昇しています

という通知メールが届くようになっているというお話。

メール本文の内容だけ見ると1,000%超増加って書かれていてパネェってなりますが、1日平均1回未満からってのが味噌ですなw

1 日の平均クリック数
(20.11.19 – 22.11.19)貴ページのクリック数が、通常の 1 日平均クリック数の 1 回未満から 1,000% 超増加しました。

通知メールはこんな感じ。

通知メールからのリンク先のSearch Consoleの検索パフォーマンスはこんな感じでした(´・∀・`)ヘー

モバイルファーストインデックスキタ━━━━(゚∀゚)━━━━!!

やっと9月ぐらいから各サイトの方でモバイルファーストインデックスに切り替わったようです(; ・`д・´)

もう最近は話題にするならなっていないようなw

その影響かサイトによってはSearch Consoleにあるカバレッジのレポートでインデックスに登録された件数が急激に伸びていました。その結果なのかわかりませんが流入が普段の2倍ぐらいに上がってる感じです。まぁそれ以外の要因かもしれませんが・・・。

今までサイトマップをいい加減にやっていたのであまり正しく認識されていなかったものがモバイルファーストインデックスに切り替わった事で正しく認識されるようになったということですかね?(´ヘ`;)ウーム…

ページ構成は動的配信によってPCサイトとモバイルサイトを切り替えているサイト構成だったんですけどね。

切り替わるとSearch Consoleのカバレッジを開くと下記のような通知が表示されるようです。

またカバレッジのレポートを見ると、グラフの下に重要な変更などがあったときにアイコンが表示されていてそこに携帯のアイコンっぽいのが出ているとモバイルファーストインデックスに切り替わったタイミングを表しているようです。

下の画像のようにカバレッジと検索パフォーマンスを比較するとカバレッジの有効なページが増えて行くのに比例して同じように流入が増えているようにも見えなくない感じ(・д・)ジーッ

とりあえず極端に下がったサイトは無かったので良かった良かった!( ´∀`)bグッ!

モバイルファーストインデックスヽ(´ー`)ノマンセー

Search Consoleで構造化データのパンくずリストが表示される

Search Consoleでパンくずリストがどのくらい認識されているのか、errorになっているのかがいつのまにか表示されるようになってた(; ・`д・´)

パンくずのマークアップに失敗しているというエラーがさっき届いて気づいたホジホジ(´σ_` ) ポイ( ´_ゝ`)σ ⌒゜

Search Console上では左のメニューにパンくずリストというのが追加されていました(´・∀・`)ヘー

エラーだれか直しておいて・・・orz

そういえばいまだにモバイルファーストインデックスに移行できていないサイトがある・・・(; ・`д・´)

Google先生切り替えマダァ?(・∀・ )っ/凵⌒☆チンチン

画像検索のSwipe to Visit 機能からの検索トラフィックのフィルタリング

Search Consoleの検索パフォーマンスで画像検索の項目に「 画像検索結果の AMP 」という項目が追加されたらしいです(´・∀・`)ヘー

これはGoogleの画像検索時に出てくる「Swipe to Visit」で表示されないレポートとのことです。

そもそもSwipe to Visitが何かっていう方は下記を参照してください。簡単に説明してしまうと、画像検索時に画像詳細を開いたときにソース元のサイトに遷移しなくても下部にあるボトムシートみたいなのをタップ、またはスライドアップするとソース元のサイトが表示されるというものらしいです。(AMP対応したページのみが対象)

実際にソース元のサイトに遷移しないのでユーザーはソース元を確認できるのでユーザビリティーは向上するけど、サイト運営者としてはトラフィックが減る?可能性を懸念するかもですね(´ヘ`;)ウーム…

ただ、自分のサイトで確認したところだと、ソース元のページがそのまま表示されるようなのでAMP用の広告などを利用している場合にはそのまま表示されていました。

ありがとうGoogle先生!!!ъ(゚Д゚)グッジョブ!!

ちなみにレポートではこんな感じで表示されていました。8月17日から計測されているようです。

8月24日のレポートを見てみると、
1日の合計クリック数が約12,336で「画像検索結果のAMP」のクリック数が5,298なので約43%が「画像検索結果のAMP」のクリックのようです。

合計表示数を見てみると、
1日の合計が545,477で、「画像検索結果のAMP」の表示数が594,333なので
約108%が「画像検索結果のAMP」の表示・・・・(´・ω`・)エッ?

100%越えの限界突破キタ━━━━(゚∀゚)━━━━!!

おら、ワクワクしてきたぞ(*´Д`)ハァハァ

なんで、合計値を超えてるのだろうか・・・w

合計表示回数のヘルプを見てみると、
合計インプレッション数とは、ユーザーの検索結果にサイトへのリンクが表示された回数です。この回数の計算方法は、検索結果をスクロールして表示したかどうかに応じて、画像やそのほかのタイプの検索結果とは異なります。

と書かれていました。

この辺の影響なのかな・・・(´ヘ`;)ウーム…

まぁ、いっかΨ(`∀´)Ψケケケ

検索パフォーマンスのレポートメール

何か昨日ぐらいにSearch Consoleから月間のレポートと思われるメールが届いた・・・(; ・`д・´)

前からあった機能だっけ・・・?送られてきているサイトと来ていないサイトがあるのがなぞw

何かの設定の違いですかね?(´ヘ`;)ウーム…

とりあえず下記みたいなメールが届きますたキタ━━━━(゚∀゚)━━━━!!

メール内容を見る限りですと、Search Consoleの検索パフォーマンスの日付指定で7月1日から7月31日までのレポートで前月との比較値などを確認できる内容を分かりやすくメールでお知らせしてくれる機能っぽいですね!(゚д゚)(。_。)(゚д゚)(。_。) ウンウン

項目として、下記4項目がピックアップされていました。 その中の上位が3つなどが抽出されているような感じでした。

  • Google検索(クリック数、表示回数)
  • コンテンツの実績( 上昇率上位のページ前月との比較、 パフォーマンス上位のページ )
  • サイトへのアクセス経路(上昇率上位のクエリ、 パフォーマンス上位のクエリ )
  • オーディエンスの詳細を確認する( デバイスクリック数、 上位の国クリック数 、 Google 検索タイプ )

Search Consoleなんていちいち見てる暇なんて( ´゚д゚)(゚д゚` )ネーって言う人には良いのかもですね!ъ(゚Д゚)グッジョブ!!

普段から良くSearch Consoleの検索パフォーマンスを見てる人にとっては( ´_ゝ`)フーンってぐらいにしか思わないかもw

便利になる事は良いこと!(゚д゚)(。_。)(゚д゚)(。_。) ウンウン

広告に関する問題レポート

だいぶ前にgoogle先生から「広告に関する問題レポート」でポップアップ広告とプレスティシャル広告がユーザービリティーを低下させてるからやめてね!もし対応しないなら2019年7月から全部広告は表示させないからね!( `・∀・´)ノヨロシク

という通知を受け取っていましたが、7月ならまだいっかホジホジ(´σ_` ) ポイ( ´_ゝ`)σ ⌒゜

って余裕かましてたら気が付けば5月・・・GWも終わりだしそろそろ対応するかという事で対応を行いますた!

目次

  1. 広告に関する問題とは
  2. 広告に関する問題レポート内容について
  3. サイト審査のリクエスト
  4. サイト審査の結果

広告に関する問題とは

そう、Better Ads Standards という団体?的なものがありそこで対象となる広告の基準が公開されています。

「広告に関する問題」は、Better Ads Standards(ユーザーが特に不快に感じると業界で特定された広告に関する問題を集めたもの)に違反している広告を識別するために作成されました


https://www.google.com/webmasters/tools/ad-experience?hl=ja

ここの基準に反しているものはダメだよ!絶対に!って感じで指摘されます(; ・`д・´)

ここの基準に反しているとレポートに出てくるのですが、サイトによってはそもそも審査がされていなくて未審査でフィルタリングがオフの状態になっていました。

審査が開始される基準は不明ですが、私が管理しているサイトで見ていると、アクセスが少ないサイトはだいたい未審査でした。なので恐らくある程度アクセスが無いとそもそも広告がブロックされる事がないのかもしれません・・・。もしくはユーザーからの通報とか?なのかな(´ヘ`;)ウーム…

ちなみに月間50万PVぐらいのサイトだと審査がされていて、20万PVぐらいのサイトは審査されていませんでした(´・∀・`)ヘー

広告に関する問題レポート内容について

Better Ads Standards の基準を満たしていないと Search Console から通知がきます。今年の1月ぐらいに来てた通知メールになります。

最初届いたときは恐怖で胸いっぱい・・・(((((((( ;゚Д゚))))))))ガクガクブルブルガタガタブルブル

どうしようか悩んだ結果・・・7月からなら暫く様子見するかwww

という結露に至り、現在に至ります(ΦωΦ)フフフ…

通知内容にある「広告に関する問題レポート」というリンクをクリックすると、Web Tools という画面に飛びます。そこのページの左側のメニューに「広告に関する問題レポート」という項目があり、PC,モバイルという項目がありますので、各デバイスで基準に違反していないか確認することが可能です。

レポートはドメイン単位でのレポートになりますので、ドメイン選択がされていない状態でPC,モバイルをクリックするとまずは Search Console に登録してあるドメイン一覧からドメインを選択する必要があります。

もちろん事前に Search Console に登録してあるのが前提です!!未登録の場合にはまず Search Console の登録からやる必要があるかと思います!

確認したいドメインを選択したら次ような画面が表示されて、検出結果という項目にあるリンクをクリックすると、問題となっている箇所が具体的に動画付きで指摘されています(; ・`д・´)

動画はおそらく実際にサイトを検閲した人の動作を録画した内容のようでした。分かりやすい!(゚д゚)(。_。)(゚д゚)(。_。) ウンウン

ちなみにこの画面の下に異議申し立てが出来るような入力があり、そこで指摘されているような広告じゃない場合には申し立てが出来るようでした。

?マークで 補足が下記のように書かれていました(´・∀・`)ヘー

ルートドメイン

サイトの最上位階層です。広告に関する問題レポートには、ルートドメインとその下の階層のページに影響する問題が表示されます。ルートドメインが example.com の場合、このレポートには www.example.com、news.example.com、example.com/finance などにおける広告の問題が表示されます。

https://support.google.com/webtools/answer/7308033

地域

サイトが割り当てられている Ad Standard による地域区分です。A: 米国とカナダ、B: ヨーロッパ、C: その他の地域

広告のフィルタリング

サイトが割り当てられている Ad Standard による地域区分です。A: 米国とカナダ、B: ヨーロッパ、C: その他の地域
オフ: Chrome では、お客様のサイトに掲載されている広告はフィルタリングされません。
オン: 全地域において、Chrome ブラウザを使ってこのサイトのページにアクセスするユーザーには広告は表示されません。違反内容を修正して、サイトの再審査をリクエストしてください。詳細
一時停止中: お客様のサイトが審査中のため、Chrome の広告フィルタは一時停止しています。詳細
開始日 – [日付]: サイトの審査ステータスが [不合格] であり、記載の日付から広告フィルタが開始されます。
広告フィルタを開始する 30 日前までに、登録されているサイト所有者とユーザーに Google からメールが届きます。
広告フィルタが適用されないようにするには、違反内容を修正してサイトの再審査を受ける必要があります。詳細

レポート内容をこんな感じでした。次は対応した時の流れ!

サイト審査のリクエスト

指摘されていた箇所を修正した後に、レポート画面下部にあった審査のリクエストで審査を依頼することが可能です。依頼する場合にはどのように対応したか内容を書く必要があります。

注事項としては下記の点になります。大雑把に言うと、連続して審査のリクエストは出来ないよ!また審査合格した後にまた不合格になった場合にはすぐにはリクエスト出来ないよ!だから慎重にリクエストを投げてね!って感じでした。

その他にもいろいろなケースの具体例が下記引用もとには書かれていましたので確認しておくとよいかと思います!


1 回目の審査のリクエストの送信: リクエストが処理される間、広告フィルタは一時停止されます。この審査の結果が [不合格] の場合、2 回目のリクエストをすぐに送信できます。
2 回目の審査のリクエストの送信: リクエストが処理される間、広告フィルタは一時停止されます。この審査の結果が [不合格] の場合、30 日間は 3 回目のリクエストを送信できません。広告に関する問題レポートに記載された日付に広告フィルタが開始されます。
3 回目以降の審査のリクエストの送信: 前回のリクエストの送信後 30 日が経過するか、サイトの審査のステータスが [不合格] から [合格] に変わるまで、送信できません。

https://support.google.com/webtools/answer/7072706#the_review_cycle

また審査の対象は一度のリクエストでサブドメインを含めた全てが対象とのこと。

自分の場合には広告自体を削除したので該当広告を削除しましたと書いてリクエストしました。

削除対象としてはChromeブラウザで見ているユーザーだけを対象に削除を行いました。(他のブラウザの場合には今まで通りにポップアップも、プレスティシャル広告を表示している状態)

なぜこんな対応をしたかというと、ポップアップ広告とプレスティシャル広告をやめたことで収入が極端に下がるのが嫌だったので出来れば様子を見たかったという点と、Search Console から来ていた通知内容にも書かれていましたが、

Chrome では、2019/07/09 より に広告が表示されなくなります。利便性に関する違反が モバイル向けページ で検出されました。」

というChromeではという点が気になっていてこの対象となるのはChromeだけで、他のブラウザでは表示されるってこと?という疑問がありました。

そのため、一旦はブラウザを判定してChromeの場合だけ該当広告タグを除外するという形を取り審査をリクエストしてみました。


審査リクエストを行うとレポート画面が審査待機中に変更されます。そのタイミングで広告のフィルタリングが一時停止になるようです。

メールでも審査リクエストの内容が届きます。

ここまでやったら後は、寝て待つだけですホジホジ(´σ_` ) ポイ( ´_ゝ`)σ ⌒゜

サイト審査の結果

審査リクエストをした翌日になんと結果が届きました!はやっ!(; ・`д・´)

早いと2,3時間で審査が完了した時もありました。(18時ぐらいにリクエスト投げて21時に完了)

内容を見てみると

合格キタ━━━━(゚∀゚)━━━━!!

無事にフィルタリングが解除されたようです(゚д゚)(。_。)(゚д゚)(。_。) ウンウン

これで安心安心。

ただ気になる点としては、広告収入が下がるんじゃないかという不安・・・(´;ω;`)ブワッ

さてさて、どうなることやら((((;゚Д゚))))ガクガクブルブル

解析不能な構造化データについて

なんかSearch Consoleで「解析不能な構造化データ」とかいう項目が出てきた(; ・`д・´)

前からあったっけ・・・?(´ヘ`;)ウーム…

中身を見てみると構造化データの記述が正しくないらしい(´・∀・`)ヘー

こんな感じの画面です。5610件だと・・・(; ・`д・´) ナ、ナンダッテー!! (`・д´・ ;)

解析不能な構造化データ

最初に見つかったのが3月28日だったのでそれぐらいから導入されたのかな?

詳細に書いてある各エラーをクリックすると対象ページのURL一覧が確認できます。

対象画面のURL一覧

各リンクをクリックすと画面右側に構造化データの検証結果を表示してくれます(・∀・)イイネ!!

てか、画像が黒塗りばっかりで参考にならないかもw

エラーが出ている該当部分に薄いピンク色をつけて表示してくれますw

上記の例だと、構造化データの文字列にダブルクォーテーションが正しくエスケープされていなくてタグ要素の閉じる位置がおかしくなっていたようです。

早急に修正しる!!!(; ・`д・´)

構造化データの検証には構造化テストツールでURL、またはページのソースコードを張り付ければ検証も可能です。

ソースコードを修正しながら検証もできるので構造化テストツールでテストしながら修正しながら確認して問題点箇所を特定すると(・∀・)イイ!!

基本的にはどこが正しくないのかエラー内容も表示してくれているのでそれを直して行く感じです。

自分の方で表示されていたエラーは下記になります。

解析エラー: 「,」または「}」がありません

文字列に ダブルクォーテーションが正しくエスケープされていなくて要素の閉じる位置がおかしく 構造化データがおかしくなっていたようです。

解析エラー:「}」またはオブジェクト メンバーの名前がありません

上記と同様。 文字列に ダブルクォーテーションが正しくエスケープされていなくて要素の閉じる位置がおかしく 構造化データがおかしくなっていたようです。

文字列中に無効なエスケープ シーケンスがあります

上記と同様。文字列に ダブルクォーテーションが正しくエスケープされていなくて要素の閉じる位置がおかしく 構造化データがおかしくなっていたようです。

文字列中に無効なエスケープ シーケンスがあります

エスケープが必要無い文字列に¥などのでエスケープしているとダメのようです。たとえば、”タイ\’トル\”みたいなダブルクォーテーションで囲っている場合にはシングルクォーテーションをエスケープする必要が無い場合にもこのエラーが出ていました。後は意味もなく ¥ を利用したりしていると・・・。

これ結構面倒かも・・・orz

htmlエスケープした方が良いのかな・・・(´ヘ`;)ウーム…

修正が完了したら修正を検証ボタンを押すのを忘れずに!!

恐らく押さなくてもそのうちクロールして検証してくれるかと思いますが、押すことで明示的に通知が出来ますよ!!

修正を検証を押すと、次の画面が表示されます。

この時に軽く何ページか確認されている感じがします。それでエラーがあると検証が進まない感じでした。まぁ初期検証中ってメッセージだし本当に直ってるのか数ページ軽く確認してるんですかね(゚д゚)(。_。)(゚д゚)(。_。) ウンウン

問題なく進むと、「修正を検証」が「詳細を表示」に代わるのでそれを押して詳細を表示する

初期検証失敗の場合には次のようなエラーが出ます。

初期検証が問題なく進むと、検証の状況を確認することが出来るようです(・∀・)イイネ!!

後は大人しくアニメでも見て待っていましょう!

検証が終わるとメールが届きますよ!クル━━━━(゚∀゚)━━━━!!

検証が始まったときにもメールが届くようです。

ドメインプロパティの追加

少し前からサーチコンソールでプロパティセットが使えなくなってしまって
早くドメインプロパティが使えるようにならないかな~って思ってたら機能キタ━━━━(゚∀゚)━━━━!!

メールで「新機能であるドメイン プロパティがアカウントに追加されました」という通知が来てました。

メールで「新機能であるドメイン プロパティがアカウントに追加されました」という通知が来てました。

ウェブマスター向け公式ブログでも告知があったようです。

Search Console の新機能ドメイン プロパティをご紹介します

ドメイン プロパティには、同じドメイン名のすべての URL のデータが表示されます。Search Console にウェブサイトを登録することで、同じドメインのすべてのプロトコル、サブドメイン、パスのデータが集約されるため、手動でデータを集計する必要はありません。モバイルページ用に「m.」で始まる URL を使用している場合でも、HTTP から HTTPS に移行する場合でも、サイトのデータが Search Console に自動的に集約され、Google 検索でドメイン全体がどう認識されているかを簡単に把握できます。



https://webmaster-ja.googleblog.com/2019/03/announcing-domain-wide-data-in-search.html

目次

  1. ドメインプロパティとは
    1. 旧サーチコンソールのプロパティセットとの違い
  2. サーチコンソールで対象ドメインをプロパティに追加する。
    1. プロパティ追加を選択
    2. プロパティタイプの選択
    3. DNSレコードでのドメイン所有権の確認
  3. DNSにTXTレコードに追加する
    1. お名前.comにTXTレコードを追加
  4. TXTレコード認証

ドメインプロパティとは

サーチコンソールではプロパティ単位で検索パフォーマンスなどを確認することが出来ます。

プロパティは基本的にはドメイン単位で登録するために、サブドメインでwwwとwww無しやhttp、httpsなどは別物として認識されてしまいます。

そういったサブドメインなどを全て含めて検索パフォーマンスを見たい場合に、ドメインプロパティを使うことでサブドメインを含めたものや http、https の違う場合にも合算してくれる便利な機能ですワーイヽ(゚∀゚)メ(゚∀゚)メ(゚∀゚)ノワーイ

旧サーチコンソールではプロパティセットと呼ばれていたものと似ています。

旧サーチコンソールのプロパティセットとの違い

旧サーチコンソールのプロパティセットは複数のプロパティをまとめるものだったので今回のドメインプロパティと同様の機能ですが、違う点としてはドメインプロパティがドメイン単位でしかまとめられないのに対して、プロパティセットは複数のドメイン(別々のドメイン)をまとめることが出来た点になります。

この別々のドメインをまとめられた機能は個人的には便利で利用していましたが・・・無くなって残念です(´・ω・`)ショボーン

サーチコンソールで対象ドメインをプロパティに追加する。

プロパティ追加を選択

まずは、サーチコンソールにログインして左上にあるプロパティ一覧から追加を選択

まずは、サーチコンソールにログインして左上にあるプロパティ一覧から追加を選択
まずは、サーチコンソールにログインして左上にあるプロパティ一覧から追加を選択

2.プロパティタイプの選択

左側のドメイン入力欄に該当するドメインを入力して「続行」を押す

左側のドメイン入力欄に該当するドメインを入力して「続行」を押す

3.DNSレコードでのドメイン所有権の確認

DNSレコードにTXTレコードを追加する内容が表示されるのでコピーしてDNSレコードに追加する。画面は開いたままにしておきます。

 DNSレコードにTXTレコードを追加する内容が表示されるのでコピーしてDNSレコードに追加する。画面は開いたままにしておきます。

DNSのTXTレコードを追加

お名前.comにTXTレコードを追加

DNSを変更する場合には、ドメインを管理している各サービスごとに違ってきます。
今回は例としてお名前.comでの方法になります。こちらを参照してください!

TXTレコード認証

手順3で表示された画面で「確認」を押すと、DNSレコードの確認が行われます。

DNSレコードが正しく反映されていれば、認証が成功して下記の画面が表示されます。

DNSレコードが正しく反映されていれば、認証が成功して下記の画面が表示されます。

TXTレコードが正しく設定されていない場合や、追加されているけどDNSレコードが反映されていない場合には下記のようなエラー画面が表示されるようです。

TXTレコードが正しく設定されていない場合や、追加されているけどDNSレコードが反映されていない場合には下記のようなエラー画面が表示されるようです。

TXTレコード追加したのに反映されないよ!!!っていう方はDNSレコードの反映にはタイムラグがあるので「後で確認」を押して暫く大人しく待ちましょう!(*´・ω・)(・ω・`*)ネー

認証画面の注意事項に

注:DNSの変更が適用されるまでに時間がかかる場合があります。Search Consoleですぐにレコードを確認できない場合は、1日待ってからもう一度お試してください

とも書かれていますしおすし。

ちなみに「後で確認」を押すとプロパティ一覧の一番下の方に未認証という項目に出てきますので、暫く経過したら確認すると認証されるかと思います!( ´∀`)bグッ!

「後で確認」を押すとプロパティ一覧の一番下の方に未認証という項目に出てきます

正しく認証されるとプロパティ一覧にドメイン名の下にドメインプロパティと表記されているプロパティが表示されるようです。

正しく認証されるとプロパティ一覧にドメイン名の下にドメインプロパティと表記されているプロパティが表示されるようです。

これで完了キタ━━━━(゚∀゚)━━━━!!

この設定をしておけばサブドメインを含めた検索パフォーマンスを確認することが可能になります。

ドメインプロパティを使わない場合には各サブドメイン単位でプロパティを追加して行き、各サブドメインのプロパティごとの検索パフォーマンスしか見ることが出来ません;y=ー( ゚д゚)・∵. ターン

ただ、以前のサーチコンソールでは行えたプロパティセットでは別ドメインの検索パフォーマンスをまとめるという使い方は出来なくなったようです。

個人的には便利で多用していたので残念・・・(´;ω;`)ウッ…

Web Light の結果について

あ、ぽこたんインしたお!

久しぶりの登場キタ━━━━(゚∀゚)━━━━!!

すっかり更新するのが止まってしまいました・・・シーッ! d( ゚ε゚;)

Search Consoleを見ていたら数日前に気づいたのですが、

検索での見え方に「Web Light の結果」というのが増えていました。

目次

  1. Web Lightの結果
  2. Web Lighttとは
  3. 低帯域幅コード
  4. コード変換の対象
  5. コード変換の制限

Web Light の結果

Search Consoleの検索アナリティクスで見る限りですと、4月30日から集計されているっぽいです(´・∀・`)ヘー

Web Lightとは

ヘルプでWeb Light の結果を調べてみると下記のページがありました。

Web Light: 検索されたモバイルページを軽量化して読み込みを高速化する

Google では、低速のモバイル接続で検索するユーザー向けに、軽量で読み込みが速いページを表示しています。低速のネットワークでもスムーズに表示できるよう、ウェブページをその場でコード変換するので、ページの読み込みが高速になる一方で、データ通信量が節減されます。この技術は Web Light と呼ばれています。Web Light ページでは、関連コンテンツの大半が維持され、元のページを表示するリンクもユーザーに提示されます。Google でのテストによると、最適化したページの読み込みは元のページより 4 倍速く、使用するバイト数も 80% 削減されます。また、こうしたページは高速で読み込めるため、ページヘのトラフィックも 50% 増加しました。

とのことです。
低速のネット回線を利用しているユーザー向けに、Googleが最適化をして表示したページの結果に流入してきたユーザーの結果ということのようです。

低帯域幅コード

実際にどう表示されるか確認するためのツールとして下記のものが用意されていました。

低帯域幅コード変換

確認したいURLを入力して実行するとQRコードが出力されるので

それを実機で読み取るとコード変換されたページが確認できるようです。

実際に確認してみたところですと高速化の為かgifアニメーションが動かない状態で表示されたり、cssとかが若干聞いていない状態で表示がされていました(´・∀・`)ヘー

ドロワーが開かなかったよ!!Σ(゚д゚lll)ガーン

ちなみにURLは下記の感じになるようです。

ページのホスト名に googleweblight.com が付加されます。つまり、example.com/mypage にあるページの場合、コード変換されないページの指標は example.com/mypageとして表示され、コード変換されたページの指標は example.com.googleweblight.com/mypage として表示されます。

コード変換の対象

・低速のネットワーク接続を使用していると Google が検出した場合。(低速として判定する基準は不明)
・Chrome ブラウザと Android ブラウザ(バージョン 2.3 以上)からの検索
・スマートフォンを使用している場合のみです。(パソコンやタブレット対象外)
・コード変換されたページから別ページへの遷移も基本的に全てコード変換される。※コード変換が出来ないページなどは対象外

コード変換の制限

・Google アナリティクスはページビューの統計情報のみがサポート。(ユニバーサル アナリティクスのみがサポート)
(イベント トラッキングはレポートされない)
・ページに表示される広告の数は3つが上限(広告は元のページでリクエストされている順番で選択)

まとめ

対象が低速ネット回線が前提という事もあり

Search Consoleの検索アナリティクスで、国を絞ると主要国では対象なるデータが殆どありませんでした。

私のデータですと、インドネシア、ブラジル、インドが大半のデータとなっていました。

ということは日本ユーザーなどではあまり遭遇しないページなのかもしれませんね(゚д゚)(。_。)(゚д゚)(。_。) ウンウン

 

とりあえずGoogle先生♪♪♪ d(`Д´)b♪♪♪サンキュー

Ajax利用時のインデックス制御について

たま~に、Search ConsoleからクロールエラーでAPI(外部サイトに公開している)として利用しているものがエラーで検出されていたんですが、ここまで見てくれるのか~!あざっすって思って感謝していますた。

ふと考えてみると、クローラーが認識しているという事はインデックスもされてるんじゃないか?という疑問が出て site コマンドでインデックス状況を見てみると・・・AjaxでリクエストしているURLが見事にインデックスされていました(; ・`д・´)

Ajaxで取得しているページが数千件ほどインデックスされてしまっている状況・・・orz

Ajaxで取得している内容はオリジナルページの一部情報を取得してリクエスト元サイトに内容を埋め込むものになっています。その結果、リクエスト元ページから自分のサイトへのリンクが張られて誘導されるというものになっていました。

※一部情報とは、リクエスト元サイトに挿入する作りで作っているため、headerタグとかbodyタグ無しのhtmlコードを返すものとなっています。

このオリジナルページの一部情報だけが表示されるAjaxのリクエストが直リンクでも開くため、クローラーがインデックスしまっている?状況なのかな。※クローラーはリンクをたどるわけではなくてリファラーは無しで直リンクで飛んでくる。

一部しか情報が無いため検索結果でAPIの結果ページから流入してきたユーザーに対してのユーザビリティーがかなり悪いし、Ajaxで表示している内容はオリジナルページの一部のため、そのページはインデックスする必要が無くてむしろオリジナルページの方を見てもらいたい!!

よって、対策を考えること。

検討した内容は下記になります。

 

1.robots.txt で disallow でブロックしてしまう。

クローラーにクロールさせるのブロックする方法を行うと、既にインデックスされているページに対してもクロールが出来なくなってしまい、インデックスが残ってしまう可能性があるため却下。出来ればリンクも辿って欲しい!!

2.API結果の発リンクに nofollow を設定する。

nofollow を指定するとクロール自体がされなくなるだけなので、インデックスが消えるわけじゃないため却下。またクローラーにはリンクを認識してほしいので nofollow は設定しない。

noindexはページランクを渡すため。下記参照。

noindexとは? SEOでの効果的な使い方を理解しよう!

3.noindex でインデックさせないようにしてしまう。

クローラーにはリンクを認識してもらいつつインデックスを消すことが出来るため、こちらを候補として採用(゚∀゚)キタコレ!!

ただし、単純にレスポンス結果に noindex タグを入れてしまうと、リクエスト元サイトに挿入されるため、Ajaxのレスポンス結果が noindex されるわけではなくてリクエスト元ページが noindex の対象になってしまうかも!?(((((((( ;゚Д゚))))))))ガクガクブルブルガタガタブルブル

これが出来たらコワいな・・・w

と思っていたら、noindex は header 以外でも有効らしい。下記ブログにも書かれていますが、悪意あるユーザーがコメントとかで noindex を利用したら消されちゃうってことかっ!?エッ(゚Д゚≡゚Д゚)マジ?

アブネ━━━━Σ(゚д゚;)━━━━!!

https://lblevery.com/sfn/attract/seo/internal-seo/noindex/

4.canonical で正規化する。

オリジナルページへURLを正規化することで間違ったインデックスを正しくできるため、こちらも候補として採用(゚∀゚)キタコレ!!

ただ、canonical は header タグの中でしか認識されないため、今回のAjax通信のレスポンスとしてHTMLで返すことは出来ない。やる場合にはHTTPヘッダーとして返してあげる必要がある。

Googleがrel=”canonical”タグを無視する時とGoogleにrel=”canonical”タグを確実に認識させる方法


とりあえず深く考えず試したのが noindex の方法になります。

noindex の設定方法について

noindex の設定方法はいくつかあります。

1.meta タグで指定する。

対象ページに下記を記述するだけ!

<meta name=”robots” content=”noindex”>

ページ単位で指定する必要がある。

2.robots.txt で指定する。

robots.txt に下記のように記述する

Noindex: /test/

ディレクトリ単位で指定ができる。

3.HTTP ヘッダーで指定する。

レスポンスとして下記を出力して返す。

X-Robots-Tag: noindex

ページ単位で指定する必要がある。

詳細はヘルプを確認してくらはい!


今回は、URLで大きく分けられていたので方法2の「robots.txtで指定する」方法でディレクトリ単位での設定を利用してみました。

設定する前にsiteコマンドで確認したインデックス数は約8000件でした。

数日後、対象サイトのSearch Consoleを見ていると、ブロックされたリソースが大量に増えてることに気づく・・・(; ・`д・´) ナ、ナンダッテー!! (`・д´・ ;)

ブロックされたリソースを見ると、数日前に設定したAPI関係のURLが対象になっている・・・(;´・ω・)

あれ、noindexって、クロールは許可してインデックスだけしないって感じじゃないんだっけ?(´ヘ`;)ウーム…

ブロックもしちゃう?それなら disallow と変わらないじゃん・・・(;´・ω・)

念のため Fetch as Google でクローラーが認識している画面を確認すると、見事にAPIの部分が表示されていませんでした・・・。下部のブロックされたリソースにもAjax部分が書かれていました。Σ(゚◇゚;)マジデッ!?

これは意図した動きではない!こんなのは望んでない!!バカーヾ(゚д゚)ノ゛

ちなみにインデックスされていた件数は減少していました。一応インデックスの方は削除されて言ってる模様です。

※設定する前にsiteコマンドで確認したインデックス数は約8000件だったのが7件になっていた。

noindex時の指定方法が違う場合の Fetch as Google の挙動検証

念のため、meta タグに設定されているものと、robots.txt で指定してる場合の挙動を確認。

検証用ファイルとして下記を用意。

・robots.txt でdisallow を指定した場合に表示させるhtml

disallow.html

<html>
<head>
</head>
<body>
disallow
</body>
</html>

・メタタグでnoindexを指定した場合に表示させるhtml

noindex.html

<html>
<head>
<meta name="robots" content="noindex">
</head>
<body>
noindex
</body>
</html>

・robots.txtでnoindexを指定した場合に表示させるhtml

noindex-robots.html

<html>
<head>
</head>
<body>
noindex robots
</body>
</html>

・httpヘッダーでnoindexを指定した場合

noindex-header.php

<?php

$html = <<< EOF
<html>
<head>
</head>
<body>
noindex http header
</body>
</html>
EOF;

header("Content-type: text/html; charset=utf-8"); 
header("X-Robots-Tag: noindex");
echo($html);

robots.txt

User-Agent: *
Disallow: /disallow.html
Noindex: /noindex-robots.html

上記ファイルを元に再度 Fetch as Google を実行してみた結果、下記の結果になりますた。

・disallow.html

ブロック扱いで、レンダリングもされない。(クロールされない)

・noindex.html

ブロックされずにレンダリングされる。(クロールされる)

・noindex-robots.html

ブロック扱いで、レンダリングもされない。(クロールされない)

・noindex-header.php

ブロックされずにレンダリングされる。(クロールされる)

うーむ、やっぱり robots.txt で指定した noindex の場合にははクロールすらされなくなるってことですかね・・・orz

指定方法で挙動が違うって問題ないの!?( ´゚д゚)(゚д゚` )ネー

 

どうしようかな~?って考えてたら・・・そういえば元々オリジナルページに一部の情報を使ってるんだから canonical で良いんじゃない?って思いつきますた( ̄ー ̄)ニヤリ

ただ canonical は meta 以外では使えないので AjaxのHTTPヘッダーで canonical を指定して返すことに!!

phpであれば下記のように出力すればOKъ(゚Д゚)グッジョブ!!

header("Link: <https://example.com/>; rel="canonical");

色々悩んだけど、今のところはこれで検証中です。

経過報告

siteコマンドで確認できる件数では数が増えているのですが、search console上のブロックされたリソースの数は減少傾向になってきましたキタ――(゚∀゚)――!!

減少し始めて日付がcanonicalを設定した日付付近なので今回の設定内容が影響を与えてるようです。

2017/10/09時点

まとめ

noindex の指定方法が違うとクローラーの挙動が違うので気を付ける。

robots.txtで指定したものはクロール自体をブロックされてしまうっぽい。クローラーがリンクを辿れない状況になる。

これで良いのかな~?って感じだけど、とりあえずAPI用のURLがインデックスから消えることと、APIを利用してくれてるサイトでAPIの部分で挿入されたHTMLがクローラーにちゃんと認識してくれるのであれば(・∀・)イイ!!

ベストプラクティスがあればどなたか教えてクレメンス!|д゚)チラッ

https://developers.google.com/webmasters/ajax-crawling/docs/learn-more

https://developers.google.com/webmasters/ajax-crawling/docs/faq?hl=ja#excludesomeurls