グーグルさん、「良いコンテンツ」ってどういうもの？ 定義を教えて！【SEO記事13本まとめ】

グーグルの考える「良質なコンテンツ」の定義は、どういうものなのだろうか。グーグル長山氏のコメントをもとに解説する。
ほかにも、ページ表示速度と直帰率の関係、rel="canonical"再入門、常時HTTPS、Googleオプティマイズ、MFI、サイト内検索とグーグル検索、ビッグキーワードで上位表示するTIPSなどなど、SEO関連の情報をまとめてお届けする。

グーグルさん、「良いコンテンツ」ってどういうもの？ 定義を教えて！
グーグルの定義ではなく、自分のユーザーを知るのが大切 （長山一石 on ツイッター）

「良いコンテンツ」とは、どういうものなのだろうか。

いま検索エンジンに評価されるには、「良質で独自のコンテンツ」が必要だと言われる。昔のような「リンクを増やせばいい」「キーワードが含まれていることが大切」といった単純なことではない。

その「良いコンテンツ」とはどういうものかについて、グーグルの長山氏がツイッターで次のようにつぶやいていた。

つまり、「『良いコンテンツ』の明確な定義なんて、そんな簡単に作れるものではない」ということだし、それができれば今のグーグルよりもすばらしい検索エンジンが作れるということだろう。

その定義と判断方法をまだ確立できていないからこそ、グーグルは絶えずアルゴリズムを改善し続けているのではないだろうか。

また、「良質なコンテンツ」の定義をいったん確立したとしても、未来永劫それで問題ないというものではないだろう。なぜなら、ユーザーの考えや好み、置かれた状況、時代によっても「良いコンテンツ」は変化する。インターネットによって社会や人も変わるスピードがどんどん加速しているのだから。

さらに言えば、さまざまな背景・さまざまな状況の多様な人に一律に適用できる「良いコンテンツ」の定義なんて、あるはずがない。

それは「良いレストラン」を定義するのが不可能なのと同様だ。

年収が10億円あって世界中のおいしいものを食べ尽くした人にとっての「良いレストラン」と、母親の手料理しか食べたことがなく手持ちのお金も少ない人にとっての「良いレストラン」が同じはずがない。

肉体労働で疲れた人、初めてのデートに臨む人、職場の仲間でワイワイ騒ぎたい人、がんばった自分にご褒美をという人、それぞれ「良いレストラン」の定義は違うだろう。

この件に関しては、「グーグルが（現時点で）定義する良いコンテンツ」を見つけ出そうとするのはあまり意味がないと、筆者は思う。

グーグルのアルゴリズムを知ろうとするのではなく、自分が対象とするユーザーにとって役立つコンテンツがどんなものであるかを絶えず知ろうとする取り組みが、マーケティングに携わる人間にとってはもっとも大切なもののはずだ。

日本語で読めるSEO/SEM情報

モバイルではページ表示が1秒→7秒に遅くなると直帰率は113%悪化する！
コンバージョン率も低下 （Google Developers Japan）

モバイルでのページ表示速度に関する最新の調査データをグーグルが公開した。

たとえば次のような数字が出ている。

• モバイルのランディング ページが完全に読み込まれるまでの平均時間は 22 秒

• 読み込みに 3 秒以上かかるページからは 53% のモバイルサイト訪問者が離脱

• 見えない部分も含めたすべてのコンテンツが読み込まれるまでに 10 秒以上かかるページが調査したページのうち 70%

さらに、深層ニューラル ネットワークを用いて計算させたところ、こんな予測結果が出たとのことだ（予測精度90%に達しているとのこと）。

• ページの読み込み時間が 1 秒から 7 秒に増えると、モバイルサイト訪問者の直帰率が 113% 増加する

• ページの要素（テキスト、タイトル、イメージ）の数が 400 から 6,000 に増えると、コンバージョン率が 95% 低下する

モバイルユーザーは遅いサイトをとにかく嫌っていることが、最新調査でも浮き彫りになった。スピード改善には積極的に取り組もう。

rel="canonical"の働きと注意点を再確認してみよう
命令ではなくヒント （長山一石 on ツイッター）

グーグルの長山氏が、rel="canonical"の仕組みをツイッターで紹介した。

念のために筆者からも簡単に説明すると、同一もしくはほぼ同一のコンテンツが復数のURLで公開されている状況で、代表となるメインのURL（インデックスさせたいURL）がどれなのかをグーグルに伝えるために利用できるのが rel="canonical" だ。専門用語で言うと、「正規化」する役割を rel="canonical" は持つ。

SEOに取り組むならぜひ覚えておきたい仕組みだ。

ただし、rel="canonical" に関しては、理解しておくべき重要な仕様がある。それについて、長山氏は続けてツイートしている。

「命令」なのか「参考情報」なのかの違いだ。

Googlebotは、たとえばrobots.txtやnoindex meta タグに書かれた情報を「命令」として認識し、その指示には必ず従う。

対して、rel="canonical" は命令としては扱わない。非常に強い指示として認識するものの、あくまでも扱いは参考情報（ヒント）であり、rel="canonical" を打ち消すような要因があれば、その指示に従わないこともありうる。

たとえば、明らかに内容が異なるページに向けて rel="canonical" を設定したとしたら、無視されることがある。

世の中には、適切ではない rel="canonical" 指定をしているサイトも多いし、悪用されるとおかしなSEOスパムにもつながりかねないので、やむを得ないのだろう。

Yahoo!ニュースが常時HTTPS化
pixivやBASEも （Yahoo!ニュース スタッフブログ）

Yahoo!ニュースが常時HTTPSに移行した。それにともなうURL変更をヤフーがアナウンスしている。

ヤフーは、検索を含むすべてのサービスの常時HTTPS化を進めている（AOSSL）。一部のサービスはまだ移行が終わっていないようだが、大部分はHTTPSになっている（2017年3月には完了予定としていた）。

他国と比べて日本は、ウェブサイトの完全HTTPS化が遅れている。しかしそれでも確実にHTTPSは普及している。最近では、イラスト投稿サイトのpixivや、ECサイトのプラットフォームBASEがHTTPS化した。

あなたの運営サイトのHTTP移行はもう完了しているだろうか？まだだとしたら、移行の予定はたっているだろうか？

手軽にA/Bテストができる、Googleオプティマイズの正式版が登場
三拍子も四拍子もそろったA/Bテストツール （アナリティクス 日本版 公式ブログ）

長らく待望されていた、グーグル製のA/Bテストツール「Googleオプティマイズ」が、正式に一般公開され、ベータ版ではなく正式版となった。

Googleオプティマイズは、WebサイトなどでA/Bテストを実行するためのツールだ。2016年9月にベータ版として公開されていたが、3月31日（日本時間）に、いよいよ正式版になった。

ベータ版には、25万人以上のアカウントの開設申請があったそうだ。それだけA/Bテストの需要があるという証明だ。

A/Bテストは敷居が高いように思うかもしれないが、Googleオプティマイズは手軽にA/Bテストを実施できる。グーグルは、とっつきやすさとして次のような特徴をアピールしている。

• 導入しやすい
• 使いやすい
• わかりやすい
• 試しやすい

Googleオプティマイズは、Googleアナリティクスと連携して動作する仕組みだ。すでにサイトにGoogleアナリティクスを導入しているのならば、サイト側のタグの修正はほんの1行で済む。

Googleアナリティクスにも「ウェブテスト」の機能があったが、テストページを別URLで用意するか、そうでなければ高度なJavaScriptプログラミングが必要だったため、使い勝手は非常に悪かった。

それに対してGoogleオプティマイズは手軽にA/Bを実施できる。改善案のバージョンも、HTMLやJavaScriptの知識がなくても設定できる。実際に試してみたが、非常に使いやすく、レポート結果もわかりやすい。

サービスは「Googleオプティマイズ」と「Googleオプティマイズ360」の2種類がある。

通常のGoogleオプティマイズのほうは、無料でだれでも利用できるバージョン。Googleオプティマイズ360のほうは、高度な機能を備えた上位バージョンで有償だ。

通常版は360版と比べると、次のような機能制限がある。

• テスト数に制限がある（3テストまで）
• 多変量テストができない（制限）
• Googleアナリティクスのオーディエンスターゲティングを利用できない
• テストの評価指標をテスト実行中に変更できない
• 公式サポートやSLAがない
• など

しかし一般のウェブサイトで利用する分には、通常のGoogleオプティマイズでも当分は不自由しないだろう。

ユーザー体験向上やコンバージョン率アップなどのサイト改善のために、Googleオプティマイズ正式版でA/Bテストを実施してみよう。

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

今週は、筆者が米サンノゼで先月参加したSMX West 2017カンファレンスのセッションレポートを3本お届けする。

• 2人のGoogle社員が何でも答えてくれた――フレッドアップデート、PWA、重複コンテンツペナルティ、機械学習などなど #SMX West 2017

  盛り上がりました！

  ★★★★★

  • すべてのWeb担当者 必見！
• 「MFIでは表示速度をランキング要因にしない」をGoogleが撤回、速いページを評価する ＃SMX West 2017

  モバイルだからこそスピードが求められる

  ★★★★☆

  • すべてのWeb担当者 必見！
• Google モバイルファーストインデックス導入はまだ数か月先、”クオリティ ニュートラル”を目指すため #SMX West 2017

  慌てふためかないことが大切

  ★★★☆☆

  • MFIを気にしている人だけ

海外のSEO/SEM情報を日本語でピックアップ

グーグルが力説、「速いサイトは儲かるサイト」
コンバージョン向上のためにスピード改善に励もう （LukeW）

コンバージョン（成約）の向上をテーマにしたカンファレンスを、グーグルがアイルランドで開催した。そのなかで、モバイルサイトの高速化がECサイトの売り上げに大きく影響することを解説したセッションがあった。

そこで語られた内容の重要ポイントをグーグルのロブルースキー氏が個人ブログにまとめているので紹介する（強調は筆者による）。

• スマートフォンのパフォーマンス（表示速度）には制限があるが、ユーザーは速いことが当然のように思っている。

• モバイルECは購入プロセスの初期段階に位置する。50%のユーザーはブランド（社名や商品名、サービス名）にモバイルで最初に接触する。

• ほとんどの場合、コンバージョンに至るまでに（単一のデバイスで完結するのではなく）平均で2.6個のデバイスを経由（使い分け）している。

• 米国のショッピングサイトの表示にかかる時間は平均7秒。

• ページの表示時間が1秒から3秒に遅くなると、直帰率は32%悪化すると予想される。

• モバイルでページ表示速度が1秒速くなると、コンバージョン率が27%改善した。

• モバイルの表示速度は1秒以内が理想。しかし、もろもろの処理に600ミリ秒はかかるので、実際にサイトオーナーが管理できる範囲は400ミリ秒程度しかない。

• モバイルページの表示速度を改善する際にまず調査すべきは次の3つ。

  • 画像
  • 縮小されていないリソース
  • リクエストの数

• 画像は、平均するとウェブのデータの68%を占めている。画像を圧縮すれば転送データ量を削減でき、表示を高速化できる。

  画像がスクリーンに見える範囲に入ったときだけに読み込まれる「Lazy Load」（遅延読み込み）を使うのは良い手法。しかし、「download and hide」（ダウンロードしておいて隠す手法）や「download and shrink」（ダウンロードしておいて小さくしておく手法）は、使うべきではない。

• リソースを最小化すること。CSSやJavaScriptを圧縮（minify）すると、転送サイズを70%削減できる。さらにGZIP圧縮を使うと、転送サイズはさらに減らせる。

• ウェブの68%のサイトは50個以上のリソースをリクエストする。次のようなことをうまくすれば、リクエスト数を減らせる。

  • ブラウザキャッシュ
  • ページのリソースを統合する
  • JavaScriptを非同期で読み込む
  • ファーストビューのCSSを優先読み込みさせる

• リダイレクトの多用は、可能ならば避けるべき。それぞれのリダイレクトで「DNS参照」「TCP接続」「データ転送」の時間がかかるからだ。

• モバイルサイトのスピードは収益にかかわる要素だとみなすべき。

ユーザーは速いサイトを望んでおり、速いことは売上アップにも繋がることをしっかりと認識してスピード改善に取り組みたい。

サイト内検索ページを削除するアルゴリズムをグーグルは持っている
ユーザーの役に立たないから （The SEM Post）

サイト内検索の結果ページを、通常ページのようにインデックスさせているサイトがある。しかしグーグルは、専用のアルゴリズムによって、サイト内検索結果ページをグーグルの検索結果に出さないようにしているようだ。

米サンノゼで先月開催されたSMX West 2017カンファレンスで、グーグルのゲイリー・イリェーシュ氏は次のようにコメントした。

一般的に言って、僕たちはサイト内検索ページがインデックスされることを嫌う。ほとんどの場合、ユーザーの役に立たないからだ。

そういったページをインデックスから取り除くアルゴリズムを実際に持っていて、基本的にクロールしないようにする。

ただ、うまくいかないこともある。そんなときは、手動で介入して、インデックスされてしまった内部検索結果ページのために新しいルールを作成する。

サイト内検索結果ページは、通常はページが単純に並んでいるだけだ。

もし、どこかのサイトのサイト内検索結果ページがグーグルの検索結果に表示されたら、検索ユーザーはどうなるだろうか。グーグルで何かを検索して、その検索結果ページが表示され、そこから飛んだ先でまた別の検索結果を見ることになる。この状況は、良いユーザー体験だとはいえない。

サイト内検索ページをインデックスさせることで、サイトのボリュームを水増しし、それでグーグルの評価を上げることが可能だった時代が、過去にはあった。しかし今はまったく役に立たない手法だ。むしろ低品質ページが増えることで、評価が下がると考えるほうが自然だろう。

ビッグキーワードで上位表示したいなら画像が狙い目？
挑戦してみるといいかも （Gary Illyes on Twitter）

グーグルのゲイリー・イリェーシュ氏が、次のようなSEOのTIPSをツイートした。

イリェーシュ氏が言及しているのは、ウェブ検索結果に差し込まれる画像や動画のユニバーサル検索結果のことだ。

ユニバーサル検索結果に含めるのは、ウェブ検索で上位表示するよりはたしかに難易度が低いように思える。写真や動画を検索ユーザーが求めているようなキーワードなら、狙ってみるといいかもしれない。

5年前に削除したURLにGooglebotが今でもアクセスしてくる。そういうもの？
Googlebotは忍耐強く繰り返しクロールを試みる （John Mueller on Twitter）

5年前に削除したページがあります。そのURLは404を返していて、バックリンクもないのですが、いまだにGooglebotがアクセスしてきます。これは普通のことですか？

こうした質問をツイッターで受けたグーグルのジョン・ミューラー氏は、次のように答えた。

ありうることだ。Googlebotは忍耐強いんだ（笑）。そのURLが依然として削除されたままなら、まったく問題ない。

クロールバジェットの浪費に関しても心配いらない。

たとえ404や410を返してたとしても、いったん発見したURLに対してはGooglebotは半永久的にクロールを試みると思って問題ない。何度か404が返ったとしても、ミスで一時的にページが消えていただけかもしれないし、ひょっとしたら復活している可能性がゼロではないからだ。

だから、削除したページがクロールされることは気にしなくていい。

通常のURLと比べたらロボットの訪問頻度は格段に落ちるはずだ。クロールやインデックス、ランキングに悪影響が出ることはないので、不安を感じなくていい。

そもそも、グーグルがどのURLをクロールするかは、あなたがどんなページをサイトで公開しているかと直接は関係ない。あなたのサイトで使っているCMSのデータベースにグーグルがアクセスできるわけではないのだから。

Googlebotは、既知のURLからリンクをたどるほか、さまざまな情報をもとにクロールしている。そのため、想定しないURLに対してクロールが来るのは日常的にあることだと思っておくのがいいだろう。

HTTPSにした後は否認ファイルの再アップロードも忘れずに
正規URLに対して否認処理が実行されるから （John Mueller on Twitter）

もしあなたが自分のサイトをHTTPS化したのならば、忘れていないか確認すべきことが1つある。

それは、HTTPS化の前にリンクの否認ファイルをSearch Consoleでアップロードしていたとしたら、HTTPSで登録したサイト用にも忘れずにアップロードしておく、ということだ。

正規URL（HTTPS対応後は、https:で始まるURL）に対してリンク否認は処理される。HTTPSで登録したサイトに否認ファイルがなかったとしたら、それまでの否認が無効になってしまう可能性がある。

なお、HTTPのサイトにアップロードしてあった以前の否認ファイルは削除してもいいしそのままでもかまわない。

SEO Japanの
掲載記事からピックアップ

更新なし。