ダイナミックレンダリングをGoogleはもはや推奨せず、回避策であり最終手段
[レベル: 上級] ダイナミック レンダリングに関する技術ドキュメントを Google は更新しました。 ダイナミック レンダリングの利用を推奨せず、別の方法を採用するように強く促しています。 ダイナミック レンダリングは回避策であり非推奨 こちらは更新前のドキュメントの最初のセクションです。 こちらは更新後のドキュメントの最初のセクションです。 まず、最上段に掲載されている注釈が変更されました。 以前の注釈は次のとおりでした。 このページでは、JavaScript バージョン以外のページをクローラに提供する方法について説明します。ユーザー エージェント（モバイル、タブレット、パソコン）の種類に応じて異なるバージョンのページを提供する方法については、動的な配信に関するガイドをご覧ください。 現在の注釈です。 📝すずき注: この記事を書いている時点では日本語ドキュメントは未更新なので、訳は
Google、モバイル検索に連続スクロールを導入。下位ページでもクリック率アップするかも
[レベル: 初級] Google はモバイル検索結果に連続スクロールを導入しました。 米 Google (google.com) の英語検索で始まっています。 スクロールすると次々と検索結果が出現 下にスクロールすると次々と検索結果が出現します。 一般的によく使われる “Infinite scrolling”（無限スクロール）という用語ではなく、“Continuous scrolling”（連続スクロール）と Google は呼んでいます。 連続スクロールは無限スクロールとは若干異なっています。 従来の 4 ページ目相当までは無限スクロールです（※ 4 ページの理由は後述）。 それ以降の結果を見るときは、今までのように “See more”（もっと見る）ボタンで次の結果を読み込みます。 連続スクロールの導入により、スワイプ動作でスクロールするだけで検索結果の続きを見ることができます。 検索
Googleページ エクスペリエンス アップデートは6月中旬から段階的に導入開始
[レベル: 中級] Google は、Page Experience Update（ページ エクスペリエンス アップデート）の導入を、当初予定していた 5 月から少し遅らせて 6 月中旬に開始することを Search Central 公式ブログでアナウンスしました。 段階的に展開していくとのことです。 アナウンス記事では、関連するそのほかの変更と Search Console の新しいレポートについても触れています。 ページ エクスペリエンス アップデートは 6 月中旬から段階的にロールアウト ページ エクスペリエンス アップデートに関する発表内容の要点は次のとおりです。 2021 年 6 月中旬に導入開始 ランキングシグナルとして完全に組み込まれるのは 8 月の終わり 完了までは段階的に展開していく 極端なランキング変動は想定していない ページ エクスペリエンス アップデートはもともとは
Googlebotが混合コンテンツを読み込まなくなるかも、Chromeのセキュリティ強化はSEOにも影響あり
[レベル: 上級] Chrome が混合コンテンツ (Mixed Content) をデフォルトでブロックするように仕様が変わります。 この仕様変更は Googlebot のクロールにも影響を与える可能性があります。 HTTPS ページなのに、HTTP で配信されたコンテンツはインデックスされなくなるかもしれません。 混在コンテンツを Googlebot は読み込むのか？ 混在コンテンツのデフォルトブロックが Googlebot に影響を与えるかどうか？ を先日のオフィスアワーで質問しました。 回答としては「影響はない」とのことだったのですが、質問の意図をうまく伝えることができていなかったみたいで僕が望んでいたような説明は得られませんでした。 Chrome のレンダリングエンジンを Googlebot は 採用しています。 Chrome のレンダリングに関わる変更は Googlebot に
Chromeがネイティブlazy-loadをサポート、JSなしで画像を遅延読み込み可能に
[レベル: 上級] Google Chrome 76 がネイティブ lazy-load をサポートするようになりました。 JavaScript のライブラリを利用することなく、ブラウザの標準機能として画像の遅延読み込みが可能になります。 ネイティブ lazy-load は開発版 Chrome (Canary) で試験運用されていました。 自動で遅延読み込み 次の動画は子猫の画像だけを掲載したデモ用ページをスクロールした様子です。 デベロッパーツールの Network パネルで見ると、スクロールに応じて画像が順に読み込まれているのがわかります。 この遅延読み込みは JavaScript で実装しているわけではなく、Chrome の標準機能として実装された lazy-load の機能で実現しています。 loading 属性でネイティブ lazy-load ネイティブ lazy-load を利用
PWAはネイティブアプリに今のままでは勝てない？ PWAが解決すべき3つの大きな課題
[レベル: 上級] 多くのサイトが PWA に対応するようになってきました。 しかし、PWA がネイティブアプリの完全な置き換えになるには克服しなければならない問題がまだ残されているように思えます。 Stefan Dorresteijn 氏が dev.to で、PWA が現状で抱えている大きな問題を 3 つ指摘しました。 どんな問題なのかを、追加情報を交えてこの記事で完結にまとめます。 Apple の PWA サポート状況 Android の Chrome では、ネイティブアプリに引けを取らないほどに PWA の機能が充実してきました。 これに対し、iOS の Safari は PWA のほとんどの機能をサポートできていません。 こちらは、Google の Thomas Steiner 氏が作成した、PWA のサポート状況を検出するツールを使って iOS 版 Safari をチェックした状
ダイナミックレンダリングは一時的な回避策、最終的にはSSRの実装を
[レベル: 上級] Dynamic Rendering（ダイナミック レンダリング）は、JavaScript で生成されるコンテンツを確実にインデックスさせるために利用できる仕組みです。 しかし、一時的な回避策としてみなしたほうがいいでしょう。 数年後には必要性が薄れているかもしれません。 最終的には、Server-side Rendering（サーバー サイド レンダリング）の実装が望まれます。 ダイナミックレンダリングよりも SSR JavaScript が関わってくるコンテンツのインデックスに特に問題を感じていないのであれば、Googlebot のレンダリング（正確には、Web Rendering Service）に任せて構いません。 特別な構成は不要です。 しかしながら、Googlebot が実行できない JavaScript を使っていたりインデックスされるまでに時間がかかりすぎ
新たなSEOの到来か？ AMPストーリーが専用ブロックでGoogle検索に表示される #AMPConf
[レベル: 上級] AMP ストーリー専用のセクションが検索結果に表示されるようになります。 東京の六本木で 4 月 17 〜 18 日に開催された AMP Conf 2019 で発表がありました。 AMP ストーリーは、本をパラパラとめくるようにして物語風に一連の情報を閲覧できる AMP の機能です。 文字ではなく、画像や動画をふんだんに使ったビジュアルさに特徴があります。 こちらは、AMP Conf で紹介された楽天レシピの AMP ストーリーです。 動画のようですが、AMP HTML で作成されています。 専用アプリは不要で、プラットホームを問わずブラウザで表示できます。 Google 検索の AMP ストーリー 現在は、2 つのタイプで AMP ストーリー はモバイル検索結果に表示されます。 カルーセル サイト専用 (host-specific) のカルーセルにそのサイトの AMP
Google、SEOに適したLazyloadの仕様を公開
[レベル: 上級] SEO と相性がいい Lazyload の実装を解説するドキュメントを Google はデベロッパー向けサイトで公開しました。 3つのアドバイス ドキュメントには3つの指針が書かれています。 1. viewport 内で見えるようにする viewport 内にあるコンテンツは、必ず Google にも見えるようにしておきます（viewport は簡単に言えば、スクリーンに表示される領域）。 つまり、重要なコンテンツが viewport に入ったときは確実に読み込ませます。 IntersectionObserver API と polyfill を実装するように Google は指示しています。 2. 無限スクロールでは paginated loading を使う 無限スクロールを採用している場合は、paginated loading を実装します。 paginated
ページのダウンロード時間が1000ミリ秒を超えると、Googlebotがクロールに制限をかける可能性あり
[レベル: 上級] Googlebot がページをクロールするときにかかるダウンロード時間が 1,000 ミリ秒を超えると、クロールに支障をきたすかもしれません。 一応の目安として、100 〜 500 ミリ秒以内を考慮しておくとよさそうです。 ページのダウンロード時間は 100 〜 500 ミリ秒が理想、1,000 ミリ秒は遅すぎ （旧）Search Console のクロールの統計情報レポートでは、ページのダウンロード時間の情報を確認することができます。 ページのダウンロード時間は、Googlebot がリソースを純粋にリクエストするのにかかった時間を示すデータです。 PageSpeed Insights のようにユーザーが使うブラウザの表示にかかる時間ではありません。 リソースは、HTML のほか画像や CSS、JavaScript、PDF なども含みます。 ダウンロード時間の目安に関
Google、ページの読み込み速度をランキング要因にするSpeed Updteを導入開始
[レベル: 全員] ページの読み込み速度をモバイル検索のランキング要因として利用する Speed Update（スピード アップデート）をすべてのユーザーに対して Google は導入を開始しました。 Speed Updateは、7月の導入が今年の1月に事前アナウンスされていました。 導入開始のアナウンスのみ 発表があったのは導入が始まったことだけです。 この記事を書いている時点では、導入開始以外の新たな追加情報は出ていません。 ウェブマスターの公式 Twitter アカウントが導入開始を伝えています。 The Speed Update, which enables page speed in mobile search ranking📱, is now rolling out for all users! More details on Webmaster Central 👉 htt
Google、求人検索ためのIndexing APIを公開。即時性が高いクロール・インデックスを可能に
[レベル: 上級] 求人検索に対応した JobPosting 構造化データを設定しているページ向けに、Indexing API という仕組みを Google は公開しました。 Indexing API を利用すると、Google にクロールをダイレクトに要求し最新の状態にインデックスを常に保つことができます。 求人情報ページのみ 求人検索には即時性が求められます。 新たに募集が始まった求人はすぐさま検索結果に出すべきだし、募集を終了した求人は直ちに検索結果に出ないようにすべきです。 求人サイトがページを新規に公開したり募集終了ページを削除したりしても、通常のクロール/インデックスのプロセスでは即時性を実現できません。 検索結果に出るまでに数日かかるかもしれないし、もう募集を締め切った求人が検索結果に残り続けるかもしれません。 こうした問題を解決するために、Indexing API が導入さ
Search Consoleの新機能、「URL検査」ツールを使ってみた
[レベル: 上級] ベータ版が提供されている新しい Search Console の新機能として「URL 検査」ツールが1週間ほど前に追加されました。 すべてのユーザーに提供されるまでには、1〜2週間くらいかかるとのことでした。 今朝見てみると僕のアカウントでも使えるようになっていました 簡単に使ってみた状況をこの記事で紹介します。 URL 検査ツール 初体験 URL 検査ツールを利用できる状態だと、左メニューに「URL 検査」が出ています。 あるいは、「インデックス カバレッジ」で URL を選択したときに右側に出現するメニューからもアクセスできます。 AMP やリッチリザルトのレポートで URL を選択した場合も、右下に小さく見えている「検査」リンクからツールを起動できます。 検査結果はさまざまです。 こちらは正常にインデックスされている状態の「URL は Google に登録されてい
【訂正記事】Google Speed Updateで影響を受けるのは本当に遅いページだけ、スピード改善が段階的に評価されるのは影響を受けた場合
[レベル: すべて] 『今月導入される Google Speed Uptate は速ければ速いほど評価が上がるアルゴリズムだった』という記事を2日前に投稿しました。 しかしながら、この記事は事実を正確に反映していませんでした。 訂正のために正しい内容を書きます。 Speed Update はすごく遅いサイトだけに影響、改善は段階的に評価される Google のJohn Mueller（ジョン・ミューラー）氏は、間違って解釈された Speed Update の仕様について、次のように正しました。 Speed Update は本当に遅いサイトだけに影響する Speed Update の影響を受けたサイトは、段階的に改善できる（もちろん理想的なのは、十分に速度改善すること） Speed Update の実施は今でも今月を目指している サイトが十分に速いのであれば、それ以上に速くしても何も変わらな
今月導入される Google Speed Uptate は速ければ速いほど評価が上がるアルゴリズムだった
[レベル: 中級] 【UPDATE】 この記事は事実を正しく反映していないことが判明しました。 こちらの記事で説明しています。 ページの読み込み速度をモバイル検索のランキング要因として用いる “Speed Update”（スピード アップデート）を Google は今月導入する予定です。 Speed Update は、本当に遅いページだけが影響を受けるアルゴリズムだと思われていました。 しかしながら実際には、速ければ速いほど評価が上がるアルゴリズムになっているようです。 Speed Update では、読み込み速度が速いと段階的に評価が上がる Speed Update の導入を事前アナウンスした公式ブログの記事は次のように説明していました。 The “Speed Update,” as we’re calling it, will only affect pages that delive
Google PageSpeed Insightsのoriginコマンドでサイト全体のスピードを計測
[レベル: 中級] ウェブページの表示スピードを計測するツールの PageSpeed Insights で、サイト全体を集計した速度データを調べられるようになりました。 これまでは、単一のページが検証の対象でした。 origin: コマンドで集計データをレポート サイト全体の速度データを集計してレポートを出すには origin: をドメイン名の URL の先頭に付けます。 僕のサイトであれば、origin:https://www.suzukikenichi.com で検証します。 僕のサイトは、全体としては「Fast」（速い）という結果が出ました。😃 あるいは、個別ページを検証すると、origin: コマンドを使うと集計データをレポートすることができるという説明が出てきます。 Chrome ユーザー エクスペリエンス レポートでは、このorigin（https://www.example
JSサイトのための第4のレンダリング構成としてダイナミックレンダリングをGoogleが発表 #io18 #io18jp
[レベル: 上級] JavaScript で構築されたサイトのために Dynamic Rendering（ダイナミック レンダリング）と呼ぶ仕組みを Google はサポートするようになります。 米マウンテンビューで開催された Google I/O 2018 のセッションで Google の John Mueller（ジョン・ミューラー）氏が発表しました。 Google が現在サポートする JS サイトのための3つのレンダリング構成 JavaScript でレンダリングされたコンテンツを適切にインデックスするために、次の3つのレンダリング構成を Google は現在サポートしています。 Client Side Rendering（クライアント サイド レンダリング）――クライアント側、つまりブラウザまたは Googlebot がすべてをレンダリングする。Googlebot がレンダリングで
PWA版GoogleマップがGoogle Playからインストール可能に、PWA対応したGoogle検索は高速化に成功 #io18 #io18jp
[レベル: 中級] 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 マップ アプリの軽量版のプログレッシブ ウェブアプリで」と説明に書かれています。 「プログレッシブ ウェブアプリ」が何なのかを一般ユーザーが理解できるかどうかはとも
Chromeのデータをページ速度評価にGoogleは確かに使っていた（Google社員に確認）#BrightonSEO
[レベル: 中級] ページの表示速度を計測するデータの1つとして、Chrome User Experience Report（Chrome ユーザー エクスペリエンス レポート）を Google は利用しています。 英ブライトンで先週参加した BrightonSEO で John Mueller（ジョン・ミューラー）氏に直接確認することができました。 Chrome によって取得されたデータを検索に利用 ページの読み込み速度をモバイル検索のランキング指標に取り入れる Speed Update（スピード アップデート）を7月に控えています。 Google はどのようにして読み込み速度を判断しているのでしょうか？ Distilled（ディスティルド）の Tom Anthony（トム・アンソニー）氏は、Chrome が取得したデータを使っていることを Google が認めたとコメントしていました（
Google、モバイルファーストインデックスを本格展開、準備が整ったサイトから移行（ただしアルゴリズム更新ではないので注意！）
[レベル: All] モバイル ファースト インデックスの展開を本格的に開始したことを Google はウェブマスター向け公式ブログでアナウンスしました。 MFI のベストプラクティスを満たしているサイトが順次移行の対象になります。 日本語での翻訳記事は今日中に公開されると思われます。 【UPDATE】 公開されました: 『モバイル ファースト インデックスを開始します』 MFI おさらい まず、簡単にモバイル ファースト インデックス（以下、MFI）をおさらいしておきましょう。 MFI が何かを十分に理解していればここは飛ばして構いません。 MFI はモバイル向けページを主たるインデックスの対象にする変更です。 これまでは、PC 向けページがインデックス対象になっていました。 従来は PC 向けページの評価に基づいて検索順位が決定されました。 今後は、モバイル向けページの評価に基づいて検
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
