[レベル: 初級] Google 検索の観点からは、そのページのメインコンテンツとして動画を利用することは推奨されません。 メインコンテンツを補強するための要素として動画は利用すべきです。 文字起こしやコメントを加えて動画を使う コンテンツとして動画を使う場合の注意点に関して Google の John Mueller（John Mueller）氏が英語版オフィスアワーで言及しました。 一般的に言って、ウェブページのメインコンテンツとして動画を使うときは気を付けたほうがいい。メインコンテンツを補う形で動画を使うべきだ。メインコンテンツの置き換えとして動画を使うべきではない。 単に動画を貼り付けるのではなくその動画に関するコンテンツ、たとえば文字起こししたものやその動画の内容に関する見解を加えたり、メインコンテンツを裏付けるための参照先として利用したりするといい。 Google にとって動画

[レベル: 中級] 検索結果のスニペットの先頭にそのコンテンツの公開日が表示されることが多くあります。 この日付を Google 検索に正しく伝えるためのベストプラクティスをウェブマスター向け公式ブログが解説しました。 前提: 日付は複数の要因で決定される まず前提として知っておくべきことがあります。 スニペットの日付は、表示される・表示されないも含めて、完全にアルゴリズムによって決められます。 日付の決定には複数の要因が用いられています。 たとえば、構造化データはその要因の 1 つですが、構造化データだけを Google は頼りにしているわけではありません。 したがって、コンテンツ発行者（僕たち）が望む日付を強制的に表示させることはできません。 それでも、より適切な日付をスニペットに表示させるためのベストプラクティスが存在します。 適切な日付情報を Google に提供する方法 細かなこ

[レベル: 中級] 評価・レビューの構造化データ (AggregateRating/Review) と Q&A の構造化データ (QAPage) を同じページに同時に追加することはできるのでしょうか？ 結論を言えば、追加できます。 複数の構造化データを同時に利用可能 評価の構造化データとQ&Aの構造化データを同じページに使うことができます？ こんな質問が英語版オフィスアワーで取り上げられました。 ミューラー氏は次のように回答しました。 もちろんだ。ダメだという理由がすぐには思い浮かばない。 たとえば Amazon は、評価とレビューに加えて、投稿型の Q&A のコンテンツも商品ページに設置しています。 このページで、評価とレビューの構造化データと Q&A の構造化データの両方をマークアップすることができます。 ついでに、パンくずリストの構造化データも追加することだってできるでしょう。 Go

Web担当者Forum の連載コーナー、「海外&国内SEO情報ウォッチ」を更新しました。 今週のピックアップはこちらです。 内部リンクにトラッキングパラメータを付けるのはSEO面でリスクあり ほかにも、ウェブサイト運営や SEO に役立つ、次のような情報を取り上げました。 Search Consoleから緊急警告！ 検索結果のクリックが著しく減少しました 3万ページを削除したら、検索ランキングへの影響はいかに？ Fetch as Googleを使いすぎるとペナルティを受ける!? リンク否認ツールの間違った使い方： ×見覚えのないリンクを否認する サイトの長期的な成功は「ランキング要因の研究」ではなく「UX改善」が必要 figcaptionタグはalt属性の代わりになる？ URL検査ツールでPCサイトのスクリーンショットを取得できない グーグル、JSレンダリングの速度向上に取り組み中 広告も

[レベル: 中級] 「ドメイン プロパティ」の機能が新バージョンの Search Console に追加されました。 ドメイン プロパティは、www ありなしやモバイルサイト向けの m ドメインなどすべてのサブドメインと、http および https の両方のプロトコルのサイトのデータをまとめてレポートします。 旧バージョンの Search Console で提供されていた、複数のプロパティをまとめることができるプロパティ セットにも似た機能になります。 ドメイン名レベルと URL レベルを選択してプロパティ追加 ドメイン プロパティが有効になると Search Console に新規にプロパティ（サイト）を登録する際に、次の 2 つのうちどちらのプロパティを追加するかどうかを尋ねられます。 ドメイン URL プレフィックス 「ドメイン」が今回新たに追加されたドメイン プロパティの作成です

[レベル: 初級] 1 つのサイトマップにすべての URL を記載して送信する場合と、複数のサイトマップに分割して URL を送信する場合とでは Google のクロールとインデックスに違いが生じてくるのでしょうか？ Google の John Mueller（ジョン・ミューラー）氏によれば、サイトマップがどのように分かれていても Google は気にかけないとのことです。 サイト管理の形態に合わせてサイトマップを構成できます。 サイトマップがどのように分割されていようが Google は気にしない ウェブページと画像を1つのサイトマップにまとめるべきか、それとも分けるべきか？ この質問にミューラー氏は次のように回答しました。 どちらのやり方も機能する。 Google 側の技術的な仕組みで言うと、発見したサイトマップをすべて統合して 1 つの大きなファイルにまとめる。そして、それを処理する

[レベル: 中級] リッチリザルト テスト ツールがコードでの検証をサポートしました。 構造化データのコードを編集しながらの検証が可能です。 これまでは URL を入力して、公開しているページの検証しかできませんでした。 昨年 11 月の Chrome Dev Summit でアナウンスされていた機能拡張です。 RRTT でコード検証 リッチリザルト テスト ツールにアクセスすると、「URL」と「コード」の切り替えができるようになっています。 コードを選択し、検証したい構造化データを貼り付けて、テストを実行します。 画面左には貼り付けたコードが出ているので、修正しながら検証を継続できます。 構造化データの公開前の検証が可能になったのは非常に便利です。 エラーを修正したりコードを調整をしたりといったことが事前にできます。 ただし、注意点があります。 リッチリザルト テスト ツールがサポートと

[レベル: 上級] SEO と相性がいい Lazyload の実装を解説するドキュメントを Google はデベロッパー向けサイトで公開しました。 3つのアドバイス ドキュメントには3つの指針が書かれています。 1. viewport 内で見えるようにする viewport 内にあるコンテンツは、必ず Google にも見えるようにしておきます（viewport は簡単に言えば、スクリーンに表示される領域）。 つまり、重要なコンテンツが viewport に入ったときは確実に読み込ませます。 IntersectionObserver API と polyfill を実装するように Google は指示しています。 2. 無限スクロールでは paginated loading を使う 無限スクロールを採用している場合は、paginated loading を実装します。 paginated

[レベル: 初級] 新しい Search Console は、サイトに影響を与える可能性があるクロールエラーだけをレポートするようになっています。 旧 Search Console は、Googlebot が検出したすべてのエラーをレポートしていました。 インデックス カバレッジ レポートのエラーは重要なもののみ Google の John Mueller（ジョン・ミューラー）氏によれば、旧 SC のクロール エラー レポートとは異なり、新 SC のインデックス カバレッジ レポートはすべてのエラーを表示しなくなっているそうです。 理由の1つは、すべてのエラーをレポートすると、たとえ無視できるものであってもそれにとらわれすぎて本当に重要な問題を見過ごしてしまうウェブマスターがいるからです。 たとえば、どこからもリンクしていないはずだし、サイトマップにも載せていないはずの URL を Goo

[レベル: 上級] 記事が最初に公開された日時と最後に更新された日時の両方を構造化データでマークアップすることを、Google の John Mueller（ジョン・ミューラー）氏は推奨しました。 また、Google に日時を正しく認識させるために、構造化データで指定する日時とページ内に書かれている日時を統一することが重要です。 公開日と更新日の両方をマークアップする 構造化データでマークアップするなら、公開日と更新日のどちらを使用すべきか？ この質問にミューラー氏は、次のように回答しました。 どちらを使っても構わないが、個人的には両方マークアップすることを勧める。両方をマークアップすることができるはずだ。 Google のアルゴリズムには両方とも役に立つ。 schema.org の Article や NewsArticle、BlogPosting などのタイプは、公開日と更新日の両方の

[レベル: 上級] noindex タグを JavaScript によってクライアントサイドで挿入することが可能です。 Googlebot はきちんとレンダリングし処理できます。 しかしながらこの方法は、処理に時間がかかることがあるため推奨されません。 JS による noindex 挿入を推奨しない JavaScript によってクライアントサイドでレンダリングさせた rel="canonical" タグを Google は無視するということでした。 サーバーが返す HTML に rel="canonical" が存在している必要があります（実際には、クライアントサイドでレンダリングした rel=”canonical” も認識されるらしいことが検証からわかっている）。 一方で、rel="canonical"（と rel="amphtml"）以外の要素、たとえば noindex robots

[レベル: 上級] 求人検索に対応した JobPosting 構造化データを設定しているページ向けに、Indexing API という仕組みを Google は公開しました。 Indexing API を利用すると、Google にクロールをダイレクトに要求し最新の状態にインデックスを常に保つことができます。 求人情報ページのみ 求人検索には即時性が求められます。 新たに募集が始まった求人はすぐさま検索結果に出すべきだし、募集を終了した求人は直ちに検索結果に出ないようにすべきです。 求人サイトがページを新規に公開したり募集終了ページを削除したりしても、通常のクロール/インデックスのプロセスでは即時性を実現できません。 検索結果に出るまでに数日かかるかもしれないし、もう募集を締め切った求人が検索結果に残り続けるかもしれません。 こうした問題を解決するために、Indexing API が導入さ

[レベル: 上級] AMP の開発状況を示すロードマップの現状を紹介する記事を AMP プロジェクトの公式ブログが投稿しました。 正式リリースされた機能と開発中の機能、取り組みが始まったばかりの機能が数多く紹介されています。 個人的に気になった機能を2つ、この記事で取り上げます。 amp-next-page は AMP ページで無限スクロールを実装するコンポーネントです。 ページの下までスクロールすると追加のコンテンツが自動で読み込まれます。 EC サイトの商品リストページや、ソーシャルメディアのタイムライン、長いブログ記事などでおなじみの UI ですね。 無限スクロールが AMP ページでも利用できるようになります。 一般的に、AMP ページでは、内部リンクをたどった場合は AMP ページではなく通常のモバイルページに移動します。 amp-next-page を構成すれば、一連のコンテン

[レベル: 上級] ベータ版が提供されている新しい Search Console の新機能として「URL 検査」ツールが1週間ほど前に追加されました。 すべてのユーザーに提供されるまでには、1〜2週間くらいかかるとのことでした。 今朝見てみると僕のアカウントでも使えるようになっていました 簡単に使ってみた状況をこの記事で紹介します。 URL 検査ツール 初体験 URL 検査ツールを利用できる状態だと、左メニューに「URL 検査」が出ています。 あるいは、「インデックス カバレッジ」で URL を選択したときに右側に出現するメニューからもアクセスできます。 AMP やリッチリザルトのレポートで URL を選択した場合も、右下に小さく見えている「検査」リンクからツールを起動できます。 検査結果はさまざまです。 こちらは正常にインデックスされている状態の「URL は Google に登録されてい

[レベル: 上級] SEO に適した Lazy Load 推奨構成を Google が近いうちに提案してくれるかもしれません。 Google の John Mueller（ジョン・ミューラー）氏が Twitter で次のようにコメントしました。 Lazy Load の画像にはさまざまな方法がある。画像検索のインデックスにはどんなマークアップが有効なのかを考えることには明らかに価値がある（うまくいくものもあれば、いかないものもある）。より明確な推奨ができないか私たちは検討中だ。 There are various ways to lazy-load images, it's certainly worth thinking about how the markup could work for image search indexing (some work fine, others don

[レベル: 中級] タブや展開型の UI を採用して、初期状態で隠れているコンテンツは Google 検索では重要度を下げられることがあります。 しかし、表示領域が PC よりも狭いモバイル向けページではこのタイプの UI はよく使われます。 詳細を非表示にすることで本当に必要な情報を最初からなるべく多く見せるという、ユーザー体験を考慮してのことです。 こうした理由から、初期状態で表示されていなかったとしてもモバイル ファースト インデックスでは評価を下げられることはありません。 隠しコンテンツとして乱用が可能ではないかと懸念が生じますが、そうした乱用あるいは誤用を防ぐためのアルゴリズムを Google は備えているとのことです。 非表示コンテンツの乱用・誤用は MFI ではアルゴリズムで防ぐ MFI では容認される非表示コンテンツの乱用について、Google はどのように対処するのか？

[レベル: 中級] 複数の強調スニペットを同時に表示する検索結果を導入したことを Google はアナウンスしました。 検索意図が複数考えられるクエリの場合に、それぞれの意図に応じた強調スニペットが複数出現することがあります。 複数出現するマルチファセット強調スニペット 同時に複数が出現する強調スニペットを Google は “multifaceted featured snippets” と名付けています。 “multifaceted”（マルチファセット、マルチファセッテッド）は、日本語では「多面」「多角的」と訳されます。 「多面強調スニペット」と呼ぶこともできそうですが日本語名称は不明なので、この記事では「マルチファセット強調スニペット」ととりあえず呼ぶことにします。 マルチファセット強調スニペットは、いくつもの検索意図が考えられるクエリで出現することがあるとのことです。 たとえば、“

[レベル: 上級] 高速な表示を実現するために AMP ではキャッシュモデルを利用します。 僕たちのウェブサーバーからではなく AMP の CDN サーバーからキャッシュという形でコンテンツがユーザーに配信されます。 キャッシュなので、常に最新の情報とは限りません。 オリジナルのコンテンツは更新されているのに、キャッシュは古いままという状況がありえます。 ユーザーには古くなった情報を返してしまいます。 更新が頻繁なページでは問題になるかもしれせん。 更新が頻繁なページの AMP 対応のベストプラクティスをセミナー参加者に先日質問され、その場では完全な回答を提供できず、その後 AMP に詳しい方に教えていただいたのでこの記事で共有します。 2つの方法が考えられます。 何もしない <amp-list> を使う 何もしない AMP キャッシュの仕組みをこのブログで以前に詳細に解説しました。 オリ

[レベル: 上級] schema.org を用いた構造化データの利用方法についてGoogle の John Mueller（ジョン・ミューラー）氏が英語版オフィスアワーでとても役立つアドバイスを与えてくれました。 この記事では、ミューラー氏によるアドバイスの要点を簡潔にまとめます。 構造化データはすべてが使われるとは限らないが、あればエンティティの理解に役立つことも

[レベル: 上級] オランダのアムステルダムで2月13〜14日に開催された AMP Conf 2018 に参加してきました。 この記事では、基調講演のハイライトをレポートします。 AMP の現状 3,100 万のドメインが AMP ドキュメントを発行 検索に出てくる AMP ページのクリックの 60% 以上が、ニュース以外のサイト AMP ページの滞在時間は2倍 AMP でコンバージョンが2倍 AMP が目指すのは、いまだかつてないほどにユーザーにフォーカスした強力な、開かれたウェブを実現すること。 そして、誰でも使える一般的なものにすること。 AMP Stories ユーザーのコンテンツ消費の仕方が変わってきた。モバイルでは長い記事を読みずらく、1〜2分でユーザーは読む。 そこで、AMP Stories（AMP ストーリー）を導入した。 AMP Stories は次のような機能を持つ。