Google砲を狙え！ 待望のDiscoverレポートがSearch Consoleに登場【SEO記事13本まとめ】

今週のピックアップ

Google砲を狙え！ 待望のDiscoverレポートがSearch Consoleに登場
おすすめ記事からのトラフィックレポート （グーグル ウェブマスター向け公式ブログ） 国内情報

“グーグル砲”とも呼ばれるDiscover（ディスカバー）のパフォーマンスレポートがSearch Consoleに提供された（Search Consoleの［検索パフォーマンス］＞［Discover］）。

レポートでは、次のような統計情報を入手できる。

• 自分のサイトはユーザーの Discover にどのくらい表示されているか？ どのくらいのトラフィックがあるのか？
• Discover で特にパフォーマンスの高いコンテンツはどれか？
• 従来の検索結果と比べて、Discover ではコンテンツのパフォーマンスがどのように変化しているか？

Discoverからの一定以上のアクセスがあると、検索パフォーマンスのレポートが「検索結果」と「Discover」の2つになる（Discoverからのアクセスがないサイトはメニューに出ないようだ）。

これまでDiscoverのトラフィックをアクセス解析ツールで分析するのは難しかった（ほとんどはダイレクトとして記録されるため）。だが、Search Consoleでデータが見られるようになったのはありがたい。

Discoverからのトラフィックが多い記事の特徴を見つけ出し、「グーグル砲」狙いに役立てよう。

念のために説明しておくと「Discover」とは、ChromeとスマホのGoogleアプリが備えている、あなたが興味関心を持ちそうな記事を選んで表示する機能だ。

具体的には次のような場所で表示されているものだ（Discover登場時の記事より）。

• Chrome ―― 新規タブを開いたときに「おすすめの記事」として表示される部分
• Googleアプリ ―― アプリを立ち上げると表示されるディスカバー（Discover）という名称の機能

グーグル検索SEO情報①

blockquoteタグを使えば重複コンテンツ対策に役立つ！？
よくある勘違いです （Reddit） 海外情報

こんな言説を聞いたことはないだろうか？

引用を意味する blockquote タグは、重複コンテンツを防ぐことに有効だ

もしあなたがこれを信じているとしたら、それは必ずしも正しくない。もっとわかりやすく言うと、間違っている。

blockquote で囲まれていたからといって、ほかの場所から引用されたものだとしてグーグルが特別扱いすることはない。つまり、blockquote は重複コンテンツ対策には役立たない。

グーグルのジョン・ミューラー氏は、そのように説明したうえで、引用時のアドバイスを次のように述べている。

だれかのコンテンツをそっくりそのまま引用しただけで付加価値がなければ、ユーザーに対しても検索エンジンに対しても良い印象は与えない。

一方で丸ごと引用したとしても、それに関係するさらに多くの情報を付け足したり、関連する他のページにリンクしたりすれば非常に有益なものになるだろう。

引用による重複コンテンツ扱いを本当に避けたいのであれば、独自の価値ある情報を提供することが最も効果的だ。

念のために説明しておくが、blockquote が役に立たないというのはあくまでも、グーグルの重複コンテンツ扱いという点においてだ。「引用」であることをデザインによってユーザーに示す目的では、blockquote には明確な意味がある。

ミューラー氏の解説をここで紹介したのは、単なる無断転載に近い行為をしながら「blockquote で囲んでいるから大丈夫」だと思っているような人たちに知ってほしかったからだ。

Google検索インデックス障害の余波、Search Consoleデータ17日分が喪失
4/9～4/25のデータが置き換えられた （Data anomalies in Search Console） 海外情報

4月上旬に発生したインデックスの技術的なトラブルは復旧後もあとを引いている。このトラブルの影響で、Search Consoleのいくつかのレポートにも障害が発生した。障害自体は（これも予想外に長引いたものの）直ったのだが、無視できない爪痕を残した。

というのも、検索パフォーマンスを除くすべてのレポートのデータが欠損しただ。レポートが停止していた4月9日～4月25日までのデータは、障害が復旧した4月26日のデータに置き換えられた。つまり、4月9日～4月25日までのデータは失われてしまったのだ。

たとえば、4月9日～4月25日のカバレッジレポートの数字は変化がない。この期間は、4月26日のデータになっているためだ。

Search Consoleのデータを常時取得しているなら、データ喪失のことを頭に入れておこう。正しい分析ができなくなるかもしれない。

クロールバジェットに関係するXHRと404の小ネタ
クロールバジェット小話 （Gary Illyes on Twitter ／ Google Webmaster Central office-hours） 海外情報

クロールバジェットに関する小話を2つ紹介する

XHRもクロールバジェットを消費する

JavaScriptで動的なコンテンツを実現するAjax（エイジャックス）で一般的に使われている「XHR（XMLHttp​Request）」も、クロールバジェットを消費する要因になるとのことだ。通常は、悪影響を及ぼすことはないだろうが、Ajaxを多用しているサイトのウェブ担当者は念のため開発者にも共有しておくといい。

クロールバジェットを解説した公式ブログ記事にはXHRへの言及が追加されている（この記事を書いている時点では日本語記事は未更新）。

404もクロールバジェットを消費する

Googlebotは、404を返すURLでも半永久的に再クロールし続ける。したがってクロールバジェットを消費するのだが、こちらも悪影響を及ぼすことはない。主な理由は次の2つだ。

• 404のURLを再クロールする頻度は非常に低い
• クロールバジェットが限られているときは重要なURLを優先してクロールする

一般的に言って、404がクロールを阻害することはないと理解しておこう（アクセスできるはずの404が大量に発生しているのは大問題だが、それはクロールバジェットとは別の話）。

XMLサイトマップ＋lastmodで再クロールをさらに促進
乱用は禁物 （Google Webmaster Central office-hours） 海外情報

Search Consoleでサイトマップを送信するとGooglebotのクロールを促進できる。これはご存じの方も多いだろう。しかしXMLサイトマップのURLエントリに lastmod を記載すると、更新したコンテンツを優先して再クロールする指示になることもご存じだろうか？

lastmod はそのページの更新日を伝える要素だ（「lastmod」はlast modifiedの略）。XMLサイトマップにpriority や frequency といった要素を記載してもグーグルは利用しないが、lastmod は利用しているようだ。

具体的には、次のように記述する。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> 
<url>
<loc>http://www.example.com/hoge.html</loc>
<lastmod>2019-05-10</lastmod>
</url>
</urlset>

更新したのが数ページであれば、URL検査ツールでライブテスト実行した後にインデックス送信すれば、速やかな再クロールをリクエストできる（上限あり）。しかしURLの数が多かったり、日々のそうした作業を自動化したりするのでれば、「サイトマップ ＋ lastmod」が有用だ。

ただし lastmod の乱用は禁物だ。サイト全体をクロールさせたいからといって更新してもいないページのURLに偽りの lastmod を追加すると、グーグルはやがてそのサイトのサイトマップを信用しなくなる。かえって逆効果でサイトマップが役に立たなくなる。気を付けよう。

グーグル検索SEO情報②

「WordPressはSEOに強い」は都市伝説
シェアが多いから検索結果にも多く出る （John Mueller on Twitter） 海外情報

WordPressで作られたサイトと比べると、HTMLで作ったサイトをグーグルは上位表示しますか？

こんな質問を受けたグーグルのジョン・ミューラー氏は、次のように返答した。

ページはページだ。

エディタで手書きしたページと比較してWordPressで作成したサイトのページに特別なものは何にもない。オンラインでコンテンツを作る際には、自分にとって便利なものを使えばいい。

「WordPressはSEOに有利だ」という話をときおり耳にするが、完全に都市伝説だ。公式ヘルプフォーラムでもつい最近そんな投稿を目にした。

あるリサーチによれば、WordPressはCMS全体の60%以上のシェアを獲得し、インターネットの全サイトの33.8%を占めているそうだ。単純に考えると、3サイトに1サイトはWordPressで作られているということになる。

検索結果でWordPressサイトが多く見られるのは、単純に、シェアが多いからだろう。

日本でもブログツールが出始めた2004年前後ならば、まったく検索エンジンを意識していない手書きHTMLのページに比べれば、ブログツールを使うほうがSEOに有利だったという事実はあるかもしれない。

その頃は、全ページのtitle要素が同一だったり、サイト内リンクがしっかりと張られていなかったりという状況が多かった。そのため、ブログツールを導入するだけで、検索エンジンにページ内容を理解されやすくなったからだ。

また売り文句として「SEOに強い」としたWordPressテーマが多数公開されているため、検索で有利になると特に初級者は無条件に思い込んでしまうのかもしれない。

とにもかくにも、WordPressだというそれだけの理由でグーグルは評価を高めることは絶対にない。

もちろん、Web担当者が苦労しなくてもサイト構造・ページ内コンテンツ構造・内部リンクといったものをちゃんと作れるという点では、WordPressに価値はある。しかし、それはあくまでも「SEOにとってマイナス」の状況を減らすだけだ。それだけで検索上位に表示される時代ではない。

グーグルが検索ユーザーに届けたいのは、WordPressで作ったページではなくクエリに最も関連したページなのだから。

CMSへの移行はランキングに影響するのか？
サイトのデザイン変更は検索に変化を与える可能性あり （John Mueller on Twitter） 海外情報

シンプルなHTMLのサイトからCMSのサイトに変換すると、評価がゼロに戻ってしまうというようなランキングへの影響がありますか？ URLは同じに保ちます。

こんな質問をツイッターで聞かれたグーグルのジョン・ミューラー氏が、次のように答えた。

本質的にはデザインの変更だ。以前のURLを保持すればあらゆることがやりやすくなる。

しかしながら、サイトが変わるということは（多くの場合はレイアウトや内部リンクが変わる）そうした変更による新しい状態は、時間が経過すると検索に反映するだろう。以前の状態とは異なるかもしれない。

CMS化したりCMS移行したりしなくても、サイトのリニューアルには検索ランキングへの影響がつきまとう。

まず、URLの変更だ。URLが変わると、一時的であるにせよ順位が下がることがある。パターンが統一されていないURL変更は影響がより長引くことがある。グーグルがサイト全体のURL変更だということを認識するのに時間がかかるためだ。したがって、URLの変更は極力避けたい。

またレイアウトの変更も影響を与えることがある。たとえば、リニューアル時のデザイン変更にともない、内部リンクを撤去したら検索エンジンがクロールするURLの発見に影響がでるだろう。PageRankの流れという点でも変化がでるかもしれない。

別の例としては、検索エンジンがヒントとして扱うHTMLタグの構造変更がある。たとえば、以前は見出しHTMLタグを設定していたのに、リニューアルでそのタグをなくしてCSSで見た目だけ見出しっぽくしたdivにしてしまったら、これもグーグルのコンテンツ理解に影響するかもしれない（筆者注： 見出しタグが大きなランキング要因ということではないが、そのページに書かれていることをグーグルが理解するシグナルとして使われることがある）。

リニューアルに際してコンテンツそのものを更新したとしたら、もちろん評価も変わってくる。

もっとも筆者も「CMSへの移行や乗り換えを含む全面リニューアルは、ランキングへの影響が懸念されるから控えるべきだ」などと主張するつもりはない。逆に、リニューアルによって、良い影響がでてくることも十分にありえる。

伝えたいのは、大掛かりなリニューアルは検索に影響する可能性があることをあらかじめ念頭に入れておく必要があるということだ。発注側としてSEO要件を把握し、制作側にもちゃんと伝え、チェックする体制を整えるようにしたい。

新しいSearch Consoleではリンク否認ツールは廃止？
だれもそんなことは言っていない （Reddit） 海外情報

新バージョンのSearch Consoleではリンクの否認ツールが提供されていない。いつ提供されるのだろうか？ グーグルのジョン・ミューラー氏は、次のようにコメントしている。

まだ案内できるような計画はない。

このコメントを聞いて、否認ツールは廃止されるのではないかという憶測もでている。そうした憶測に対してミューラー氏は次のように反応している。

公表できるような計画がないと言っただけなのに、なぜそれが廃止の決定のように受け止められてしまうのか？ 困惑してしまう。

ミューラー氏の個人的な理想としては、否認ツールを提供しなくても済むようにしたいようだ。

理由としては次のようなものがある：

• グーグルはすでに、不自然なリンクをアルゴリズムによって自動的に無効化している
• リンクを否認する作業にサイト管理者が時間と労力を費やしてしまい、ユーザーのためのサイト作りの妨げになっているケースも少なくない
• 誤った使い方で価値があるリンクまで否認してしまう人も存在する

否認ツールを使う必要がないに越したことはないのだ。

一方で、身に覚えがない不自然なリンクが大量に張られたり、グーグルのアルゴリズムを完全には信用できなったりする人もいる。そういった人たちにとっては、否認ツールは必要な機能だ。なくては困るだろう。

否認ツールを新Search Consoleでも提供するにしても、もっと使いやすくわかりやすくするために改善を加える可能性も考えられる。いずれにしても、どうしてもリンクを否認する必要があると考えるなら、当面は旧Search Consoleを利用するしかない。

グーグルのIndexing APIは、しごと検索とライブ配信以外でも機能するのか？
クロールはすぐに来たが （Stories by Tobias Willman on Medium） 海外情報

しごと検索（求人検索）では、最新の求人情報をユーザーに提示するために Indexing APIの利用が推奨される。Indexing APIは、求人情報ページが追加、更新または削除されたときに速やかなクロールとインデックスを要求できる仕組みだ。

現状ではIndexing APIは、しごと検索とライブ配信だけに利用できる（ライブ配信も即時性が重要だ）。だが高速な再クロール、再インデックスが可能なら通常のページでもIndexing APIを利用したいところだ。

しかしグーグルのジョン・ミューラー氏によれば、Indexing APIのサポートを他のタイプのページにも拡大するかどうかはわからないとのことである。

では、しごと検索もライブ配信も構成していない通常のページでIndexing APIを利用したらどうなるのだろうか？ そんな実験をした人がいる。

なんと通常ページであっても、Indexing APIでリクエストした直後にGooglebotはクロールを始めたそうだ。ところが、クロールしたもののインデックス（検索結果）には反映されなかったとのことだ。

つまり、通常ページに対するIndexing APIの利用はクロールには影響するようだがインデックスには影響しない。よって、実質的に役には立たない。

残念だが、条件を満たしているかどうかをグーグルはきちんと見ているらしい。考えてみれば納得で、クロールしてみなければ対象コンテンツかどうかはわからないので、クロールまでは実行されるのだろう。

一般のWebページでIndexing APIを使うのはクロールリソースの無駄遣いになるようなので、公式にサポートされるまでは対象コンテンツ種別以外では使わないようにしておくのがいいだろう。

4月のオフィスアワー ―― SCのリンクレポート、rel="prev/next"その後、info:検索代替など
AMP Confのハイライト紹介あり （ウェブマスター オフィスアワー） 国内情報

4月のオフィスアワーが開催された。金谷氏とあんな氏が回答してくれた質問は次のとおりだ。

• Search Consoleに表示されるリンク
• rel="prev/next"廃止後のURLの正規化
• HTTPSのランキングへの影響
• サブドメインのサイトがきちんと認識されない
• 会社名でナレッジパネルが表示されない
• 3月中旬の順位変動
• URLの重複でインデックスされない
• rel="prev/next"と無限スクロール
• 画像がインデックスされない
• info: の代わりの方法
• インデックスされなくなった
• モバイルユーザビリティのエラー
• しごと検索でロゴが表示されない
• URL検査ツールがもの足りない

前回のオフィスアワーでの訂正で、Search Consoleのリンクレポートにはnofollowリンクも表示されることがはっきりした。また廃止されたrel="prev/next"に関する質問は、このlink要素を実装していたのであればチェックしておこう。

Q&Aの前には、新しい機能の紹介や4月に東京六本木で開催されたAMP Confのハイライトに触れている。こちらも見ておこう。

海外SEO情報ブログの
掲載記事からピックアップ

4月に東京で開催されたAMP Confカンファレンスのセッションレポート記事を3本ピックアップする。

• #AMPConf 2019で発表された検索関連の最新AMPニュース――amp-scriptやSXG、AMPストーリーなど

  AMPの進化がわかる

  ★★★★★

  • すべてのWeb担当者 必見！
• AMPキャッシュを本来のURLで表示するSXG対応の検索をGoogleが正式公開。一方ヤフーは試験公開 #AMPConf

  AMPのURL問題を解決

  ★★★★☆

  • AMPがんばってる人用（ふつうの人は気にしなくていい）
  • 技術がわかる人に伝えましょう
• 新たなSEOの到来か？ AMPストーリーが専用ブロックでGoogle検索に表示される #AMPConf

  AMPストーリー ゴリ押しの予兆？

  ★★★★☆

  • SEOがんばってる人用（ふつうの人は気にしなくていい）
  • 技術がわかる人に伝えましょう