Google、モバイルファーストインデックス移行の通知をさらに多くのサイトに一斉配信
[レベル: 初級] モバイル ファースト インデックスへの移行が完了した通知を Google はさらに多くのサイトに一斉に配信したようです。 Search Console からの通知でメールボックスがいっぱいになっている人も多いのではないでしょうか。 モバイル ファースト インデックスが有効 初期の頃は一律に英語での通知でしたが、現在の通知は日本語ユーザーに対してはきちんと日本語で送られるようになっています。 Mobile-first indexing enabled for https://www.suzukikenichi.com/blog/ https://www.suzukikenichi.com/blog/ の所有者様 モバイル ファースト インデックスが有効になっているため、スマートフォン用 Googlebot のログでサイトのトラフィックが増加している可能性があります。また、
先見の明があるならAMPよりもPWAに注目!? プログレッシブウェブアプリでウェブサイトのアプリ化が可能に
[レベル: 上級] Android版の Chrome Canary と Chrome Dev でWebAPKの機能を利用できるようになりました。 WebAPKを利用すると、PWA (Progressive Web App: プログレッシブ ウェブ アプリ)を実装したサイトをアプリのように扱うことができます。 WebAPKの設定手順 WebAPKを設定する手順を説明します。 まずChrome (CanaryかDev) でパッケージ化の機能を有効にします（この機能はまだ試験運用中のため）。 次のURLで構成できます。 chrome://flags/#enable-improved-a2hs 『「ホーム画面に追加（改訂版）」機能を有効にする』のセクションです。 設定変更後はChromeの再起動が必要です。 また、セキュリティ設定で「提供元不明のアプリ」の有効化も必要です。 準備が整ったら、Web
Googleがフライト検索とホテル検索をウェブ検索に融合、検索結果からそのまま予約可能に
[レベル: 中級] 検索結果から簡単に旅行を手配できる機能を Google は提供開始しました。 フライトとホテルの両方を検索結果から直接予約することができます。 フライト検索とホテル検索を融合 こちらは、米 Google (google.com) で “trip to sydney”（シドニー旅行）をウェブ検索したときに出る旅行ガイドです。 「EXPLORE」タブには、目的地の説明や人気スポットなどの概要がまとまっています（日本の Google でも旅行ガイドの概要は提供されています）。 ここからが新しい機能です。 旅行ガイドページに「FLIGHTS」タブが追加され、フライト検索できるようになりました。 日付や発着空港を指定してフライトを探せます。 航空会社やアライアンス、搭乗クラスなどの詳細な条件指定も可能です。 条件に見合ったフライトを選択すると、Google 検索から予約サイトにそ
Google、検索結果にコンテンツを投稿できるSNS風サービス”Google Posts”を日本でも開始
[レベル: 上級] Googleは、検索結果にコンテンツを投稿できるサービスを日本でも導入しました。 Google Japan の Search & Developer Partnerships である Duncan Wright（ダンカン・ライト）氏がTwitterでアナウンスしています。 Posts with Google in action in Japan. pic.twitter.com/lEoGzm8VJn — Duncan Wright (@dunc_Can) 2016年12月21日 このサービスの正式名称は不明です。 「Google Posts（グーグル・ポスト）」と呼ばれことが多いようですが、ダンカンさんは「Posts with Google」と表現しています。 Google Postsとは Google Postsとは、Googleが試験的に提供を始めたソーシャルメディ
Googleがモバイル ファースト インデックスを導入予定、影響は？対応は？
[レベル: 中級] 【UPDATE】 この記事は公式発表よりも前に投稿したものです。 Googleから公式発表が出ています。 より具体的な情報は下の記事で説明してます。 Google、モバイルファーストインデックスの導入予定を正式発表。スマホ向けページを検索の評価対象に。SEOへの影響は？ 米ラスベガスで開催されたPubCon Las Vegas 2016でGoogleのGary Illyes（ゲイリー・イリェーシュ）氏は、Mobile First Index（モバイル ファースト インデックス）への移行を計画していることを発表しました。 現在は、PC向けページの評価をもとにして検索結果ができあがります。 対して、モバイル ファースト インデックスでは、モバイル向けページ（スマホ向けページ）の評価をもとにして検索結果ができあがります。 モバイル ファースト インデックスに関してさまざまな情
企業・店舗の電話番号と営業時間のGoogleワンボックスが日本でも表示される
[対象: 上級] 企業や店舗の問い合わせ電話番号や営業時間を表示するワンボックス/アンサーボックスが、日本のGoogle (google.co.jp) でも表示されるようになっていることを確認しました。 電話番号や営業時間のワンボックスは今年4月に導入されましたが、その時点では日本のGoogleでは表示されていませんでした。 問い合わせ電話番号のワンボックス 問い合わせ電話番号のワンボックスの例です。 3つ目の、中小企業であるセルフデザイン（僕が所属している会社です）が出ているくらいなのに、超大手のJCBやANAは出ません。 Googleが情報を取得できていないのかもしれません。 また企業によっては「電話番号」以外にも、「カスタマーサービス」のような一般的に用いられる問い合わせ用電話番号の呼称でも出てくることがあります。 営業時間のワンボックス こちらは営業時間のワンボックスです。 電話番
Google、「スマホ対応」をランキング要因に利用することを決定。4/21から導入。
[レベル: 初・中・上級] Googleは、スマホ対応しているかどうかをモバイル検索のランキング要因として使用することを発表しました。 4月21日からの導入を予定しています。 またApp Indexingに対応したアプリコンテンツもランキング要因として利用するようにしました。 こちらは今日（現地時間の2月26日）から導入されています。 モバイルフレンドリーが単なるラベル表示からランキング要因に 昨年11月に、そのページがスマートフォンに対応しているときに、「Mobile-friendly」（モバイル フレンドリー）というラベルをGoogleはモバイル検索結果に表示するようにしました。 日本には、翌月の12月に導入されました。 「スマホ対応」というラベルが付きます。 導入時点では、「スマホ対応」ラベルは単純に表示だけの仕様でした。 スマホ対応しているかどうかはランキング要因にはなっていません
robots.txtによるサイトマップのクロスサイト送信 » 海外SEO情報ブログ・メルマガ
robots.txtでサイトマップ（サーチエンジン対象のXMLサイトマップ）を送信できる仕組みを、Sitemap Autodiscovery（サイトマップ・オートディスカバリー）といいます。 通常、サイトマップは同じドメインのディレクトリに保存しなければなりません。 たとえば、このブログのサイトマップであれば、www.suzukikenichi.com内のどこかのディレクトリに格納しなければなりません。 しかし、sitemap.orgはサイトマップの仕様を拡張し、サイトマップを任意の場所に保存することができるようになりました。 Sitemap Cross Submission（サイトマップ・クロス・サブミッション、サイトマップ・クロス送信）と言います。 ※定義された明確な用語があるわけではないようです。Cross-host submissionとか、Cross-Domain Sitemap
XMLサイトマップとRSSフィードの両方を送信することをGoogleが公式に推奨
[対象: 中級] 新しいページや更新したページを含めサイト内のすべてのページのクロールを促進するために、XMLサイトマップとRSS・Atomフィードの両方を送信することを、英語版ウェブマスター向け公式ブログでGoogleは推奨しました。 有用性の高い情報なので、早ければ今日にも、日本語版の公式ブログで翻訳記事が公開されるだろうと予測します。 したがってこの記事では、若干の補足を加えつつも要点を簡潔にまとめて解説します。 XMLサイトマップとフィードの違い まずXMLサイトマップとフィードの違いと特徴を知りましょう。 一般的には、単にサイトマップと呼ぶことが多いですね。 普段僕たちがウェブマスターツール（またはrobots.txtのAuto Discovery）で送信する検索エンジン向けのサイトマップです。 サイトマップには通常、Googleにクロール・インデックスさせたいURLをすべて記述
削除したページを単一のページにまとめて301リダイレクトするとソフト404になる
[対象: 中級] 削除したページをいくつも1つのページに301リダイレクトすると、ソフト404としてGoogleには認識されることがあるようです。 複数の古いページを1つのページにまとめてリダイレクトしない 英語版のGoogleウェブマスター向け公式フォーラムで、Google社員のJohn Mueller（ジョン・ミューラー）氏が次のようにコメントしています。 古いページたちを単一のページにリダイレクトすると、ソフト404としてみなされる。これは基本的には、私たちのアルゴリズムにおいては404、「ページが見つかりませんでした」と同じように扱われる。 一般的には、（なくなったURLに対しては）エラーだとはっきりわかるページを使い、404のHTTPステータスコードを返すことが推奨される解決策になる。 内容が古くなったり削除したりしたページをすべてトップページに301リダイレクトすることは、ソフ
Googleウェブマスターツールでドメイン移転の通知が可能に
新しいデザインになったGoogleウェブマスターツールは、古いインターフェイスも利用することができましたが、完全に新しいバージョンに切り替わりました。 Google Webmaster Central Blogで、公式アナウンスがありました。 Out with the old, in with the new 日本では、Googleウェブマスターヘルプ フォーラムでGoogle社員のKyotaro氏が通知しています。 ウェブマスター ツールのデザインが新しくなりました。 もはや古いバージョンを使用することはできず、ウェブマスターツールの通常のURLにアクセスしても新バージョンが表示されます。 ブックマークの更新を忘れずに。 そして、新バージョンへの完全移行と同時に、新しい機能が追加されました。 「アドレスの変更(Change of Address)」という機能です。 「アドレスの変更」を使
301リダイレクトが使えないときの転送方法
ドメインを移転するときには、301リダイレクトを使うのが鉄則です。 しかし、何らかの事情で301リダイレクトが使えないときは、どうしたらいいのでしょう。 301の代替手段として使えるのは、meta refreshです。 meta refreshは、指定した秒数が経過した後、指定したURLへ自動転送することができるHTMLコードで、headセクションに次のように記述します。 <meta http-equiv="refresh" content="●;URL=http://..."> ※「●」は秒数 検索エンジンは、指定する秒数を「0」秒にすることで、301リダイレクトとして処理してくれるようです。 Yahoo!は、インフォセンターで以下のように説明しています。 ●には、転送元から転送先にリダイレクトする場合に要する時間を秒数で記述します。この値を「0」とした場合、YSTは301リダイレクト（
rel=“author” link要素で著者情報をGoogle検索結果に表示させる方法 〜 WordPressプラグインあり
[対象: 中級] 著者情報をGoogleの検索結果で表示させる第4の方法を今日は紹介します。 これまで利用可能な設定方法は次の3とおりでした。 rel=”author”要素とrel=”me”要素を使う rel=authorパラメータを使う メールアドレスを登録する ※1つめは古い方法で今でもサポートされていますが面倒なのでオススメしません。2つめはリンク先ページのタイトルが「自分が管理しないサイトでもコンテンツ著者情報をGoogle検索に表示させる方法」になっていますが自分のサイトでも利用できます。 新たに加わったのは、rel=”author” のlink要素をheadセクション内に記述する方法です。 Googleのヘルプには今のところ載っていない、非公式な設定なのかもしれませんが機能することがJoost de Valk氏によって確認されています。 【UPDATE】サポートを始めたようです
スマートフォン用ページに振り分けるときはrel=”canonical”を設定する
iPhoneやiPad、Android端末の普及でスマートフォン専用のページを用意するサイトも増えてきています。 スマートフォンからのアクセスに対して「リダイレクトによってスマートフォン専用のURLに振り分けるとき」の注意点を今日はお伝えします。 rel=”canonical”タグで、対応するデスクトップ用ページのURLを指定してください。 重複コンテンツの発生を防止するためです。 現状GoogleはデスクトップPCとスマートフォンを区別せず同等に扱います。 スマートフォン用の検索結果も用意していません。 共に、ウェブクローラのGooglebotがクローリングします。 ※従来のモバイル端末はモバイルクローラのGooglebot-Mobileがクローリングします。詳しくはこちらの記事を参照。 スマートフォン用のコンテンツはデスクトップ用のページと、完全ではないにしてもほぼ同じになるはずです。
301リダイレクトを使った「WWWあり」と「WWWなし」の統一
僕のところに、毎月１，２件必ず寄せられる質問があります。 それは、「wwwあり」のURLと「wwwなし」のURLに関する質問です。 もう少し正確に言うと、「wwwあり」と「wwwなし」の統合です。 同じコンテンツを示すURLが、「http://www.example.com/」と「http://example.com/」のように、２つに分かれてしまっている場合があります。 人間にとっては同じでも、検索エンジンにとってはまったく別のページになります。 被リンクが両方に張られていたら分散してしまうし、それよりもなによりも異なるURLで同じコンテンツなので、複製コンテンツとしてマークされてしまう危険も付きまといます。 本来ならサイトの構築を始める前に、「wwwあり」で運用するのか、「wwwなし」で運用するのか決めるべきですが、何らかの事情で分かれてしまっていることもあるでしょう。 そこで、「ww
Twitterの過去のツイートがGoogleで検索可能に
調査会社ではなく自社のデータになりますが、Twitterでは1日に6億回の検索が発生しているそうです Twitter内よりはAPIを通しての検索が大半を占めるようですが、それでもツイートを探す検索が日々大量に実行されていることは間違いない事実でしょう。 個人的にはTwitterの検索はイマイチかななんて感じています。 site:twitter.com で対象ドメインを限定してGoogleでサイト内検索したほうが探しやすかったりします。 ただ日本でもTwitterが爆発的に普及してユーザーが増えてきたことからも想像できるように新しいツイートが次から次へと発信され、膨大な数のツイートが検索結果としてヒットするかもしれません。 過去のツイートが埋もれてしまうこともありえます。 でも期間指定ができれば探しやすくなるかもしれません。 Googleは、過去のツイートを検索可能にする機能をGoogle.
Google Analyticsで本当の直帰率を計測する方法
昨日、鷲見さんが『Google Analyticsの直帰率は評価の指標にならない』という記事を、寄稿してくれました。 Google Analyticsの直帰率は、純粋に１ページだけを見てサイトを離れたユーザーの割合を示しています。 鷲見さんが説明しているように、「直帰率が高い ＝ 悪いこと」とは限りません。 例えば、ブログにフォーカスしてみましょう。 ブログはその特性上、最新の記事だけ読んで、あとはそのブログから離脱するケースも少なくありません。 また、RSS などで更新ごとにブログに訪れるユーザーや、リピートの多いブログであれば、尚更その割合は多くなります。 まさしく、僕のブログにあてはまります。 僕のブログは、通常１日１記事の更新です。 RSSリーダーに登録して新着記事をチェックしたり、毎日お気に入りなどから直接アクセスしたりするユーザーが大勢いてくれます。 リピータになっているので、
Googleでは直帰率とランキングは無関係、 Matt Cuttsが完全否定
直帰率は検索順位に影響を与えるのかどうか、という問題についてGoogleのJohnMu氏は否定しました。 続いて、もっとも有名なGooglerの１人、Matt Cutts氏もSphinnのコメントで、直帰率とランキングの関係を否定しています。 Without reading the article, I’ll just say that bounce rates would be not only spammable but noisy. A search industry person recently sent me some questions about how bounce rate is done at Google and I was like “Dude, I have no idea about any things like bounce rate. Why don’t
MSNbotがJavascriptを読んだ、Googlebotはどうだ？
サーチエンジンのロボットは、Javascriptを認識できるのでしょうか？ 答えは、「YES」でもあり「NO」でもあります。 より正確に言えば、徐々に読めるようになりつつあるというべきかもしれません。 WebmasterWorldのモデレータのincrediBILL氏は、MSN（Live Search）のクローラのひとつ、msnbot-mediaがJavascriptをクロールしたことを、ログの解析から発見しました。 Today I caught MSNBOT-MEDIA crawling thousands of links that were only accessible thru javascript. さらには、Ajaxまでも探すようになってきているらしいとのことです。 I’m assuming that MSNBOT-MEDIA is looking for Ajax data
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
