[レベル: 上級] ダイナミック レンダリングに関する技術ドキュメントを Google は更新しました。 ダイナミック レンダリングの利用を推奨せず、別の方法を採用するように強く促しています。 ダイナミック レンダリングは回避策であり非推奨 こちらは更新前のドキュメントの最初のセクションです。 こちらは更新後のドキュメントの最初のセクションです。 まず、最上段に掲載されている注釈が変更されました。 以前の注釈は次のとおりでした。 このページでは、JavaScript バージョン以外のページをクローラに提供する方法について説明します。ユーザー エージェント（モバイル、タブレット、パソコン）の種類に応じて異なるバージョンのページを提供する方法については、動的な配信に関するガイドをご覧ください。 現在の注釈です。 📝すずき注: この記事を書いている時点では日本語ドキュメントは未更新なので、訳は

[レベル: 上級] JavaScript によって挿入した rel="canonical" を Google は認識、処理できます。 JS 挿入の rel=canonical をサポートしなかったのは昔の話 「レンダリング前の、初期状態の HTML コードにある rel=”canonical” だけを Google は処理する」と John Mueller がちょっと前に言っていたが今でもそうなのか？ Google の Martin Splitt（マーティン・スプリット）氏に Twitter でこのように質問したユーザーがいました。 @g33konaut Does Google still only process rel="canonical" in the initially fetched, non-rendered HTML? John tweeted this a while a

[レベル: 上級] URL の末尾に付ける「/」（スラッシュ）の あり・なし の違いについて、Google の John Mueller（ジョン・ミューラー）氏が Google+ で説明しました。 結論を言うと、厳密に言えば技術的には異なるケースがありますが、正しく設定していれば通常は気にかける必要はありません。 この記事では、ミューラー氏の説明に僕からの補足を加えて解説します。 ドメイン名の最後に付けるスラッシュの有無は関係なし URL の最後につける「/」（スラッシュ）を、ミューラー氏にならって「トレイリング スラッシュ (Trailing Slash)」と呼ぶことにします。 おそらく「トレイリング スラッシュ」は明確に定義された技術用語ではなく、単純に「ディレクトリを示す場合の最後のスラッシュ」という意味の一般的な言葉ですが、SEO 俗語としてこの言葉を使います。 URL がドメイン

[レベル: 中級] Core Web Vitals（コア ウェブ バイタル）をページ エクスペリエンスとしてランキング要因に組み込む予定であることを Google は先週アナウンスしました。 この記事では、Core Web Vitals がランキング要因になることに関してよくある質問と今後出てきそうな質問に回答します。

[レベル: 中級] Core Web Vitals（コア ウェブ バイタル）を、検索のランキング要因に組み込むことを Google はアナウンスしました。 【UPDATE (2020/11/11)】 2021 年 5 月に導入することが決定しました。 詳細はこちらで。 【UPDATE (2021/04/20】 2021 年 6 月中旬の開始に延期しました。 詳細はこちらで。 Core Web Vitals とは ウェブページにおけるユーザー体験の向上を目指して Web Vitals というコンセプトを Google は先日導入しました。 具体的には次の 3 つのユーザー体験の健全性を対象とします。 ページの表示速度 ユーザー操作への反応性 視覚要素の安定性 Web Vitals を数値化するために特に重要な指標として次の 3 つを設定しました。 Largest Contentful Pai

[レベル: 上級] ウェブで優れたユーザー エクスペリエンスを実現するために “Web Vitals（ウェブ バイタル）” というコンセプトを Google は導入しました。 Web Vitals の土台として次の要素を重要視します。 読み込み時間 インタラクティブ性 ページ コンテンツの視覚的な安定性 それぞれの要素を測定するための指標とツールの提供を始めています。 Core Web Vitals: ウェブに関する 3 つの主な指標 Web Vitals を数値化するために、ウェブに関する特に重要な 3 つの指標を Google は設定しました。 ひっくるめて、“Core Web Vitals”（コア ウェブバイタル）と呼びます。 Largest Contentful Paint (LCP) First Input Delay (FID) Cumulative Layout Shift

[レベル: 上級] この記事では、Chrome Dev Summit 2019 の ウェブの高速化に関係するセッションのハイライトをレポートします。 ページの表示速度改善のためのツールやレポート、指標などがたくさん紹介されています。 ウェブが速く ウェブは速くなってきている。 昨年との比較で次のような改善が見られる。 First Contentful Paint: 7 % 速く First Input Delay: 27 % 速く ツール ウェブの高速化にはたとえば次のようなツールを使える。 PageSpeed Insights: URL を指定してそのページのパフォーマンス状況を検証できる Search Console のスピードレポート: サイト内のページをグループ化して速度状況を可視化できる 新しい指標 スピードを測定するために新しい指標を取り入れる。 Large Contentfu

[レベル: 上級] Dynamic Rendering（ダイナミック レンダリング）は、JavaScript で生成されるコンテンツを確実にインデックスさせるために利用できる仕組みです。 しかし、一時的な回避策としてみなしたほうがいいでしょう。 数年後には必要性が薄れているかもしれません。 最終的には、Server-side Rendering（サーバー サイド レンダリング）の実装が望まれます。 ダイナミックレンダリングよりも SSR JavaScript が関わってくるコンテンツのインデックスに特に問題を感じていないのであれば、Googlebot のレンダリング（正確には、Web Rendering Service）に任せて構いません。 特別な構成は不要です。 しかしながら、Googlebot が実行できない JavaScript を使っていたりインデックスされるまでに時間がかかりすぎ

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

[レベル: 上級] 多くのサイトが PWA に対応するようになってきました。 しかし、PWA がネイティブアプリの完全な置き換えになるには克服しなければならない問題がまだ残されているように思えます。 Stefan Dorresteijn 氏が dev.to で、PWA が現状で抱えている大きな問題を 3 つ指摘しました。 どんな問題なのかを、追加情報を交えてこの記事で完結にまとめます。 Apple の PWA サポート状況 Android の Chrome では、ネイティブアプリに引けを取らないほどに PWA の機能が充実してきました。 これに対し、iOS の Safari は PWA のほとんどの機能をサポートできていません。 こちらは、Google の Thomas Steiner 氏が作成した、PWA のサポート状況を検出するツールを使って iOS 版 Safari をチェックした状

[レベル: 上級] Google は、Signed HTTP Exchanges (以下、SXG) を有効にした検索を正式に公開しました。 2018 年 11 月下旬に試験用のデモ検索を公開していましたが、通常の検索で SXG が現在は有効になっています。 SXG は、AMP キャッシュにアクセスした際に AMP CDN から返されるキャッシュの URL ではなく、オリジナルの AMP コンテンツを配信している本来のサイトのドメイン名の URL で表示するための技術です。 自分のドメイン名の URL で表示できない AMP キャッシュ 検索からアクセスした AMP ページの URL はたとえば、次のようになっています。 https://www.google.co.jp/amp/s/www.example.com/amp/sxg.html これは、自分のドメイン名ではなく Google が管

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

[レベル: 中級] Google にインデックスさせたい URL に「#」（ハッシュ/フラグメント）を含めることは推奨されません。 # よりもあとの部分を削除した URL を Google（および、ほかの検索エンジン）はインデックスするからです。 代わりに History API を用いて一意の URL を各コンテンツに割り当てる構成が推奨されます。 ページ内移動の # はインデックスに問題なし ページ内の特定の場所にジャンプさせる name 属性または id 属性として # を利用するのであれば、インデックスに問題はおきません。 たとえば末尾に #f4 が付いている次の URL をクリック/タップすると、ページの途中に移動した状態で表示されます。 https://webtan.impress.co.jp/e/2014/05/09/17440/page/1#f4 Google のヘルプ記事

[レベル: 上級] dataset（データセット）の構造化データを Google がサポートするようになりました。 schema.org/Dataset の構造化データをマークアップすると、表形式で構成されたデータをリッチリザルトとして検索結果に表示できます。 定型フォーマットで整理したデータを検索結果に表示 dataset として定義できるデータの種類はさまざまです。 統一されたフォーマットで構成されたデータはたいてい dataset として利用できます。 たとえば、イメージしやすいのは CSV で保存されているデータです。 表形式になっていて、何らかのデータを系統的に提供しています。 独自の形式であっても、定型のフォーマットでデータをまとめていれば dataset として認められます。 コンピュータに読み込ませるデータは、定められたフォーマットになっていることが多いはずです。 そうした

[レベル: 上級] PWA の最も代表的な機能の1つである、”Add to Home Screen”（ホーム画面にアイコン追加）」の仕様が変更されます。 バナー型のプロンプトが現在は出現しますが、もっとコンパクトなバー型のプロンプトに変わります。 Chrome 68 以降は A2HS banner から Mini-infobar へ 仕様変更は、2018年7月にベータ版がリリース予定の Chrome 68 から適用されます。 現行の Chrome では一定の条件を満たすとスクリーンの下にバナーが出現して、ホーム画面アイコンの追加をユーザーに促します。 このバナーは “A2HS banner” と呼ばれます（”A2HS” は Add to (two) Home Screen の略)。 [鈴木補足] beforeinstallprompt イベントを呼び出すことでも A2HS バナーは表示可能

[レベル: 中級] Google は PWA の発展、普及に力を入れていますが、自社プロダクトの PWA 化にも乗り出しています。 この記事では、PWA 対応した Google マップと Google 検索について紹介します。 PWA 版 Google マップの Google Maps Go は Google Play からインストール可能 PWA に対応した Google マップは今年の2月に正式にリリースされていました。 その後 PWA 版 Google マップは「Google Maps Go」という名称で、Google Play にアプリとして掲載されるまでに至りました。 「Google Maps Go は、Google マップ アプリの軽量版のプログレッシブ ウェブアプリで」と説明に書かれています。 「プログレッシブ ウェブアプリ」が何なのかを一般ユーザーが理解できるかどうかはとも

[レベル: 上級] Google は生 の HTML に記述されている rel="canonical" だけを処理します。 クライント側のレンダリングで生成された rel="canonical" は完全に無視されます。 Web担当者Forum 連載コラムで先週取り上げ、その後 Twitter でも補足したことなのですが、特に、開発者と密接に連携してサイト管理している人にとっては重要な情報なので僕のブログでも触れておきます。 最初の状態で rel=”canonical” を返すこと JavaScript を使ってクライント側で rel="canonical" を生成させることができます。 言い換えれば、レンダリング後に rel="canonical" を挿入可能です。 JavaScript のフレームワークを使ってもいいでしょうし、Google タグマネージャでも実現可能です。 “クライント