[レベル: ALL] Google アナリティクスの管理者である場合、自動的にそのサイトが Search Console に登録されるようになります。 言い換えると、Google アナリティクス の管理権限を所有していれば、Search Console での所有者確認の操作は不要です。 今後数か月にわたってこの変更が適用されていきます。 GA を管理していれば手動での SC 登録が不要に 現状でも、Google アナリティクスのトラッキングコードを利用して Search Console でのサイトの所有者確認が可能です。 しかしそれでも、「Google アナリティクス トラッキング コード」を確認方法に選択して手動での確認作業が必要になります。 今後は、Google アナリティクスの管理権限があれば何もする必要はありません。 自動的に Search Console に登録されます（正確には

[レベル: 上級] PWAをサポートしていないブラウザでもホーム画面アイコンを追加できる仕組みとして、PWACompat を Google は公開しました。 PWACompat を構成すると、Web App Manifest を解釈しないブラウザために、関連する meta タグや link 要素を自動的に挿入してくれます。 PWACompat で iOS 版 Safari にもホーム画面アイコンを追加 iOS 版 Safari は Service Worker のサポートに着手しましたが、完成にはまだほど遠い状態です。 たとえば、Web App Manifest（マニフェスト ファイル）によるホーム画面アイコン追加の機能をまだサポートできていません。 iOS にホーム画面アイコンを追加させようとしたら、link rel="apple-touch-icon" のようなタグを別途追加する必要が

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

[レベル: 中級] ウェブページの表示スピードを計測するツールの PageSpeed Insights で、サイト全体を集計した速度データを調べられるようになりました。 これまでは、単一のページが検証の対象でした。 origin: コマンドで集計データをレポート サイト全体の速度データを集計してレポートを出すには origin: をドメイン名の URL の先頭に付けます。 僕のサイトであれば、origin:https://www.suzukikenichi.com で検証します。 僕のサイトは、全体としては「Fast」（速い）という結果が出ました。😃 あるいは、個別ページを検証すると、origin: コマンドを使うと集計データをレポートすることができるという説明が出てきます。 Chrome ユーザー エクスペリエンス レポートでは、このorigin（https://www.example

[レベル: 上級] schema.org でマークアップされた構造化データのすべてのプロパティをGoogle はインデックスする 可能な限り多くの構造化データをマークアップした方がいい 2018年4月6日に開催された ISM Spin-off #4 − Google Search Night で Google の Gary Illyes（ゲイリー・イリェーシュ）氏は、このように発言しました。 セッションの合間に僕が 1対1 でゲイリーと話したときのことです。 検索に使っていなくてもインデックスしている schema.org が定義する構造化データには非常に多くのタイプとプロパティが存在します。 リッチリザルトなどで Google が利用しているのは、ほんのごく一部です。 いったい Google はどのタイプのどのプロパティをサポートしているのでしょうか？ リッチリザルトで使われない構造化デ

[レベル: ALL] 2018年4月6日に ISM Spin-off #4 – Google Search Night が開催されました。 来日中の Gary Illyes（ゲイリー・イリェーシュ）氏のキーノートスピーチに続けて行われた AMA セッションでは、光栄なことに僕がモデレータを務めました。 オフィスアワーでおなじみの、金谷さんと長山さん、あんなさんも加えた4人の豪華ゲストを招いての Q&A セッションです（長山さんも米国から来てくださいました）。 この記事では、AMA セッションで交わされた Q&A を一挙公開します。 (c)Shintaro Akesaka AMA の様子――左から、ゲイリー・あんなさん・長山さん・金谷さん では、始めましょう！ 日本に滞在中にいちばん困るのは何？ アイスブレイクとして、日本に来ている長山さんとゲイリーに尋ねた質問です。 長山さん: 京都にオフ

[レベル: 初〜中級] GoogleのJohn Mueller（ジョン・ミューラー）氏が、2016年に向けてのSEOの秘訣について話しました。 12月15日に開催した英語版オフィスアワーで出た質問に対する回答です。 おぉ、（その質問が）きたねぇ。来年に向けての魔法みたいなSEOの秘訣っていうのは何もないんだ。今開発中の上位表示のmetaタグについては話せない。公開してもまだ機能しないんだ。 だけど概して言えば、AMPとモバイルフレンドリーについてもっといろんなことを私たちから来年は聞くことにおそらくなるだろう。モバイルフレンドリーは私たちがここ数年ずっとやってきたことだ。 モバイルフレンドリーは今でもとても大切なテーマだ。たくさんのサイトが適切にやっていないのを依然として目にする。モバイルフレンドリーがほかよりも大きな変化ではないだろうか。 もちろんモバイルフレンドリー以外にもあるだろう。

[レベル: 初〜中級] nofollowリンクの使い方に関して、GoogleのJohn Mueller（ジョン・ミューラー）氏が英語版のオフィスアワーで参加者の質問に回答しました。 nofollowリンクをサイト内で多用することに問題はありません。 その一方で、ユーザーの役に立つコンテンツへのリンクであればnofollowを付ける必要性はまったくありません。 オフィスアワーでのQ&A 参加者が次のようにミューラー氏に質問しました。 外部サイトへのリンクをすべてnofollowにすることを、良いことだとはGoogleは思っていないというのは本当ですか？ 広告やユーザー生成コンテンツのリンクをnofollowにしようかと考えています。 ミューラー氏は次のように回答します。 いいや、そんなことはない。 nofollowリンクがサイトにたくさんあったとしてもまったく問題ない。たくさんの広告やユーザ

[レベル: 上級] JSON-LDで記述したschema.orgのリッチスニペットをGoogleが検索結果に表示するようになりました。 これまでは、MicrodataまたはRDFaによるマークアップだけがリッチスニペットに対応していました。 JSON-LDによるレシピのリッチスニペット 下のキャプチャは、あるレシピサイトの検索結果に表示されたレシピのリッチスニペットです。 このページには、JSON-LDをシンタックスに使った schema.org/Recipe が構造化データとして記述されています。 MicrodataやRDFaではマークアップされていません。 Google社員がサポート開始を通知 Googleからの公式アナウンスは出ていません。 しかしながらGoogleのMariya Moeva（マリヤ・モエヴァ）氏が、JSON-LDのリッチスニペットのサポートを開始したことをGoogl

[レベル: 中〜上級] Googleは、schema.orgを使用したパンくずリストをサポートしました。 これまでは、schema.orgで定義されているもののパンくずリストを表す構造化データとしてschema.orgを利用することはできませんでした。 パンくずリストのドキュメント更新 パンくずリスト (breadcrumbs) の開発者向けドキュメント（英語）が2015年6月12日付で更新され、schema.orgを使ったパンくずリストの記述を説明するようになっています。 以前は、Data-Vocabulary.org を使った例でした。 Data-Vocabulary.orgは、すでに運営維持を停止しその役割をschema.orgに譲っています。 Googleがschema.orgのパンくずリストのサポートを開始したことは、Dan Brickley（ダン・ブリックリー）氏に確認が取れて

[レベル: 上級] Googleは、iOSアプリのApp Indexingのサポートを始めたことをアナウンスしました。 これまでApp IndexingはAndroidアプリだけをサポートしていました。 今後は、Android端末とiPhone（とiPad）の両方からApp Indexingを利用できます。 こちらは、Googleが公式アナウンスで例として掲載したiPhoneでのApp Indexingです。 レストラン予約アプリのOpenTableのディープリンクが検索結果に出ています（左）。 タップすると、OpenTableアプリ内のコンテンツ（そのレストランの情報）に検索結果から直接アクセスできます（右）。 iOSのApp Indexingは、今後数週間をかけて世界中で展開していきます。 GoogleアプリとChromeで利用可能です。 AndroidのApp Indexingと完全

Bloombergが報じたところによると、GoogleとTwitterが提携に合意しました。 この提携によりGoogleは、Twitterに投稿されたツイートの情報を即座に取得し検索結果に反映できるようになります。 両者のエンジニアはすでに開発に着手しているそうで、2015年前半にはツイートが検索結果に表示されると思われます。 初めてではなく2度目の提携 GoogleとTwitterは2009年に一度提携しています。 Googleは、ツイートの生のデータ、通称“Firehose”（ファイヤーホース）にアクセス可能でした。 ツイートを即座に検索結果に反映できます。 しかし2011年に提携は解消されました。 結果として、Googleのリアルタイム検索が消滅します。 提携解消の詳しい理由はいまだに明らかになっていません。 これ以降、Googleはツイートを通常のウェブページと同じようにクロール、

[対象: 上級] この記事では、JSON-LDをシンタックスに用いたschema.orgの記述方法について詳しく解説します。 CSS Niteで講演 2014年9月20日（土）に、CSS Nite LP36 powered by In-house SEO Meetup 「ビジネスに活用できる2014年SEOトレンド」がベルサール神田 イベントホールで開催されました。 僕は出演者として登壇し、セマンティック検索と構造化データ、schema.orgをテーマに公演しました。 このなかで、JSON-LDの使い方についても説明しました。 [撮影：飯田昌之] 参加者には録画した動画とスライドが提供されています。 年内には（無償で）一般公開される予定です。 ですが、JSON-LDを使ったschema.orgをもっともっと多くのサイト管理者に使ってもらうことが僕の希望です。 3か月近くも待たせたくありませ

[対象: 中級] Googleは、Googleブログ検索の提供を終了したようです。 しかし専用のパラメータを付けて検索することで、ブログだけを対象にした検索を引き続き利用可能です。 Googleブログ検索ページは利用不可 www.google.co.jp/blogsearch や www.google.com/blogsearch にアクセスすると404エラーページが返ってきます。 blogsearch.google.co.jp や blogsearch.google.com にはアクセス可能ですがロゴが表示されないおかしなページです（https:// でアクセスすると404）。 検索してもブログ検索ではなくウェブ検索の結果が返ってきます。 検索結果ページの「もっと見る」オプションからも「ブログ」を選択できなくなっています。 どうやらサービスの提供終了の公算が強そうです。 ソーシャルでの言

[対象: 上級] 一般的に言って、Googleにとっては、擬似静的化したURLよりもパラメータが付いた動的なURLのほうが好ましいようです。 動的URLは書き換えずにパラメータを付けたままで GoogleのJohn Mueller（ジョン・ミューラー）氏が、あるSEO関連フォーラムで次のようにコメントしました。 Just wanted to add that from Google’s point of view, the clean, parameterized URL is generally preferred to any unnecessary URL-rewriting. If you want a nice-looking URL-line in search, use breadcrumb markup instead. Googleの観点から付け加えさせてもらうと、わかり

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

[対象: 全員] インドのウェブマスター向け公式ブログが、一般のサイト管理者から投稿があった質問への回答を公開しました。 Matt Cutts（マット・カッツ）氏をはじめ、世界各国のGoogleのサーチクオリティチームのメンバーが答えています。 サーチクオリティチームが回答したウェブマスター向けQ&A【インド編】 Q: ブログ記事の「+1」はランキング要因になっているのか。 リンクはいまでも検索順位の助けになっているのか。+1や言及のようなソーシャルシグナルは、リンクに取って代わることになりそうか。 A: ウェブサイトのランキングを決定するために200以上のシグナルをGoogleは使っている。 本当の人間のユーザーがクリックした+1ボタンは、ランキングと検索結果におけるサイトの表示に影響する数百あるシグナルのうちの1つとして実験されている。 どんなシグナルであっても、検索品質を全体として向

[対象: 上級] Ajaxを利用しているページでは、Googleのクロールやインデックスを考えた場合、pushStateを使ったほうが“#”（ハッシュ）を使うよりも労力が少なくなりそうです。 下の質問にGoogleのMatt Cutts（マット・カッツ）が回答しました。 Ajaxのナビゲーションを管理するために“#!”から“pushState”に更新すべきだろうか？ Googleは両方ともサポートしている。だけどpushStateは特別な設定が不要だしGoogleも余分な処理をしなくて済む。 Matt Cutts氏の答えを一言でまとめると上のようになります。 ここからは僕からの補足です。 #を使ったAjaxページをSEO対応にするのは面倒 一般的に、Ajaxを使ったページではURLに“#”が含まれます。 検索エンジンは#以下をユニークなURL（の一部）として処理しません。 そこでGoogl

[対象: 中〜上級] 僕のブログではてブ数がいちばん多いのはウェブページを高速化するTIPSを解説した記事です（まだ読んでない人はぜひ読んでください！）。 その記事では高速化全般を扱っていましたが、今日の記事ではJavaScriptに的を絞って表示速度をスピードアップできる施策を6つ紹介します。 もともとはSearch Engine PeopleブログのOptimizing JavaScript for Better Web Performanceで説明されていたものです。 記事作者のJoydeep Deb（ジョイディープ・デブ）氏に僕のブログでの転載許可をもらえました (Thanks, Joydeep!)。 逐一の翻訳ではなく、書かれている内容をもとに僕の言葉で解説していきます。 1. HTTPリクエスト削減のためにJavaScriptファイルを1つに統合する ウェブページの表示を高速化

[対象: 上級] ページの表示速度が、Googleのランキングを決める指標として日本を含むインターナショナルで導入されていることがSMX Advanced Seattle 2012で判明しました。 そこで今日は、ウェブページの高速化を取り扱ったセッションをレポートします。 スピーカーは、ECサイトのREIでSEOに携わるJonathon Colman（ジョナサン・コールマン）氏です。 ウェブサイトのパフォーマンス最適化 サイトを高速化する理由 コンバージョン率の最適化 カスタマーエクスペリエンスとカスタマー満足度の向上 直帰率を下げる。 競争率が非常に激しいキーワードでオーガニックからのトラフィックを増やす。 全体的な競争力を高める。 運用費を節約する。 数字で見るページスピード Googleではページスピードが検索の1%に影響している。 ユーザーがページ表示に待てるのは2秒まで。 3秒以