タグ

ブックマーク / www.suzukikenichi.com (529)

  • JavaScript挿入したrel=canonicalをGoogleは処理できる

    [レベル: 上級] JavaScript によって挿入した rel="canonical" を Google は認識、処理できます。 JS 挿入の rel=canonical をサポートしなかったのは昔の話 「レンダリング前の、初期状態の HTML コードにある rel=”canonical” だけを Google は処理する」と John Mueller がちょっと前に言っていたが今でもそうなのか? Google の Martin Splitt(マーティン・スプリット)氏に Twitter でこのように質問したユーザーがいました。 @g33konaut Does Google still only process rel="canonical" in the initially fetched, non-rendered HTML? John tweeted this a while a

    JavaScript挿入したrel=canonicalをGoogleは処理できる
  • Google Merchant Center経由の商品掲載にはLPでの税込み総額表示が必要に

    [レベル: 初級] Google Merchant Center を利用したショッピング広告および [ショッピング] タブでの無料リスティングのランディングページで、消費税込みの総額表示が 2021 年 4 月 1 日から必須になります。 消費税額を含めた価格表示が国の法律によって義務付けられることにともなう更新です。 日での VAT の表示に関する変更 Merchant Center のヘルプページに『日での VAT の表示に関する変更』という件名のお知らせが掲載されています。 先日、日における商品のランディング ページでの VAT の表示に関する要件が更新されました。この新しい要件を遵守するため、日で販売される商品のランディング ページでは、今後商品価格と VAT を分けて表示することができなくなります。4 月 1 日より、ランディング ページに表示する商品の価格には VAT

    Google Merchant Center経由の商品掲載にはLPでの税込み総額表示が必要に
  • ページエクスペリエンスシグナルはGoogle検索のより強いランキング要因に将来的になることも

    [レベル: 上級] ページ エクスペリエンス シグナル は将来的に、より影響力が強いランキング要因になることもありえます。 ページ エクスペリエンス シグナルについての Twitter ユーザーからの質問の回答のなかで Google の Danny Sullivan(ダニー・サリヴァン)氏が言及しました。 最初はソフト ローンチで サリヴァン氏の発言をまとめると次のようになります。 (コア ウェブ バイタルを組み込んだ)ページエクスペリエンスのランキング要因化は、スイッチを切り替えるような、大きな変化が一晩で発生するようなことにはならない 相対的な評価にも依存する。ページ スピードやモバイル フレンドリーのランキングシグナルと同様 たとえば、モバイル フレンドリーがランキング要因になったときは、モバイル フレンドリーなサイトはまだ少なかった。この状況で、モバイル フレンドリーを強いランキン

    ページエクスペリエンスシグナルはGoogle検索のより強いランキング要因に将来的になることも
  • ECサイトのGoogle SEOで必須、固有商品IDとしてGTINを追加する

    [レベル: 中級] 商品を販売しているサイトに対して固有商品 ID を提供するようにと Google は検索セントラル公式ブログで勧めました。 固有商品 ID によって、その商品が何であるかを正確に特定できるようになるからです。 日でも無料リスティングが始まった [ショッピング] タブに掲載する際には、マーチャントセンターから商品フィードを送信します。 このフィードには固有商品 ID を含めることが強く推奨されます。 公式ブログの記事は回りくどいようにも感じるので、僕からの補足を加えながら噛み砕いて説明します。 固有商品 ID とは 「固有商品 ID」とは、個々の商品/製品に割り当てられる一意の番号です。 世界で共通です。 ある商品が、ショップ A で売られていても、ショップ B で売られていても同じ商品であれば固有商品 ID は同じです。 その商品が、日で売られていても米国で売られて

    ECサイトのGoogle SEOで必須、固有商品IDとしてGTINを追加する
  • 5500万件の不正レビューをGoogleマップから削除、Googleはどのようにマップスパム対策しているのか?

    [レベル: 中級] Google マップのスパムにどのように対応しているかを Google は公式ブログで解説しました。 具体的に明かすと逆に悪用されかねないと詳細な説明を避けつつも、マップスパム対策の取り組みの一部を Google は紹介しています。 通常ユーザーとの行動様式の違いを検出 当のマップユーザーの行動様式との違いを検出してスパム判断に用います。 たとえば、ユーザーは通常、通勤や長距離移動の経路案内、あるいはレストランなどのサービスを探すときにマップを利用します。 また、実際に訪れた場所についてレビューや写真を投稿します。 こうした一般的な行動様式を機械学習によって学びます。 もしこうした行動様式から外れたユーザーがレビューを投稿した場合は偽物の可能性があると判断します。 バンコクのユーザーが突然、メキシコシティのカーディーラーに★1つの評価悪いレビューを投稿したら怪しいと判

    5500万件の不正レビューをGoogleマップから削除、Googleはどのようにマップスパム対策しているのか?
  • Google、定期購入とペイウォールコンテンツに関するドキュメント更新――構造化データを追加べきサイト、検索結果に表示される情報の制御

    [レベル: 上級] 定期購入とペイウォール コンテンツに関するドキュメントを Google は更新しました。 次の 2 点です。 構造化データを追加べきサイト 検索結果に表示される情報の制御 定期購入とペイウォール コンテンツを提供するサイトでは、Flexible Sampling(フレキシブル サンプリング)構造化データをマークアップすることにより、ログインが必要な有料コンテンツや会員専用コンテンツを Googlebot にはクロール、インデックスさせることができます。 Flexible Sampling を構成しておけば、ユーザーと Google に異なるコンテンツを配信していてもクローキングにはなりません。 とはいえ、Google の検索結果に掲載されなくてもいい定期購入とペイウォール コンテンツでは Flexible Sampling をわざわざ実装する必要はありません。 こうした

    Google、定期購入とペイウォールコンテンツに関するドキュメント更新――構造化データを追加べきサイト、検索結果に表示される情報の制御
  • Chromeデベロッパーツールでコア ウェブ バイタルを常に計測するHeads-Up Display (HUD) 機能

    [レベル: 上級] Chrome Canary のデベロッパーツールで、今閲覧しているページのコア ウェブ バイタルを常に表示できるようになります。 「HUD: Heads-Up Display(ヘッドアップ ディスプレイ)」という機能です。 CVW をオーバーレイで常時計測 デベロッパーツールで、コア ウェブ バイタルの HUD を有効にした状態のキャプチャです。 ページの右上にコア ウェブ バイタルの 3 つの指標をオーバーレイで表示しています。 今開いているページのコア ウェブ バイタルです。 ページを移動するとそのページのコア ウェブ バイタルを計測します。 コア ウェブ バイタルを常時計測する Chrome 拡張があります。 同等の機能がデベロッパーツールに備わった感じですね。 デベロッパーツールで HUD を有効にする Chrome のデベロッパーツールでコア ウェブ バイタル

    Chromeデベロッパーツールでコア ウェブ バイタルを常に計測するHeads-Up Display (HUD) 機能
  • 検索結果の情報源を提供する機能をGoogleが導入、信頼できるサイトからの情報かが検索結果でわかる

    [レベル: 中級] 検索結果で、その結果がどんなサイトからの情報なのかを表示する機能を Google は導入しました。 Wikipedia の説明文を引用 サイトの情報を見るには検索結果にあるタテの 3 点ドットをクリック/タップします。 そのページを公開しているサイトが Wikipedia に掲載されている場合は、Source(情報源)として Wikipedia から引用した説明を表示するボックスが出現します。 “About this result”(この結果について)という見出しが付いています。 Wikipedia から引用する理由は無料で利用できることに加えて、 最も多くの情報を蓄積していて 最も最新で 最も信頼できる からだそうです(異論があるかもしれませんが、Google 的にはそういうことです)。 説明に加えて、HTTPS を適用しているサイトには次の注釈も付きます。 Your

    検索結果の情報源を提供する機能をGoogleが導入、信頼できるサイトからの情報かが検索結果でわかる
  • お買い得がわかる? Googleが価格下落を商品リッチリザルトに表示

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

    お買い得がわかる? Googleが価格下落を商品リッチリザルトに表示
  • Chrome88のデベロッパーツールのレコーディング機能でウェブバイタルの情報を記録できるように

    [レベル: 上級] ウェブ バイタルを記録するオプションが、安定版 Chrome 88 のデベロッパー ツールの [Performance] レコーディング機能に追加されました。 安定版の Chrome 88 は 1 月 19 日にリリースされました。 現在更新できます。 Web Vital オプションで CLS を調査する 大きな CLS (Cumulative Layout Shift) が発生しているページをデベロッパー ツールの [Performance] で計測してみます。 デベロッパー ツールで [Performance] を開くと [Web Vitals] というオプションが上部にあるので、チェックを入れてレコーディングを開始します。 レコーディング結果の赤色のひし形♦️が、発生した CLS です(Layout Shift の略で LS と表記さている)。 結果を下に少しスク

    Chrome88のデベロッパーツールのレコーディング機能でウェブバイタルの情報を記録できるように
  • ChromeでHTTPS接続がデフォルトになるかも、HSTSはもう不要?

    [レベル: 上級] Google Chrome が HTTPS をデフォルトのプロトコルとしてウェブページに接続するようになるかもしれません。 現在は HTTP がデフォルト プロトコル https または http のプロトコルを付けずに URL をオムニボックス(Chrome の URL バー)に打ち込んでアクセスした場合、現在は http:// を自動的に付加してそのページに Chrome はアクセスします。 たとえば、[example.com] とだけ入力してアクセスすると [http://example.com/] の URL に置き換えて Chrome はリクエストを送信します。 もしサイトが HTTPS 対応していてかつリダイレクト設定していれば [https://example.com/] にリダイレクトされて、再度接続し直します(※HSTS を設定していない場合、詳しくは

    ChromeでHTTPS接続がデフォルトになるかも、HSTSはもう不要?
  • Google アナリティクス 4 (GA4) はAMPをまだサポートしていない

    [レベル: 上級] Google アナリティクス 4(以下、GA4)は AMP をまだサポートしていません。 したがって AMP ページのトラフィックを計測できません。 AMPの GA4 未サポートは担当チームに認識されているが Google アナリティクス 4(以下、GA4)は 2020 年 10 月に Google が正式リリースした新しいバージョンの Google アナリティクスです。 前のバージョンのユニバーサル アナリティクスからすでにアップグレードして GA4 を利用しているサイトも出てきているでしょう。 しかしながら、AMP を導入しているサイトでは注意が必要です。 この記事を公開している時点では、GA4 は AMP にまだ対応していません。 つまり、AMP ページへのアクセスを取得できません。 amp-analytics を解説する AMP の公式サイトおよび Google

    Google アナリティクス 4 (GA4) はAMPをまだサポートしていない
    t-w-o
    t-w-o 2021/01/20
    そうか、そうなるのか。サポート開始予定のスケジュールも公開されていないのは厳しいなあ。AMPの計測、本当に色々と面倒だ……
  • Google、Question Hubを米国で提供開始。検索ユーザーが知りたいことを直接入手できる

    [レベル: 上級] Google の Question Hub(クエスチョン ハブ)が米国で利用できるようになりました。 Question Hub とは Question Hub とは、 検索ユーザーがウェブで見つけられなかった情報に関する質問を収集し、 その質問に対するコンテンツを作成してサイトで公開し、 Google に通知できる ツールです。 現在はベータ版として一部の国と言語で公開されています。 米国(英語) インド(ヒンディー語、英語) インドネシア(インドネシア語) ナイジェリア(英語) 今回導入された米国を除けば、十分な質と量のコンテンツがウェブで公開されてるとは必ずしも言えない国と言語です。 そこで Google は、ウェブでは手に入らなかった情報についての質問をユーザーから直接集めて、その質問をコンテンツ製作者に提供します。 コンテンツ製作者は、その質問に対するコンテンツ

    Google、Question Hubを米国で提供開始。検索ユーザーが知りたいことを直接入手できる
  • Passage Indexingはまだ導入されず、検索での見え方は通常の結果と同じ

    [レベル: 上級] Passage Indexing に関して追加の情報が入りました。 次の 3 つです。 まだ導入されていない 通常の検索結果と見た目は同じ data-nosnippet タグは Passage Indexing を抑制しない まだ導入されていない Passage Indexing はまだ導入されていません。 この機能の発表当初は 11 月の導入予定でした。 ですが、12 月 23 日(米国太平洋時間)の時点では依然として未導入の状態です。 It is not. — Danny Sullivan (@dannysullivan) December 23, 2020 今日明日の導入は考えづらいので、来年の導入になるでしょう。 なお、今月初め(2020 年 12 月)に実施されたのコア アップデートとも Passage Indexing は関係ありません。 通常の検索結果と見

    Passage Indexingはまだ導入されず、検索での見え方は通常の結果と同じ
  • WebストーリーでAdSenseをプログラマティック広告として配信可能に

    [レベル: 上級] Web ストーリーで AdSense 広告を配信できるようになりました。 コードを貼り付けるだけでよく、広告専用のページを作成する必要はありません。 アド マネージャーと AdSense のプログラマティック広告を Web ストーリーで配信 Web ストーリーでの広告配信はすでに可能でした。 ただし、広告専用のページを作成する必要がありました。 <html ⚡4ads> タグで構成します。 一方、プログラマティック広告では広告用のコードを既存の Web ストーリー のコードに挿入するだけです。 どんな広告をどこに表示するかは自動で決定されます。 プログラマティック広告は次の 2 種類の広告がサポートします。 アド マネージャー AdSense まだベータ版ではありますが、一般公開されすべてのパブリッシャーが利用できます。 AdSense のプログラマティック広告設定 W

    WebストーリーでAdSenseをプログラマティック広告として配信可能に
  • 動的に変化するスニペットをGoogleがテスト――展開して増えるスニペットと画像が出現するスニペット

    [レベル: 中級] 動的に変化するスニペットを Google は検索でテストしているようです。 2 種類あります。 1 つはスニペットが展開する検索結果で、もう 1 つは画像がスニペットの中に出現する検索結果です。 展開するスニペット まず、展開するスニペットです。 スニペットの先頭にノートのようなアイコンが付いています。 そのアイコンをクリックするとスニペットが展開して、より多くのスニペットが表示されます。 Anyone seen this? Google testing a meta description expander in the SERP. Default displaying the regular ~150 characters and expanding to 300+ chars. pic.twitter.com/UYrR6WLf8L — Jordan Long (@

    動的に変化するスニペットをGoogleがテスト――展開して増えるスニペットと画像が出現するスニペット
  • 【確定】コアウェブバイタルがGoogleランキング要因になるのはモバイル検索だけ

    [レベル: 中級] Core Web Vitals(コア ウェブ バイタル)がランキングに影響を与えるのはモバイル検索だけになりそうです。 ページ エクスペリエンス シグナルの 1 要素として2021 年 5 月からコア ウェブ バイタルをランキング要因に組み込むことを Google は発表しています。 FAQ が正しかった Google は先日ヘルプコミュニティに、『Core Web Vitals & Page Experience FAQs』(コア ウェブ バイタルとページ エクスペリエンスに関してよくある質問)を投稿しました。 その中で次のように言及しています。 At this time, using page experience as a signal for ranking will apply only to mobile Search. 現時点では、ランキングに対するシグナ

    【確定】コアウェブバイタルがGoogleランキング要因になるのはモバイル検索だけ
  • Google、コアウェブバイタルの基準を満たすインジケーターを検索結果に表示するテストを開始

    [レベル: 中級] Core Web Vitals(コア ウェブ バイタル)が 2021 年 5 月からランキング要因に組み込まれます。 これにあわせて、検索結果に表示されたウェブページがコア ウェブ バイタルの基準を満たしていることを示すインジケーターが付くようになります。 このインジケーター表示のテストを Google は始めたようです。 CWV インジケーターは手裏剣アイコン? インジケーター表示のテストに遭遇したユーザーがキャプチャを Twitter に共有しています。 @g33konaut hey… what does that Ivón mean? pic.twitter.com/0oA8eTyOxd — Klaus Bandisch (@friendsaround50) December 5, 2020 It seems that my SERP is being teste

    Google、コアウェブバイタルの基準を満たすインジケーターを検索結果に表示するテストを開始
  • AMPページと通常ページのどちらのコアウェブバイタルをGoogleはランキング要因として見るのか?

    [レベル: 上級] AMP 配信しているサイトでは、通常ページと AMP ページのどちらの Core Web Vitals(コア ウェブ バイタル)がランキング要因として評価されるのでしょうか? 答えは、検索結果に出ている方のページです。 ユーザーが見ているページの CWV で評価する 基的な考え方としては、検索結果に出ているページのコア ウェブ バイタルがランキング要因の指標になります。 もし検索結果に AMP ページが出ていれば、その AMP ページのコア ウェブ バイタルが評価の対象です。 何らかの理由で(たとえば、AMP の構成にエラーがあり)通常のモバイル向けページが検索結果に出ていれば、通常ページのコア ウェブ バイタルが評価対象になります。 PC 検索では、AMP 対応しているかどうかに関係なく PC 向けページのコア ウェブ バイタルが評価対象になるでしょう(ただし、コア

    AMPページと通常ページのどちらのコアウェブバイタルをGoogleはランキング要因として見るのか?
  • Google画像検索の画像認識はまだまだ不完全、リンゴ🍎とバナナ🍌を区別できるくらい

    [レベル: 上級] 画像認識の技術Google は画像検索に用いていますが、完成度はまだ決して高くないようです。 Search Off the Record ポッドキャストのエピソード 10 で、Gary Illyes(ゲイリー・イリェーシュ)氏が、画像インデックスの処理について説明したなかで言及しました。 画像インデックスのプロセス 大まかに言うと、次のようなプロセスで画像はインデックス処理されるそうです。 コンテンツ変換(インデックスできる形式に変える)の際に、基的には画像タグを抽出する。あわせてほかのデータからも情報を取得する。 その画像がある URL を特殊な画像インデクサーに送る 画像認識・解析が実行される 最後の画像認識・解析については深く考えてはいけないようです。 完璧とは言い難く、目指すべきレベルにはまだ到達できていません。 リンゴとバナナくらいは区別できますが、ペン

    Google画像検索の画像認識はまだまだ不完全、リンゴ🍎とバナナ🍌を区別できるくらい