[対象: 中〜上級] Googleウェブマスターツールの「データハイライター」が日本語を含む全言語で利用可能になりました。 昨年12月の公開時には英語版だけの提供でした。 データハイライターは、イベントに関するデータを実際のページを見ながら「タグ付け」できる機能です。 コンサートや演劇、スポーツなどのイベントの名称や日程、開催場所やチケット料金などの情報を簡単な操作で指定できます。 イベント情報は検索結果にリッチスニペットとして表示されることがあります（ナレッジグラフにも利用されるらしい）。 イベント関連データをGoogleに伝えるためには本来ならば、イベントのための構造化マークアップ（schema.orgの例）を用いてHTMLのタグとしてソースに記述しなければなりません。 しかしデータハイライターを使えばHTMLタグを編集しなくてもウェブマスターツールからの画面操作で、ページのなかから、

[対象: 全員] ウェブマスターツール経由でGoogleが送ってくる警告メッセージは何種類あるのか？ どのメッセージを送るかはどうやって決めているのか？ ウェブマスター向けビデオの質問受付中にGoogleモデレーターで僕が投稿した上の質問をMatt Cutts（マット・カッツ）氏が取り上げて回答してくれました。:） いい質問だ。 この時点では、何十万というメッセージを僕たちは毎月送っている。 たくさんの数に聞こえるけれど、Blekkoという検索エンジンは数百万ものスパムページが“毎時間”作られていると見積もっているそうだ。 ウェブの世界はとても大きいからそのうちの数%がスパムだったとしても驚くことじゃない。 だから僕たちはそういったスパムを見つけ出すのに実に多くの時間を費やしている。 そして発見するとメッセージと通知を自動的に送信しているんだ。 何十万ものたくさんの通知を毎月送信している。

[対象: 上級] サイトの所有者を証明するrel=”publisher”の利用をGoogleが推奨し始めたというニュースがこの記事のトピックです。 コンテンツの著者情報を検索結果に表示する機能をGoogleが導入して以来しばらくたちました。 Google（と僕w）が推進してきたせいもあり著者情報表示を自分のサイトに設定するサイト管理者も増えました。 コンテンツ作成者の“顔”を検索結果で見る機会に今は頻繁に出くわします。 著者情報を設定するにはrel=”author”を使うのが一般的です（リンクにパラメータとして付けるかまたはlink要素として設置する）。 ところが、今度はrel=”publisher”の利用をGoogleはプロモーションしてきたようです。 米国のローカル検索の第一人者であるMike Blumenthal（マイク・ブルーメンソール）氏によると、Google+ローカルページを作

[対象: 上級] schema.orgの仕様に従ったパンくずリストの設定方法をこの記事では解説します。 パンくずリストを示すための構造化マークアップを適切に記述していなかったばかりに間違ったパンくずリストがGoogleの検索結果に表示されてしまったというトラブル事例を先日紹介しました。 パンくずリストであることを検索エンジンに伝える構造化データにはいくつか種類がありますが、ここではschema.orgを使います。 公式サイトでのガイダンスはこちらになります。 では行ってみましょう。 下のようなパンくずリストだったとします。 TOP > イタリア料理 > パスタ > カルボナーラ HTMLのソースコードはもっともプレーンな状態だと下のようになります。 <a href="/">TOP</a> > <a href="/italian/">イタリア料理</a> > <a href="/italia

[対象: 中〜上級] Googleアナリティクスのソーシャルレポート機能を使ってサイトに張られている被リンクを調べる一風変わった方法をこの記事では解説します。 【UPDATE】 レポートへのアクセス方法が変わりました。 現在のやり方はこちらの記事を参照してください。 Googleアナリティクスのトラックバックで被リンクを簡単チェック まず左ナビゲーションのメニューから [トラフィック] − [ソーシャル] − [参照元ソーシャルネットワーク] を選択します。 そうするとFacebookやTwitter、はてなブックマークなど自分のサイトのコンテンツが共有されたソーシャルネットワークの一覧が出てきます。 どれでもいいので、どれか1つのソーシャルメディアを選択します。 「ソーシャルメディアを経由した訪問数」のグラフが表示されます。 グラフの上にあるタブでは「ソーシャルメディアからの参照」が初期

[対象: 中級] URLが変わらないタブ切り替え型のページでは初期状態で選択されていないタブに隠れているコンテンツは無視されるかもしれないという情報を昨日の投稿で伝えました。 しかし背景や前後関係が不明だったので本当にそうなのかどうかの結論を出せませんでした。 この発言をしたGoogleのJohn Mueller（ジョン・ミューラー）氏から詳しい説明をもらえたので今日の投稿でフォローアップします。 以下、ジョンさんからの説明の日本語訳です（原文は記事の終わりに転載します）。 状況による。 適切な経験則からすると次のようになる — タブに隠れているコンテンツのために特にあるいはそのコンテンツのためだけにユーザーがやって来たのなら、最初の状態でもっと発見しやすくもっと見やすくしておきたいと思うはずだ。 タブにあるコンテンツがただの“おまけ”の情報の場合、たとえば一般的な情報を載せている製品ペー

[対象: 上級] 今日の記事はECサイトを管理するウェブ担当者向けのトピックです。 schema.orgは、GoodRelationsの構造化データのスキーマを取り入れたことを公式アナウンスしました。 これによりschema.orgを構造化データとして採用した際に、よりきめ細かなECサイト向けのプロパティが入手可能になります。 まず、簡単に補足します。 schema.orgとは、GoogleとYahoo!、Microsoft（と後にYandex）が共同で策定した構造化データの仕様またはそれを取りまとめる組織のことです。 GoodRelationsは馴染みがないと思いますが、Eコマースに特化した構造化データで、販売する商品やサービスに関する非常に豊富なボキャブラリを定義しています。 GoogleはGoodRelationsもサポートしていて、たとえばリッチスニペットを表示するための情報として

[対象: 全員] URLを、日本語ドメイン名で指定してもPunycodeで指定しても同じURLとしてGoogleは認識しPageRankの分散が発生することはない。 英語版ウェブマスター向け公式ヘルプフォーラムでのGoogleのJohn Mueller（ジョン・ミューラー）氏の発言から明らかになります。 すなわち、HTMLのaタグでリンクを貼る際には日本語ドメイン名でそのままURLを記述しても、Punycodeに変換した状態で記述しても別々のURLとしてではなく同じ1つのURLとしてGoogleは処理してくれるのです。 <a href="http://鈴木謙一.jp/">鈴木謙一のホームページ</a> <a href="http://xn--4gq162dxnz36f.jp/">鈴木謙一のホームページ</a> 上は日本語をそのまま書き下はPunycodeに変換して書いています。 見た目は違

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

[対象: 初級] 新しく公開したページを30分位内にGoogleにインデックスさせるにはどうしたらいいか？ こんな質問がWebmasterWorldに投稿されました。 なぜ30分以内にインデックスさせたいんだ？という疑問も出てきますが、質問者は理由にまでは触れていないのでここでは置いておくとしてこの要望を叶えるにはどんな手段が考えられるでしょうか。 インデックスのスピードはさまざまな要因に依存しますね。 このスレッドに書き込まれた返信のコメントと僕の知識・経験から考えると主だった要因は次のようになりそうです。 更新頻度 Ping送信/RSS配信 サイトマップ送信 Fetch as Googleからのインデックス送信 サイトのオーソリティ サイトのタイプ ソーシャルメディアでの共有 それぞれを簡潔に説明します。 Googleのインデックスに影響を与える主だった要因 更新頻度 月に1回更新する

[対象: 上級] サイトに実装している構造化データをGoogleがどのように認識しているかの状態をGoogleウェブマスターツールで確認できるようになりました。 ウェブマスターツールの [最適化] メニューのなかに [構造化データ] というダッシュボード（レポート）ができています。 レポートには以下の3種類があります。 サイト レベル アイテム レベル ページ レベル 1. サイト レベル サイトレベルのレポートは、どんなタイプの構造化データをGoogleが認識しているかを表示します。 Googleがサポートする構造化データは、schema.orgやmicroformats、RDFaなどいくつかありますが、どの仕様のどの型をGoogleが得検出しているかを知ることができます。 2. アイテム レベル アイテムレベルのレポートは、その構造化データがどのページで検出されたかを表示します。 最終

[対象: 中〜上級] 調べる機会があったので忘備録も兼ねた「robots.txtの“Allow”の使い方」の解説が今日のテーマです。 robots.txtは検索エンジンのクローラのアクセスを拒否するために使用します。 英語で「許可しない」を意味する“Disallow”という命令をアクセスを拒否するために用います。 たとえば、以下のようにrobots.txtに記述したとします（ユーザーエージェントを指定する記述は省略してます）。 Disallow: /private/ この場合は、ルートディレクトリのなかにある「private」ディレクトリに含まれているすべてのコンテンツへのクローラのアクセスをブロックできます。 ところが英語で「許可する」を意味する“Allow”という命令をrobots.txtで使用することができます。 よくあるのが次のようなrobots.txtです。 User-Agent

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

[対象: 上級] Googleは、HTTPステータスコードの404と410を現在は区別して取り扱うようになっているようです。 そうは言っても404と410の差異は非常に小さなものになります。 英語版のGoogleウェブマスター向け公式ヘルプフォーラムで投稿のあった質問に対してGoogle社員のJohn Mueller（ジョン・ミューラー）氏が念入りに確認した結果明らかになりました。 we are now treating 410s slightly differently than 404s. In particular, as I mentioned above, when we see a 404 we’ll sometimes want to confirm it to make sure that it’s a permanent removal. With a 410 HTTP

サイトのリニューアルやドメインの移転にあわせてページ構成も変更した際に、不要になって削除するページが出てくる場合があります。 変更後の新しいサイトに対応するページがあるなら301リダイレクトすればいいのですが、ない時はどうしたらいいのでしょうか。 削除したページの被リンクやPageRankを捨ててしまうのはもったいない気がします。 “頭のいい”サイト管理者ならトップページに301リダイレクトしてせっかく貯めた資産をトップページに集めるかもしれません。 ところが、存在しなくなったページを強引にトップページに301リダイレクトして集約する技は多用しない方がよさそうです。 WebmasterWorldのフォーラム管理者のtedsterは次のように説明しています。 I know of several websites that got into ranking trouble by 301 red

[対象: 上級] Ajax利用したコンテンツをGoogleにクロール可能・インデックス可能にさせるための設定方法を今日は取り上げます。 すでにAjaxを理解している人向けなのと自分へのメモを兼ねているのでAjaxに対する細かな説明や用語解説は省きます。 「#」（ハッシュ）がURLに含まれている場合、#以下のURLをGoogleを含む検索エンジンはインデックスしません。 A. http://www.suzukikenichi.com/ajax.html#abc B. http://www.suzukikenichi.com/ajax.html#xyz 上のAとBはどちらも、http://www.suzukikenichi.com/ajax.html というURLをクロールしてインデックスするだけです。 #付きのURLをインデックスすることはありません（終わりに補足説明あり）。 Ajaxでは、

[対象: 上級] 今日の記事は、rel=”prev”とrel=”next”によるページネーションを扱ったかなり難易度が高いトピックになります。 rel=”prev/next”とビューオールページを用いたGoogleが推奨するページネーション処理を確実に理解している状態でないと意味不明でしょう。 Google、ページネーション問題を解決するrel=“next”タグとrel=“prev”タグをサポート開始 Googleが推奨するビューオールページとページ分割のベストプラクティス 僕自身の理解度を深めるための記事とも言えます。 なので今日は興味がある方だけ読んでください。 ページネーションについての処理方法をGoogleのMaile Ohye(マイリー・オイェ)さんがビデオで解説しました。 使用しているスライドと補足説明がWebmaster Centralブログの記事でも公開されています。 マイ

[対象: 中〜上級] ドメイン名の移転のようにURLを変更する時は301リダイレクトを設定するのが鉄則です。 でも無料ブログや無料のホームページスペースなど301リダイレクトを設定できない環境でサイトを運営している人もいます。 そんな時は待機時間を0秒にしたmeta refreshタグかrel=”canonical”タグを使う代替手段が考えられます。 この待機時間なしのmeta refreshとrel=”canonical”との併用についてSEOmozのRand Fishkin(ランド・フィッシュキン)氏とGoogleのMatt Cutts(マット・カッツ)氏がツイートでやり取りしていました。 301を使えないサイトだったとする。待機時間なしのmeta refreshとrel=”canonical”を組み合わせて使ったことのある人はいる？ 検索エンジンにとっては問題ないと思うんだが。 0秒

[対象: 全員] 検索結果に表示されるページのタイトルが、HTMLに記述したtitleタグとは異なりGoogleによって勝手に変更されてしまうことがあります。 このブログでもGoogleによるtitleタグ書き換えについて何度か記事を書いてきました。 検索結果のタイトルをGoogleが激しく書き換える理由 Googleによるtitleタグ書き換えを防ぐ方法 Google社員に4つ質問してみた 〜 rel=prev/next、titleタグ書き換え、不自然リンクへの警告、ツイッターの影響 Google、titleタグ書き換えのアルゴリズムを改善か？ titleタグが修正されてしまう原因は多少は分かっているものの、合点がいかないことも多く対処が難しいのが実情です。 ウェブマスターからの問い合わせやクレームが多いのか、ウェブマスター向け公式ブログでついにtitleタグの書き換えについて説明があり

ベータ版として公開されていたGoogle Analyticsの非同期トラッキングコードが、標準のトラッキングコードになっています。 4月の半ばくらいから移行が始まっていたようで、僕のGAアカウントでも確認できました。 Googleはウェブページの表示速度をランキングアルゴリズムに取り入れたのでこの流れにも沿っていますね。 新規のサイトでは非同期トラッキングコードを導入しましょう。 既存のサイトは面倒かもしれませんが張り替えをおすすめします。 ※ベータ版のコードとも一部変更あり。 読み込み時間の高速化にも役立し正確なデータ取得にも貢献します。 また、非同期トラッキングコードでしか利用できない機能が将来公開されるかもしれません。 貼りつける場所に注意点があります。 以前のトラッキングコードと違い、非同期トラッキングコードは基本的にheadセクション内（head終了タグ直前）に記述します。 co