構造化データで複数アイテムをマークアップする際のガイドラインをGoogleが更新。ネストするか@idで関連付けする
[レベル: 上級] 1 つのページで、複数のアイテム（タイプ）を構造化データでマークアップする際の注釈を構造化データのガイドラインに Google は追加しました。 関連するエンティティのタイプはネストするかもしくは @id で関連付けます。 一方で、独立したエンティティは個別にマークアップできます。 複数タイプをネスト たとえば、解説動画付きのレシピの構造化データは次のようにマークアップできます。 <script type="application/ld+json"> { "@context": "https://schema.org/", "@type": "Recipe", "name": "バナナブレッドのレシピ", "description": "とっても美味しいバナナブレッドのレシピ", "image": "http://example.com/banana-bread.jpg
コアウェブバイタルの検索結果への反映はリアルタイムなのか？
[レベル: 上級] 来月、2021 年 5 月にコア ウェブ バイタルがページ エクスペリエンス シグナルに追加されランキング要因になります。 コア ウェブ バイタルを改善した場合の検索結果への反映にはどのくらいの時間がかかるのでしょうか？ リアルタイムではない、若干のタイムラグありか？ Google の John Mueller（ジョン・ミューラー）氏によれば、更新間隔がどうなるかはまだ完全には決まっていないようです。 コア ウェブ バイタルの評価は Chrome ユーザーのアクセスをもとにした Chrome ユーザーエクスペリエンス (CrUX) レポートから算出されています。 十分なデータが必要になってくるため、少なくともリアルタイムにはなりそうにありません。 改善後の検索結果への反映にはある程度の時間がかかると予想されます。 もっとも、どのくらいの時間がかかるかは定かではありません
Google、CLSの定義を変更。ページエクスペリエンスシグナルは新CLSで評価する
[レベル: 上級] コア ウェブ バイタルの 3 要素の 1 つである CLS (Cumulative Layout Shift) の定義が変わります。 2021 年 6 月に コア ウェブ バイタル がページ エクスペリエンス シグナルとしてランキング要因になります。 ページ エクスペリエンス シグナルでは、新しい定義で取得する CLS のスコアが評価に用いられます。 すべてのサイトで CLS が改善 CLS の定義がどんなふうに変更になるかはこのあと簡潔に説明しますが、まず重要なのは、変更によってすべてのサイトで CLS のスコアが良くなる点です。 Google によれば、新しい計測方法の CLS のもとでは次のような変化が見られるとのことです。 スコアが悪くなるページはゼロ 55% のサイトは 75 パーセンタイルでスコアに変化なし 45% のサイトは 75 パーセンタイルでスコアが
コンテンツ著者をGoogleはどのようにして認識しているのか？――プロフィールページが重要
[レベル: 上級] そのコンテンツを作成したのは誰なのか、そしてその人物がどんな存在なのかを Google はどのようにして認識しているのでしょうか？ プロフィールページで自分を明かす コンテンツ著者を Google はどのようにして認識するのかに関して John Mueller（ジョン・ミューラー）氏はオフィスアワーで次のように説明しました。 コンテンツを作った人が誰なのか、その人はどういった存在なのかを私たちのシステムは認識しようとする。いくつかの異なる要因に基づいて認識しており、たとえばプロフィールページへのリンクやそのページにある視覚要素などだ。 ミューラー氏はこのように説明したうえで、著者に関するすべての情報が載っているプロフィールページへ（各記事から）リンクすることを推奨しています。 プロフィールページは、ウェブに存在するその人の情報を集約する場所の役割を果たすようにします。
Googleページ エクスペリエンス アップデートは6月中旬から段階的に導入開始
[レベル: 中級] Google は、Page Experience Update（ページ エクスペリエンス アップデート）の導入を、当初予定していた 5 月から少し遅らせて 6 月中旬に開始することを Search Central 公式ブログでアナウンスしました。 段階的に展開していくとのことです。 アナウンス記事では、関連するそのほかの変更と Search Console の新しいレポートについても触れています。 ページ エクスペリエンス アップデートは 6 月中旬から段階的にロールアウト ページ エクスペリエンス アップデートに関する発表内容の要点は次のとおりです。 2021 年 6 月中旬に導入開始 ランキングシグナルとして完全に組み込まれるのは 8 月の終わり 完了までは段階的に展開していく 極端なランキング変動は想定していない ページ エクスペリエンス アップデートはもともとは
オートコンプリートのクエリ候補をGoogle検索はどのようにして生成しているのか
[レベル: 初級] オートコンプリートという機能によって検索クエリの候補を Google 検索は提案します。 このオートコンプリート機能によって検索候補がどのように生成されるかを公式ブログが解説しました。 面白い内容なので、この記事で要点をまとめて紹介します。 オートコンプリートに影響する要因 次のような要因によってオートコンプリートは検索候補を生成します。 多くのユーザーが検索しているクエリ 検索数が増えているクエリ 検索ユーザーの言語 検索ユーザーがいる場所 クエリ全体 新しさ 検索対象のトピック 「多くのユーザーが検索しているクエリ」と「検索数が増えているクエリ」はオートコンプリートのベースです。 特に説明は不要でしょう。 ユーザーが使っている言語にもオートコンプリートは依存します。 日本語で検索する場合と英語で検索する場合では候補は異なります。 「検索ユーザーがいる場所」もオートコ
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 をチェックした状
PWA+TWAでウェブサイトを完全アプリ化、PWAサイトのGoogle Play登録も可能に
[レベル: 上級] Trusted Web Activity (トラステッド ウェブ アクティビティ) を実装すると、Progressive Web App (PWA) のサイトを Google Play にアプリとして登録することができます。 Trusted Web Activity とは Trusted Web Activity（以下、TWA）を簡単に説明します。 TWA は、アプリの中にウェブページをコンテンツとして表示できる機能です。 2017 年の Chrome Dev Summit で発表されました。 試験的な公開でしたが、Android 版 Chrome 72 のリリースとともに正式に利用可能になりました。 アプリの中にウェブページを表示させると聞くと、開発に詳しい方は Chrome Custom Tab や WebView を思い出すかもしれません。 どちらもアプリのコンテ
モバイルウェブのスピードアップに不可欠なのは 画像・JS・フォント の最適化 #ChromeDevSummit
[レベル: 中級] 昨日とおとといに続いて、今日も 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（パフォーマンス バジェット）
iOS版Safariにホーム画面アイコンを簡単に追加できるPWACompat
[レベル: 上級] PWAをサポートしていないブラウザでもホーム画面アイコンを追加できる仕組みとして、PWACompat を Google は公開しました。 PWACompat を構成すると、Web App Manifest を解釈しないブラウザために、関連する meta タグや link 要素を自動的に挿入してくれます。 PWACompat で iOS 版 Safari にもホーム画面アイコンを追加 iOS 版 Safari は Service Worker のサポートに着手しましたが、完成にはまだほど遠い状態です。 たとえば、Web App Manifest（マニフェスト ファイル）によるホーム画面アイコン追加の機能をまだサポートできていません。 iOS にホーム画面アイコンを追加させようとしたら、link rel="apple-touch-icon" のようなタグを別途追加する必要が
レンダリング後にGoogleに無視されるのはrel=canonicalとrel=amphtmlの2つだけ。hreflangとprev/nextはクライアントサイドでの挿入が可能
[レベル: 上級] JavaScript で DOM を操作してクライアントサイドでレンダリングした rel="canonical" は Google には無視されます。 rel="canonical" 以外のほかのタグはどうなのでしょうか？ 同じように無視されるのでしょうか？ それともきちんと認識されるのでしょうか？ 無視されるのは rel=”canonical” と rel=”amphtml” だけ Google の John Mueller（ジョン・ミューラー）氏によれば、rel="canonical" と rel="amphtml" だけが無視されるようです。 この2つのタグに関しては、生 HTML での配信が要求されます。 一方で同じ link 要素であっても、hreflang と rel="prev/next" に関しては、クライアント側のレンダリングで挿入しても Google
読み込み速度改善が売上に与える影響と競合とのスピードを比較するツールをGoogleが公開
[レベル: 中級] ページの読み込み速度に関係するデータを計測するツールを Google は新たに2つ公開しました。 1つは Speed Scorecard（スピード スコアカード）、もう1つは Impact Calculator（インパクト カリキュレータ）です。 どちらも同じページで利用できます。 Speed Scorecard Speed Scorecard は他のサイトとのスピードを比較できるツールです（1つのサイトの計測ももちろん可能）。 日本を含む12か国でのスピードと、3G/4G を選択して計測できます。 Amazon と楽天市場、メルカリのスピードを比べてみました。 右上にあるオプションで国と 3G/4G を選択できます。 スピードはリアルタイムの計測ではありません。 Chrome User Experience Report のデータに基づいています。 実際の Chrom
Googleモバイルファーストインデックス後はレスポンシブが唯一の選択肢か？ #inhouseseo
[レベル: 中級] レスポンシブ ウェブ デザインが選択すべき構成だ (Responsive Web Design is the way to go.) Google の Gary Illyes（ゲイリー・イリェーシュ）氏は、8月22日に開催された ISM Spin-off #2 で、このようにレスポンシブ ウェブ デザインをかつてないほどに推奨しました。 これまでは、「動的な配信」と「別々の URL」を含めた3つのモバイル構成のどれを選択しても構わないと言っていました。 しかし方針を変えて、レスポンシブ ウェブ デザイン1本に絞ったのです。 動的な配信と別々のURLが抱える問題 レスポンシブ ウェブ デザイン（以下、RWD）をゲイリーが強く推奨する最大の理由は、モバイル向けサイトと PC 向けサイトに差異がないことです。 見た目は違っていたとしても、同じ HTML を配信しているので、コ
amp-bindが一般公開、ECサイトでのAMP対応がいよいよ現実的に
[レベル: 上級] AMP プロジェクトは amp-bind を一般公開しました。 amp-bind は、“オリジントライアル”に参加したサイトで試験的に公開されていました。 しかし、すべてのサイトでもはや完全に機能します。 amp-bind でダイナミックな機能を実現 一般的に言って、AMP は、ニュース記事やブログ記事、レシピなど静的なコンテンツに向いています。 だれがいつ読んでも、閲覧中にどんな動作をしても、コンテンツは変化しません。 いつも同じです。 しかし、ユーザーのアクションに応じてコンテンツが変化する動的なページが現代のウェブではそこかしこに存在します。 EC サイトであれば、たとえば次のような動的な機能は当たり前です。 サイズや個数に応じた合計金額の変化 タップしたサムネイル画像に応じた拡大画像の切り替え 商品の絞り込みや並び替え サイト内検索 ところが、従来の AMP の
位置情報を偽装して、その場所にいなくてもその場所のモバイル検索結果をPCのChromeで調べる方法
[レベル: 中〜上級] この記事では、Google Chromeを使って位置情報をエミュレートする方法、言い換えれば任意の場所に設定する方法を解説します。 位置情報を偽装することで、実際にその場所にいなくてもその場所で検索したときの（モバイル）検索結果を調べることが可能になります。 Google Chromeで位置情報をエミュレートする手順 まず次のいずれかの操作で、デベロッパーツールを起動します。 [Google Chromeの設定]（右上の3本バー） − [その他のツール] − [デベロッパー ツール] Ctrl + Shift + i (Windows) / Cmd + Opt + i (Mac) 標準では、ウィンドウの右にデベロッパーツールが出現します。 ツールを下に移動します。 その方が見やすいからです。 ウィンドウっぽい四角のアイコンをクリックします。 ツールが下に移動します。
Google、「スマホ対応」をランキング要因に利用することを決定。4/21から導入。
[レベル: 初・中・上級] Googleは、スマホ対応しているかどうかをモバイル検索のランキング要因として使用することを発表しました。 4月21日からの導入を予定しています。 またApp Indexingに対応したアプリコンテンツもランキング要因として利用するようにしました。 こちらは今日（現地時間の2月26日）から導入されています。 モバイルフレンドリーが単なるラベル表示からランキング要因に 昨年11月に、そのページがスマートフォンに対応しているときに、「Mobile-friendly」（モバイル フレンドリー）というラベルをGoogleはモバイル検索結果に表示するようにしました。 日本には、翌月の12月に導入されました。 「スマホ対応」というラベルが付きます。 導入時点では、「スマホ対応」ラベルは単純に表示だけの仕様でした。 スマホ対応しているかどうかはランキング要因にはなっていません
モバイル検索結果の15%がディープリンク、App Indexing設定の4つのコツをGoogleが解説
[対象: 上級] Googleによると、App Indexingは着実に普及しているようです。 AndroidにおけるGoogle検索の15%がApp Indexingによるディープリンクを現在返す 直近の四半期ではディープリンクのクリックが10倍に急増した こうした流れを受けて、App Indexingを適切に実装するための4つのコツをGoogleは英語版ウェブマスター向け公式ブログで紹介しました。 アプリ開発者にウェブマスターツールへのアクセス権を与える 検索結果でのアプリの利用状況を理解する 確実に、アプリの重要なリソースがクロールされるようにする アプリのエラーを監視する 1. アプリ開発者にウェブマスターツールへのアクセス権を与える App Indexingに関して次の状況をウェブマスターツールでは現在チェックできます。 アプリ内のインデックスされているページのエラー Googl
Google、PageSpeed Insightsのユーザーエクスペリエンス診断機能を正式公開
[対象: 中〜上級] Googleが提供するPageSpeed Insights（ページスピード・インサイト）ツールを使うとサイトの表示速度を診断できます。 スピード診断に加えて、モバイルサイトのユーザーエクスペリエンスを診断する機能を昨年12月からベータ版として試験的に提供していました。 このユーザーエクスペリエンス診断機能を正式に導入したことをGoogleは公式アナウンスしました。 モバイルサイトのユーザーエクスペリエンスを診断 PageSpeed Insightsでは、モバイルサイトにおける次の5項目に関するユーザーエクスペリエンスを評価点付きで診断できます。 viewport の設定 コンテンツのサイズを表示域に合わせる 判読可能なフォント サイズの使用 タップ ターゲットのサイズを適切に調整する プラグインを使用しない 修正が必要な項目に関しては問題点の詳細を提示します。 ちなみ
検索結果1位のクリック率は17.16%、ロングテールはCTRが高い 〜 CATALYST調べ
[対象: 中級] Google検索のCTR（クリック率）を調査したデータをまとめたレポートを、CATALYSTが公開しました。 この記事では、このCTR調査レポートのなかから主だったデータを紹介します。 調査方法 対象キーワード: 17,500個 対象サイト: 59サイト 対象期間: 2012年10月〜2013年6月 利用したデータ: Googleウェブマスターツールの検索クエリ 調査方法の詳細はレポートを参照してください。 検索結果10位のCTR 下の表は、検索結果1位〜10位まで、言い換えると検索結果1ページ目のCTRを表しています。 上の表のデータをグラフ化したものです。 1位のCTRは17.16%です。 やっぱり1位はダントツで高いですね。 上位の4位で全体の83%を占めています。 Above the foldに表示されることが重要だとCATALYSTは述べています。 48%のユー
「Above the foldのコンテンツは1秒以下で表示させること」、モバイルサイトの高速化をGoogleが推奨
[対象: 中〜上級] モバイル向けサイト（スマートフォン向けサイト）の高速化に取り組むように、Googleは、ウェブマスター向け公式ブログであらためて推奨しました。 Official Google Webmaster Central Blog: Making smartphone sites load fast 速さが求められているのに現実は遅い いくつかのリサーチから次のような結果が出ています。 素早く使えて手軽なので、ユーザーはスマートフォンを使っている モバイル向けページは、平均して表示時間にたいてい7秒以上かかっている 表示に1秒以上かかると「時間がかかっている」とユーザーは感じ、遅いサイトには再訪問しないかもしれない “速い”モバイルサイトをユーザーは求めていますが、実際のモバイルサイトは“遅い”のが現状です。 そこで、モバイルサイト高速化のために知っておくべき基本的な知識と対応
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
