[レベル: 上級] Google は、Signed Exchange (SXG) を PC 検索でもサポートするようになりました。 これまではモバイル検索だけでのサポートでしたが、予告どおりに PC 検索でもサポートが始まりました。 サイト間のキャッシュ/プリフェッチを PC でも Chrome や Edge、Vivaldi などの Chromium ベースのブラウザでは、モバイル同様に PC でもサイト間（オリジン間）でのキャッシュ配信とプリフェッチが可能になります。 キャッシュとプリフェッチにより表示速度の向上を期待できます。 Google によれば、SXG によりモバイル検索からのアクセスにおいて平均で 300 〜 400 ミリ秒 LCP を短縮できたそうです。 LCP はコア ウェブ バイタルの指標です。 SXG はコア ウェブ バイタルの改善に役立ちます。 トップニュースで SX

[レベル: 中級] 動画だけを掲載するページの作成を推奨するガイドを、検索セントラル サイトの動画検索のベストプラクティスに 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

[レベル: 上級] この記事では、Chrome Dev Summit 2019 の ウェブの高速化に関係するセッションのハイライトをレポートします。 ページの表示速度改善のためのツールやレポート、指標などがたくさん紹介されています。 ウェブが速く ウェブは速くなってきている。 昨年との比較で次のような改善が見られる。 First Contentful Paint: 7 % 速く First Input Delay: 27 % 速く ツール ウェブの高速化にはたとえば次のようなツールを使える。 PageSpeed Insights: URL を指定してそのページのパフォーマンス状況を検証できる Search Console のスピードレポート: サイト内のページをグループ化して速度状況を可視化できる 新しい指標 スピードを測定するために新しい指標を取り入れる。 Large Contentfu

[レベル: 上級] 試験的に公開されていた <amp-script> が一般公開されました。 AMP では原則的に、AMP で定義された以外の JavaScript を動かすことが許されていません。 しかし、<amp-script> を利用すれば任意の JavaScript を AMP ドキュメントで実行することが可能になります。 好きな JavaScript を AMP で実行 <amp-script> を使うと、自分で書いた JavaScript はもちろんのこと、React や Angular、Vue.js といった JavaScript フレームワークを構成することも可能です。 ユーザーのアクションに応じてインタラクティブなコンテンツや機能を <amp-script> は提供できます。 ※Chrome Tech Talk Night #14 で Paul Bakaus 氏が紹介して

[レベル: 上級] Google は、Signed HTTP Exchanges (以下、SXG) を有効にした検索を正式に公開しました。 2018 年 11 月下旬に試験用のデモ検索を公開していましたが、通常の検索で SXG が現在は有効になっています。 SXG は、AMP キャッシュにアクセスした際に AMP CDN から返されるキャッシュの URL ではなく、オリジナルの AMP コンテンツを配信している本来のサイトのドメイン名の URL で表示するための技術です。 自分のドメイン名の URL で表示できない AMP キャッシュ 検索からアクセスした AMP ページの URL はたとえば、次のようになっています。 https://www.google.co.jp/amp/s/www.example.com/amp/sxg.html これは、自分のドメイン名ではなく Google が管

[レベル: 上級] DeepCrawl が主催したウェビナーで Google の Martin Splitt（マーティン・スプリット）氏が、JavaScript サイトの SEO に関するさまざまな質問に回答しました。 このなかで、サーバーサイドでレンダリングすべき要素、言い換えると、JavaScript を介してレンダリングさせるべきではない要素をスプリット氏は挙げました。 スプリット氏によると、SEO を考慮するのであれば、次の要素はサーバーサイドでレンダリングしてからクライアント（ユーザーと Googlebot）に配信したほうがいいとのことです。 メインコンテンツ 構造化データ title タグ meta description hreflang 日付に関する記述 メインコンテンツは、ページの評価において最も重要です。 現在の WRS（ウェブ レンダリング サービス）が、古い Chr

[レベル: 中級] Google が提供するパフォーマンス測定ツールの PageSpeed Insights が分析エンジンに Lighthouse を使用するようになりました。 英語および日本語の公式ブログでアナウンスが出ています。 PageSpeed Insights, now powered by Lighthouse PageSpeed Insights、Lighthouse の使用を開始しました PSI と Lighthouse の分析方法を統一 Lighthouse も Google が提供するパフォーマンス測定ツールですが、PageSpeed Insights（以下、PSI）とは異なる独自の仕組みでパフォーマンスを測定しています。 チェックする指標は同一ではないし、同じ指標だったとしても計測結果が違ってくることが普通にあります。 どちらも Google 製のツールなのにどちら

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

[レベル: 中級] Google にインデックスさせたい URL に「#」（ハッシュ/フラグメント）を含めることは推奨されません。 # よりもあとの部分を削除した URL を Google（および、ほかの検索エンジン）はインデックスするからです。 代わりに History API を用いて一意の URL を各コンテンツに割り当てる構成が推奨されます。 ページ内移動の # はインデックスに問題なし ページ内の特定の場所にジャンプさせる name 属性または id 属性として # を利用するのであれば、インデックスに問題はおきません。 たとえば末尾に #f4 が付いている次の URL をクリック/タップすると、ページの途中に移動した状態で表示されます。 https://webtan.impress.co.jp/e/2014/05/09/17440/page/1#f4 Google のヘルプ記事

[レベル: 中級] 【UPDATE】 この記事は事実を正しく反映していないことが判明しました。 こちらの記事で説明しています。 ページの読み込み速度をモバイル検索のランキング要因として用いる “Speed Update”（スピード アップデート）を Google は今月導入する予定です。 Speed Update は、本当に遅いページだけが影響を受けるアルゴリズムだと思われていました。 しかしながら実際には、速ければ速いほど評価が上がるアルゴリズムになっているようです。 Speed Update では、読み込み速度が速いと段階的に評価が上がる Speed Update の導入を事前アナウンスした公式ブログの記事は次のように説明していました。 The “Speed Update,” as we’re calling it, will only affect pages that delive

[レベル: 中級] この記事では、先月の終わりにカナダのバンクーバーで参加した『Call To Action Conference (CTAConf) 2017』のセッションをレポートします。 セッションスピーカーは、Moz の Rand Fishkin（ランド・フィッシュキン）氏です。 フィッシュキン氏は言わずと知れた、SEO のエキスパートです。 「検索エンジン最適化」ではなく「コンバージョン率最適化」のカンファレンスでどのようなことをフィッシュキン氏は語ったのでしょうか？ ユーザー行動がSEOの重要指標に Google はユーザー行動を見ている 昨日、ウィル・レイノルズ（ランドの知り合いのスピーカーの名前）は、人間（の行動）のシグナルが SEO で重要になってきたと言った。 つまり、人間に最適化しなければならない。 このカンファレンスのテーマは、CRO (Conversion Rat

[レベル: 中級] この記事では、モバイル ファースト インデックスの導入にともなう、次のような構成のモバイルサイトの対応について解説します。 モバイル向けサイトのリストページは、アイテムの表示件数を初期状態では PC 版よりも少なくしている 「もっと見る」のような要素でアイテムを追加表示する 「もっと見る」のタップを繰り返してアイテムをさらに追加表示する モバイル UX 向上のための「もっと見る」 モバイルサイトでのリストページでは、「もっと見る」や「次の○件」のようにして、タップすることでさらに多くのアイテムを表示するユーザーインターフェイスが使われることがあります。 多過ぎるアイテムを一度に表示すると、表示速度が落ちるし見づらくなるからです。 ユーザー体験を向上させるための UI です。 ただし、モバイルサイトでこうした UI を採用していても、PC サイトではもっと多くのアイテムを

[レベル: 中級] Googleは、キーワードプランナーで提供するデータに制限をかけました。 広告費用が少ない広告主は、月間平均検索ボリュームの詳細なデータが手に入らなくなることがあります。 キーワードプランナーは本来はAdWords広告主のためのツールです。 しかし、SEOためのキーワードリサーチの目的で利用しているサイト管理者も多いはずです。 広告を出稿していないサイト管理者にとっては、この制限はたいへん残念な仕様変更になりそうです。 広告費用が少ないと検索ボリュームが（かなり）大まかに丸められる 英語版のAdWordsコミュニティでGoogle社員がキーワードプランナーの更新について次のようにアナウンスしました。 Hi AdWords Community, As of this week, previous technical issues affecting the Keyword

[レベル: 初〜中級] 1月15日に開催された英語版の Webmaster Central office-hours hangout でGoogleのJohn Mueller（ジョン・ミューラー）氏がtitleタグに関する参加者からの質問に回答しました。 ひと昔前とは事情が変わってきているtitleタグの現在の扱いを知ることができます。 ミューラー氏が説明したtitleタグの現在の使い ランキング要因の1つとしてtitleタグを使っているに過ぎない。titleタグは、主要な要因としては使われていなくて、決定的に重要な意味を持つものではない。 したがってうまくいくだろうと期待して、キーワードをtitleタグにたくさん入れることに価値はない。 それに、検索結果でのユーザー体験を損ねるからtitleタグにキーワードを詰め込んでいるときはそのことを私たちは検出しようとする。そのページが何のページな

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

パンダ・アップデートは、質の低いサイトが検索結果に出ないようにすると同時に、質の高いサイトを高評価することを目指しています。 パンダ・アップデートを開発する際にウェブページや記事の質を判断するために利用した質問の具体例を23個、米GoogleのWebmaster Central Blogが公開しました。 パンダ・アップデートが高品質だと評価するサイトを作成するためのヒントになるので、すべてを日本語に訳します。 ※日本語として意味が分かりやすいような訳を試みていますが、専門職ではないので原文の微妙なニュアンスを表現できていないかもしれません。気付いた点があればご指摘ください。 ※3〜4項目ごとに行間を開けています。意味の句切れではなく読みやすさを考慮してです。 高品質なサイトかどうかを判断する質問 この記事で示されている情報を信用するか。 この記事は、そのトピックについてよく知っている専門家

[対象: 上級] この記事では、非常に華麗な無限スクロールを実装しているサイトを紹介します。 美しく、見やすい、SEOも考慮できた QUARTZ の無限スクロール そのサイトは、ニュースメディアサイトの QUARTZ です。 「百聞は一見にしかず」で、実際に QUARTZ に訪問して見てください。 注目してほしいのはブラウザに表示されるURLです。 無限スクロールで下がっていくと、今あなたが見ている記事に対応したURLに自動的に切り替わります。 下方向だけでなく上に戻ればまたそれに対応してURLが変わります。 titleタグももちろん切り替わります。 個別のURLをブラウザのアドレスバーに入れれば、直接そのコンテンツを閲覧できます。 そして、そこから無限スクロールが始まります。 記事に与えられた個別のURLは、そのURLできちんとGoogleにインデックスされています。 Mozのランドもイ

[対象: 上級] SEOの効果を期待して、商品やサービスの名前、あるいはジャンルや地域などそれらのアイテムが含まれるカテゴリを必ずしもURLに含める必要はありません。 またキーワードをURLに含める必要もありません。 検索エンジンのためには不要 確かに、検索エンジンはURLをヒントにして、そのページのトピックが何であるかやサイトの構造がどうなっているかを知ろうとしているかもしれません。 しかしそれは副次的なものであり、それ単体で強い影響力を持つものではありません。 コンテンツや内部リンクなど他のシグナルによって理解させることができているのであれば、URLの構成がアドバンテージになることはないのです。 GoogleのJohn Mueller（ジョン・ミューラー）氏による、これを証明する、発言のいくつかを挙げます。 From our (Google’s) point of view, you

[対象: 中級] 削除したページをいくつも1つのページに301リダイレクトすると、ソフト404としてGoogleには認識されることがあるようです。 複数の古いページを1つのページにまとめてリダイレクトしない 英語版のGoogleウェブマスター向け公式フォーラムで、Google社員のJohn Mueller（ジョン・ミューラー）氏が次のようにコメントしています。 古いページたちを単一のページにリダイレクトすると、ソフト404としてみなされる。これは基本的には、私たちのアルゴリズムにおいては404、「ページが見つかりませんでした」と同じように扱われる。 一般的には、（なくなったURLに対しては）エラーだとはっきりわかるページを使い、404のHTTPステータスコードを返すことが推奨される解決策になる。 内容が古くなったり削除したりしたページをすべてトップページに301リダイレクトすることは、ソフ

[対象: 上級] 事前レンダリングと呼ぶ技術を使って、ウェブページの表示時間を高速化する方法をこの記事では解説します。 事前レンダリングとは 事前レンダリング (Prerendering)とは、その名のとおり、ページの読み込み（正確にはレンダリング）を前もって実行する仕組みです。 Google検索で採用されている「インスタントページ」には事前レンダリングが使われています。 下のキャプチャは、Googleで「Amazon」を検索したときのChromeのタスクの状況をタスクマネージャで確認したものです。 「事前レンダリング」でAmazon.co.jpが出ています。 「Amazon」で検索したユーザーはかなり高い確率で（1位に出てきた）Amazonのホームページをクリックするはずです。 Chromeは先回りして、ユーザーがクリックしなくてもAmazonのホームページを取得および描画、つまりレンダ