[対象: 上級] 訪問者が一定時間、たとえば15秒以上滞在したら直帰とはみなさなくするGoogleアナリティクスの設定を今日は紹介します。 英語版のGoogleアナリティクス公式ブログで紹介されていた方法になります。 設定方法は簡単で以下のコードを標準のトラッキングコードに挿入するだけです。 setTimeout("_gaq.push(['_trackEvent', '15_seconds', 'read'])",15000); 追加のコードを挿入した後の完全なトラッキングコードは次のようになります。 <script type="text/javascript"> var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-XXXXXXX-1']); _gaq.push(['_trackPageview']); setTimeout("_gaq

[対象: 全員] スマートフォン端末での表示に最適化されたページがモバイル検索結果に表示されるときに、「スマホ対応」というラベルをGoogleはスニペットに追加するようにしました。 また将来的には、”モバイルフレンドリー”の条件をランキング要因として利用する可能性があります。 「スマホ対応」のラベル スマートフォンで適切に表示できるように最適化してある状態をGoogleは「モバイル フレンドリー (mobile-friendly)」 と呼んでいます。 モバイルフレンドリーなページには、英語の場合は「Mobile-friendly」、日本語の場合は「スマホ対応」というラベルがスニペットの先頭に付きます。 この新しい仕様は、今後数週間かけて世界中で展開してきます。 もちろん日本も含まれます。 僕の環境では、米Googleでは確認できますが日本のGoogleではまだ適用されていません（そんなわけ

[対象: 全員] 米国版のGoogleウェブマスター向け公式ヘルプフォーラムでGoogle社員のJohn Mueller（ジョン・ミューラー）氏がコメントした、Googleウェブマスターツール に関する2つの情報を今日は紹介します。 1. 「HTMLの候補」はrel=“canonical”で正規化したURLも表示する 「HTMLの候補」は、重複したmeta descriptionやtitleタグを通知してくれます。 ところがrel=”canonical”タグを記述して正規化したはずのURLが重複したtitleタグのページの例として表示されることがあるようです。 ミューラー氏は次のように回答しています。 単純に、Googlebotがクロールして発見したURLを「HTMLの候補」は表示しているからだ。rel=”canonical”を使っていても表示する。 つまりrel=”canonical”と

[対象: 初級] サイトマップ（検索エンジンに送信するサイトマップ）にまつわるちょっとした2つのTIPSがこの記事のトピックです。 サイトマップの再クロールの頻度と更新の通知方法 サイトマップでのインデックス確認とサイトマップの分割 GoogleのJohn Mueller（ジョン・ミューラー）氏が（Googleの公式ではない）SEOヘルプフォーラムで投稿したコメントが参照元になります。 Does Google reprocesses submitted sitemaps from time to time? – Pro Webmasters google webmaster tools – Is it possible to find out whether one given page has been indexed? – Pro Webmasters ではそれぞれを見ていきましょう。

[対象: 中級] 新しいページや更新したページを含めサイト内のすべてのページのクロールを促進するために、XMLサイトマップとRSS・Atomフィードの両方を送信することを、英語版ウェブマスター向け公式ブログでGoogleは推奨しました。 有用性の高い情報なので、早ければ今日にも、日本語版の公式ブログで翻訳記事が公開されるだろうと予測します。 したがってこの記事では、若干の補足を加えつつも要点を簡潔にまとめて解説します。 XMLサイトマップとフィードの違い まずXMLサイトマップとフィードの違いと特徴を知りましょう。 一般的には、単にサイトマップと呼ぶことが多いですね。 普段僕たちがウェブマスターツール（またはrobots.txtのAuto Discovery）で送信する検索エンジン向けのサイトマップです。 サイトマップには通常、Googleにクロール・インデックスさせたいURLをすべて記述

[対象: 中級〜上級] Googleは、スマートフォン向けのクローラが使用するUser-Agent（ユーザーエージェント、以下「UA」）を変更する予定であることをアナウンスしました。 これまでは、スマートフォン版クローラのUAとして「Googlebot-Mobile」をGoogleは使っていました。 これを、標準のウェブ版クローラと同じ「Googlebot」に今後3〜4週間後に切り替えます。 スマホ版Googlebotの新しいUser-Agent スマートフォン版Googlebotの新しいUAは以下のようになります。 Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (c

[レベル：中〜上級] ※長い記事になりますが、ものすごく重要な仕組みなので確実に理解してほしい内容です。 ひと続きのコンテンツを複数のページに分割する“Pagination”（ページネーション）によって起こる可能性がある、重複コンテンツ問題に対処するために、rel=“next”要素とrel=“prev”要素のサポートをGoogleが開始しました。 「ページネーション」は、いわゆる「ページ送り」のことです。 一連の長い記事を複数のページに分けたり、多数のカテゴリがある時にいくつかのまとまりに分けたりするときによく使われます。 ページネーションを利用していた場合、rel=”canonical”タグを使って2ページ目より後のページを1ページ目に正規化することをGoogleは推奨していません。 上は僕がセミナーで使ったスライドの一部分です。 詳しいことはブログでも説明しています。 ページネーション

[対象: 上級] この記事では、「DNSプリフェッチ」という仕組みを利用してウェブページの表示速度を高速化する方法を解説します。 DNSプリフェッチとは 上級者向けの記事なのでDNSが何かの説明は省きます。 DNSプリフェッチを利用すると、外部ドメイン名（ホスト名）の名前解決（DNSルックアップ）を事前に強制できます。 ユーザー（ブラウザ）がそのドメインにアクセスする前にすでに名前解決が完了しているので、読み込み時間の短縮を図ることができるのです。 DNSの名前解決にかかる時間は平均して200ミリ秒とわずかですが、モバイル回線では無視できる長さではないかもしれません。 またときとして1秒以上かかることもあり、遅延による表示速度の低下の防止に役立てられます。 DNSプリフェッチは、ページの読み込みと同時に実行されまたCPUやネットワークへの負荷が低いため、そのほかの処理を遅らせてしまう心配も

[対象: 中級] 今日は、スマートフォン向けのサイトを検証するときに便利なツールを2つ紹介します。 レスポンシブ・ウェブデザインでの表示を簡単に確かめられるブックマークレットとスマホでのページ閲覧をシミュレーションするアプリケーションソフトです。 1. レスポンシブ・ウェブデザイン ブックマークレット 1つ目はレスポンシブ・ウェブデザインがどのように機能しているかをチェックするブックマークレットです。 こちらのページにアクセスして「RWD Bookmarklet」というボタン（リンク）をブラウザのお気に入りに追加するか、ブックマークバーにドラッグ&ドロップします。 レスポンシブ・ウェブデザインを確かめたいページでブラウザに追加したそのリンクをクリックすると下のような画面になります。 中央上にある赤枠で囲んだ4つのアイコンをクリックすると解像度を変化させた表示に切り替えることができます。 ア

今日は技術的なトピックを扱います。 通常、ウェブページがもう存在しなくなったときは404のHTTPステータスコードを返します。 するとしらばくすれば検索結果からも消えます。 しかしGoogleウェブマスターツールでは、ずっと以前になくなったはずのページが「クロールエラー」セクションで「見つかりませんでした」として表示されることがあります。 理由は、404エラーを返したページが今でもないままなのか確認するためにGooglebotが再訪問するためです。 404は“Not Found”（見つからない）で、ページがなくなったことではなくアクセスできない状態を示します。 アクセスできない理由は、ページを削除したことではなくネットワークの障害やサーバーの不具合による一時的なものかもしれません。 通常のページよりは頻度が低いですが、その404を返したページを再び訪問して相変わらずないままなのかそれとも再

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

[対象: 全員] Googleは、Googleアカウントのログイン状態にかかわらず、すべてのGoogle検索をHTTPSでの接続つまりSSL検索を利用するように仕様を変更しました。 すでに実施済みです。 僕たちにとってこれが何を意味するかというと、Google検索からのトラフィックの検索キーワードを取得することが不可能になります。 Googleアナリティクスでいうと、「(not provided)」だけになってしまいます。 HTTPSへ強制的にリダイレクト Googleアカウントからログオフした状態で、http://www.google.co.jp/ のように http:// で始まるURLでGoogle検索にアクセスしても、 https:// で始まるURLに強制的にリダイレクトされます。 FirefoxやChromeでは、ブラウザが内蔵しているGoogle検索ツールやアドレスバーからG

[対象: 中〜上級] Googleウェブマスターツールの検索クエリレポートを、Google AdWordsのレポートで表示できるようになりました。 これにより、オーガニック検索つまりSEOと有料広告つまりPPCの、キーワードごとの掲載順位やクリック数、クリック率などを1つのレポートで比較分析できます。 英語版のAdWords公式ブログで1週間前にアナウンスがありました。 日本語版公式ブログではまだアナウンスがありませんが、日本語のヘルプはできあがっています。 有料広告とオーガニック検索結果の成果を測定する – AdWords ヘルプ 実際に設定可能でデータもきちんと出てきます。 設定が完了してからのデータが反映されるため、上のキャプチャは比較するほどには十分な情報が集計できていません。 それでもイメージはつかめるはずです。 （ちなみに、僕が所属する会社の腕利きPPC担当からキャプチャをもら

[対象: 中級] 著者情報をGoogleの検索結果で表示させる第4の方法を今日は紹介します。 これまで利用可能な設定方法は次の3とおりでした。 rel=”author”要素とrel=”me”要素を使う rel=authorパラメータを使う メールアドレスを登録する ※1つめは古い方法で今でもサポートされていますが面倒なのでオススメしません。2つめはリンク先ページのタイトルが「自分が管理しないサイトでもコンテンツ著者情報をGoogle検索に表示させる方法」になっていますが自分のサイトでも利用できます。 新たに加わったのは、rel=”author” のlink要素をheadセクション内に記述する方法です。 Googleのヘルプには今のところ載っていない、非公式な設定なのかもしれませんが機能することがJoost de Valk氏によって確認されています。 【UPDATE】サポートを始めたようです

[対象: 中〜上級] Googleはリッチスニペットテストツールを大きく改良しました。 リッチスニペットテストツールは、リッチスニペットに使われる構造化データが正しく構成できているかを検証し検索結果での表示をシミュレーションするためのツールです。 大きな改良点は次の3つです。 名称を「Structured Data Testing Tool」に変更 ユーザーインターフェイスと結果表示を一新 日本語を含む英語以外の言語にも対応 名称を「Structured Data Testing Tool」に変更 ツールの名前が「Structured Data Testing Tool」に変わりました。 日本語だと「構造化データ テスト ツール」になるでしょうか。 ユーザーインターフェイスと結果表示を一新 UIがガラリと変わりました。 すっきりしていて見やすくなったと僕は感じます。 レシピのリッチスニペッ

[対象: 上級] schema.orgで構造化マークアップしたパンくずリストは、Googleの検索結果のリッチスニペットとしては表示されないことがわかりました。 schema.orgを用いたパンくずリストの設定方法を昨日の記事で解説しました。 しかし認識はされているようだけれど検索結果のリッチスニペットに適用されないっぽいと記事の後半で補足しました。 schema.orgではパンくずリストのリッチスニペットが出ないと木村さんもGoogle+で投稿していたので、Googleの人に尋ねたところ未対応との回答が返ってきたのです。 現状のschema.orgの構造化マークアップによるリッチスニペットのためのパンくずリストをGoogleはサポートしていません。検索結果でパンくずリストを表示させたいなら別の構造化データを利用したほうがいいでしょう。 Googleが悪いわけではなくてschema.org

[対象: 全員] 手動による対策、いわゆる手動ペナルティが与えられているか、与えられている場合はどんな内容なのかをGoogleウェブマスターツールで確認できるようになりました。 日本語でもすでに利用可能です。 Googleウェブマスターツールでの確認方法 「手動による対策」ページヘは、ダッシュボードの「検索トラフィック」からアクセスできます。 手動の対策を受けていないサイト 手動の対策を受けていない場合は、「手動によるウェブスパム対策は見つかりませんでした。」というメッセージだけが表示されます。 通常はこの状態だろうし、この状態でなければいけませんね。 公式アナウンスによれば、Webスパムとして手動の対策を受けインデックス削除されたドメインは直近の分析では、総インデックスのなかの2%未満とのことです。 手動の対策を受けているサイト その2%に含まれている、ウェブスパムとして手動対応を受けて

[対象: 中〜上級] さまざまなモバイル向けサイトの研究中に出くわした、ユーザビリティを大きく損ねる12個の要素をE-consultancyがブログで解説しました。 ユーザビリティの悪化だけではなく、なかにはGoogleのランキングを下げる原因にも繋がるスマートフォンサイトの構成ミスも含まれています。 モバイル対応が必須になっている現在のサイト運営において、とても参考になる記事なので紹介します。 なお直訳ではなく、僕なりの言葉で要点を説明します。 英語がわかる方は原文も読んでください。 モバイルサイトのユーザビリティを損ねる12個の欠陥 1. 突然デスクトップ向けサイトに切り替わる モバイル向けのページを閲覧していたのに、デスクトップ向けページに突然移動させられてしまうサイトは確かにありますね。 モバイル向けのデザインだったのに、ページを移動したら何の前触れもなくPC向けのデザインに切り替

[対象: 上級] Googleアナリティクスのイベントトラッキングを利用してGoogle検索からのトラフィックがあったキーワードの順位を計測する方法をこの記事では紹介します。 GoogleのAnalytics AdvocateであるJustin Cutroni氏がAJ Khon氏に教授した方法になります。 さっそく設定方法からいってみましょう。 以下のコードをheadセクションに挿入します。 <script type="text/javascript"> if (document.referrer.match(/google\.(com|co\.jp)/gi) && document.referrer.match(/cd/gi)) { var myString = document.referrer; var r = myString.match(/cd=(.*?)&/); var ran

サイトのボリュームが大きくなってくると何ページがインデックスされているか気になってくるものです。 インデックスされていないページは検索結果で表示されることがないので、SEOにおいては存在しないに等しいとも言えます。 あなたはインデックスされているURLをどうやって調べていますか？ その数字は正確だと思いますか？ 今日のテーマは、「Googleにインデックスされたページの正確な数」を調べる方法です。 Googleと書きましたが、Yahoo!でもBingでも同じことが言えるはずです。 一言でいうと、そんな方法はありません（タイトルが“釣り”っぽくてゴメンナサイ）。 インデックス数を調べる2つの定番手段についてその注意点を説明します。 “site:”コマンド インデックスを調べるのに真っ先に思いつくのが、”site:”コマンドです。 しかし、”site:”コマンドは何度も言っているように信頼でき