Helpful Content Update(ヘルプフルコンテンツアップデート)をGoogleが導入、役に立たないコンテンツの評価を下げるアルゴリズム更新
[レベル: 中級] Googleは、“Helpful Content Update（ヘルプフル コンテンツ アップデート）” と名付けた新しい検索アルゴリズムのアップデートを実施しました。 Helpful Content Update は一言でいうと、ユーザーの役に立つことを主目的としたコンテンツをより高く評価し、検索エンジンからのトラフィックを獲得することを主目的としたコンテンツを検索結果で上位表示しないようにするアップデートです。 この記事では、Google 検索セントラル ブログでの公式アナウンスに加えて、Search Engine Land ならびに Glenn Gabe 氏が Google から直接入手したという追加情報をもとに、Helpful Content Update の全体像を解説します。 Helpful Content Update 概要 Helpful Content
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
Google、1年たてばリダイレクトは解除可能。引き継いだ評価はリダイレクトなしでもそのまま残る
[レベル: 上級] 1 年たてばリダイレクトを解除して構わない。 たとえリダイレクトを停止しても、引き継がれたシグナルはそのまま残る。 こうした情報を、Google の Gary Illyes（ゲイリー・イリェーシュ）氏が Twitter に投稿しました。 リダイレクトは半永久的に保持する必要なし 旧 URL から新 URL へ検索エンジンの評価を引き継ぐためにリダイレクトを構成します。 「リダイレクトが有効であるかぎり評価は引き継がれる」、逆に言えば、「リダイレクトを停止すれば評価の引き継ぎは止まる」、このように僕たちは理解してきました。 そのため、リダイレクトは半永久的に継続するのが原則です。 しかしながら、そうではないことが判明しました。 リダイレクトを 1 年間 継続しておけば、リダイレクトを解除しても、旧 URL から新 URL への評価の引き継ぎは継続します。 つまり、リダイレ
Google、検索におけるリダイレクトの技術ドキュメントを大幅に刷新
[レベル: 上級] URL を変更した際の、検索におけるリダイレクトの利用方法を説明する技術ドキュメントを Google は大幅に刷新しました。 日本語ページはまだ更新されていません。 英語で読みたくない人のために、この記事では、新たに追加された情報を中心に注目点を紹介します。 【UPDATE (2021/7/12)】 日本語ページも更新されました。 リダイレクトの種類は 2 つ リダイレクトには大きく分けて 2 種類あります。 Permanent redirects（恒久的なリダイレクト） Temporary redirects（一時的なリダイレクト） 恒久的なリダイレクトでは、リダイレクト先の URL を検索結果に表示します。 一方、一時的なリダイレクトでは、リダイレクト元の URL を検索結果に表示します。 たとえば、https://example.com/abc/ を https:
ページスピードをGoogleはどのようにしてランキング要因に組み込んだのか？
[レベル: 中級] Google 検索チームの社員が検索に関するトピックをポッドキャストで配信する Search Off the Record の新しいエピソードが公開されました。 語り手として出演するのはいつもの 3 人です。 John Mueller（ジョン・ミューラー） Gary Illyes（ゲイリー・イリェーシュ） Martin Splitt（マーティン・スプリット） 3 人が今回テーマにしたトピックは、ランキング要因としてのページスピードです。 言い換えると、ページ エクスペリエンス シグナル/コア ウェブ バイタルの 1 つの要素でもあるページ表示の速さをランキング要因に組み込むことにした過程を語っています。 ページスピードの重み付けをどうするか？ ページスピードをランキング要因に組み込む際に考慮する必要がったのは、その重み付けです。 つまり、どのくらい強い要因にするかです。
コンテンツ著者をGoogleはどのようにして認識しているのか？――プロフィールページが重要
[レベル: 上級] そのコンテンツを作成したのは誰なのか、そしてその人物がどんな存在なのかを Google はどのようにして認識しているのでしょうか？ プロフィールページで自分を明かす コンテンツ著者を Google はどのようにして認識するのかに関して John Mueller（ジョン・ミューラー）氏はオフィスアワーで次のように説明しました。 コンテンツを作った人が誰なのか、その人はどういった存在なのかを私たちのシステムは認識しようとする。いくつかの異なる要因に基づいて認識しており、たとえばプロフィールページへのリンクやそのページにある視覚要素などだ。 ミューラー氏はこのように説明したうえで、著者に関するすべての情報が載っているプロフィールページへ（各記事から）リンクすることを推奨しています。 プロフィールページは、ウェブに存在するその人の情報を集約する場所の役割を果たすようにします。
ついに！Search Consoleが正規表現をサポート
[レベル: 上級] Google Search Console に 2 つの改良が加わりました。 検索パフォーマンス レポートが正規表現フィルタをサポート 比較時の 2 つ以上の指標の同時レポート表示 検索パフォーマンス レポートが正規表現をサポート 正規表現によるフィルタを検索パフォーマンス レポートがサポートしました。 ついに！です。 これで、複雑な条件を指定してデータを絞り込めます。 [検索キーワード] と [ページ] のフィルタで正規表現を利用できます。 たとえば、[海外SEO情報ブログ] と [海外SEOブログ] の 2 種類のクエリで僕のブログを探す読者がたくさんいます（正式名称は前者です！）。 このとき正規表現を使って [海外SEO(情報)?ブログ] と指定すれば両方のクエリを同時に指定してフィルタできます。 例で出したのはとてもシンプルな正規表現ですが、熟知している人にとっ
混合コンテンツとおさらば、HTTPで配信する画像をChromeがHTTPSに自動アップグレード
[レベル: 上級] Google Chrome で混合コンテンツを心配する必要はもうありません。 HTTPS ページなのに HTTP で配信されたコンテンツを、自動的に HTTPS で読み込んでくれます。 混合コンテンツの画像を自動アップグレード HTTPS のページにもかかわらず HTTP で画像を配信している場合、従来は混合コンテンツとして警告対象になりオムニボックス（URL バー）には鍵マークは出ませんでした。 混合コンテンツに対処するために、Chrome における混合コンテンツの扱いを段階的に変更することを Google は 1 年前にアナウンスしています（Web担当者Forum でのコラムの方がわかりやすいかも）。 最新バージョンの Chrome （安定版 Chrome 86 で確認）は、画像が混合コンテンツになっている場合に自動的に HTTPS にアップグレードして読み込みを試
WordPress 5.5に実装されたネイティブ サイトマップ機能を無効化する方法
[レベル: 中級] この記事では、Wordpress 5.5 に標準実装されたサイトマップ生成機能を無効化する方法を紹介します。 WordPress のコア XML サイトマップ機能 リリースされたばかりの WordPress 5.5（この記事を公開している時点での最新バージョン）は、検索エンジン向けの XML サイトマップを作成する機能をコア機能として標準実装しました。 これまでサイトマップ生成にはプラグインを利用していました。 コア サイトマップは WordPress をインストールしたディレクトリの直下に作られます。 ファイル名は wp-sitemap.xml です。 example.com に WordPress をインストールしていたらサイトマップの場所は example.com/wp-sitemap.xml になります。 アクセスしたサイトマップはこんな感じです（正確には、サイ
iframeのネイティブLazy-loadがウェブ標準に、<iframe>タグにloading=lazy属性を追加するだけで遅延読み込み可能に
Native lazy-loading for <iframe> was added to the HTML standard today: https://t.co/KgO8lIBdEK Thanks @domfarolino for the heavy lifting with spec & tests 🎉 https://t.co/GLy6qHE7l5 — Simon Pieters (@zcorpan) July 8, 2020 YouTube 動画でネイティブ Lazy-load ネイティブ Lazy-load は、loading=lazy 属性を追加するだけで遅延読み込みを可能にします。 専用の JavaScript は不要です。 ブラウザの標準機能として Lazy-load をサポートします。 もとともは Chrome の独自機能として Google が開発しました。 Ch
『Google検索の仕組み』ヘルプ記事が更新。プライマリ クロール/セカンダリ クロールとは？
[レベル: 初級] 『Google 検索の仕組み』のヘルプ記事を Google は更新しました。 数多くの解説を新たに追加しています。 追加コンテンツの一例 たとえば、詳細版の「クロール」セクションには「プライマリ クロール / セカンダリ クロール」に関する説明が追加されました。 プライマリ クロール / セカンダリ クロール Google は、ウェブサイトのクロールに、モバイル クローラとパソコン クローラの 2 種類のクローラを使用します。各タイプのクローラは、ページにそのタイプのデバイスでアクセスするユーザーをシミュレートします。 Google は、サイトの「メインクローラ」として 1 つのクローラタイプ（モバイルまたはパソコン）を使用します。そのメインクローラで、サイト内のクロール対象ページすべてをクロールします。新しいウェブサイトについては、メインクローラはすべてモバイル クロ
Google、ウェブサイトのUX健全性を示すWeb Vitalsを導入。3つの重要指標はLCP/FID/CLS
[レベル: 上級] ウェブで優れたユーザー エクスペリエンスを実現するために “Web Vitals（ウェブ バイタル）” というコンセプトを Google は導入しました。 Web Vitals の土台として次の要素を重要視します。 読み込み時間 インタラクティブ性 ページ コンテンツの視覚的な安定性 それぞれの要素を測定するための指標とツールの提供を始めています。 Core Web Vitals: ウェブに関する 3 つの主な指標 Web Vitals を数値化するために、ウェブに関する特に重要な 3 つの指標を Google は設定しました。 ひっくるめて、“Core Web Vitals”（コア ウェブバイタル）と呼びます。 Largest Contentful Paint (LCP) First Input Delay (FID) Cumulative Layout Shift
「メタ ディスクリプションがない」がモバイル ファースト インデックスの一般的なエラーに追加
[レベル: 初級] モバイル ファースト インデックスのベストプラクティスに掲載している一般的なエラー一覧に “Missing meta description”（メタ ディスクリプションがない）を Google は追加しました。 Missing meta description 一般的なエラーの一覧の、“Missing page title”（ページタイトルがない）の下に“Missing meta description”（メタ ディスクリプションがない）が加わっています。 提案される修正方法は title タグがないときと同じです。 問題の修正方法: タイトルとメタ ディスクリプションがモバイル版とパソコン版の両サイトで同等になるように設定します。 なお、この記事を公開した時点では、日本語ページにはまだ更新が入っていません。 「ページタイトルがない」の下は「モバイル向け URL がエラ
内容が薄いページはまとめて本当に強い少数のページを作るべき、とGoogle社員がアドバイス
[レベル: 初級] 内容が薄いページがたくさんあるなら 少数のページに統合してコンテンツの量を増やして品質を高くするように作り変えたほうがいい 中身に乏しいページが大量にできあがっていることを不安に感じているサイト管理者に対して、Google の John Mueller（ジョン・ミューラー）氏はこのようにアドバイスしました。 分散させずにまとめ、本当に強い少数のページを作る 質問者はゲーム関連のサイトを運営しています。 UGC サイトのようで、ユーザーが投稿した（ゲームに関する）質問に別のユーザーが回答します。 2、3 行で終わってしまうような量が少ない質問・回答が大量にできあがるらしく、内容が薄いページに Google には見えるに違いないとサイト管理者は心配しています。 具体的にサイトを見ていないし、一般論だと断りを入れてミューラー氏は次のように勧めました。 大量のページをサイト内に
本当に重要な理由がない限りはURL変更すべきではない、SEO価値は本質的にゼロ
[レベル: 初級] 確固たる理由がない限りは、URL を変更すべきではありません。 多くの場合において、SEO 上の価値は URL 変更にはありません。 それでいて、変更した URL の数が多いときは順位変動が発生することがあります。 URL 変更 の SEO 価値は本質的にゼロ Google の John Mueller（ジョン・ミューラー）氏は、URL 変更に関して次のようにコメントしました。 一般的には、そうすべき本当に重要な理由がない限りは、URL を変更することは私なら断固としてやめさせるだろう（たとえば、“_” から “-” への変更や “php” から “htm” への変更）。 本質的に SEO 価値はゼロだ。それでいて、順位の乱高下に苦しむことがしばしばある。 It sounds like it's too late in your case, but in general
Google社員がコメント「アフィリエイトサイトであることをGoogleに隠す必要はない」
[レベル: 初級] アフィリエイトサイトを Google は毛嫌いしてはいません。 アフィリエイトであることを Google に隠す必要はありません。 アフィリエイトリンクは隠すべき？ rel=”sponsored” を付けるべき？ 広告のようなリンクがリンクプログラムとしてガイドライン違反にならないようにするために、次の 2 とおりの対応を Google は提案しています。 rel = "nofollow" またはより具体的な属性を <a> タグに追加する robots.txt ファイルによって検索エンジンからブロックされる中間ページにリンクをリダイレクトする 2 つめの robots.txt を使うやり方は、自分のサイト（もしくは管理できる別のサイト）の URL にリンクして、そこから実際のアフィリエイト URL にリダイレクトする方法です。 リダイレクト元の URL をブロックしてお
Search Consoleのアドレス変更ツールが改良、サイト移転の確認がしやすく
[レベル: 中級] 現在の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
アフィリエイトリンクにはrel=sponsoredを付けるようにGoogleが推奨（でもnofollowのままで問題なし）
[レベル: 中級] アフィリエイトサイトのリンクのように金銭の獲得を目的としたリンクには、可能であれば rel="sponsored" リンク属性を追加することを Google の John Mueller（ジョン・ミューラー）氏は推奨しました。 rel="sponsored" は、rel="noffolow" の扱いの変更とともに導入された新しいリンク属性です（詳しくはこちらの記事を参照）。 とはいえ、 rel="sponsored" はあくまでも推奨であり必須ではありません。 nofollow 属性を引き続き利用できます。 マネタイズリンクには rel=“sponsored” の利用を推奨 次のような質問をミューラー氏は尋ねられました。 読者にとって、クリックするリンクがマネタイズを目的としたことが明らかであれば問題なく、さらに Google にとっても明らかになるように rel=sp
「構造化データはもっと難しくなる」とGoogle社員が予測、構造化データはSEOの必須スキル
[レベル: 上級] 構造化データが今よりも簡単になっていくことはなく、むしろさらに複雑で難しくなっていくだろうと Google 社員が予想しています。 構造化データはさらに難解に Google が利用する構造化データの将来について、Google の John Mueller（ジョン・ミューラー）氏はオフィスアワーで次のようにコメントしました。 将来的、少なくとも近い将来にもっと多くの種類の構造化データマークアップを使うようになると私は考える。そして、さまざまな検索機能の要件という点で、おそらくもっと複雑になっていくだろう。検索結果での装飾的な機能もそうだし、たしか Google アシスタントの読み上げ機能なども現状では多分に構造化データに依存している。 構造化データの分野はもっと拡大していくだろうから、さらに多くのマークアップが登場してくると予想する。新しい構造化データが出てくると、実装や
モバイルファーストインデックスの技術ドキュメントをGoogleが刷新、準備編からベストプラクティス編へ
[レベル: 中級] モバイル ファースト インデックス対応を説明する技術ドキュメントを Google は大幅に更新しました。 この記事ではその変更点の概要を紹介します。 なお、記事を公開している時点では更新されているのは英語版ページです。 日本語版ページはまだ更新されていません。 MFI 技術ドキュメントの変更点概要 まず、ドキュメントのタイトルが変わりました。 旧: Prepare for mobile-first indexing 新: Mobile-first indexing best practices 「モバイル ファースト インデックスに向けて準備する」が「モバイル ファースト インデックスのベストプラクティス」になりました。 MFI への移行が完了したサイトが増えたので “Prepare”（準備）という表現がそぐわなくなってきたからかもしれません。 準備編からベストプラクテ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
