[レベル: 上級] rel="nofollow" 属性の扱いを Google は変更しました。 従うべき命令としてではなく、手がかりのためのヒントとして利用するようになります。 また、nofollow の派生型として、link タグと用いる 2 種類の rel 属性を新たに導入しました。 nofollow 属性の扱いを変更 rel="nofollow" 属性が付いたリンクを Google はこれまでランキング要因としては利用していませんでした。 PageRank を渡すこともないしアンカーテキストも評価しません。 そして、nofollow 属性を命令 (Directive) として Google は扱い、必ず従ってきました（nofollow リンクが評価されている状況があるという分析もあるけれど、公式見解では nofollow リンクはランキング要因から除外されることになっている）。 今後

[レベル: 中級] ネイティブ Lazy-load を簡単に実装する WordPress 用のプラグインを Google が公開しました。 ネイティブ Lazy-load は JavaScript のライブラリを利用することなく loading 属性を追加するだけで、画像と iframe の遅延読み込みを可能にします。 1 か月前にリリースされた Chrome 76 でサポートされました。 設定不要、インストールするだけで WP で Lazy-load Native Lazyload プラグインの使い方は非常にシンプルです。 インストールして有効にするだけです。 設定項目はありません。 有効にすると、img タグと iframe タグに loading=”lazy” 属性をプラグインが自動的に追加します。 現状では、loading 属性をサポートするブラウザは Chrome 76（以上）だ

[レベル: 上級] Google Chrome 76 がネイティブ lazy-load をサポートするようになりました。 JavaScript のライブラリを利用することなく、ブラウザの標準機能として画像の遅延読み込みが可能になります。 ネイティブ lazy-load は開発版 Chrome (Canary) で試験運用されていました。 自動で遅延読み込み 次の動画は子猫の画像だけを掲載したデモ用ページをスクロールした様子です。 デベロッパーツールの Network パネルで見ると、スクロールに応じて画像が順に読み込まれているのがわかります。 この遅延読み込みは JavaScript で実装しているわけではなく、Chrome の標準機能として実装された lazy-load の機能で実現しています。 loading 属性でネイティブ lazy-load ネイティブ lazy-load を利用

[レベル: 上級] JavaScript を多用するウェブサイトの SEO のために必要な基本知識を解説するドキュメントを Google はデベロッパーサイトで公開しました。 ドキュメントに書かれている内容をざっくり紹介します。 Googlebot が JavaScript を処理するプロセス Googlebot による JavaScript の処理は次の 3 つのプロセスに大きく分かれます。 Crawling（クローリング） Rendering（レンダリング） Indexing（インデックシング） 2 番目のレンダリングが、静的な HTML ドキュメントにはないプロセスになります。 レンダリングが完了して初めて最終的なコンテンツがインデックシング プロセスに渡されます。 クローリングもレンダリングも、すぐ実行されるとは限りません。 “キュー” に保存され順番に処理されます（なので、レンダ

[レベル: 初級] 先日 Google はモバイル検索結果にファビコンを表示するようにしました。 このファビコンはドメイン単位、もう少し正確に言うとサブドメイン単位で決定されます。 したがってページ単位でファビコンを切り替えることはできません。 トップページで設定されたファビコンを取得 ヘルプページと検証結果から判断する限りでは、トップページで設定されたファビコンを検索結果に表示するファビコンとして Google は取得するようです。 ホームページのヘッダーに次の構文の <link /> タグを追加します。 Google では、ホームページをクロールするたびにファビコンの有無、またはファビコンの更新の有無を確認します。ファビコンを変更し、Google にその変更を知らせたい場合は、サイトのホームページのインデックス登録をリクエストできます。 ※強調は僕による ページごとにファビコンを変える

[レベル: 中級] 同じドメイン名のサイトから 3 件以上のページが検索結果に通常は同時に出現しないように検索の仕様を Google は変更しました。 検索結果の多様性を高めることが目的です。 同一ドメインのページは 2 件まで 同一ドメインのページが同時に複数表示されることがあります。 こちらは、僕のサイトからのページが 3 件並んだ（過去の）検索結果です。 今回の仕様変更により、基本的には 2 件までに制限がかかりました。 検索結果の多様性を高めることが狙い 同一サイトからの結果ばかりだと多様さが失われます。 違うサイトからのいろいろな情報を得たいというユーザーのフィードバックをもとに仕様を変更するに至ったとのことです。 検索結果のほとんどが同じサイトからというケースもありましたね。 例外あり どんなときでも絶対に 2 件までということでもありません。 特定のクエリにおいては、関連性が

[レベル: 上級] メジャーな 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 に害を与えるようには作られていないと自身で詳しく

[レベル: 上級] WordPress サイトを AMP 対応する公式プラグインのバージョン 1.0 安定版が正式公開されました。 AMP プラグインのディレクトリからダウンロードできます。 統一されたデザインと機能を AMP で実現 v1.0 の大きな特徴の 1 つは統一されたデザインと機能を AMP ページで実現できる点です。 v1.0 以前のプラグインは、AMP ページのデザインが変わってしまい通常のモバイルページと比べるとかなり簡素に変換されてしまっていました。 しかし、v.1.0 では、AMP ページの外観および機能は通常のモバイルページとなんら変わりありません。 最新の AMP プラグインには 3 つのモードがあります。 Native Mode（ネイティブ モード）: サイトを完全に AMP 化する。すべてのページが AMP になり、通常の PC ページやモバイルページはなくな

[レベル: 上級] 検索エンジン向けの Lazyload の推奨を Google は先日公開しました。 この推奨に関して、2つの補足をこの記事では紹介します。 1. polyfill は重要 ドキュメントでは、IntersectionObserver API と polyfill の2つの技術を実装するように Google は指示しています。 「SEO」という観点では、polyfill が非常に重要です。 現在の WRS（Web Rendring Service、Google 検索のレンダリングシステム）は、Chrome 41 相当です。 IntersectionObserver API は Chrome 51 からサポートされました。 したがって、IntersectionObserver API で遅延読み込みさせる画像を Google は認識できません。 そこで、polyfill が重

[レベル: 中級] 昨日とおとといに続いて、今日も 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（パフォーマンス バジェット）

[レベル: 上級] リッチリザルト テストツールで、コードスニペットによる検証が可能になります。 現状では、URL を入力し公開されているウェブページの検証だけに対応しています。 米サンフランシスコで先週開催された Chrome Dev Summit 2018 で、Google の Matin Splitt 氏がセッション中に紹介しました。 （※今日までブログ更新を休む予定でしたが、今日から再開します。） RRTT でコードによるリアルタイム検証 リッチリザルト テストツール（以下、RRTT）のトップページに「< >コード」のオプションが見えます。 現在の RRTT では、URL の入力ボックスだけが表示されています。 コードを貼り付けて検証できます。 コードスニペットによる検証は、構造化データ テストツールでは可能です。 しかしながら、その後継ツールとしてベータ版が公開されている RRT

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

[レベル: 上級] Lazy Load で読み込ませる画像を SEO に対応させる、言い換えれば、検索エンジンにインデックスさせるための方法として、次の2つを Google の John Mueller（ジョン・ミューラー）氏は Google I/O 2018 のセッションで推奨しました。 <noscript> タグ 構造化データ Lazy Load 画像は SEO に不向き Lazy Load で読み込ませる画像が SEO に不向きな理由は以前にも説明したことがありますが、もう一度簡単におさらいしておきます。 そんなの知ってるよという方はここは読み飛ばして構いません。 Lazy Load（レイジー ロード）とは、遅延読み込みのことです。 画像の表示によく使われます。 ページを表示した段階では画像を読み込ません。 スクロールして、ユーザーの見えるエリアに画像（が表示されるべき場所）が入った

[レベル: ALL] 2018年4月6日に開催された ISM Spin-off #4 – Google Search Night で Google の Gary Illyes（ゲイリー・イリェーシュ）氏が基調講演しました。 この記事では、その講演のなかからモバイル ファースト インデックス (以下、MFI) に関する部分をレポートします。 MFI の現状 MFI によくある誤解――インデックスは1つ。モバイル検索用とPC 検索用に別々のインデックスを作成するわけではない 準備ができたサイトから移行を始める。MFI 移行によって検索トラフィックが減らないようにする MFI 移行によって起こる目に見える変化: クロールの大部分がモバイル版 Googlebot になる モバイル版ページからコンテンツが取得される MFI に移行したかどうかを調べる方法: Search Console に届く通知

[レベル: 初〜中級] 導入時期が依然として不透明なモバイル ファースト インデックスですが、導入に備えて確実に必要になる対処がいくつかあります。 そのうちの1つが alt 属性です。 モバイル向けページで alt 属性 をもし省略しているなら、今すぐにでも設定する必要があります。 ひとたびモバイル ファースト インデックスへの切り替えが実行されれば、検索結果、特に画像検索結果に悪い影響が出るかもしれません。 alt 属性を設定していなモバイルサイトが多い モバイルサイトでの alt 属性の状況について、Google の John Mueller（ジョン・ミューラー）氏は英語版のオフィスアワーで 次のように注意を促しました。 alt 属性に関してモバイルファーストインデックス チームから特によく聞くのは、alt 属性を画像に設定していないサイトがたくさんあるということだ。 alt 属性がな

[レベル: 上級] この記事では、EC サイトを AMP 対応させる方法を解説します。 米カリフォルニア州マウンテンビューで先週開催された Google I/O 2017 で僕が参加したセッションにもとづきます。 AMP はニュースサイトやブログのような静的コンテンツを提供するサイトに向いています。 一方で、EC サイトのようなダイナミックな機能を必要とするサイトには向いていません。 向いていないというよりも、機能不足で実装不可能と行ったほうが正確でしょうか。 しかし状況は変わりつつあります。 AMP プロジェクトは EC サイトにも AMP を使えるように取り組んでいます。 AMP 対応した EC系サイトも増えつつあります。 それでは、どのようにして EC サイトをAMP 対応させていくかを、これから解説します。 EC サイトで利用できる AMP コンポーネント EC サイトでよく使われ

[レベル: 上級] 5月17〜19日に米マウンテンビューで開催された Google I/O 2017 の「From AMP to PWA: Progressive Web AMPs」というセッションで、日本の楽天レシピの成功事例が紹介されました。 AMP と PWA を組み合わせたことによって、楽天レシピは大きな成果を手にしています。 AMP + PWA による楽天レシピの成果 AMP と PWA を組み合わせた構成により、次のような結果が楽天レシピでは出たそうです。 AMP ページにランディングした場合、1ユーザーあたりの滞在時間が 50% 増 AMP ページから次のページへのクリック率が 3.6 倍 ホーム画面アイコン追加 ホーム画面アイコンを追加したユーザーは訪問数が 1.7 倍 ホーム画面アイコンを追加したユーザーはページビューが 3.1 倍 プッシュ通知 プッシュ通知で、2週目か

[レベル: 中級] この記事では、日本からでも、google.com（米Google） を使って英語表示で検索する方法を説明します。 もし仕組みの説明には興味がなければ、下をブラウザにブックマークしてください。 https://www.google.com/?gl=us&hl=en&gws_rd=cr&pws=0 このURLにアクセスすれば、日本にいても Google.com で英語表示で検索できます。 このURLが意味することに興味があれば解説を読み進めてください。 リダイレクト&日本語を強制される 2、3年前から、米国以外ではgoogle.comで英語の検索をすることが難しくなりました。 まず、www.google.com にアクセスすると初回は www.google.co.jp に強制的にリダイレクトされます。 ページの右下に「Google.com を使用」というリンクがあるのでクリ

[レベル: 中級] Google検索でリッチスニペットを表示させるための構造化データとして、旧式の data-vocabulary.org を今でも利用することができます。 しかし、現在Googleが公開している仕様としての schema.org を利用することが推奨されます。 schema.org 対 data-vocabulary.org GoogleのJohn Mueller（ジョン・ミューラー）氏がTwitterでフォロワーから schema.org と data-vocabulary.org の利用について質問を受け、それに対してアドバイスしています。 @Ck_eMrkg I'd use the markup as in our docs: https://t.co/IUvzMZGv2W — John Mueller (@JohnMu) 2016年4月13日 @Ck_eMrkg

[レベル: 上級] サイトリンク検索ボックス向けの schema.org を用いた構造化データをマークアップすると、検索結果に自サイトのサイト内検索システムで実行できる検索ボックスを表示することができます。 このサイトリンク検索ボックス用の構造化データマークアップは、Google の検索結果にサイトリンク検索ボックスがすでに表示されているサイトに対してのみ機能します。 検索結果にサイトリンク検索ボックスが表示されていないサイトでマークアップしても、サイトリンク検索ボックスを表示するように Google に指示を出すことにはなりません。 サイトリンク検索ボックスのマークアップはどちらのバージョンを選ぶかの指示 Google の John Mueller（ジョン・ミューラー）は、サイトリンク検索ボックスのための構造化マークアップについて次のように説明しました。 サイトリンク検索ボックスに関して