[レベル: 中級] この記事では、FAQ（よくある質問）のリッチリザルトの成功事例を紹介します。 サントリーは、検索結果での FAQ リッチリザルトの表示により Google 検索からのトラフィックを対前年比で約 4 割増加させました。 Q&A コンテンツを FAQ 構造化データでマークアップ お客様からの質問に回答するコンテンツに FAQPage 構造化データをサントリーは実装しました。 FAQ のリッチリザルトを Google の検索結果に表示させるためです。 500 以上のページが現在 FAQ リッチリザルト対応しています。 検索トラフィックが対前年比で 141 %⬆ その結果、前年と比較して検索トラフィックが 141 % に増加しました。 試験運用に参加 FAQ のリッチリザルトが公開されたのは今年の 5 月です。 ですが、サントリーは、一般公開前の早期試験運用に参加していました。

[レベル: 上級] URL 検査ツールやモバイルフレンドリー テスト ツールなど各種ツールのレンダリングエンジンを Google はアップデートしました。 最新の JavaScript を実行できます。 ツールのレンダリングエンジンは古いまま Googlebot のレンダリングエンジン (WRS: Web Rendering Service) は、常に最新の Chrome と同等のレンダリング機能を持つように今年 5 月に改良されました。 しかし、URL 検査ツールやモバイルフレンドリー テストなどのツールは古いレンダリングエンジン (Chrome 41 相当）のままでした。 そのため、JavaScript が正常に実行されているのかどうかをツールで検証することが困難でした。 ツールがアップデートしたことで、安心して検証が可能になります。 レンダリングエンジンがアップデートされたツールは次

[レベル: 上級] robots.txt の noindex 構文のサポートを終了することを Google は告知しました。 REP のインターネット標準化にともなう決定です。 機能していたが未サポートだった robots.txt の noindex クローラのクロールを拒否するために robots.txt では Disallow 構文を用います。 User-agent: * Disallow: /dontcrawl.html Google では、クロールではなくインデックスを拒否するために Noindex 構文が使えていました。 User-agent: Googlebot Noindex: /dontindex.html HTML の head セクションで使える noindex robots meta タグと同じ働きをします。 しかし、robots.txt での noindex を G

[レベル: 中級] サイトマップを生成する機能を WordPress のデフォルトの機能として実装するプロジェクトが始まりました。 WordPress のコアにサイトマップを組み込む 現状では、サイトマップを作成する機能は WordPress の標準機能としては備わっていません。 サイトマップ生成にはプラグインをインストールするかツールを自作します。 WordPress の人気プラグインの上位 15 個のうち、実に 4 個がサイトマップ生成の機能を提供しているとのことです。 WordPress ユーザーがサイトマップを必要としている証明です。 SEO においてもサイトマップは今や必須と言っていいでしょう。 ウェブで最も使われている CMS である WordPress で構築されたサイトの多くが SEO にも取り組んでいるはずです。 こういった経緯もあり、WordPress のコア機能として

[レベル: 中級] 2019 年 7 月 1 日から新規サイトに対してモバイル ファースト インデックス（以下、MFI）をデフォルトにすることを Google は事前通知しました。 この日以降、 Google が新たに認識したサイト（それまで存在を検出していなかったサイト）は、最初から MFI でインデックスされます。 つまり、PC 向けページではなくモバイル向けページがインデックスの対象となりランキング決定に利用されます。 新規サイトは MFI への切替なし 現状ではすべてのサイトが今までどおりに PC 向けページがインデックスされます。 準備が整ったと判断されたサイトが MFI へと移行します。 昨年 12 月の時点では、検索結果に表示される 50 %以上のページが MFI に移行したとのことでした。 7 月 1 日からは初めからモバイル向けページがインデックスされるので、移行プロセス

[レベル: 上級] 検索品質評価ガイドラインを 2019 年 5 月 16 日付けで Google は更新しました。 検索品質評価ガイドラインは、Google 検索の品質を評価する際に評価者が参照する解説書です。 もともとは非公開でしたが、2015 年 11 月に一般公開されました。 検索品質評価ガイドラインは、不定期に内容が更新されます。 僕自身は最新版をまだ読めていません。 The SEM Post の　Jennifer Slegg（ジェニファー・スレッグ）が更新前後の差分をまとめています。 最新版の検索品質評価ガイドラインには大きな変更点はないようです。 しいて挙げると、次の 3 点が比較的特筆すべき変更になるようです。 E-A-T からページ品質へ 著者の専門性要件の緩和 インタースティシャルへの言及 The SEM Post の記事を参照して、おおまかに変更点を解説します。 E-

[レベル: 上級] メジャーな 2 大 JavaScript フレームワークである Angular と React、そしてこの 2 つには及ばないもののシェアを伸ばしてきている Vue.js を採用したウェブサイトは基本的に Google 検索においてうまく機能します。 SEO と相性が悪いフレームワークではありません。 ただしいくつか気をつける点もあります。 Angular/React/Vue は Google SEO に問題なし JavaScript SEO をテーマにした DeepCrawl との Q&A 動画チャットで、Google の Matin Splitt 氏が、メジャーな JavaScript フレームワークの Google 検索での利用について説明しました。 次の 3 つの JS フレームワークは Google の SEO に害を与えるようには作られていないと自身で詳しく

[レベル: 中級] Google の現在の検索結果には、従来の青色リンクのほかリッチリザルトや強調スニペット、ナレッジグラフ カードなどさまざまな特殊機能が加わっています。 こうした検索結果に含まれるさまざまな形式を解説したヘルプ記事を Google は公開しました。 ページやサイトに最適な機能のアドバイスもしています。 「サイトの検索結果機能を有効にする」ヘルプ記事 検索結果の一般的なカテゴリとして、次が挙げられています。 通常の青色リンク 拡張機能 リッチリザルト ナレッジグラフ カード 強調スニペット Onebox の検索結果 こちらは、通常の青色リンクの説明です。 こちらは、ナレッジグラフ カード の説明です。 こちらは、Onebox の検索結果説明です。 リッチリザルトは特別で、カーソルを当てるとポップアップが出現し、さらに詳細を説明しているデベロッパーサイトへリンクしています（

[レベル: 中級] 昨日とおとといに続いて、今日も Chrome Dev Summit 2018 のセッションレポートをお届けします。 セッションのタイトルは “Speed Essentials: Key Techniques for Fast Websites” です。 昨日レポートしたセッションと同じようにモバイルウェブの高速化がテーマです。 しかし、こちらはより実践的な内容になっています。 パフォーマンス改善に非常に役立つテクニックが満載です。 パフォーマンス改善の優先対象は画像とJS、フォントの3つ モバイルウェブで 1 ページあたりデータ量が多いリソースは次の順番（HTTP Archive 調べ） 画像 (約 500 KB) JavaScript (約 380 KB) フォント (約 80 KB) この 3 つは Performance Budget（パフォーマンス バジェット）

[レベル: 上級] SEO と相性がいい Lazyload の実装を解説するドキュメントを Google はデベロッパー向けサイトで公開しました。 3つのアドバイス ドキュメントには3つの指針が書かれています。 1. viewport 内で見えるようにする viewport 内にあるコンテンツは、必ず Google にも見えるようにしておきます（viewport は簡単に言えば、スクリーンに表示される領域）。 つまり、重要なコンテンツが viewport に入ったときは確実に読み込ませます。 IntersectionObserver API と polyfill を実装するように Google は指示しています。 2. 無限スクロールでは paginated loading を使う 無限スクロールを採用している場合は、paginated loading を実装します。 paginated

[レベル: 上級] Googlebot がページをクロールするときにかかるダウンロード時間が 1,000 ミリ秒を超えると、クロールに支障をきたすかもしれません。 一応の目安として、100 〜 500 ミリ秒以内を考慮しておくとよさそうです。 ページのダウンロード時間は 100 〜 500 ミリ秒が理想、1,000 ミリ秒は遅すぎ （旧）Search Console のクロールの統計情報レポートでは、ページのダウンロード時間の情報を確認することができます。 ページのダウンロード時間は、Googlebot がリソースを純粋にリクエストするのにかかった時間を示すデータです。 PageSpeed Insights のようにユーザーが使うブラウザの表示にかかる時間ではありません。 リソースは、HTML のほか画像や CSS、JavaScript、PDF なども含みます。 ダウンロード時間の目安に関

[レベル: 上級] Service Worker の機能を利用することにより、Google は繰り返し行われる検索の結果を 2 倍速く表示するに成功したそうです。 VentureBeat（ベンチャービート）が報じています。 SW + Navigation preload で速度2倍 繰り返される検索にこの速度改善は適用されるとのことなので、Service Worker のキャッシュ機能を利用しているのでしょう。 キャッシュは Service Worker が持つ定番の機能です。 さらに、Navigation preload という仕組みを Google は Service Worker で構成しているとのことです。 状況によっては、Service Worker が起動するまでの時間がネットワークのレスポンスを遅らせてしまうことがあります。 結果として、ページの読み込みも遅くなります。 Na

[レベル: 上級] AMP Stories (AMP ストーリー) の v1.0 が公開され、すべての開発者が利用できるようになりました。 これまでは、申請してホワイトリストに登録してもらう必要がありました。 通常の検索での AMP ストーリー AMP ストーリーは、本をパラパラとめくるようにして物語風に一連の情報を閲覧できる AMP の機能です。 文字ではなく、画像や動画をふんだんに使ったビジュアルさに特徴があります。 AMP ストーリーは、試験用の Google 検索でしか見ることができませんでしたが、今は通常の検索で見ることができます。 こちらは Washington Post（ワシントン・ポスト）の AMP ストーリーです（“Washington Post” でモバイル検索すると、AMP ストーリーのカルーセルが出てきます）。 AMP ストーリーのもう少し詳しい解説は、Web担当者

[レベル: 中級] 【UPDATE】 この記事は事実を正しく反映していないことが判明しました。 こちらの記事で説明しています。 ページの読み込み速度をモバイル検索のランキング要因として用いる “Speed Update”（スピード アップデート）を Google は今月導入する予定です。 Speed Update は、本当に遅いページだけが影響を受けるアルゴリズムだと思われていました。 しかしながら実際には、速ければ速いほど評価が上がるアルゴリズムになっているようです。 Speed Update では、読み込み速度が速いと段階的に評価が上がる Speed Update の導入を事前アナウンスした公式ブログの記事は次のように説明していました。 The “Speed Update,” as we’re calling it, will only affect pages that delive

[レベル: 上級] JavaScript で構築されたサイトのために Dynamic Rendering（ダイナミック レンダリング）と呼ぶ仕組みを Google はサポートするようになります。 米マウンテンビューで開催された Google I/O 2018 のセッションで Google の John Mueller（ジョン・ミューラー）氏が発表しました。 Google が現在サポートする JS サイトのための3つのレンダリング構成 JavaScript でレンダリングされたコンテンツを適切にインデックスするために、次の3つのレンダリング構成を Google は現在サポートしています。 Client Side Rendering（クライアント サイド レンダリング）――クライアント側、つまりブラウザまたは Googlebot がすべてをレンダリングする。Googlebot がレンダリングで

[レベル: 上級] モバイル フレンドリー テスト ツールとリッチリザルト テスト ツールで、レンダリング後のソースコードと読み込めなかったリソース、JavaScript のエラーを取得できるようになりました。 モバイル フレンドリー テストとリッチリザルト テストがレンダリング検証ツールに早変わり 下のキャプチャはモバイル フレンドリー テスト ツールの実行結果です。 左に「ページの読み込みに関する問題」、右に「ソースコード」があります。 「ソースコード」を選択すると、Googlebot がレンダリングした後の HTML のコードを確認できます。 初期状態の素のコードではなく、DOM を解釈した後のコードというのがポイントです。 たとえば JavaScript で DOM を操作しているページで Googlebot が正しく実行できているかどうかをソースコードレベルで検証可能です。 「ペ

[レベル: 上級] オランダのアムステルダムで2月13〜14日に開催された AMP Conf 2018 に参加してきました。 この記事では、基調講演のハイライトをレポートします。 AMP の現状 3,100 万のドメインが AMP ドキュメントを発行 検索に出てくる AMP ページのクリックの 60% 以上が、ニュース以外のサイト AMP ページの滞在時間は2倍 AMP でコンバージョンが2倍 AMP が目指すのは、いまだかつてないほどにユーザーにフォーカスした強力な、開かれたウェブを実現すること。 そして、誰でも使える一般的なものにすること。 AMP Stories ユーザーのコンテンツ消費の仕方が変わってきた。モバイルでは長い記事を読みずらく、1〜2分でユーザーは読む。 そこで、AMP Stories（AMP ストーリー）を導入した。 AMP Stories は次のような機能を持つ。

[レベル: 上級] AMP 対応したニュース記事に掲載する画像のサイズ要件を Google は変更しました。 今までよりも大きなサイズの画像でないと、AMP カルーセルに表示されなくなる可能性があります。 横幅が 696 px から 1200 px へ 画像の横幅の最低サイズが拡大されました。 Article（記事）の構造化データの実装方法を解説している Google のデベロッパー向けサイトのドキュメントが次のように更新されています。 【以前】 Images should be at least 696 pixels wide. （画像は横幅が最低でも 696 ピクセルでなければなりません。） 【現在】 Images should be at least 1200 pixels wide. （画像は横幅が最低でも 1200 ピクセルでなければなりません。） 画像の横サイズ要件が、696

[レベル: 初級] Google は、『Search Engine Optimization (SEO) Starter Guide』（日本語名: 検索エンジン最適化（SEO）スターター ガイド）を大幅に改訂し新バージョンとして公開しました。 『検索エンジン最適化（SEO）スターター ガイド』とは 『検索エンジン最適化（SEO）スターター ガイド』は、Google が編集した、基本的かつ最重要な SEO の施策をまとめたマニュアル本です。 2008年11月に英語版が公開されました。 2009年6月には、日本語を含む40言語の翻訳版が出されました。 その後2010年9月に、内容を追加した更新版をリリースしています。 7年たった今でも依然として SEO のベストプラクティスだと Google は言うものの、モバイルの最適化がスマートフォンではなくフィーチャーフォンだったりと時代にマッチしなくな

[レベル: 中級] Googleは、Mobile First Index（モバイル ファースト インデックス）の導入を正式にアナウンスしました。 Mobile-first Indexing モバイル ファースト インデックスに向けて モバイル ファースト インデックスでは、PC向けページではなく、モバイル向けページの評価に主に基づいてランキングが決定されます。 Gary Illyes（ゲイリー・イリェーシュ）氏が米ラスベガスで10月に開催されたPubCon Las Vegas 2016で発表していたGoogle検索の仕様変更です。 正式な実施時期はまだ決まっていません。 今後数か月にわたり小規模な実験を行ったうえでの判断になるとのことです。 評価対象がPC向けページからモバイル向けページへ 詳細は公式アナウウンスを読んでいただくとして、概要としてはモバイル ファースト インデックス（以下、