[レベル: 上級] そのコンテンツを作成したのは誰なのか、そしてその人物がどんな存在なのかを Google はどのようにして認識しているのでしょうか？ プロフィールページで自分を明かす コンテンツ著者を Google はどのようにして認識するのかに関して John Mueller（ジョン・ミューラー）氏はオフィスアワーで次のように説明しました。 コンテンツを作った人が誰なのか、その人はどういった存在なのかを私たちのシステムは認識しようとする。いくつかの異なる要因に基づいて認識しており、たとえばプロフィールページへのリンクやそのページにある視覚要素などだ。 ミューラー氏はこのように説明したうえで、著者に関するすべての情報が載っているプロフィールページへ（各記事から）リンクすることを推奨しています。 プロフィールページは、ウェブに存在するその人の情報を集約する場所の役割を果たすようにします。

[レベル: 上級] Product（商品）の構造化データで価格下落をリッチリザルトに表示できるようになりました。 米 Google (google.com) の PC 検索とモバイル検索ですでに導入されています。 リッチリザルトで通常価格と比較できる 価格下落の拡張表示によって、価格が下がったときにそのことをリッチリザルトでユーザーは認識できます。 Price（値段）に続くカッコの中に “typically $39” と書かれています。 「通常 39 ドル」の意味です。 現在の値段が 27.99 ドルなので 10 ドル以上値下がりしたことがわかります。 Offer タイプを追加する 価格下落を表示させるには、Offer タイプを Product 構造化データに追加します。 AggregateOffer ではいけません。 price プロパティで指定する値段は特定の金額にする必要があります。

[レベル: 上級] “December 2020 Core Update” と名付けられた、広範囲にわたるコア アルゴリズム アップデートを Google は先週後半に実施しました。 時間がたつにつれて、かなり大きな変動が発生しているようです。 Passage Indexing が、今回のコア アップデートと同時に導入されたのではないかという推測もあるようですが、どうなのでしょうか？ Google の John Mueller（ジョン・ミューラー）氏が、この推測に対して英語版オフィスアワーでコメントしました。 別の変更とコア アップデートをセットでは実行しない Passage Indexing がもう導入されたかどうかはわからないが、通常は、そうしたほかの変更とセットでコア アップデートを実行することはない。 同時に実行することがひょっとしたらあり得るかもしれないが、それはコア アップデー

[レベル: 上級] Search Console のリンク否認ツールが新しいバージョンになりました。 Google Search Central の Twitter 公式アカウントがアナウンスしています。 Today we're completing the migration of the Disavow links tool to the new Search Console interface 🎊 ✅ Improved interface ✅ Download a disavow file as a text file ✅ Error reports for uploaded files are no longer limited to 10 errors Read more at https://t.co/KSY9a4o3Pp pic.twitter.com/TRKFx0XCEI

[レベル: 上級] Googlebot が HTTP/2 でのクロールを開始しました。 2020 年 11 月から HTTP/2 でクロールし始めることを Google は 9 月下旬にアナウンスしていました。 予定どおりの実施です。 サーバーログで、Googlebot の h2 クロールを確認 予想外に（理由は後述）、HTTP/2 による Googlebot のクロールを僕のブログでもサーバーログで確認できました。 www.suzukikenichi.com 172.69.69.207 - - [14/Nov/2020:03:46:49 +0900] "GET /blog/how-to-set-up-503-error/ HTTP/2.0" 200 32415 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) A

[レベル: 中級] 2021 年 5 月に Core Web Vitals（コア ウェブ バイタル）がランキング要因になります。 コア ウェブ バイタルをページエクスペンリエンス シグナルの 1 つとしてランキング要因に組み込むことを Google は予告していました。 約束どおり 6 か月（以上）前に、具体的な日程を公式ブログで発表しました。 【UPDATE (2021/04/20)】 2021 年 6 月中旬の導入になりました。詳しくはこちらの記事を参照。 Core Web Vitals がページエクスペンリエンス シグナルに組み込まれる 関連性や品質を最も重要な要因として Google はランキングを決定しています。 一方で、近年はユーザー体験もランキングで考慮するようになってきました。 ユーザーが検索結果から訪問したページのユーザー体験、言い換えるとページエクスペンリエンスとして次

[レベル: 初級] [他の人はこちらも検索] の新しいデザインを Google は PC 検索でテストしているようです。 モバイル検索と似たデザインの [他の人はこちらも検索] 検索結果に戻ってきたときに出現する [他の人はこちらも検索] は以前から利用できています。 PC 検索でテスト中の [他の人はこちらも検索] は最初から検索結果に表示されています。 こちらは、右パネルに表示される [他の人はこちらも検索] です。 こちらは、検索結果の間に差し込まれる [他の人はこちらも検索] です。 モバイル検索では、検索結果の間に差し込まれる [他の人はこちらも検索] はすでに導入されていました。 PC 検索結果のデザインをモバイル検索結果のデザインに寄せてくるのはよくあることです。 [関連する検索キーワード] が [ほかのキーワード] に 検索結果のいちばん下に出てくる [関連する検索キーワー

[レベル: 上級] ページ内の特定の部分をランキングの対象にできる Passage Indexing を Google が導入することを今週月曜日に紹介しました。 Indexing という用語を使っているのでインデックス システムの変更に思えますが、そうではありません。 実際にはランキング システムの変更です。 誤解を生まないように僕は記事の中できちんと説明しましたが、SEO 業界全体で見ると誤って認識している人も多いようです。 そこで、誤解を解くための補足を Google SearchLiaison アカウントが Twitter で投稿しました。 この記事では、SearchLiaison のツイートと、別の Google 社員とのセッションで入手した情報をもとに Passage Indexing について追加説明します。 インデックスするのは今までどおりページ、一部分だけを対象に評価でき

[レベル: 上級] AMP Page Experience Guide（AMP ページ エクスペリエンスガイド）というツールを Google は公開しました。 We're excited to release the AMP Page Experience Guide! A tool that provides AMP developers with actionable advice to help improve the performance of their AMP pages. Test your AMP page today 👉 https://t.co/3sLCYnTCZk pic.twitter.com/B0gTHyLMfu — AMP Project (@AMPhtml) October 13, 2020 AMP ページ エクスペリエンスガイドは、Google 検索のペ

[レベル: 初級] 健康と安全に関する新しい属性が Google マイビジネスに追加されました。 コロナ関連の追加属性 新型コロナにビジネスが適切に対策しているかどうかを顧客に知らせるための属性を Google マイビジネスでしばらく前から設定できるようになっていました。 スタッフの検温やマスク着用です。 「次の顧客の案内前にスタッフによる消毒」が新たに追加されています。 たとえば、その都度アルコール消毒している場合には追加しておくといいでしょう。 ビジネスのタイプによっては、会計/レジが（透明の）仕切板で区切られているかどうかの属性もあるようです。 英語では [Safety dividers at checkout] とのことですが、僕が管理するビジネスにはありませんでした。 Great to see @GoogleMyBiz adding even more attributes (d

[レベル: 中級] Milestone が検索結果のクリック率 (CTR) 調査を実施し、その結果を公開しました。 この記事では、特に注目したい結果を紹介します。 調査方法 概要 調査方法の概要は次のとおりです。 期間: 2019 年 7 月 〜 2020 年 7 月までの 13 か月間 収集データ: 2,736,000,000 以上の表示回数、4,527,000 個のクエリに対する 157,460,000 件のクリック、175 ドメイン 検索結果 1 〜 15 位までのデータを取得 対象国: 米国 1 ページ目の全種類の検索結果の CTR は 49.5%、リッチリザルトの CTR は 58.2% 調査結果による特筆すべきデータを抜き出します。 1 ページ目の、すべての種類の検索結果の CTR は 49.5% 1 ページ目の、リッチリザルトの検索結果の CTR は 58.2% タイトルと

[レベル: 初級] ほかのサイトに記事を配信した場合、同一の記事が複数ウェブに公開されていることになります。 それらを通常 Google は重複コンテンツとみなし、どれか 1 つを検索結果に表示します。 検索結果に表示されるのは必ずしも配信元のオリジナル記事とは限りません。 これは受け入れなければならない事実です。 重複扱いされたくないなら記事配信しない 同一の記事をほかのサイトにも配信する、いわゆる「シンジケート (Syndicate) 」の Google の扱いに関する質問に John Mueller（ジョン・ミューラー）は次のように回答しました。 同じ記事なのだから、シンジケートした記事はもちろん重複コンテンツになる。 基本的には、どれか 1 つを選んで検索結果に表示する。それは、別のサイトに配信した記事かもしれないし、あなたのサイトのオリジナル記事かもしれない。 オリジナルの記事が

[レベル: 中級] iOS 版 Safari が WebP をサポートしました。 しかしながら、MacOS 版 Safari は未サポートのままです。 iOS 版 Safari が WebP を表示 こちらは、JPEG 画像です。 みんな見えているはずです。 こちらは、WebP 画像です。 ブラウザによっては見えていないかもしれません。 iOS 版 Safari 14 が WebP をサポートしたので、どちらの画像も表示できます。 Safari が WebP に対応したのはとても嬉しいニュースです。 WebP 利用の最も大きな懸念がなくなりました。 ところが…… MacOS 版 Safari はサポートせず MacOS 版（デスクトップ版）の Safari は バージョン 14 でも WebP に対応していないままです。 表示できていません。 インスペクタを見ると WebP には読み込みエ

[レベル: 初級] 公開前の開発中サイトが検索にインデックスされないようにするにはどうしたらいいか？ オフィスアワーで出たこの質問に Google の John Mueller（ジョン・ミューラー）氏が回答しました。 推奨: ユーザー認証・IP 制限 開発中サイトのインデックスを防止するための最良の方法として次の 2 つをミューラー氏は提案しました。 ユーザー認証 IP アドレス制限 ユーザー名とパスワードでアクセス制限をかけます。 Googlebot は、適切なユーザー名とパスワードを送信できないのでそのサイトのページをクロールもインデックスもできません。 加えて、関係者以外のユーザーのアクセスも防げます。 最も手堅い方法です。 ユーザー認証は、簡単なものであれば .htaccess で設定できるし CMS の機能を使ってもいいでしょう。 検索すれば、たくさんの情報が見つかります。 IP

[レベル: 上級] AMP ページと非 AMP ページでの記事構造化データの要件および使われ方の違いを Google は明確化しました。 非 AMP ページでの記事リッチリザルト 検索デベロッパーサイトの記事構造化データを解説するページの先頭に、AMP ページと非 AMP ページの説明があります。 構造化データを含む AMP: 構造化データを含む AMP ページは、トップニュース カルーセル、リッチリザルトのホスト カルーセル、映像ニュース、モバイル検索結果のリッチリザルト内に表示できます。これらの検索結果には、画像、ページのロゴ、その他の魅力的な検索結果機能を含めることができます。 構造化データを含む非 AMP ウェブページ: 非 AMP ページに Article 構造化データを含めると、Google がウェブページの詳細を理解し、Article リッチリザルトで記事の見出しテキスト、画

[レベル: 上級] Search Console で利用できる URL パラメータツールの現状と今後について Google の John Mueller（ジョン・ミューラー）氏がオフィスアワーで説明しました。 URL パラメータは現在停止中、新バージョンを開発中 ミューラー氏の説明の要点をまとめると次のようになります。 URL パラメータ ツールのデータ更新がしばらくの間停止しているが、Google 側の問題であり廃止を予定しているからではない URL パラメータのものと似たデータを内部的には使用している 停止状態はまもなく解消するはず 新（現）バージョンの Search Console には、新しいツールとして URL パラメータを移行準備中 ということで、旧 Search Console の URL パラメータ ツールは現状ではうまく機能していないようです。 ですが、それはツールそのも

[レベル: 中級] 画像検索で提供する画像ライセンス表示の機能を Google は正式版として公開しました。 画像ライセンス表示は 2020 年 2 月にベータ版としてリリースされていました。 画像ライセンスを構成しているウェブページの画像が画像検索結果に掲載されると、サムネイル画像に「ライセンス可能」バッヂが付きます。 プレビュー画面には、ライセンスの詳細情報が掲載されます。 「画像の配置場所」はその画像を入手できるページへリンクしています。 「認可の詳細」はその画像の使用許諾のページへリンクしています。 PC の画像検索でも、バッヂと画像ライセンス情報は掲載されます。 入手できるページと使用許諾ページへのリンクも付きます。 ライセンスで絞り込み また、画像検索の [ツール] にライセンスでフィルタする機能が付きました。 次の 2 タイプの条件で画像を絞り込めます。 クリエイティブ・コモ

[レベル: 初級] 記事の更新日時はどのような状況で更新するのが適切なのでしょうか？ たとえば、,（コンマ）を 1 つ追加しただけでも更新すべきなのでしょうか？ 構造化データとサイトマップで異なる Google のJohn Mueller（ジョン・ミューラー）氏は、原則的に、次のような基準に基づくことを推奨しています。 構造化データの更新日時: コンテンツを大幅に変更したときに更新する サイトマップの更新日時: 再クロールが必要な変更であれば更新する (this thread has gotten better, but different :-)) For SD, I'd use significant content updates (since that's shown & would be misleading otherwise). For Sitemaps, any chang

[レベル: 上級] テキスト フラグメントが付いた URL を、Search Console の検索パフォーマンスがレポートするようになっています。 テキスト フラグメントは #:~:text= が付いた URL で、ページ内の特定のテキストの場所をダイレクトに表示する機能です。 ユーザーは該当箇所までスクロールする必要がありません。 Chrome 81 から実装されました。 テキスト フラグメント付き URL は、ユーザーが作成することもできるし、強調スニペットにも使われています。 検索パフォーマンスがレポートするテキスト フラグメント付き URL は強調スニペットでの表示と思われます。 検索パフォーマンス レポートのテキスト フラグメント URL 検索パフォーマンスがレポートするテキスト フラグメント付き URL のデータです。 ページの URL 部分を拡大します。 フィルタで「tex

[レベル: 上級] リンク先ページが高速に表示されることがわかっているとき、「高速版ページ」のラベルを Chrome が付けるようになります。 アンカーテキスト長押しで速いページかどうかをチェック リンクのアンカーテキストをモバイル版 Chrome で長押します。 そのリンク先ページの表示が十分に速い場合に、コンテキストメニューに「高速版ページ」というラベルが出ます。 アクセスする前に速く表示されるかどうかをユーザーは確かめられます。 Core Web Vitals で評価 高速かどうかは Core Web Vitals の指標を用いて判断します。 そのページを過去に訪問したユーザーのデータに基づいて評価されます。 また公開直後だったり訪問者が少なかったりして 評価に十分なデータが集まっていないときは、サイト内の類似したページをもとに評価するとのことです。 Chrome ベータ 85 で試