[レベル: 上級] この記事では、検索結果に表示されたページタイトルと <title> タグで設定された実際のタイトルを検索結果で比較できるブックマークレットを紹介します。 先日 Google が実行したページタイトル生成のアルゴリズムの更新の調査に役立ちます（検索セントラルブログで日本語訳記事が出ています）。 検索結果のタイトルと実際の title タグ/h1 タグを比較 このブックマークレットを作成したのは Chris（クリス）氏です。 Hey folks. I have update the SERP title comparison bookmarklet. It will now download the JSON comparison data on click, not automatically.https://t.co/i4BVdoVKbN@_fede_gomez_ @a

[レベル: 初級] この記事では、Search Console で所有権を持っているサイトの URL を一覧表示する方法を紹介します。 プロパティ確認済み所有者の管理ページ（旧SC） 確認済みのプロパティの一覧にはこちらの URL からアクセスできます。 こちらのキャプチャのように、所有権を持っているサイトがリストされています。 [詳細の確認] をクリックすると次の情報を確認できます。 サイト確認した方法 再確認の施行日と成功・失敗 確認済みサイト所有者 ページのデザインを見て気付いた人もいるでしょうが、旧 Search Console のツールですね。 名前も「検索セントラル」ではなく「ウェブマスター セントラル」になっています。 それでも、多くのサイトを Search Console で管理している人には一覧で見られるのは便利なんじゃないでしょうか。 所有権を持っているサイトだけが対象

[レベル: 初級] 最近起こった、検索結果に表示するページタイトル生成のアップデートに関して Google は検索セントラルブログで詳しく説明しました。 なお、この記事では「タイトルの書き換え」という表現をあえて使いません。 Google 的には、title タグはあくまでも、検索結果に表示するページタイトルにかかわる要因の 1 つに過ぎず、必ずしも従うものではないからです。 したがって、「書き換え」ているわけではなく自分たちが最適だと考えるページタイトルを生成するために単に参考にしているという認識です。 新しいアルゴリズムはクエリではなくページ全体を参考にしてタイトルを生成する 検索結果に表示するタイトルを生成するアルゴリズムは以前のものと大きく変わりました。 いちばん大きな変化は、タイトル生成に影響する要因です。 以前のタイトル生成: クエリに依存する 現在のタイトル生成: ページ全体

[レベル: 上級] ファーストビューに掲載されている画像を Lazy-load（遅延読み込み）すると コア ウェブ バイタル の 1 指標である LCP を低下させる恐れがあります。 そのため WordPress は、ファーストビューの画像にネイティブ Lazy-load を適用しないように改善する予定です。 ネイティブ Lazy-load は、画像の <img> タグに loading="lazy" 属性を付けることで、ブラウザの機能として遅延読み込みを実現する技術です。 現在は、Chrome や Edge、Firefox など多くのブラウザがサポートしています。 ファーストビュー画像を遅延読み込みさせた WP は LCP が悪化 Lazy-load の利点は、スクリーン領域に入っていない画像を読み込ませないことでデータの転送量を抑えられることです。 スクリーン領域に近づいたところで初め

[レベル: 上級] 1 つのページで、複数のアイテム（タイプ）を構造化データでマークアップする際の注釈を構造化データのガイドラインに Google は追加しました。 関連するエンティティのタイプはネストするかもしくは @id で関連付けます。 一方で、独立したエンティティは個別にマークアップできます。 複数タイプをネスト たとえば、解説動画付きのレシピの構造化データは次のようにマークアップできます。 <script type="application/ld+json"> { "@context": "https://schema.org/", "@type": "Recipe", "name": "バナナブレッドのレシピ", "description": "とっても美味しいバナナブレッドのレシピ", "image": "http://example.com/banana-bread.jpg

[レベル: 上級] 検索結果のプレビューを制御するための新しい robots meta タグが検索結果に反映され始めたようです。 数日後に導入を開始する予定だと Google は 1 週間前にアナウンスしていました。 検索結果に反映されていることを、 バカに毛が生えたブログさんが確認しています。 上の結果に出ている僕のブログ記事のスニペットはデフォルトの文字数です（デフォルトはクエリによっても文字数が変わる）。 一方、バカ毛さんのブログ記事のスニペットは極端に短くなっています（5文字制限とかやりすぎ😅）。 さて、この記事では、検索結果のスニペットの文字数を制御する max-snippet robots meta タグと data-nosnippet HTML 属性に関する補足情報を紹介します。 英語版オフィスアワーで、Google の John Mueller（ジョン・ミューラー）氏が言

[レベル: 上級] 検索結果のプレビューを制御するための新しい robots meta タグを Google は先月末に発表しました。 数日後に導入を開始するとのことです。 グローバルで展開が始まり、展開完了までには来週いっぱいかかります。 Beginning in a few days, Google Search will start using new preview markup in search results. It will be fully live worldwide by next week. Learn more about the new markup here: https://t.co/hmjhcvguJF — Google Webmasters (@googlewmc) October 16, 2019 New markup settings allow s

[レベル: 上級] rel="nofollow" 属性の扱いを Google が変更したことを昨日お伝えしました。 これまでは命令として必ず従ってきましたが、これからはヒントとしての利用になります。 そうすることが適切だと判断した場合は、無視することがありえます。 また、rel="sponsored" 属性と rel="ugc" 属性を新たに導入しました。 働きは rel="nofollow" と同じですが、対象とするリンクをより限定しています。 この記事では、公式アナウンスで説明されているよくある質問にプラス α して解説します。

[レベル: 上級] 試験的に公開されていた <amp-script> が一般公開されました。 AMP では原則的に、AMP で定義された以外の JavaScript を動かすことが許されていません。 しかし、<amp-script> を利用すれば任意の JavaScript を AMP ドキュメントで実行することが可能になります。 好きな JavaScript を AMP で実行 <amp-script> を使うと、自分で書いた JavaScript はもちろんのこと、React や Angular、Vue.js といった JavaScript フレームワークを構成することも可能です。 ユーザーのアクションに応じてインタラクティブなコンテンツや機能を <amp-script> は提供できます。 ※Chrome Tech Talk Night #14 で Paul Bakaus 氏が紹介して

[レベル: 上級] AMP の開発状況を示すロードマップの現状を紹介する記事を AMP プロジェクトの公式ブログが投稿しました。 正式リリースされた機能と開発中の機能、取り組みが始まったばかりの機能が数多く紹介されています。 個人的に気になった機能を2つ、この記事で取り上げます。 amp-next-page は AMP ページで無限スクロールを実装するコンポーネントです。 ページの下までスクロールすると追加のコンテンツが自動で読み込まれます。 EC サイトの商品リストページや、ソーシャルメディアのタイムライン、長いブログ記事などでおなじみの UI ですね。 無限スクロールが AMP ページでも利用できるようになります。 一般的に、AMP ページでは、内部リンクをたどった場合は AMP ページではなく通常のモバイルページに移動します。 amp-next-page を構成すれば、一連のコンテン

[レベル: 上級] フォーラムに書き込まれたコメントのプレビューを、カルーセル形式で掲載する検索結果を Google はテストしているようです。 【UPDATE】 記事終わりに更新情報を追記 カルーセル形式でプレビュー表示されるフォーラムの書き込み カルーセル形式でプレビュー表示されるフォーラムの書き込みの具体例です。 Reddit の掲示板に書き込まれたコメントに適用されています（“reddit cryptocurrency trading” のモバイル検索結果）。 フォーラムへのコメントを検索結果にカルーセル形式で出すテストは今年の春頃に始まっていました。 その時は僕自身は再現できなかったのですが、現在は確実に見ることができます。 Stack Overflow が一例です。 Reddit とは異なり、Stack Overflow のケースでは Top answer のラベルや投票数が入

[レベル: 初級] Google は、『Search Engine Optimization (SEO) Starter Guide』（日本語名: 検索エンジン最適化（SEO）スターター ガイド）を大幅に改訂し新バージョンとして公開しました。 『検索エンジン最適化（SEO）スターター ガイド』とは 『検索エンジン最適化（SEO）スターター ガイド』は、Google が編集した、基本的かつ最重要な SEO の施策をまとめたマニュアル本です。 2008年11月に英語版が公開されました。 2009年6月には、日本語を含む40言語の翻訳版が出されました。 その後2010年9月に、内容を追加した更新版をリリースしています。 7年たった今でも依然として SEO のベストプラクティスだと Google は言うものの、モバイルの最適化がスマートフォンではなくフィーチャーフォンだったりと時代にマッチしなくな

[レベル: 中級] この記事では、重複コンテンツが、サイトの品質が低いことには必ずしも繋がらないこと、しかしクロールには悪い影響を与える可能性があることを説明します。 EC サイトで重複コンテンツが不規則に発生 英語版のオフィスアワーでこんなやりとりがありました。 参加者が次のように質問します。 ECサイトを運営しています。 システム上の問題で1つのページに複数の URL が不規則に次々と割り当てられてしまい重複コンテンツが発生します。 rel=”canonical” と noindex で対応していますが、ほかに何かできることはありますか？ こういった状態は品質の面で問題になるでしょうか？ Google の John Mueller（ジョン・ミューラー）氏は次のように説明します。 まず、どうして URL が不規則に作られるのかの原因を調べたほうがいい。 中小規模のサイトであれば、多少の重

[レベル: 中級] Google の John Mueller（ジョン・ミューラー）氏によれば、自己参照の rel=”canonical” タグを設定しているページに noindex タグを設置しても問題はないとのことです。 noindex がきちんと処理され、検索結果から非表示になります。 rel=”canonical” は noindex ページに向けてはいけない 基本的に、noindex robots meta タグを設定したページに rel=”canonical” タグを向けるべきではありません。 rel=”canonical” は正規化のための仕組みです。 正規化には、検索結果に表示させたい代表となる URL を検索エンジンに伝える目的があります。 にもかかわらず、正規ページ、すなわち検索結果に表示させようとするページに noindex が付いているのは矛盾しています。 rel=

[レベル: 中級] レスポンシブ ウェブ デザインが選択すべき構成だ (Responsive Web Design is the way to go.) Google の Gary Illyes（ゲイリー・イリェーシュ）氏は、8月22日に開催された ISM Spin-off #2 で、このようにレスポンシブ ウェブ デザインをかつてないほどに推奨しました。 これまでは、「動的な配信」と「別々の URL」を含めた3つのモバイル構成のどれを選択しても構わないと言っていました。 しかし方針を変えて、レスポンシブ ウェブ デザイン1本に絞ったのです。 動的な配信と別々のURLが抱える問題 レスポンシブ ウェブ デザイン（以下、RWD）をゲイリーが強く推奨する最大の理由は、モバイル向けサイトと PC 向けサイトに差異がないことです。 見た目は違っていたとしても、同じ HTML を配信しているので、コ

[レベル: 中〜上級] ページネーションしている一連のページの集まりで、2ページ目以降を noindex にすることに問題はない。 ただし、noindex にしてもクロールバジェットの節約には役立たない。 Google の John Mueller（ジョン・ミューラー）氏は、英語版のオフィスアワーでこのように説明しました。 ページネーションで noindex を利用可能 ページを分割している、いわゆるページネーション構成では、rel="prev" と rel="next" を用いて、分割したページの関連性を伝える設定を Google は推奨しています。 しかし、2ページ目以降をインデックスさせる（検索結果に表示させる）必要性を感じていないのであれば、noindex robots meta タグを設定することも可能です。 まったく問題ありません。 noindex はクロールバジェットの節約に

[レベル: 上級] Googleは、デベロッパー向けサイトの AMP セクションの内容を拡充しました。 また、項目ごとに整理整頓し、以前よりも全体像を把握しやすくしました。 項目を追加、整理整頓 左が以前のメニューです。 右が現在のメニューです。 以前は「Introduction to AMP」（AMPの紹介）と「Use AMP」（AMPの使い方）の2つだけでした。 現在は、次の5つのサブセクションに増えています。 About AMP Enhance AMP for Search Validate AMP Remove AMP Content from Search Integrate with Google products 上から順に次のような中身です。 About AMP――AMPの全体的な説明 Enhance AMP for Search――Google 検索のための AMP 実装

[レベル: 上級] AMP 対応をやめたとき、AMP コンテンツが Google 検索に表示されなくするようにする方法を Google はデベロッパー向けページに追加しました。 Google は3つの方法を説明しています。 僕の見解も交えながら、この記事で紹介します。 【方法1】Google 検索から AMP ページを削除 この方法を使うと、検索ユーザーにエラーを発生させることなく AMP ページが検索結果に表示されるのを止めることができます。 正規ページ (rel="canonical" で指定しているページ) の HTML コードから、rel="amphtml" を削除する AMP ページの URL を、対応する正規ページの URL に 301 リダイレクトまたは 302 リダイレクトする AMP ページがなくなったことを次のようにして確かめる Google 検索して AMP ページが

[レベル: 中級] アクセス解析における、AMP と非 AMP ページ（通常ページ）との間の移動で生じる不正確なトラッキングの問題を Google アナリティクスは解消しました。 同一ユーザーとして正常に認識 AMP ページと非 AMP ページにアクセスがまたがった場合、同じユーザーなのに異なるユーザーとして認識してしまうという問題がAMP のアクセス解析には存在していました。 その結果、ユニークユーザー数が実際よりも多くなってしまったり直帰率が異常に高くなってしまったりする現象が発生します。（詳細はこちらの記事で解説）。 Google アナリティクスに限らずに、amp-analytics を利用するすべての解析ツールに共通の問題です。 欠陥とも呼んでいいこの難題を Google アナリティクスはようやく解決できました。 AMP ページと非 AMP ページ間でも、同じユーザーであれば同じユ

[対象: 全員] 自分が管理する2つのサイトをそれぞれリンクし合ったら、リンク交換あるいは過剰な相互リンクだとして品質ガイドライン違反に問われるのでしょうか？ 米Google ウェブスパムチームの隊長、Matt Cutts（マット・カッツ）氏が僕からの質問に（Yay!）回答してくれました。 釣り全般のサイト（サイトA）を運営していたとします。それとは別にルアーフィッシングに特化したサイト（サイトB）も運営していたとします。 このときサイトBからサイトAにリンクすることはガイドラインに違反しますか？ もちろん、どちらのサイトにも質の高いコンテンツがあってどちらも同じ管理者によって運営されていることを明示しておきます。 特定のケースじゃなくてもっと広い視点から質問したと思うからそれに対しても答えよう。 単にサイトBからサイトAにリンクするだけならガイドライン違反にはならない。 2つしかサイトを