Google推奨の動画SEO: 各動画に専用ページを作成する
[レベル: 中級] 動画だけを掲載するページの作成を推奨するガイドを、検索セントラル サイトの動画検索のベストプラクティスに Google は追加しました。 各動画の専用ページを作る この記事を公開している時点では、日本語ページはまだ更新されていません。 オリジナルの英語ページには次の段落が加わっています。 【UPDATE (2021/11/18)】 日本語ページにも更新が入りました。 To give your videos maximum exposure, create a dedicated page for each video, where the video is the most prominent subject on the page. Some features require that type of video page, including Key Moments
Lazy-loadはLCPを悪化させる!? WordPressは2つ目の画像からネイティブLazy-loadを実装するように改良予定
[レベル: 上級] ファーストビューに掲載されている画像を Lazy-load（遅延読み込み）すると コア ウェブ バイタル の 1 指標である LCP を低下させる恐れがあります。 そのため WordPress は、ファーストビューの画像にネイティブ Lazy-load を適用しないように改善する予定です。 ネイティブ Lazy-load は、画像の <img> タグに loading="lazy" 属性を付けることで、ブラウザの機能として遅延読み込みを実現する技術です。 現在は、Chrome や Edge、Firefox など多くのブラウザがサポートしています。 ファーストビュー画像を遅延読み込みさせた WP は LCP が悪化 Lazy-load の利点は、スクリーン領域に入っていない画像を読み込ませないことでデータの転送量を抑えられることです。 スクリーン領域に近づいたところで初め
Google、動画SEOのベストプラクティスを公開。YouTube動画と技術ドキュメントで解説
[レベル: 中級] 動画 SEO に役立つ新しいリソースを Google は公開しました。 YouTube の動画と検索セントラルの技術ドキュメントでベストプラクティスを解説している。 動画 SEO 向け動画 Google 検索の動画を担当しているプロダクト マネージャの Danielle Marshak（ダニエル・マーシャク）氏が、動画 SEO の基本的なベストプラクティスをライトニングトークで解説しています。 次のトピックに触れています。 ウェブで動画を見つけられるようにする 動画構造化データでマークアップする 高品質なサムネイル画像を設定する 動画サイトマップを送信する 動画ファイルに Google がアクセスできるようにする 日本語字幕あり Marshak 氏は（当然）英語で話していますが、日本語字幕を利用できます。 歯車アイコン⚙️から [字幕] を選択し [日本語] を指定しま
タグマネージャとJavaScriptを使って構造化データを生成する方法をGoogleが解説
[レベル: 上級] JavaScript を利用して構造化データを生成する方法を解説するドキュメントを Google はデベロッパーサイトで公開しました。 Google タグマネージャおよびカスタム JavaScript を使ったやり方を説明しています。 タグマネージャで構造化データを動的に生成 手順の詳細はドキュメントを読んでいただくとして、この記事では特に気にかけておくべき点に触れておきます。 カスタム HTML で作成 タグマネージャで、構造化データ用に構成するタグはカスタム HTML です。 ページ内容に応じて動的に構造化データを生成するために変数を使えます。 変数の例はドキュメントで参照できます。 SSR の利用可能 サーバー サイド レンダリング (SSR) を実装している場合は、構造化データの生成も SSR に含めることができます。 Googlebot のレンダリングにかかる
ネイティブLazy-loadをWordPressで簡単実装するプラグインをGoogleが公開
[レベル: 中級] ネイティブ Lazy-load を簡単に実装する WordPress 用のプラグインを Google が公開しました。 ネイティブ Lazy-load は JavaScript のライブラリを利用することなく loading 属性を追加するだけで、画像と iframe の遅延読み込みを可能にします。 1 か月前にリリースされた Chrome 76 でサポートされました。 設定不要、インストールするだけで WP で Lazy-load Native Lazyload プラグインの使い方は非常にシンプルです。 インストールして有効にするだけです。 設定項目はありません。 有効にすると、img タグと iframe タグに loading=”lazy” 属性をプラグインが自動的に追加します。 現状では、loading 属性をサポートするブラウザは Chrome 76（以上）だ
ネイティブLazy LoadをChromeが試験的にサポート開始
[レベル: 上級] JavaScript のライブラリを実装することなく、ブラウザにもともと備わっている機能として lazy load を実行する仕組みを Chrome Canary 75 がサポートするようになります。 lazy load 専用の属性を HTML コードに追加するだけで、 <img> と <iframe> で指定するコンテンツを簡単に遅延読み込みできます。 通称、”Native（ネイティブ） lazy load” は、昨年の 8 月に構想ができあがりました。 ついに本格的に試験運用が始まります。 ネイティブ lazy load を制御する loading 属性 ネイティブ lazy load を制御するには、 <img> タグまたは <iframe> タグに loading 属性を追加します。 3種類の値を設定できます。 loading="lazy": lazy は la
WordPressをAMP対応するプラグインの正式版 v1.0 が公開。統一されたデザインと機能のAMPページを実現
[レベル: 上級] WordPress サイトを AMP 対応する公式プラグインのバージョン 1.0 安定版が正式公開されました。 AMP プラグインのディレクトリからダウンロードできます。 統一されたデザインと機能を AMP で実現 v1.0 の大きな特徴の 1 つは統一されたデザインと機能を AMP ページで実現できる点です。 v1.0 以前のプラグインは、AMP ページのデザインが変わってしまい通常のモバイルページと比べるとかなり簡素に変換されてしまっていました。 しかし、v.1.0 では、AMP ページの外観および機能は通常のモバイルページとなんら変わりありません。 最新の AMP プラグインには 3 つのモードがあります。 Native Mode（ネイティブ モード）: サイトを完全に AMP 化する。すべてのページが AMP になり、通常の PC ページやモバイルページはなくな
ページのダウンロード時間が1000ミリ秒を超えると、Googlebotがクロールに制限をかける可能性あり
[レベル: 上級] Googlebot がページをクロールするときにかかるダウンロード時間が 1,000 ミリ秒を超えると、クロールに支障をきたすかもしれません。 一応の目安として、100 〜 500 ミリ秒以内を考慮しておくとよさそうです。 ページのダウンロード時間は 100 〜 500 ミリ秒が理想、1,000 ミリ秒は遅すぎ （旧）Search Console のクロールの統計情報レポートでは、ページのダウンロード時間の情報を確認することができます。 ページのダウンロード時間は、Googlebot がリソースを純粋にリクエストするのにかかった時間を示すデータです。 PageSpeed Insights のようにユーザーが使うブラウザの表示にかかる時間ではありません。 リソースは、HTML のほか画像や CSS、JavaScript、PDF なども含みます。 ダウンロード時間の目安に関
GoogleがDataset構造化データをサポート、表形式のデータを検索結果に表示
[レベル: 上級] dataset（データセット）の構造化データを Google がサポートするようになりました。 schema.org/Dataset の構造化データをマークアップすると、表形式で構成されたデータをリッチリザルトとして検索結果に表示できます。 定型フォーマットで整理したデータを検索結果に表示 dataset として定義できるデータの種類はさまざまです。 統一されたフォーマットで構成されたデータはたいてい dataset として利用できます。 たとえば、イメージしやすいのは CSV で保存されているデータです。 表形式になっていて、何らかのデータを系統的に提供しています。 独自の形式であっても、定型のフォーマットでデータをまとめていれば dataset として認められます。 コンピュータに読み込ませるデータは、定められたフォーマットになっていることが多いはずです。 そうした
レンダリング後に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、2018年3月上旬にコアアルゴリズムのアップデートを実施。順位下落の対処方はすばらしいコンテンツを作り続けること以外になし
[レベル: 中級] コアアルゴリズムのアップデートを先週実施したことを Google 検索の Twitter 公式アカウントがアナウンスしました。 同時に、アルゴリズム変更があったときの心構えをアドバイスしています。 先週にコアアルゴリズムのアップデートを実施したとのことです。 検索結果を改善するために設計された変更を毎日 2つ以上、Google は普段実施しています。特定の改善に集中したものもあれば、幅広い改善を狙った変更もあります。 先週、広範囲に影響するコアアルゴリズムの更新を実施しました。年に数回こうした更新を定期的に実施しています。 Each day, Google usually releases one or more changes designed to improve our results. Some are focused around specific impro
Google、動的に出現する「他の人はこちらも検索」をPC検索にも導入
[レベル: 中級] 検索結果に出てきたページに訪問してから再び検索結果に戻ってきたときに、「他の人はこちらも検索」を動的に出現させる機能を Google は2017年1月にモバイル検索で導入しました。 同等の機能を PC 検索にも導入しました。 こちらは通常の検索結果です。 僕のブログのページが1位に出ています。 クリックしてページに訪問しバックボタンを押して検索結果に戻ります。 すると「他の人はこちらも検索」ボックスがワンテンポ遅れて出現します。 キャプチャではわかりづらいですが、対象の結果は枠線で囲まれます。 どの結果のページに訪問したかをわかりやすくするためですかね。 モバイル検索と同様に、訪問したページによって提案されるクエリが異なります。 研究熱心な方はどういうアルゴリズムになっているかを分析するといいかもしれません。 Google としては、ユーザーの手間を省いたうえで検索回数
遂に来た！通信が安全ではないことを示す警告をすべての非HTTPSページにGoogle Chromeが常に表示。2018年7月リリースのバージョン68から
[レベル: 初〜中級] HTTPS ではなく HTTP で配信されているすべてのページに対して、通信が安全ではないことを通知するラベルを Chrome ブラウザで常に表示することを Google はアナウンスしました。 2018年7月にリリースされる Chrome 68 から実装する予定です。 全 HTTP ページに「保護されていない通信」ラベルを常時表示 HTTPS で配信していないページ、言い換えれば、HTTP のままで配信しているページには「保護されていない通信」のラベルが URL アドレス欄の先頭に表示されます。 たとえば、今でも HTTP で頑張っている東京都の公式ホームページは、この記事を書いている時点での最新版の Chrome（安定版）のバージョン 64 では、次のように表示されます。 と言っても、気になるところは何もありませんが。 これが、2018年7月にリリースされる C
Googleのモバイルファーストインデックス、今はどんな状況？導入に向けて必要な対応まとめ
[レベル: 初級] モバイル ファースト インデックス (以下、MFI) 導入に向けての現在の状況をウェブマスター向け公式ブログで Google は説明しました。 サイト管理者として必要な対応にも触れています。 日本のウェブマスター向けブログでもすぐに翻訳版が出てくるだろうと予想するので、この記事では要点を簡潔にまとめます。 MFI の現状まとめ 今までは、基本的に PC 向けページをインデックスし、ランキングに使ってきた。MFI ではモバイル向けページをインデックスし、ランキングに使う――モバイルユーザーの方が現在は多くなっているので、それに合わせた変更 MFI に切り替わるとスマートフォン版 Googlebot のクロールが増加する 検索結果のスニペットやキャッシュはモバイル向けページから取得される レスポンシブ ウェブ デザインの構成および、PC 版のコンテンツとマークアップをすべて
Googleのモバイルファーストインデックスに切り替わったかどうかを知るにはログファイルが役立つ
[レベル: 上級] 管理しているサイトがモバイル ファースト インデックス（以下、MFI）へ移行したのかどうかを調べる方法として、サーバーのログファイルの監視を Google の John Mueller（ジョン・ミューラー）氏は推奨しました。 ログファイルを見て、スマートフォン版 Googlebot の活動量が PC 版 Googlebot の活動量を逆転し上回っているようであれば、MFI に切り替わっている可能性が濃厚です。 現状: PC 版 Googlebot ＞ スマホ版 Googlebot ⇒ MFI後: PC 版 Googlebot ＜ スマホ版 Googlebot プライマリのインデックスに PC 向けページが使われている現状では、PC 版の Googlebot のアクセスが多くを占めています。 対して、スマートフォン版（モバイル版）の Googlebot のアクセスは PC
すべての非HTTPSページにシークレットモードで警告表示、開発版ChromeにGoogleが実装
[レベル: 上級] Google は、シークレットモードでアクセスするすべての 非 HTTPS（通常のHTTP） ページに対して警告を表示する計画です。 今年の10月にリリースする Chrome 62 からの実装を予定しています。 この仕様が開発版 Chrome の Canary に一足早く実装されました。 「シークレットモードで HTTP に警告」のオプション シークレットモードで HTTP に警告を発する機能は、（まだ）デフォルトでは無効です。 chrome://flags/#mark-non-secure-as で有効にできます。 有効化するには、“Warn on HTTP while in incognito mode” を選択します。 有効にした状態で、HTTP ページにシークレットモードでアクセスすると「保護されていない通信」のラベルがアドレスバーの先頭に表示されます。 10月
Google、ウザい広告はChromeで表示しなくなることを決定。広告に関する問題のレポートをSearch Consoleで公開
[レベル: 初・中・上級] ユーザー体験を損ねる広告を掲載しているサイトに対して、Chrome ブラウザでは広告を一切表示しなくなるようにすることを Google は発表しました。 これにあわせて、サイトに掲載している広告に問題があるかどうかを調べるツールの提供を始めました。 背景 Google が、こうした決定を今回下した背景の1つに、ユーザー体験を損ねる広告の増加が挙げられます。 いきなり大きな音楽で再生が始まる広告や記事を見る前に強制的に見せつけられる広告のような不愉快な広告は誰しもが体験したことがあるはずです。 広告そのものは悪いものではなく、健全な経済活動です。 広告閲覧者と広告発行者の双方にとってより良いオンライン広告を提供するために Coalition for Better Ads という団体が組織されています。 Coalition for Better Ads は消費者に受
【SEO豆知識】同一サイトから復数ページが検索結果に同時に出るのは、他のサイトのスコアが低いから
ほかのサイトの結果のスコアが低い Google の Gary Illyes（ゲイリー・イリェーシュ）氏は、SEO 豆知識として次のように Twitter で説明しています。 同じサイトから2つ以上の結果が検索結果に出ているときは、通常、そのクエリに対するほかの結果のスコアがずっと低いからだ。 DYK usually when you see more than 2 results from the same site in the SERP, that's because other results score much lower for the query? pic.twitter.com/Bz4DPaR8PC — Gary Illyes ᕕ( ᐛ )ᕗ (@methode) 2017年3月30日 つまり、ほかのサイトのページと比較して検索クエリに対して関連性が高いページが復数存在する
Google、モバイルファーストインデックスの導入予定を正式発表。スマホ向けページを検索の評価対象に。SEOへの影響は？
[レベル: 中級] Googleは、Mobile First Index（モバイル ファースト インデックス）の導入を正式にアナウンスしました。 Mobile-first Indexing モバイル ファースト インデックスに向けて モバイル ファースト インデックスでは、PC向けページではなく、モバイル向けページの評価に主に基づいてランキングが決定されます。 Gary Illyes（ゲイリー・イリェーシュ）氏が米ラスベガスで10月に開催されたPubCon Las Vegas 2016で発表していたGoogle検索の仕様変更です。 正式な実施時期はまだ決まっていません。 今後数か月にわたり小規模な実験を行ったうえでの判断になるとのことです。 評価対象がPC向けページからモバイル向けページへ 詳細は公式アナウウンスを読んでいただくとして、概要としてはモバイル ファースト インデックス（以下、
Google、AMPに完全対応した爆速表示の広告 A4A を公開
[レベル: 上級] Google (AMP Project) は、AMPページでも高速で表示される広告として、AMP for ads、略称 “A4A” を公開しました。 メインコンテンツの表示を遅らせることなく、広告のすばやい表示を A4A は実現しています。 広告表示も爆速 A4A 広告 と A4A ではない広告の表示速度にどのくらいの違いがあるかをデモンストレーションしたアニメーションを、AMP Projectが公式ブログの記事で紹介しています。 左が A4A ではない普通の広告で、右が A4A 広告です。 ページの上部にデモ用の青いバナー広告が表示されます。 検索結果をタップしてページに飛んだあと、A4A ではない普通の広告が完全に表示されるまでには3.12秒かかっています。 それに対して、A4A 広告は0.5秒で表示が完了しています。 訪問者に広告をしっかりと見てほしい広告出稿者と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
