Google、AMP対応のモバイル検索を2月24日に正式公開
[レベル: 上級] Googleが、AMPに対応したモバイル検索を2月24日に正式公開する予定であることを、Advertising Age（以下、Ad Age）が報じました。 Googleはコメントせず 2月24日の公開は、AMPに詳しい複数の情報筋からAd Ageが直接得た情報です。 ただし、Googleの広報担当は正式な公開日についてはコメントを拒否しています。 Ad Ageがこのニュースを伝えたのは2月18日（現地時間）です。 新たな情報はその後入ってきていません。 したがって間違いなく2月24日の公開だとは断定できません。 とはいえ、信ぴょう性は高いように思います。 もし本当に2月24日だとしたら、米国時間での話になるので日本ではほぼ1日進んで2月25日になるでしょう。 Googleからの公式アナウンスが直前にあるのか直後にあるのか、期待しながら待ちたいところです。 これだけAMP
Google検索でリッチスニペット結果が多すぎると、品質と関連性を満たしていても表示されないことがある
[レベル: 中級] リッチスニペットが検索結果に表示されるには、3つの基準を満たしている必要がありました。 しかし、1つの検索結果ページにあまりにも多くのリッチスニペットが表示されてしまうと乱雑な状態に見えてしまうため、基準を満たしていても、あるクエリでは表示されていたとしても別のクエリでは表示されないということが起こりうるようです。 多すぎるリッチスニペットは検索結果をゴチャゴチャにする GoogleスイスのZineb（ジネブ）さんが、フォロワーからのリッチスニペットに関する質問に回答していました。 [フォロワーの質問]: リッチスニペットが検索結果に表示されるまでには、平均的にどのくらいの時間がかかりますか？
ユーザー登録・購読申し込み型のコンテンツにAMPが対応
[レベル: 上級] AMPプロジェクトは、AMPコンテンツにおける有料型や購読式のコンテンツ提供に対応したことをアナウンスしました。 ユーザー登録や購読申し込みを必要とするコンテンツでも、AMPを利用できるようになりました。 AMPでもユーザー登録や購読申し込みさせたいコンテンツ発行者 現状では、AMPに対応しているサイトはニュースサイトのようなメディア系サイトが大半です。 ニュースサイトでは、記事を読むのに課金制にしたり、無料であっても登録制にしたり、無料の場合には月に5記事までにしたりなどさまざまなプランを提供していることが多くあります。 広告とともにコンテンツ利用への課金はニュースサイトにとっては非常に重要な役割りをビジネス上担っています。 購読・登録・課金の重要性はもちろん、ニュースサイトに限った話ではありません。 ありとあらゆるジャンルのサイトが対象になります。 そこでAMPプロ
AMPコンテンツとしてGoogleモバイル検索に表示させるには、有効なAMPページと構造化データが必須
[レベル: 上級] AMPコンテンツとして、Googleのモバイル検索結果に表示されるには次の2つが必須の要件になります。 AMP HTMLの仕様に従った有効なAMPページであること schema.orgを用いた構造化データを実装していること Googleジョン・ミューラー氏が説明 1月29日の英語版ウェブマスター向けオフィスアワーで、次のような質問が出ました。 有効なAMPページとしてみなされるためには、エラーをゼロにする必要がありますか？ GoogleのJohn Mueller（ジョン・ミューラー）氏は次のように回答します。 純粋に技術的な観点から言えば、#development=1 を付けてエラーが出ていないなら、それが有効なAMPページということになる。 理論上は、その（有効なAMP）ページをAMPコンテンツとして私たちは使うことができるだろうし、ほかのサービスも同様にAMPコンテ
Google、商品とレビューのschema.orgにJSON-LDをサポートしたことを正式にアナウンス
[レベル: 上級] JSON-LDで設定したレビューと評価のschema.orgをリッチスニペットとして検索結果にGoogleが表示し始めたニュースを2日前に伝えました。 この時点ではGoogleからは公式にも非公式にもアナウンスは出ていませんでした。 しかし、John Mueller（ジョン・ミューラー）氏は、商品およびレビューの構造化データに対してJSON-LDをサポートしたことをGoogle+で昨日発表しました。 Announcing JSON-LD support for Reviews and Products structured data markup. Along with the launch of support for JSON-LD for Reviews and Products structured data markup, we’ve cleaned up s
AMP (Accelerated Mobile Pages) 導入前に知っておくといい話
[レベル: 上級] GoogleのJohn Mueller（ジョン・ミューラー）氏が、英語版の公式ヘルプフォーラムで Accelerated Mobile Pages (AMP) について質問したユーザーに情報を提供しました。 AMP導入を検討している人の参考になるので紹介します。 AMP導入に参考になる情報 今のところは、正規の検索ではまだAMPページを表示していない。2月後半の開始を予定している。 まず最初は、ニュース系コンテンツをカルーセル形式で表示することになるだろう。エンジニアによれば、ほかのタイプも公開後すぐに追加していく予定とのこと。 一般的には、AMPページはページ単位で結び付けられる（各AMPページには対応する[通常の]ウェブページが存在する）。もちろんAMPだけのページを作ることもできる。 私たち[Googlebot]がクロールして link rel=amphtml を
Google、JSON-LDで設定した🌟レビュー・評価🌟のリッチスニペットを検索結果に表示
[レベル: 上級] JSON-LDで設定したレビューと評価のリッチスニペットをGoogleは検索結果で表示し始めました。 2015年7月にJSON-LDでのリッチスニペットをGoogleはサポート開始していました。 しかし一部のタイプに限られていて、この時点ではレビュー・評価は対応がまだ完了していませんでした。 検索結果に出てきたレビューと評価のリッチスニペット こちらは実際に検索結果に出てきたレビューのリッチスニペットです。 インド映画のレビューページです。 ソースコードには、schema.org/Review がJSON-LDで書かれています（見づらかったのでキャプチャは貼りません）。 こちらは、僕が実験していたページに出てきた評価のリッチスニペットです。 schema.orgの動画 (VideoObject) をJSON-LDでマークアップしています。 平均評価として、aggrega
Googleがウェブマスター向けガイドラインを大幅改定 ―― いったい何が変わったのか？
[レベル: 初・中・上級] Googleは、ウェブマスター向けガイドラインを大幅に改定しました。 この記事では、主だった変更点を抽出して解説します。 認識しておきたい変更点が数多くあります。 新しいウェブマスター向けガイドラインの主だった変更点 セクション分け 以前は、次の3つのセクションに大きく分かれていました。 デザインとコンテンツに関するガイドライン 技術に関するガイドライン 品質に関するガイドライン 現在は、2つに分かれています。 一般的なガイドライン 品質に関するガイドライン 内容が減ったわけではなく、「デザインとコンテンツに関するガイドライン」と「技術に関するガイドライン」の2つが、「一般的なガイドライン」にまとめられた感じになっています。 「一般的なガイドライン」はさらに次の3つのサブセクションに分かれています。 Google がページを検出できるよう手助けする Google
HTTPS接続の状態をチェックできるGoogle ChromeのSecurityパネル
[レベル: 上級] HTTPSの状態を検証するための「Security（セキュリティ）」パネルがGoogle Chromeのデベロッパーツールに追加されました。 Securityパネルでは、次の3項目の安全性を知ることができます。 証明書: 有効なTLS/SSL証明書が使用されているかどうか TLS接続: 安全なTLS/SSL接続が確立されているかどうか リソース: 画像やJavaScriptなどのリソースもTLS/SSLで配信されているかどうか Securityパネルのレポート具体例 SecurityパネルでHTTPSの状態がどのようにレポートされるかの具体例をいくつか見てみましょう。 まずChromeのデベロッパーツールを立ち上げます。 [Google Chromeの設定]（右上の3本バー） − [その他のツール] − [デベロッパー ツール] Ctrl + Shift + i (Wi
ユーザーには見えてGooglebotには見えないインタースティシャルはクローキングになるのか？
[レベル: 中級] ユーザーには見えるけれど、Googlebotには見えないインタースティシャルはクローキングとしてみなされるのでしょうか？ クローキングになる可能性はそう高くはなさそうです。 しかしユーザー体験を損ねる可能性は高そうです。 Googlebotには見えないインタースティシャルに対するGoogle ジョン・ミューラー氏の見解 GoogleのJohn Mueller（ジョン・ミューラー）氏にTwitterで次のように質問したユーザーがいました。 Fetch as Googleの「取得してレンダリング」ではGooglebotには正常にページが見えています。でも、「訪問者にはこのページが以下のように表示されます」ではポップアップだけでコンテンツが表示されていません。これはクローキングにあたりそうでしょうか？ ミューラー氏はこのように返答します。 ひょっとしたらクローキングになるかも
モバイルフレンドリーの条件にページの表示速度が加わるのは時間の問題か？
[レベル: 中級] 近い将来、モバイルフレンドリーであることの条件に「ページの表示速度が十分に速いこと」が加わるかもしれません。 スマホで適切に表示されても遅ければモバイルフレンドリーではない 昨年末に開催された英語版のオフィスアワーで、GoogleのJohn Mueller（ジョン・ミューラー）氏は次のように話しています。 多くのサイトがUIをモバイル向けっぽく移行し、モバイル端末で機能するようにしているのを知っている。 だが実際にページを開くたびに何千ものリクエストが発生して、すべてのコンテンツを読み込んでレンダリングし見えるべきものが見えるようになるまでに2、3分かかることもある。 しがたって、スピードを私たちが見るようになる可能性が将来的にあるんじゃないかと私は思う。 「このサイトはとても表示が速いモバイルサイトだから、本当にモバイルフレンドリーとして必ず扱うようにしよう。対して、
iOS 9のSafariでApp Indexingの提供が始まる
[レベル: 上級] iOS 9のSafariでApp Indexingの提供が始まっています。 iOS 9では、GoogleアプリとChromeに加えてSafariでも10月終わり頃からApp Indexingを利用できるようにするとGoogleは予定していました。 App Indexing オフィスアワー App Indexingにトピックを絞ったオフィスアワーが先日開催されました。 このなかで、GoogleのMariya Moeve（マリヤ・モエヴァ）さんが、SafariでのApp Indexingが始まっていることを認めています。 ただし、Android版のApp Indexingとは異なり、iOS版では、端末にインストールしてあるアプリだけに適用されます。 Androidでは、インストールしていないアプリであってもApp Indexingが適用されます（インストールしていないアプリ
Google、ソーシャルメディア公式アカウントのブランド検索レポート機能をSearch Consoleに追加予定
[レベル: 上級] Googleは、自サイトのソーシャルメディアの公式アカウントの検索結果での表示状況をレポートする機能をSearch Consoleに追加するようです。 イスラエルのエルサレムで昨日（11月1日）開催されたSMX Islaelで、GoogleのMichael Fink（マイケル・フィンク）氏が発表しました。 Search Consoleにソーシャルアカウントを登録 こちらは参加者の1人がツイートに挿入したSearch Consoleの実際の管理画面です。 ピントが合っておらずぼやけていますが、TripAdvisorのアカウントのようです。 設定されているプロパティ (Properties in set) には上から順に次が表示されています。 TripAdvisorの公式サイト Androidアプリ（のApp Indexing） iOSアプリ（のApp Indexing）
モバイルウェブが爆速に！ GoogleがAMP (Accelerated Mobile Pages) を立ち上げ
[レベル: 上級] Googleは、Accelerated Mobile Pages （アクセラレイティッド・モバイル・ページ）という、モバイル端末でのウェブページの表示を高速化するためのプロジェクトを公開しました。 略して、AMP（アンプ）と呼びます。 AMPで策定された仕様に従ってモバイルサイトを構成すると、モバイル検索結果からリンク先ページがまさに“一瞬”で表示されます。 AMPをデモで体験 AMPを使ったページがどのようにモバイル検索から表示されるのかを見てみましょう。 Inside Searchの公式アナウンスに動画があります。 まずこれを見て、何となくでいいので雰囲気をつかんでください。 ただ、見てもどんなだか十分にはわかりませんでしたよね。 実際に試したほうが理解できます。 AMPを体験できるサンプルのリンクもアナウンスに出ていますが、日本からでは機能しないので少し細工を加え
ページネーションしたページは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、アプリダウンロードのインタースティシャルを設置しているページはモバイルフレンドリーとみなさないことを決定。モバイル検索で順位ダウンも
[レベル: すべて] Googleは、モバイル検索結果から移動したときにアプリのダウンロードを促すインタースティシャルがページの大部分を占めている場合、そのページをモバイルフレンドリーではないとみなすことを発表しました。 僕たちがよく知るように、インタースティシャルの利用に対して以前からGoogleは否定的でした。 11月1日からランキング要因に 検索結果から移動したページの大部分がアプリのインタースティシャルで覆われていると「モバイルフレンドリーではない」とみなされ、11月1日からはモバイル検索での評価が下がることがあります。 つまり、モバイルフレンドリーアルゴリズムのネガティブ要因にインタースティシャルが追加されます。 下のキャプチャは、公式アナウンスでGoogleが示した悪いインタースティシャルと良いインタースティシャルのイメージです。 左のインタースティシャルは悪い例で、スクリーン
Google、アプリコンテンツだけのApp Indexingを今年後半に公開予定
[レベル: 上級] アプリのコンテンツをモバイル検索結果に表示できる App Indexing を利用するには、現状ではアプリコンテンツに対応するウェブページが必要です。 逆の言い方をすると、ウェブサイトを持たないアプリはApp Indexingを利用できません。 しかしウェブサイトを持たずにアプリだけを提供していても、アプリのコンテンツをインデックスすることにGoogleは取り組んでいます。 このアプリコンテンツだけのApp Indexingの一般公開は今年後半をGoogleは予定しているとのことです。 Google I/O 2015で発表 アプリだけのApp Indexingを開発中だと僕が知ったのは、SMX Advanced 2015でした。 しかし直前に開催されていたGoogle I/O 2015でScott Hoffman（スコット・オフマン）氏がすでに発表していました。 Hot
モバイルUXはGoogleのランキング要因ではない、しかし間接的には強く影響するかも
[対象: 中〜上級] モバイルのユーザー体験を今のところはランキング要因にはGoogleは取り入れていません。 しかし間接的には強く影響するかもしれません。 John Mueller（ジョン・ミューラー）氏がウェブマスター向けオフィスアワーで説明しました。 今のところはモバイルUXはランキング要因ではない Q: モバイルのユーザビリティはモバイル検索のランキング要因になっているか？ モバイル端末を使ってGoogle検索したとき、モバイルフレンドリーなサイトをそうじゃないサイトよりも上位に表示するか？ A: 現状ではそういったことはやっていないはずだ。でも時がたてば変わるかもしれない。 しかし、おそらく間接的には強く影響するだろう。モバイルでサイトが本当にうまく機能しておらず、インターネット用の主なデバイスとしてたくさんの人がモバイルを使っているなら、ほかの人にそういったサイトを勧めることは
“#”が付いたAjaxのURLをそのままGoogleがインデックスし始めた？
[対象: 上級] “#”（ハッシュ）が入ったAjaxのURLを、Googleがそのまま検索結果に表示するようになる日が近いうちに来るかもしれません。 #以降も含めたURLをインデックス SEOコンサルタントのJohn Doherty（ジョン・ドハーティ）氏がこんなツイートを投稿していました。 Google is definitely indexing Ajax now, including URLs behind a hash. Game changing. — John Doherty (@dohertyjf) 2014, 8月 23 グーグルは、ハッシュ (#) のあとに付いたURLも含めて、今間違いなくAjaxをインデックスしている。大変革が起きている。 具体的なURLは明かせないと言いつつ、自分が関与していないサイトで何度か目撃したとのことです。 通常のAjaxをインデックスさせる
Google日本、いよいよSPYW (Search Plus Your World) を正式公開か？
[対象: 中級] Google日本 (google.co.jp) が、SPYW (Search Plus Your World)を正式に公開した可能性が濃厚です。 これまではテストを繰り返し実施していたものの、ごく短時間で消えることが普通でした。 しかし先週末頃から、常時、幅広い環境でSPYWを確認できています。 SPYWが適用されているかどうかは、検索結果右上にある「人」と「地球」マークのアイコンで識別できます（このあと見せるキャプチャで確認してください）。 僕が調べた限りでは、英Google (google.co.uk) や 豪Google (google.com.au) でもGoogleアカウントにログインした状態でSPYWが適用されていました。 3月末にIA Summitで米国に滞在してるときは、co.jpでも常にSPYWを利用できました。 一方で同じとき日本では、見えたり消えたり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
