[レベル: 初級] たしかにモバイルフレンドリーなはずなのに、Search Console のモバイル ユーザビリティ レポートでモバイルフレンドリーではないと警告が出ることがあります。 しかも、一部のページに対してだけです。 理由の1つとして考えられるのは、CSS のダウンロードに時間がかかりすぎていてレンダリングが完了できていない状況です。 CSS のダウンロードが遅い 英語版オフィスアワーで次のような質問が出ました。 Search Console のモバイル ユーザビリティ レポートでサイトの一部のページがモバイルフレンドリーではないと警告が出ている スマホで実際に見ると問題ない URL 検査ツールでライブテストするとモバイルフレンドリーとして判定される 「検証」を開始すると、モバイルフレンドリーではないとして失敗する John Mueller（ジョン・ミューラー）氏は、CSS のダ

[レベル: 上級] 記事が最初に公開された日時と最後に更新された日時の両方を構造化データでマークアップすることを、Google の John Mueller（ジョン・ミューラー）氏は推奨しました。 また、Google に日時を正しく認識させるために、構造化データで指定する日時とページ内に書かれている日時を統一することが重要です。 公開日と更新日の両方をマークアップする 構造化データでマークアップするなら、公開日と更新日のどちらを使用すべきか？ この質問にミューラー氏は、次のように回答しました。 どちらを使っても構わないが、個人的には両方マークアップすることを勧める。両方をマークアップすることができるはずだ。 Google のアルゴリズムには両方とも役に立つ。 schema.org の Article や NewsArticle、BlogPosting などのタイプは、公開日と更新日の両方の

[レベル: 中級] 2018 年 10 月に英ロンドンで開催された SearchLove London 2018 で Google の John Mueller（ジョン・ミューラー）との Q&A セッションがありました。 司会者の Will Critchlow（ウィル・クリッチロウ）氏が、ハイライトをブログに公開しています。 そのなかから、SEO 業界で議論が尽きない「ドメインオーソリティ」と「サブドメイン vs. サブディレクトリ」に対する Google の見解を紹介します。 Googleは ドメインのオーソリティを見ているのか？ SEO 界隈でしばしば用いられる「ドメイン オーソリティ (Domain Authority)」というランキングシグナルに関して、ミューラー氏は次のように説明したとのことです。 Google はドメインレベルの指標を確かに見ている（ただし、それは MOZ の

[レベル: 上級] 求人検索に適用されるために必要な JobPosting 構造化データにおける、テレワーク用の仕様を Google は変更しました。 additionalProperty プロパティの代わりに jobLocationType プロパティを使います。 JobPosting 構造化データのテレワーク用マークアップ テレワークが可能な職種は従来は次のようにマークアップしていました（余談かもしれませんが、“テレワーク” は日本語です。遠隔で働くことを英語では、“Telecommute”（テレコミュート）と言います）。 "additionalProperty": { "@type": "PropertyValue", "value": "TELECOMMUTE" } サポートをすぐに打ち切る予定はないとのことですが、additionalProperty の利用を Google は現

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

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

[レベル: 初級] Google SearchLiaison の Twitter アカウント（運用は Danny Sullivan が、パーソナライズ検索に関する真相を解説しました。 パーソナライズ検索は実際にはほとんど適用されません。 一方で、パーソナライズ以外の要因で検索結果が異なってくることがあります。 この記事では、SearchLiaison による連投ツイートの要点をまとめて紹介します。 Over the years, a myth has developed that Google Search personalizes so much that for the same query, different people might get significantly different results from each other. This isn’t the case.

[レベル: 中級] Search Console の URL 検査ツールがそのページをクロールしたユーザーエージェントの情報を提供するようになりました。 モバイル ファースト インデックスに移行しているかどうかの確認に利用することもできそうです。 URL 検査にユーザーエージェント 対象範囲レポート（インデックス カバレッジ）から URL 検索ツールを実行すると、現在インデックスされている URL の状況を確認できます。 このレポートに、ユーザーエージェント (User-Agent, UA) の項目がしばらく前に追加されました。 「スマートフォン用 Googlebot」と「パソコン用 Googlebot」のどちらがそのページを直近でクロールしたがわかります。 MFI 移行の確認に利用可能 モバイル ファースト インデックス（以下、MFI）に移行したサイトでは、スマートフォン用 Google

[レベル: 中級] この記事では、11 月 12 〜 13 日に米サンフランシスコで開催された Chrome Dev Summit 2018 のセッションをレポートします。 セッションのテーマは、EC サイトにおけるパフォーマンス改善施策です。 EC サイトではどのような方針でパフォーマンス改善を進めていくべきかを成功事例を交えながら 2 人のスピーカーは解説しました。 ユーザージャーニーの改善がもたらすもの EC サイトを構成するさまざまなツールボックスがある。 どれを使うにせよ、大切なことはユーザーに焦点を当てること。ユーザージャーニーのすべてを通じて、ユーザーに違和感を感じさせてはいけない。 事例: saatva オンラインショップの saatva は、速くてスムーズな購入体験をユーザーに提供したかった。そこで AMP を導入した。 商品詳細ページを AMP 化した。検索から来たユー

[レベル: 上級] この記事では、11 月 12 〜 13 日に米サンフランシスコで開催された Chrome Dev Summit 2018 のセッションをレポートします。 今年の Chrome Dev Summit で Google が特に力を入れていたテーマはウェブのパフォーマンス改善でした。 モバイルウェブ高速化の成功事例のセッションと高速化のための最新テクニックのセッションを先週はこのブログでレポートしています。 この記事で紹介するセッションのトピックは、パフォーマンス改善に役立つツールです。 ウェブサイトの高速化にはどんなツールが利用できるのでしょうか？ 一緒に見ていきましょう。 Metrics 何かを改善しようとするなら、計測することが重要。まず何を計測するかのMetrics（指標）を決める。ユーザーにかかわる指標を計測する。 ウェブページでは、次の 3 つを指標にするといい。

[レベル: 上級] 検索エンジン向けの 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 が重

[レベル: 中級] Google が提供するパフォーマンス測定ツールの PageSpeed Insights が分析エンジンに Lighthouse を使用するようになりました。 英語および日本語の公式ブログでアナウンスが出ています。 PageSpeed Insights, now powered by Lighthouse PageSpeed Insights、Lighthouse の使用を開始しました PSI と Lighthouse の分析方法を統一 Lighthouse も Google が提供するパフォーマンス測定ツールですが、PageSpeed Insights（以下、PSI）とは異なる独自の仕組みでパフォーマンスを測定しています。 チェックする指標は同一ではないし、同じ指標だったとしても計測結果が違ってくることが普通にあります。 どちらも Google 製のツールなのにどちら

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

[レベル: 中〜上級] この記事では、昨日に続いて Chrome Dev Summit 2018 のセッションをレポートします。 セッションタイトルは “Get Down to Business: Why the Web Matters” 、モバイルウェブ、特にモバイルウェブの高速化が重要な理由をケーススタディとともに解説するセッションです。 モバイルウェブとスピード 回線速度が速い 4G がまだ普及していない国、地域がある。 ※暖色になるほど、4G が普及していない パフォーマンス改善で成果を上げたサイトが世界中に存在する。 wayfair: CV 10 % ⬆ ClickBus: 売上 15 % ⬆ Stylelight: クリックアウト CV 6.5 % ⬆ JD.ID: CV 43 % ⬆ LinkedIn: 求人応募 4 倍 ⬆ Spotify 事例 2107 年の時点では Sp

[レベル: 上級] この記事では、11 月 12 〜 13 日に米サンフランシスコで開催された Chrome Dev Summit 2018 に参加した際のセッションをレポートします。 セッションテーマは、JavaScript を多用したサイトを検索で発見されやすくするためのベストプラクティスと注意点です。 セッションスピーカーは、Google チューリッヒの Martin Splitt（マーティン・スプリット）氏と Google シドニーの Tom Greenaway（トム・グリーンアウェイ）氏です。 最新の JavaScript 技術で構成されたウェブサイトを検索フレンドリーにするための秘訣をマーティンとトムの2人がどんなふうに解説したのかを一緒に見ていきましょう。 JavaScript コンテンツの処理プロセス 1. クロール ⇒ 2. レンダリング ⇒ 3. インデックス 静的な

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

[レベル: 上級] コンテンツの著者が誰なのかを Google に伝えるために、著者のプロフィールページを作り構造化データでマークアップすることを Google の John Mueller（ジョン・ミューラー）は推奨しました。 Google+ の著者情報の廃止後は構造化データで 数年前までは、Google+ と連携することでコンテンツの著者情報を Google に伝えることができました。 しかしその後、著者情報プログラムは廃止されてしまいました（それどころか、Google+ 自体の廃止が決まっています）。 Google+ の著者情報を利用できない現状で、誰がそのコンテンツを作ったのかを Google に伝える方法として次の施策をミューラー氏は提案したのです。 サイトにプロフィールページを作る 構造化データでマークアップする プロフィールページをすでに持っている人も多いことでしょう。 Go

[レベル: 中級] Domain properties（ドメイン プロパティ）という Search Console の新しい機能を Google は一部のユーザーを対象に試験公開しました。 ドメイン プロパティは、複数のサブドメインやプロトコルのデータを統合してレポートする機能です。 ドメイン プロパティに含まれる URL テスト対象に選ばれたユーザーが Search Console にログインすると次のような ようこそ画面が表示されるようです。 ドメイン プロパティのヘルプ記事がすでにできあがってます（英語のみ）。 ヘルプによれば、ドメイン プロパティでは、特定のドメインのすべてのサブドメインとサブディレクトリ、そして http と https の両方のプロトコルのサイトのデータがすべて統合されます。 たとえば、example.com のドメイン プロパティには次の URL のデータがす

[レベル: 中級] PWA（Progressive Web Apps、プログレッシブ ウェブ アプリ）に対応したサイトを制作できる代理店のディレクトリを Google は公開しました。 Google お墨付きの PWA 代理店 この記事を書いている時点では、アジアまたはヨーロッパに拠点を構える 13 社の代理店が登録されています。 開発に携わったウェブサイトの URL とそのサイトの Lighthouse のスコアが掲載されています。 その代理店の技術力を知るための手がかりになりそうです（上のキャプチャでは、22feet Tribal Worldwide Pvt Ltd が制作したサイトのスコアは 100 点！）。 もし PWA を開発できるウェブ制作会社をあなたが経営しているのであれば、ディレクトリ登録してもらえるようにフォームから申請することができます。 審査に合格すればこのディレクト

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