AMPに対応した広告用ランディングページ「ALP」、DFPが年内に配信開始予定
[レベル: 上級] AMP プロジェクトは、広告をAMPで配信できるランディングページを開発しました。 AMP Ad Landing Pages、通称 ALP と呼びます。 ALPはAMPフォーマットで作られているので、広告用のランディングページを高速に表示できます。 ALPは1秒以内で表示完了 ALPを採用した広告ランディングページは、1秒かからずに表示を完了することができます。 Googleのモバイル検索からAMPページにアクセスし、そのページに掲載されている広告をタップしてALPが表示されるまでの流れが、次のアニメーションGIFで紹介されています。 このデモでは、広告バナーをタップしてからALPが表示されるまでに要した時間は0.83秒です。 ALPの高速表示を実現するために用いられる4つの技術 主に、次の4つの技術を用いてALPは高速な広告配信を実現しています。 ランディングページへ
AMPページ閲覧時にキャッシュではなくオリジナルのURLを表示するようにGoogleが対応、2018年後半の実現を予定
[レベル: 上級] AMP キャッシュを閲覧するときでも、そのウェブページの本来の URL を表示するように Google は取り組んでいます。 今年後半の実現を予定しているとのことです。 Google ドメイン名の URL を表示する AMP キャッシュ プライバシー保護と高速化の観点から、AMP は、オリジナルのウェブページが格納されているコンテンツ発行者のウェブサーバー（つまり僕たち自身が管理するサーバー）ではなく、AMP CDN サーバーのキャッシュから配信されます。 この仕様によって問題が生じます。 たとえば、AMP 対応したページに Google 検索からアクセスすると、本来のドメイン名での URL ではなく google.co.jp/amp/ のように Google が管理する AMP キャッシュ用のドメイン名の URL がブラウザのアドレスバーに表示されてしまいます。 正規
更新が頻繁なコンテンツのAMP対応ベストプラクティス
[レベル: 上級] 高速な表示を実現するために AMP ではキャッシュモデルを利用します。 僕たちのウェブサーバーからではなく AMP の CDN サーバーからキャッシュという形でコンテンツがユーザーに配信されます。 キャッシュなので、常に最新の情報とは限りません。 オリジナルのコンテンツは更新されているのに、キャッシュは古いままという状況がありえます。 ユーザーには古くなった情報を返してしまいます。 更新が頻繁なページでは問題になるかもしれせん。 更新が頻繁なページの AMP 対応のベストプラクティスをセミナー参加者に先日質問され、その場では完全な回答を提供できず、その後 AMP に詳しい方に教えていただいたのでこの記事で共有します。 2つの方法が考えられます。 何もしない <amp-list> を使う 何もしない AMP キャッシュの仕組みをこのブログで以前に詳細に解説しました。 オリ
2018年のAMPはどう進化するのか？ #AMPConf 2018基調講演レポート
[レベル: 上級] オランダのアムステルダムで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 は次のような機能を持つ。
好きなJavaScriptをAMPで実行できるようになるかも。Web Workerで実現か？
[レベル: 上級] 将来的に、AMP で JavaScript を利用できるようになるかもしれません。 2月にアムステルダムで開催された AMP Conf 2018 で AMP チームのエンジニアリング・リード、Malte Ubl（マルテ・ウーブル）氏がその可能性について言及しました。 Web Worker（ウェブ ワーカー）という技術を用います。 JS を使えない AMP AMP では任意の JavaScript の利用が非常に厳しく制限されています。 AMP で許可された以外の JS を使うことは基本的にはできません。 理由は、パフォーマンスを低下させる大きな要因に JS がなるからです。 しかし、JS が使えないということは現代のウェブにおいて当たり前のように使われているさまざまな機能を利用できなくなることを意味します。 任意の JS が使えないことが AMP を敬遠させる理由の1つ
「もっと見る」のMFI対応はページネーションがベスト？ #SMX Munich 2017
[レベル: 中級] この記事では、モバイル ファースト インデックスの導入にともなう、次のような構成のモバイルサイトの対応について解説します。 モバイル向けサイトのリストページは、アイテムの表示件数を初期状態では PC 版よりも少なくしている 「もっと見る」のような要素でアイテムを追加表示する 「もっと見る」のタップを繰り返してアイテムをさらに追加表示する モバイル UX 向上のための「もっと見る」 モバイルサイトでのリストページでは、「もっと見る」や「次の○件」のようにして、タップすることでさらに多くのアイテムを表示するユーザーインターフェイスが使われることがあります。 多過ぎるアイテムを一度に表示すると、表示速度が落ちるし見づらくなるからです。 ユーザー体験を向上させるための UI です。 ただし、モバイルサイトでこうした UI を採用していても、PC サイトではもっと多くのアイテムを
Googlebotのクロールバジェット最適化は必要なのか？ そもそもクロールバジェットとは？
[レベル: 上級] Googleウェブマスター向け公式ブログで、GoogleのGary Illyes（ゲイリー・イリェーシュ）氏が、Crawl Budget（クロール バジェット）について詳細に解説しました。 要点を絞って、この記事でまとめます。 完全な翻訳は、日本語版ブログで公開されるのを待ちましょう。 クロール レート リミット（クロール率上限） サイトを訪問するユーザーの体験を損ねないように、ページを取得する頻度の最大値・上限を特定のサイトに対して設定している。この最大値設定を、Googleでは”crawl rate limit”（クロール レート リミット、クロール率上限）と呼んでいる。 crawl rate limitは、簡単に言えば、Googlebotがサイトに同時に接続する数であり、次のページ取得までの待機時間も意味する。 crawl rate limitは、次のような要因で
Google、モバイルファーストインデックスの導入予定を正式発表。スマホ向けページを検索の評価対象に。SEOへの影響は？
[レベル: 中級] Googleは、Mobile First Index（モバイル ファースト インデックス）の導入を正式にアナウンスしました。 Mobile-first Indexing モバイル ファースト インデックスに向けて モバイル ファースト インデックスでは、PC向けページではなく、モバイル向けページの評価に主に基づいてランキングが決定されます。 Gary Illyes（ゲイリー・イリェーシュ）氏が米ラスベガスで10月に開催されたPubCon Las Vegas 2016で発表していたGoogle検索の仕様変更です。 正式な実施時期はまだ決まっていません。 今後数か月にわたり小規模な実験を行ったうえでの判断になるとのことです。 評価対象がPC向けページからモバイル向けページへ 詳細は公式アナウウンスを読んでいただくとして、概要としてはモバイル ファースト インデックス（以下、
ページの表示速度はレンダリングとクローリングの2つの側面でSEOに関係する
[レベル: 中級] サーバースピード、言い換えればページの表示速度が検索に与える影響について、GoogleのJohn Mueller（ジョン・ミューラー）氏が英語版のオフィスアワーで参加者からの質問に回答しました。 レンダリングにかかる時間とクロールにかかる時間の2つの側面から、表示速度による影響をミューラー氏は説明しています。 サーバースピードというものを見るときには、2つの側面があると思う。 1つの側面は、ブラウザで認識される時間だ。つまり、レンダリングにかかる時間だ。 これは、たしかにランキング要因になっている。といっても、おそらく大きな影響力はない。通常は、本当に遅いサイトと一般的な速度のサイトを差別化しようとするくらいのものだ。 よって、数ミリ秒単位で高速化しても検索結果には何も影響しないだろう。 しかし、サイトを速くすればするほど、ユーザーの滞在時間が伸びたり、サイトでより多く
Googleがウェブマスター向けガイドラインを大幅改定 ―― いったい何が変わったのか？
[レベル: 初・中・上級] Googleは、ウェブマスター向けガイドラインを大幅に改定しました。 この記事では、主だった変更点を抽出して解説します。 認識しておきたい変更点が数多くあります。 新しいウェブマスター向けガイドラインの主だった変更点 セクション分け 以前は、次の3つのセクションに大きく分かれていました。 デザインとコンテンツに関するガイドライン 技術に関するガイドライン 品質に関するガイドライン 現在は、2つに分かれています。 一般的なガイドライン 品質に関するガイドライン 内容が減ったわけではなく、「デザインとコンテンツに関するガイドライン」と「技術に関するガイドライン」の2つが、「一般的なガイドライン」にまとめられた感じになっています。 「一般的なガイドライン」はさらに次の3つのサブセクションに分かれています。 Google がページを検出できるよう手助けする Google
Google、ドメイン間の rel=”canonical” タグのサポート開始
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リダイレク
スマートフォン向けサイトにはレスポンシブ・ウェブデザインを推奨、Googleが公開したスマホサイトの最適化 at #SMX Advanced Seattle 2012
[対象: 中〜上級] SMX Advanced Seattle 2012 セッションレポート第2弾は、英GoogleのPierre Far（ピエール・ファー）氏による「スマートフォン向けサイトの最適化」です。 Far氏のプレゼンテーションは、直前にGoogle Webmaster Central Blogで公式アナウンスがあったスマートフォンサイト構築の推奨に関する記事とその詳細を説明しているドキュメントとほぼ同じ内容です。 Far氏のプレゼンと公開されたばかりのドキュメントを合わせて、Googleが推奨するスマートフォンサイトを構築する際の最適化についてレポートします。 スマートフォン向けサイトの最適化 3タイプの構成のスマートフォン向けサイトをGoogleはサポート レスポンシブ・ウェブデザイン (Responsive web design) — デスクトップとモバイルで同じURL・同
Googleのジョン・ミューラーがあなたのSEOの素朴な疑問に答えてくれた from #smxmilan
[レベル: 初・中・上級] お伝えしていたように、11月12〜13日に伊ミラノで開催されたSMX Milan 2015に参加してきました。 セッションレポートの第一弾として“Ask Me Anything With Google”の内容を紹介します。 “Ask Me Anything With Google”は日本語風に言うと「グーグルに何でも聞いてみよう」となり、GoogleのJohn Mueller（ジョン・ミューラー）氏にさまざまな質問をぶつけてそれに率直に答えてもらうというセッションです。 セッション中のモデレータからの質問と（僕も含めた）参加者からの質問とその回答に加えて、セッション終了後に僕が直接尋ねてきた質問とその回答も交えてまとめてあります。 必要なものには僕からの補足コメントを付けています。 なお特に重要度順には並べていません。 読み逃すことがないように、すべてのQ&Aを
非公開だった検索品質評価ガイドラインの最新版をGoogleが公開
[レベル: 中級] 検索結果の品質を評価するためのガイドラインの最新版をGoogleは公開しました。 これまでのものとは変更がない部分がある一方で、新たにモバイルに関する章が加わったことが最新版の最大の特徴となっています。 検索品質評価ガイドラインとは？ Googleは、ユーザーのクエリに対して関連性が高くかつ高品質なページを検索結果で返すことができているかどうかを、外部の評価者（Evaluator）に常に評価させています（評価者は普通に求人として募集されているらしい。日本でさえも）。 評価者による評価は検索品質の改善のために役立てられます。 直接的にランキングを調整するためには用いられません。 どのように検索結果の品質を評価するかを説明した「General Guidelines」（一般ガイドライン）というマニュアルが評価者に提供されます。 このマニュアルは原則的に評価者だけに配布されます
ページネーションしたページはnoindexにすべき？ rel=“prev/next”とnoindexは併用可能？
[レベル: 上級] ページネーション（ページ送り）したページには noindex robots metaタグを記述したほうがいいのでしょうか？ また、rel=”prev”とrel=”next”を設定しているページにnoindexを記述しても問題ないのでしょうか？ 9月11日のオフィスアワーで、GoogleのJohn Mueller（ジョン・ミューラー）氏がこの質問に回答しています。 質問者: ページネーションしたページにnoindexタグを付けるのは良いやり方ですか？ また、rel=”prev”とrel=”next”を記述したページにnoindexを付けるのはどうでしょうか？ ミューラー氏: 何をインデックスさせたくて、何をインデックスさせたくないのかによる。 ページネーションしたページが十分な価値をユーザーに提供しているのであれば、インデックスさせる意味があるだろう。たいした価値をユーザ
Googleは302リダイレクトを301リダイレクトとして処理することがある
[レベル: 中〜上級] 301リダイレクトは恒久的なURLの移転の際に用います。 対して、302リダイレクトは一時的なURLの移転の際に用います。 特にユーザーを自動的に転送する点において両者に違いはありませんが、検索エンジンの処理においてはいくつかの違いがあります。 使う場面も異なってきます。 しかし、状況によってはGoogleは302リダイレクトを301リダイレクトとして認識し処理することがあるとのことです。 また、301リダイレクト扱いされた302リダイレクトはPageRankを渡します。 長期間継続する302は301 英語版のオフィスアワーで参加者がJohn Mueller（ジョン・ミューラー）氏に次のように質問しました。 一時的な302リダイレクトが十分な時間継続すると、最終的にGoogleは恒久的な301リダイレクトとして処理すると聞いたことがあります。 どのくらいの時間がたつ
不自然リンクの手動対策はSearch Consoleに出てくるリンクを削除すればいいが、ペンギンが問題視するリンクはレポートに出てこないこともある
[レベル: 中〜上級] 基本的に、不正なリンクに対する手動対策は、Search Consoleの外部リンクレポートに表示されるリンクを対象にして対応すれば解除してもらえます。 しかしペンギンアップデートのようなアルゴリズムは、Googleが認識しているすべてのリンクが対象になります。 Search Consoleでは、すべてのリンクがレポートされているとは限りません。 手動対策とアルゴリズムの違い 7月3日のウェブマスター向けオフィスアワーで、不自然リンクの手動対策の解除後も検索順位が復活しないサイトの管理者がGoogleのJohn Mueller（ジョン・ミューラー）氏に質問しました。 不正なリンク構築を10年ほど続けてきて、2012年のペンギンアップデートにやられました。手動対策も与えられ、3年かけて不正なリンクを削除したり否認したりしてようやく1年半前に解除されました。 でもランキン
クロール頻度を上げてもランキングは上がらない
[レベル: 初級] たくさんクロールさせても、そのページの評価が上がることはないし検索順位は上がりません。 また、サイトマップの <priority> タグをクロールの重要度を示す要素としてはGoogleはほとんど利用しません。 Googleのジョン・ミューラー氏による説明 6月30日に開催された英語版のウェブマスター向けオフィスアワーでクロールについてのやりとりがありました。 GoogleのJohn Mueller（ジョン・ミューラー）氏に参加者の1人が次のように質問します。 50,000ページ以上ある大規模サイトのクロールバジェットをどうやったら増やすことができますか？ 現状では、重要なのに定期的にクロールされていないページがあることに気付いています。 サイトマップでは、毎日クロールされるように重要度付けしています。 何かアドバイスはありますか？ ミューラー氏は次のように回答します。
ページを削除したときは404と410のどちらを返すべきか？ => どちらでもいい
[レベル: 初〜中級] ページを削除したときには、404と410のどちらのHTTPステータスコードを返すべきなのでしょうか？ 結論を一言でいえば、Googleにおいてはどちらでも構いません。 再クロール率にも影響しません。 Googleのミューラー氏による説明 GoogleのJohn Mueller（ジョン・ミューラー）は、ユーザーから受け取った質問メールを引用して、404と410のGoogleの扱いについてGoogle+で説明しました。 I have a large site and removed lots of irrelevant pages for good. Should I return 404 or 410? What’s better for my “crawl budget”? (more from the depths of my inbox) The 410 (“G
低品質ページを大量生産しても検索エンジンの評価は上がらない、高品質コンテンツだけを作る
[レベル: 初〜中級] たとえば、自動生成でページ数を大量に増やしてもすべてのページがインデックスされることはないし、検索エンジンの評価は上がりません。 コンテンツの品質が高いページだけを作り、反対に、品質が低いページを減らすことが重要です。 ヘルプフォーラムでのQ&A 次のような内容の質問がGoogleのウェブマスター向け公式ヘルプフォーラムに投稿されました。 160万ページ以上あるのに、site:で調べると120万ページしかインデックスされていない。 Search Consoleでも120万だ。 どうしたら全ページをインデックスさせられるか？ ミューラー氏からのアドバイスはこうでした。 On the one hand, the site:-query results weren’t meant to be used as a metric — they’re a very rough
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
