[レベル: 上級] ダイナミック レンダリングに関する技術ドキュメントを Google は更新しました。 ダイナミック レンダリングの利用を推奨せず、別の方法を採用するように強く促しています。 ダイナミック レンダリングは回避策であり非推奨 こちらは更新前のドキュメントの最初のセクションです。 こちらは更新後のドキュメントの最初のセクションです。 まず、最上段に掲載されている注釈が変更されました。 以前の注釈は次のとおりでした。 このページでは、JavaScript バージョン以外のページをクローラに提供する方法について説明します。ユーザー エージェント（モバイル、タブレット、パソコン）の種類に応じて異なるバージョンのページを提供する方法については、動的な配信に関するガイドをご覧ください。 現在の注釈です。 📝すずき注: この記事を書いている時点では日本語ドキュメントは未更新なので、訳は

[レベル: 中級] 動画だけを掲載するページの作成を推奨するガイドを、検索セントラル サイトの動画検索のベストプラクティスに 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 は、検索セントラルサイトの上級者向け SEO セクションに EC サイトのベストプラクティスを追加しました。 Google 検索で EC サイトのプレゼンスを高める方法 追加されたばかりなので、日本語ページはまだ公開されていません。 英語ページのタイトルは “Best practices for ecommerce in Google Search” です。 日本語に直すと「Google 検索における eコマースのベストプラクティス」になるでしょうか。 【UPDATE (2021/10/04】 日本語ページも公開されました。 ベストプラクティスには、EC サイトがGoogle 検索でプレゼンスを高めるためにできること、やるべきことがまとめられています。 次のトピックで構成されています。 Where ecommerce content can appear

[レベル: 中級] サイトと記事の信頼性および透明性をニュースパブリッシャーが示すために必要な情報を Google は公式ブログでアドバイスしました。 Google ニュースに掲載するパブリッシャー向けの投稿ですが、E-A-T を高めたいと考えている一般サイトのコンテンツ発行者にも参考になる内容なのでこの記事で紹介します。 記事とサイトに関する情報を提供する サイトと記事の信頼性・透明性を高めるために必要なのは、そうしたことに役立つ情報を提供することです。 具体的には、次のような情報を提供することを Google は重要視しています。 明確な投稿日 記事著者の氏名 著者についての情報 ニュースの情報源 サイト運営会社、もしくはその背後にあるネットワーク（系列網） 連絡先 記事レベル/サイトレベルで分類した場合の必要情報はこうなります。 記事レベルで必要な情報 記事レベルでは、その記事やその

[レベル: 上級] そのコンテンツを作成したのは誰なのか、そしてその人物がどんな存在なのかを Google はどのようにして認識しているのでしょうか？ プロフィールページで自分を明かす コンテンツ著者を Google はどのようにして認識するのかに関して John Mueller（ジョン・ミューラー）氏はオフィスアワーで次のように説明しました。 コンテンツを作った人が誰なのか、その人はどういった存在なのかを私たちのシステムは認識しようとする。いくつかの異なる要因に基づいて認識しており、たとえばプロフィールページへのリンクやそのページにある視覚要素などだ。 ミューラー氏はこのように説明したうえで、著者に関するすべての情報が載っているプロフィールページへ（各記事から）リンクすることを推奨しています。 プロフィールページは、ウェブに存在するその人の情報を集約する場所の役割を果たすようにします。

[レベル: 中級] 新バージョンの「クロールの統計情報」レポートを Search Console で利用できるようになりました。 インターフェイスが改良されました また、レポートの種類が格段に増えています。 新しいクロールの統計情報のレポート 「クロールの統計情報」にはナビゲーションメニューからは直接アクセスできません。 [設定] メニューの [クロール] セクションからアクセスします。 なお「クロールの統計情報」のレポートを利用できるのは、トップレベルのドメインとドメインプロパティです。 サブディレクトリで登録しているプロパティでは見ることはできません。 ドメインプロパティを選択すれば、サブドメインも含めたホスト全体のクロールの統計情報を見ることができるのも改良点です。 「クロールの統計情報」では、次の項目の推移をグラフで確認できます。 クロール リクエストの合計数 合計ダウンロード サ

[レベル: 上級] ウェブで優れたユーザー エクスペリエンスを実現するために “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

[レベル: 初級] 内容が薄いページがたくさんあるなら 少数のページに統合してコンテンツの量を増やして品質を高くするように作り変えたほうがいい 中身に乏しいページが大量にできあがっていることを不安に感じているサイト管理者に対して、Google の John Mueller（ジョン・ミューラー）氏はこのようにアドバイスしました。 分散させずにまとめ、本当に強い少数のページを作る 質問者はゲーム関連のサイトを運営しています。 UGC サイトのようで、ユーザーが投稿した（ゲームに関する）質問に別のユーザーが回答します。 2、3 行で終わってしまうような量が少ない質問・回答が大量にできあがるらしく、内容が薄いページに Google には見えるに違いないとサイト管理者は心配しています。 具体的にサイトを見ていないし、一般論だと断りを入れてミューラー氏は次のように勧めました。 大量のページをサイト内に

[レベル: 上級] 画像権利の情報を示すラベルを画像検索に表示する機能を 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

[レベル: 上級] rel="nofollow" 属性の扱いを Google は変更しました。 従うべき命令としてではなく、手がかりのためのヒントとして利用するようになります。 また、nofollow の派生型として、link タグと用いる 2 種類の rel 属性を新たに導入しました。 nofollow 属性の扱いを変更 rel="nofollow" 属性が付いたリンクを Google はこれまでランキング要因としては利用していませんでした。 PageRank を渡すこともないしアンカーテキストも評価しません。 そして、nofollow 属性を命令 (Directive) として Google は扱い、必ず従ってきました（nofollow リンクが評価されている状況があるという分析もあるけれど、公式見解では nofollow リンクはランキング要因から除外されることになっている）。 今後

[レベル: 中級] rel="prev" および rel="next" のリンク要素のサポートを終了したことを Google は Twitter で告知しました。 Spring cleaning! As we evaluated our indexing signals, we decided to retire rel=prev/next. Studies show that users love single-page content, aim for that when possible, but multi-part is also fine for Google Search. Know and do what's best for *your* users! #springiscoming pic.twitter.com/hCODPoKgKp — Google Webmaste

[レベル: 上級] 先週投稿したプログレッシブ ウェブ アプリ（以下、PWA）の記事で、「AMPよりもPWAに注目したい」と個人的な思いに触れました。 ところが、PWAとAMPの対立軸を作ったように思わせてしまったかもしれません。 しかし、PWAとAMPは排他的な技術では決してありません。 それどころか、両者を組み合わせることによってさらに優れたモバイルユーザー体験を提供できます。 そこでこの記事では、PWAとAMPを組み合わせる、通称”PWAMP”について解説します。 AMPとPWAを連携する3つのパターン GoogleのAMPチームに所属している Paul Bakaus（ポール・バカウス）氏は、AMPとPWAを組み合わせるパターンとして、次の3つの形態をSmashing Magazineの記事で紹介しています。 AMP as PWA AMP to PWA AMP in PWA それぞれ

[レベル: 初〜中級] Googleは先週末に、外部サイトに向けた不自然なリンクを掲載しているサイトに対して手動で対策したことを伝える警告を大規模に送信しました。 商品やサービスを無料で受け取る見返りとして、その商品やサービスのページへPageRankを転送するリンクを張っていたサイトが手動対策の主な対象になったようです。 不自然な“発リンク”に対する警告 今回の警告は、有料リンクや自作自演リンクなどのガイドラインに違反する不正な手段を使って、外部サイトから不自然な被リンクを集めていたサイトに送られたものではありません。 不自然なリンクを外部サイトに向けて張っていたサイトに対して送られたものです。 つまり不自然な被リンクではなく、不自然な発リンクに対する警告です。 “Unnatural outbound links from http://www.example.com/ violate

[レベル: 上級] この記事では、Wordpressブログを手っ取り早くAMP対応させる方法を説明します。 AMP (Accelerated Mobile Pages) に対応したモバイル検索が一般公開されました。 Google Japanの公式ブログで発表されたこともあり、僕たちほどにはSEOと密接にかかわっていない人たちにもニュースになりました。 GoogleがAMPを強く推していることもあり、自分のサイトをAMP対応させてみようかと考えている人も多いのではないでしょうか。 そこで、「“とりあえず”AMP対応して、どんなだか様子を見てみたい」という人のために簡単にできるAMP化を解説することにします。 ただし、Wordpressでサイトを運営していることが条件です。 3つのプラグインを使います。 AMP Facebook Instant Articles & Google AMP Pa

[レベル: 初〜中級] 🎍海外SEO情報ブログの読者のみなさま🎍 あけましておめでとうございます。 今日から更新を再開します。 2016年もよろしくお付き合いください。 では今年最初の記事に入ります。 ほかのサイトからの引用であることを示すために blockquote タグを使えます。 しかしGoogleに対しては blockquote タグは引用を示すシグナルにはなりません。 したがって重複コンテンツの防止に特に役立つこともありません。 「blockquoteタグは考慮していない」とジョン・ミューラー氏がコメント 年末に開催された英語版のオフィスアワーで次のような質問が出ます。 blockquote タグをシグナルとしてGoogleは使っていますか？ 別のサイトからの情報をblockquoteで囲ってそのページにリンクすれば、それは別のサイトからの引用だとしてGoogleは認識します

[レベル: 初〜中級] 管理しているサイトにあなたはrobots.txtを設置していますか？ どんなURLに対するクロールをrobots.txtでブロックしていますか？ GoogleのJohn Mueller（ジョン・ミューラー）氏が英語版のウェブマスター向けオフィスアワーで、一般的に言える、robots.txtを使う場面と使わない場面について説明しました。 クロールが問題を引き起こすときは間違いなく使うべきケースだ。 たとえば、サイトの一部をクロールするのときに、サーバーとたくさん相互にやりとりしたりサーバーがデータベースをたくさん参照したりして、それぞれのページを表示するのに30秒もかかるようだったら、サーバーが暴走してしまうかもしれない。 すべてをダウンさせてユーザーが利用できなくなってしまうかもしれないから、そういうのはGooglebotにクロールさせたくない状況だろう。 robo

Googleは、かねてからアナウンスしていたように、ドメインをまたぐrel=”canonical”タグのサポートを開始したことを公式アナウンスしました。 ※ rel=”canonical”タグって何？、何のために使うの？ という読者さんは、まずこちらからお読みください。 「重複コンテンツ・重複URL」のおさらい rel=”canonical”の正規化で、重複コンテンツを撃退 Google, Matt Cuttsによるrel=”canonical”タグの解説ビデオ もともと、rel=”canonical”タグは、同一ドメインまたはサブドメインの中だけで有効でした。 ”www.example.com”と”example.com”を正規化することはできましたが、 ”www.example.com”と”www.example123.com”を正規化することは、できなかったのです。 301リダイレク

[レベル: 上級] ライブブログ (Live blogs) の記事更新をカルーセル形式で検索結果に表示する機能をGoogleは一般公開しました。 ライブブログとは、たとえばアカデミー賞の授賞式やスポーツの試合などをリアルタイムにブログ記事で実況中継する配信方法です。 赤色の「Live」ラベルが目印 こちらはGoogle DevelopersのGoogle+アカウントがライブブログのカルーセルを導入したことをアナウンスした投稿です。 Earlier this year, we announced that users would start seeing carousels with news content on the Search results page, powered by structured data markup that publishers implement. Tod

[レベル: 中級] サイト全体をHTTPからHTTPSへ移行した際には、Search Consoleに新たに登録したHTTPSサイトの方でリンクの否認ファイルを再度アップロードし直す必要があります。 HTTPサイトのプロパティで送信していたリンクの否認は、HTTPSサイトには引き継がれません。 HTTPS移行後にペンギンが戻ってきた!? GoogleのGary Illyes（ゲイリー・イリーズ）氏にTwitterでフォロワーが次のように質問しました。 おかしなことが起こりました。クライアント（のサイト）をhttpからhttpsへ移行したら、ペンギンアルゴリズムのペナルティがまた戻ってきたように見えます。 Search Consoleのアカウントに新しいhttpsのサイトを追加しました。でも、否認ファイルは移行していません。（httpsで登録したサイトは）新しいサイトとして認識されて、新たに

[レベル: 中級] CSSとJavaScriptのファイルへのアクセスをrobots.txtでブロックしているサイトに対して、Search Console経由で警告メッセージをGoogleは一斉に送信し始めました。 CSSおよびJSファイルにGooglebotがアクセスできません Google Search Console Teamから次のようなメッセージが届きます。 http://example.com/ の CSS および JS ファイルに Googlebot がアクセスできません http://example.com/ のウェブマスター様 Google のアルゴリズムによるコンテンツのレンダリングとインデックス登録に影響を及ぼす問題が貴サイトで発生していることが Google のシステムにより判明しました。具体的には、robots.txt ファイルでの制限のために Googlebot