[レベル: 中級] 昨日、日本時間の 2020 年 8 月 11 日の午前中から尋常ではない大変動が Google 検索に発生しました。 単なるアルゴリズムのアップデートとは思えない、異常な検索結果が各所で観測されました。 蓋を開けてみると、アルゴリズム更新ではなくインデックス システムに発生した障害が原因とのことでした。 おそらく今朝は元どおりに戻っているはずです。 カフェインに不具合発生 Google Webmaster の Twitter 公式アカウントが次のようにアナウンスしました。 月曜日に、Google の検索結果に影響するインデックスシステムの問題を検出しました。問題が検出されるとすみやかにサイト リライアビリティ エンジニアによって修正され、問題はもうそろそろ緩和しているはずです。 On Monday we detected an issue with our indexi

[レベル: 初級] アフィリエイトサイトを Google は毛嫌いしてはいません。 アフィリエイトであることを Google に隠す必要はありません。 アフィリエイトリンクは隠すべき？ rel=”sponsored” を付けるべき？ 広告のようなリンクがリンクプログラムとしてガイドライン違反にならないようにするために、次の 2 とおりの対応を Google は提案しています。 rel = "nofollow" またはより具体的な属性を <a> タグに追加する robots.txt ファイルによって検索エンジンからブロックされる中間ページにリンクをリダイレクトする 2 つめの robots.txt を使うやり方は、自分のサイト（もしくは管理できる別のサイト）の URL にリンクして、そこから実際のアフィリエイト URL にリダイレクトする方法です。 リダイレクト元の URL をブロックしてお

[レベル: 中級] すべてのサイトにモバイル ファースト インデックスを 2020 年 9 月から適用することを Google は先日アナウンスしました。 モバイル ファースト インデックス（以下、MFI）の準備が整っていないサイトは対応を進めていると思います。 あるいは、準備万端のはずなのに MFI にまだ移行されておらず不安に感じているサイト管理者もいるかもしれません。 この記事では、MFI 移行の準備ができているかどうかを調べるのに役立つツールを 2 つ紹介します。 MFI チェックツール その 1 1 つ目のツールは ZEO が提供する “Mobile First Index Checker” です。 使い方は簡単です。 検証したいサイトの PC 版の URL を入力して実行するだけです。 MFI 移行に求められる項目をチェックしてくれます。 別々の URL でモバイル向けページを

[レベル: 上級] 画像権利の情報を示すラベルを画像検索に表示する機能を Google は試験的にスタートする予定です。 画像のライセンス所有者は構造化データまたは ITPC メタデータを構成することで、Google 画像検索に画像権利情報を表示できます。 Soon, we will begin beta testing a new way for sites to display licensing information about content that appears in Google Images. The new badging and license information display isn't live yet, but you can prepare your content for it now. Learn more: https://t.co/dPGAP2

[レベル: 中級] 現在のSearch Console に昨年 10 月に移植された新しいアドレス変更ツールに Google は改良を加えました。 サイト移転が正しくできているかどうかを確認しやすくなっています。 New improvements to the Google Search Console Change of Address tool 🎊 ✔️ Redirect validation for top 5 URLs of the moving domain. ✔️ Reminders on top of both the moving domain and the destination domain. 📖 Learn more about the tool https://t.co/RJxiJeQRjl pic.twitter.com/FEfNS9VUhd — Googl

[レベル: 上級] コア アルゴリズム アップデートは、通常のウェブ検索だけではなく Discover にも影響することがあります。 また、Discover に掲載されたコンテンツがどんなトピックに分類する方法はあるのでしょうか？ コアアップデート実施時には Discover トラフィックも要確認 次のような質問が英語版オフィスアワーで出ました。 コア アルゴリズム アップデートは Discover にも影響しますか？ 1 月のコアアップデートの数週間後に Discover のトラフィックが減っていたことに気づきました。 Search Console のレポートも、インプレッションの全体的な減少を示しています。 John Mueller（ジョン・ミューラー）氏はこのように回答します。 ああ、影響する。 コアアップデートの一連の調整には Discover も含まれていたはずだ。コアアップデー

[レベル: 上級] loading=lazy 属性で実装するネイティブ Lazyload がウェブ標準になりました。 Chrome 以外のブラウザのサポートが期待されます。 The lazy loading attribute (<img loading="lazy") is now officially a web standard 🎉 Thanks to @domfarolino and other community members!https://t.co/fMqFq8gBVs pic.twitter.com/fFotntnBlD — Houssein Djirdeh (@hdjirdeh) February 12, 2020 The specification for native image lazy-loading has been merged into the HTML

[レベル: 上級] 構造化データが今よりも簡単になっていくことはなく、むしろさらに複雑で難しくなっていくだろうと Google 社員が予想しています。 構造化データはさらに難解に Google が利用する構造化データの将来について、Google の John Mueller（ジョン・ミューラー）氏はオフィスアワーで次のようにコメントしました。 将来的、少なくとも近い将来にもっと多くの種類の構造化データマークアップを使うようになると私は考える。そして、さまざまな検索機能の要件という点で、おそらくもっと複雑になっていくだろう。検索結果での装飾的な機能もそうだし、たしか Google アシスタントの読み上げ機能なども現状では多分に構造化データに依存している。 構造化データの分野はもっと拡大していくだろうから、さらに多くのマークアップが登場してくると予想する。新しい構造化データが出てくると、実装や

[レベル: 中級] モバイル ファースト インデックス対応を説明する技術ドキュメントを Google は大幅に更新しました。 この記事ではその変更点の概要を紹介します。 なお、記事を公開している時点では更新されているのは英語版ページです。 日本語版ページはまだ更新されていません。 MFI 技術ドキュメントの変更点概要 まず、ドキュメントのタイトルが変わりました。 旧: Prepare for mobile-first indexing 新: Mobile-first indexing best practices 「モバイル ファースト インデックスに向けて準備する」が「モバイル ファースト インデックスのベストプラクティス」になりました。 MFI への移行が完了したサイトが増えたので “Prepare”（準備）という表現がそぐわなくなってきたからかもしれません。 準備編からベストプラクテ

[レベル: 中級] スピード測定ツールの Test My Site を Google は大幅に改良しました。 Tesy My Site はモバイルサイトのパフォーマンスをまとめて検証できるツールとして、広告主向けに2017 年 6 月にリリースされました。 多くの機能改善と機能追加 次のような機能と改良が Test My Site ツールに追加されました。 サイト全体および個別ページのスピード検証 前月と比較してのスピードの変化（速くなったか遅くなったか） サイトのスピードが平均と比べて速いか遅いか 競合サイトとのスピード比較 スピード改善が収益に与える影響のシミュレーション スピード改善のための具体的な施策提案 完全なレポートの共有機能 Amazon はモバイルサイトは全体では、日本での 4G の環境だと表示に 1.5 秒かかるとの結果です（国と回線環境は設定できる）。 Average

[レベル: 中級] 名称や所在地など企業の情報を表す構造化データはサイト内のどのページに追加すべきなのでしょうか？ トップページでしょうか？ 会社案内ページでしょうか？ それとも、すべてのページにマークアップしたほうがいいのでしょうか？ 結論を言うと、どのページでも問題にはなりません。 あなたが適切と考えるページに追加することができます。 企業情報の構造化データはサイト内のどのページに設置してもよい 組織・企業の構造化データ（Organization とそのサブタイプ）はどのページに追加すべきなのかという質問が英語版オフィスアワーで取り上げられました。 Google の Matin Splitt（マーティン・スプリット）氏は次のように返答しています。 どのページに設置してもたいした問題にはならないと思う。すべてのページに設置しないということのほうが、もっと大事なようにも思える。 サイトにも

[レベル: 上級] 検索結果に戻ったときに「他の人はこちらも検索」というラベルで、関連ワードを出現させる機能を Google はちょうど 1 年前に導入しました。 これをさらに発展させた機能を Google はテストしているようです。 関連ワードではなく、関連するウェブページを提案します。 検索結果の中に小さな検索結果をカルーセルで作成 検索結果に出てきたページをタップしてそのページを閲覧します。 そして検索結果に戻ると、訪問したページの下に「他の人はこちらもチェック」として、関連しているページのサジェストが出現します。 関連するキーワードではありません。 カルーセルになっています。 そのページのタイトルとスニペット、URL が表示されており、さながらカルーセルのなかに “小さな” 検索結果がさらにできているようです。 米 Google (google.com) でも出現しました。 英語の

[レベル: 中級] <noscript> タグ内のコンテンツを Google はインデックスしません。 しかし画像は例外です。 <noscript> の中であっても <img> タグの要素はインデックス対象になります。 スパム対策のため <noscript> は無視される <noscript> タグは、スパムに利用されてきた経緯があります。 （JavaScript を実行する）ブラウザでは画面に表示されないものの、HTML コード内には存在するため検索エンジンには認識されます。 隠しテキストや隠しリンクとしての悪用が可能でした。 そのため、かなり以前から <noscript> 内のコンテンツを Google は無視するようになっています。 Lazyload 画像対応の noscript は例外 Lazyload で遅延読込みさせる画像をインデックスさせるために、Google は次の2つの方

[レベル: 初級] 検索結果に表示される半分以上のページがすでにモバイル ファースト インデックス（以下、MFI）に移行したことを、昨年暮れに Google は公表しました。 一方で、残りの半分の移行は一筋縄ではいかないだろうと、Google の John Mueller（ジョン・ミューラー）氏はコメントしたと Search Engine Roundtable が報じています。 モバイルページと PC ページの不一致 MFI に移行できない一番の理由は、モバイル向けページと PC 向けページが同等になっていないサイトが多いからのようです。 MFI に関する最新の公式ブログ記事から察するに、おそらく特に、次の情報の不一致が移行の妨げになっているのではないかと僕は疑います。 モバイル版ページの構造化データの欠落 モバイル版ページの画像代替テキストの欠落 モバイル向けページに構造化データがないと

[レベル: 上級] Google の求人検索が日本で導入されました。 Google Japan Blog: Google しごと検索で、仕事探しをもっとスムーズに！ Google しごと検索とは 求人検索は、その名のとおり求人情報に特化した検索機能です。 求人に関連するクエリが検索されると、企業の求人ページや求人・転職サイトに掲載されている求人情報を集約して検索結果に掲載します。 モバイル検索と PC 検索の両方で利用できます。 求人検索は、2017 年 5 月の Google I/O で Google for Jobs というサービス名で発表されました。 現在は、Job Posting として 2017 年 6 月の米国でのリリースを皮切りに、南米、中東、北アフリカなど世界中のさまざまな国と地域に展開を進めてきています。 インドやシンガポール、香港などアジア諸国でも導入が始まっているもの

[レベル: 初級] 1 つのサイトマップにすべての URL を記載して送信する場合と、複数のサイトマップに分割して URL を送信する場合とでは Google のクロールとインデックスに違いが生じてくるのでしょうか？ Google の John Mueller（ジョン・ミューラー）氏によれば、サイトマップがどのように分かれていても Google は気にかけないとのことです。 サイト管理の形態に合わせてサイトマップを構成できます。 サイトマップがどのように分割されていようが Google は気にしない ウェブページと画像を1つのサイトマップにまとめるべきか、それとも分けるべきか？ この質問にミューラー氏は次のように回答しました。 どちらのやり方も機能する。 Google 側の技術的な仕組みで言うと、発見したサイトマップをすべて統合して 1 つの大きなファイルにまとめる。そして、それを処理する

[レベル: 上級] Google は EU 圏内で、タイトルやスニペット、画像がない検索結果をテストしているようです。 昨年 9 月に可決され来週中にも施行されると報じられている EU 著作権指令の改正案に従ったものと思われます。 不具合のように見える検索結果 こちらは Search Engine Land が入手した、テストが適用されている検索結果です。 タイトルがサイト名のみ、またはなしで URL のみ スニペットなし 画像なし 「検索結果こわれてる」と思わせるような風貌になっています。 EU 著作権指令への対応 このような検索結果を Google がテストしているのは、EU 著作権指令改正案の 11 条および 13 条への対応です。 11 条は、検索エンジンやニュース収集サイト（例: Google 検索や Google ニュース）が記事の要約を掲載するときにはライセンス料を支払うこと

[レベル: 中級] リッチリザルト テスト ツールがコードでの検証をサポートしました。 構造化データのコードを編集しながらの検証が可能です。 これまでは URL を入力して、公開しているページの検証しかできませんでした。 昨年 11 月の Chrome Dev Summit でアナウンスされていた機能拡張です。 RRTT でコード検証 リッチリザルト テスト ツールにアクセスすると、「URL」と「コード」の切り替えができるようになっています。 コードを選択し、検証したい構造化データを貼り付けて、テストを実行します。 画面左には貼り付けたコードが出ているので、修正しながら検証を継続できます。 構造化データの公開前の検証が可能になったのは非常に便利です。 エラーを修正したりコードを調整をしたりといったことが事前にできます。 ただし、注意点があります。 リッチリザルト テスト ツールがサポートと

[レベル: 中級] Google の現在の検索結果には、従来の青色リンクのほかリッチリザルトや強調スニペット、ナレッジグラフ カードなどさまざまな特殊機能が加わっています。 こうした検索結果に含まれるさまざまな形式を解説したヘルプ記事を Google は公開しました。 ページやサイトに最適な機能のアドバイスもしています。 「サイトの検索結果機能を有効にする」ヘルプ記事 検索結果の一般的なカテゴリとして、次が挙げられています。 通常の青色リンク 拡張機能 リッチリザルト ナレッジグラフ カード 強調スニペット Onebox の検索結果 こちらは、通常の青色リンクの説明です。 こちらは、ナレッジグラフ カード の説明です。 こちらは、Onebox の検索結果説明です。 リッチリザルトは特別で、カーソルを当てるとポップアップが出現し、さらに詳細を説明しているデベロッパーサイトへリンクしています（

[レベル: 上級] WordPress サイトを AMP 対応する公式プラグインのバージョン 1.0 安定版が正式公開されました。 AMP プラグインのディレクトリからダウンロードできます。 統一されたデザインと機能を AMP で実現 v1.0 の大きな特徴の 1 つは統一されたデザインと機能を AMP ページで実現できる点です。 v1.0 以前のプラグインは、AMP ページのデザインが変わってしまい通常のモバイルページと比べるとかなり簡素に変換されてしまっていました。 しかし、v.1.0 では、AMP ページの外観および機能は通常のモバイルページとなんら変わりありません。 最新の AMP プラグインには 3 つのモードがあります。 Native Mode（ネイティブ モード）: サイトを完全に AMP 化する。すべてのページが AMP になり、通常の PC ページやモバイルページはなくな