Google ウェブマスター向け公式ブログ

災害時、急激なアクセス集中に備えてウェブマスターができること

14 years 2ヶ月 ago
台風や大雨、地震などの災害時には多くの方が災害情報や交通情報、避難所や防災マップといった緊急情報を確認するため、特定のサイトに突発的にアクセスが集中することがあります。こうした急激なアクセスの集中は、時にサーバーの処理能力を超え、サイトをダウンさせてしまいます。サイトがダウンしてしまうと、災害情報などの緊急情報を提供できなくなり、より多くの混乱を引き起こしてしまうでしょう。

突発的なアクセスの集中は避けることは難しいですが、あらかじめそれに備えることでサイトのダウンを防ぐことが可能です。そこで今回は、災害時などの急なアクセス集中に備えてできる比較的簡単な対策をご紹介したいと思います。
  • 軽量化したサイトを別途用意する
    災害時に備え、軽量化したサイトをあらかじめ別途用意しておきましょう。災害時にはその軽量化したサイトに置き換えます。しかし普段は使わないページを用意し、いざという時のために管理し続けるというのは負担が大きいかもしれません。そこで例えば携帯電話向けのサイトを用意し、災害時には携帯電話向けに提供しているページを PC 向けに提供するのもひとつのアイディアです。また、特にアクセスが集中するのは主にトップページであるケースが多いのではないでしょうか。そこで全ての代替ページを用意するのではなく、トップページのみ軽量化したページを用意しておき、リンク先は携帯電話向けのページにリンクするようにすることで、災害時にはトップページのみ差し替えるだけで大幅にサーバーの負荷を軽減することができます。

    軽量化のポイントは、
    • 画像やフラッシュなどの装飾的な要素は極力外し、メニューやナビゲーションなどの画像ファイルはテキストに置き換え、HTML を中心に作成する。
    • 動的なページはサーバーの負荷が高いため静的な HTML ページを用意する(情報は手動で更新します)。
  • なるべく軽いファイル形式で提供する
    データのサイズはなるべく小さくなるように心がけましょう。例えば提供する情報が文字情報の場合、ファイルサイズが大きくなる PDF ファイルなどでの情報の提供は避け、テキストデータなどの軽いデータで提供するようにしましょう。例えばこちらの PDF ファイルリッチテキストファイル をダウンロードして比較してみてください。中身はほぼ同じ内容ですが、ファイルサイズは PDF が 180KB、テキストファイルは 37KB と、テキストファイルの方が圧倒的に軽いことがわかります。

    また、同じ PDF ファイルでも、画像データから作成した PDF よりも、テキストエディタ等からテキストデータを保持したまま作成した PDF の方がデータが軽くなります。また、テキストデータを保持したまま作成された PDF は検索結果に表示されやすくなります ので PDF を作成する際は画像データから作成するのではなく、テキストデータを保持した形で作成することをお勧めします。
  • 表や数値データは CSV や XML などの形式でも用意する
    表や数値データは CSV や XML 形式のファイルでも用意しましょう。これらの形式のファイルは、比較的サイズが小さくなり、また、そのデータを利用して外部の開発者が別の災害情報サービスを提供することが可能になり、より多くの人に情報を届けることができるようになるためです。
  • サードパーティのサービスを活用する
    サードパーティのサービス等を利用し、災害時に参照される情報を中心にミラーサイトを作成することも一つの方法です。Google では Google サイトBlogger といったサービスを無料でご利用いただくことが可能です。
また、万が一サイトがダウンした場合でも Google では公的なサービスを提供するサイトについてはキャッシュデータを検索結果に表示し、ユーザーが閲覧できるようにしています。このサービスへのご登録は、こちらから お申し込みください。なお、こちらのご登録に関しましては、 go.jp ドメインのサイトや地方公共団体、各種公共サービスなど、公共性の高い非営利サイトに限らせていただきます。また、お申し込みからご登録まで少々お時間がかかりますのでご了承ください。

今回ご紹介しました対策についてのご質問は、ウェブマスター ヘルプ フォーラム へお寄せください。※災害時の問い合わせ窓口ではありませんのでご注意ください。

ページ スピード サービス - ウェブ パフォーマンスを高速化

14 years 2ヶ月 ago
2 年前、Google は ページ スピード ブラウザ拡張機能(英語) をリリースし、今年に入ってからは Page Speed Online API(英語) をリリースしました。これらを通して、デベロッパーの皆さまにウェブページ高速化のための具体的な提案を行っています。昨年には、mod_pagespeed(英語) という Apache モジュールをリリースしました。これは、自動的にウェブページを書き換えるものです。ウェブマスターの皆さまのさらなる負担の軽減と、面倒なインストール作業を不要にするために、ページ スピード関連の最新のテクノロジーである ページ スピード サービス(英語) をリリースしました。

ページ スピード サービスとは、ウェブページの読み込みを自動的に高速化するオンライン サービスです。このサービスを使用するには、お申し込みのうえ、サイトの DNS エントリが Google を指すように設定していただく必要があります。ページ スピード サービスによって、ウェブ サーバーからコンテンツが読み取られ、ウェブ パフォーマンス向上のためのベスト プラクティスが適用されたページに書き換えられます。この書き換えられたページが、世界中の Google のサーバーを経由してエンド ユーザーに提供されます。ウェブサイトのユーザーから見ると、サイトへのアクセス方法はそれまでと同じですが、ページの読み込みが高速になります。これで、ウェブマスターの皆さまは CSS の短縮化や、画像圧縮、キャッシング、gzip によるリソース圧縮などのウェブ パフォーマンス向上のためのベスト プラクティスに悩む必要はなくなります。

Google が実施した高速化のテストでは、概ねのサイトで 25% から 60%(英語) の改善が実証されています。ただし、効果はサイトごとに異なるので、皆さまのサイトが実際にページ スピード サービスによってどれだけ高速化されるかを 測定(英語) してみてください。この結果を見て、十分な効果が期待できるようであれば、こちらから ページ スピード サービスにお申し込み(英語) ください。そうでない場合は、しばらくしてからもう一度測定してみてください。Google では今後も、このサービスに改善を加えていく予定です。

現時点では、ページ スピード サービスは少数のウェブマスター様のみにご提供しています(無料)。手頃な料金でご利用いただけるようにする予定であり、詳細は後日発表いたします。このサービスへのアクセスをご希望の場合は、こちらのウェブ フォーム(英語) からお申し込みください。

検索結果における PDF ファイルの取り扱いについてのヒント

14 years 2ヶ月 ago
Google の使命は、世界中の情報を整理し、世界中の人々がアクセスできて使えるようにすることです。この使命を遂行するなかで、時として HTML 形式以外のファイル、たとえば PDF、表計算、プレゼンテーション用スライドといった形式のファイルに遭遇することがあります。ファイル形式が違うからといって、Google のアルゴリズムに支障が生じることはありません。Google では、関連性の高いコンテンツを抽出し、適切なインデックス登録を行って検索結果に反映させるよう取り組んでいます。このようなファイル形式は、標準的な HTML 形式とは大きく異なるものですが、実際にはどのようにインデックス登録されているのか、どういったガイドラインが設けられているのか、そしてファイルをインデックスに登録して欲しくない場合には、ウェブマスターの皆様はどうしたらよいか、ご存知でしょうか?

Google は 2001 年に PDF ファイルのインデックス登録を開始(英語)し、現在では 数億件もの PDF ファイルがインデックスに登録されています。今回は、PDF のインデックス登録に関して、よく寄せられる質問とその回答をまとめてみました。

質問: Google では、どんな形式の PDF ファイルでもインデックス登録できるのですか?
答え:一般的に、各種文字コードを使用した PDF ファイルに含まれているテキスト コンテンツは、どのような言語で書かれていようと、そのファイルがパスワード保護または暗号化されている場合を除き、インデックスに登録できます。テキストが画像として埋め込まれている場合は、Google ではその画像を OCR (英語)アルゴリズムで処理し、テキストを抽出することができます。簡単に言うと、PDF 文書内のテキストをコピーして、標準的なテキスト文書にペーストできるのであれば、そのテキストはインデックス登録が可能です。

質問: PDF ファイル内の画像はどうなるのですか?
答え: 現時点では、PDF ファイル内の画像はインデックスには登録されません。画像をインデックス登録するには、その画像用の HTML ページを作成する必要があります。ご自分のサイトの画像が検索結果に含まれる可能性を高めたい場合は、ヘルプ センター に記述されているアドバイスを参考にしてください。

質問: PDF 文書内のリンクはどのように取り扱われるのですか?
答え: 一般に、PDF ファイル内のリンクは HTML 内のリンクと同じように扱われます。つまり、リンクから PageRank をはじめとするインデックス登録のシグナルが渡されるので、Google は、その PDF ファイルをクロールしたのち、リンクをフォローできるようになります。現在のところ、PDF ファイル内のリンクに対しては nofollow 属性は設定できません。

質問: PDF ファイルを検索結果に表示させないようにするにはどうしたらいいですか?既に検索結果に表示されている場合は、どのようにしたら削除できますか?
答え: PDF 文書を検索結果に表示させないようにする一番簡単な方法は、そのファイル用の HTTP ヘッダーに X-Robots-Tag: noindex を追加するという方法です。既にインデックスに登録されている場合は、X-Robot-Tag で noindex を指定すれば、しばらく時間が経つとインデックスから除外されていきます。早急に削除したい場合は、Google ウェブマスター ツールの URL 削除ツール を使用してください。

質問: PDF ファイルでも検索結果の上位にランクされますか?
答え: もちろんです。通常、他のウェブサイトと同じようにランキングされます。たとえば、[mortgage market review]、[irs form 2011]、[paracetamol expert report] で検索してみると、いずれも検索結果の上位に P
DF 文書が表示されます(注: この記事の作成時点)。 これは、文書の内容と、サイトへの埋め込み方法、そして他のウェブページからのリンク状況に基づいた結果です。

質問: ページを HTML と PDF の両方の形式で提供していると、重複コンテンツと見なされるのでしょうか?
答え: できれば、コンテンツは 1 つだけにすることをお勧めします。それが難しい場合は、どちらのバージョンを優先するのかを必ず示すようにしてください。その方法としては、サイトマップに優先 URL を含める方法や、HTML 内または PDF 文書の HTTP ヘッダー 内で canonical (優先)バージョンを設定する方法などがあります。詳しくは 正規化 に関するヘルプ センターの記事を参照してください。

質問: 検索結果に表示される PDF 文書のタイトルはカスタマイズできますか?
答え: 表示するタイトルの生成には、ファイル内のタイトル メタデータとその PDF ファイルを指すリンクのアンカー テキストという 2 つの主要要素を使用しています。Google のアルゴリズムに対して、適切なタイトルを示したい場合は、上記要素を両方ともアップデートすることをお勧めします。

詳しくは、Matt Cutt による動画 PDF ファイルを検索用に最適化する(英語)をご覧ください。また、インデックスに登録できるコンテンツ形式については、ヘルプ センターでご確認いただけます。ご質問やご意見がありましたら、ウェブマスター ヘルプ フォーラムへお寄せください。

Google Chrome でサイトをうまく表示する方法

14 years 3ヶ月 ago
Google Chrome が 2008 年 9 月にリリースされて以降、すでに多くの皆様に利用していただけるようになっておりますが、残念ながらいくつかのサイトが正しく表示されないという声がまだ聞かれます。サイトが正しく表示されないのは、もちろん Google Chrome 側の不具合が原因であることもありますが、一方でサイトがある特定のブラウザだけを対象にしている場合や Web 標準に沿わない形でサイトがデザインされていることもあります。

今までに、どうしたら Google Chrome でサイトを正しく表示させられるのか、ということに関してたくさんの質問がウェブマスターやデベロッパーのみなさんから寄せられました。今回は、このためのヒントをいくつかご紹介します。

Google Chrome を検出するためには

多くの場合、Safari と Google Chrome でサイトは同じように見えます。なぜならこれらは両方とも WebKit (英語)ベースのブラウザだからです。もしあなたのサイトが Safari で正しく表示されているのなら、Google Chrome でも同様に正しく表示 されるはずです。

サイトによっては Chrome が他のブラウザと混同されてしまうことも少なくありません。Safari では正しく表示されているサイトが Chrome で正しく表示されないのならば、そのサイトが Chrome のユーザー エージェント文字列を認識していない可能性があります。

Google Chrome のユーザー エージェント文字列は次のようになります。

Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/W.X.Y.Z Safari/534.24

Chrome 11 におけるユーザー エージェント文字列の変更 - Google Japan Developer Relations Blog で紹介したように、Chrome 11 より変更になっていますので、ご注意ください。

ユーザー エージェントのタイプを検出したいのであれば、次の JavaScript が WebKit での検出に使えるでしょう。

var isWebkit =
navigator.userAgent.indexOf("AppleWebKit") > -1;

そうではなく、もし WebKit が特定のバージョン以上であることを確認したいのならば、以下の新しい機能が使えるでしょう。

var webkitVersion =

parseFloat(navigator.userAgent.split
("AppleWebKit/")[1]) ||
undefined;
if (webkitVersion && webkitVersion > 500 ) {
// WebKitの素晴らしい機能を使う
}

Google Chrome が利用している WebKit のバージョンは Ominibox に “about:version” と入力することで得ることができます。

一般的に、WebKit や Google Chrome を検出するために "Google" や "Apple" といった文字列を navigator.vendor に加えることはお勧めしません。なぜならそうしてしまうと、他の Webkit や Chromium をベースとしたブラウザを検出できなくなってしまうからです!

WebKit の検出の詳細については、webkit.org (英語)をご覧ください。


その他のヒント
  • Google Chrome は Active X プラグインをサポートしていませんが、NPAPI プラグインはサポートしています。つまり、Google Chrome では Firefox や Safari と同じように Flash や Java といったプラグインのコンテンツを見せることができます。
  • もしあなたのサイト上のテキストがうまく表示されていない場合は、適切なコンテンツ タイプと文字コードの情報を HTTP レスポンス ヘッダーもしくはページの始めや セクションのなるべくトップに近いところで記載していることを確認してください。
  • ブロックレベル要素をインライン要素の中に書かないようにしましょう。
    • 誤った例: <a><div>こちらは正しく表示されません。</div></a>
    • 正しい例: <div><a>こちらは正しく表示されます。</a></div>
  • もし JavaScript が Google Chrome でうまく動かないようでしたら、Chrome に組み込まれている JavaScript ツールやデベロッパーツールを使ってデバッグを行うことができます。
  • あなたのページで使っている文字セットは Official IANA LIst に準拠している必要があります。表の preferred MIME name の名前をご使用ください。
    例: ISO-8859-1, Shift_JIS
  • HTTP Header と Meta tag で異なる文字エンコーディングを指定している場合、Google Chrome は、HTTP Header の指定を優先的に使用します。HTTP Header と Meta tag で異なる文字エンコーディングを指定することはトラブルの原因になります。詳しい情報は、The WHATWG Blog — The Road to HTML 5: character encoding(英語)を御覧ください。
  • 基本的に文字エンコーディングは UTF-8 を使用されることをお勧めしています。何らかの理由により、旧来の文字エンコーディングを使用する必要がある場合は、これまでご紹介した内容を踏まえているかをご確認の上使用してください。
この記事に関するコメントやご質問は、ウェブマスター ヘルプフォーラム までお寄せください。

ウェブマスター ツールの内部リンクと外部からのリンクの取り扱いを変更しました

14 years 3ヶ月 ago
ウェブマスター ツールではサイトへのリンクを、外部のサイトからのリンクサイト内からのリンク の 2 種類に分類していますが、この度 ウェブマスター ツール 内のリンク データのカテゴリ分けを変更しました。今回の変更によって、リンクの合計数が変わることはありませんが、どれがサイト内からのリンクで、どれが外部のサイトからのリンクか、より実情に近いものになるのではないかと思います。

ウェブマスター ツールでは、ドメイン名のみ(example.com)、サブドメイン(www.example.com や cats.example.com)、サブディレクトリを含むドメイン(www.example.com/cats/ や www.example.com/users/catlover/)といった様々な種類のサイトを管理できます。従来は、ウェブマスター ツールに登録したサイトの URL から始まる URL のリンクのみが内部リンクに分類されていました。たとえば、www.example.com/users/catlover/ をサイトとして追加していた場合、URL が www.example.com/users/catlover/ から始まる www.example.com/users/catlover/profile.html からのリンクは内部リンクのカテゴリに入っていましたが、www.example.com/users/ や www.example.com からのリンクは外部リンクに分類されていました。また、登録したサイトが www.example.com だった場合、example.com からのリンクは外部からのリンクと見なされていました。リンクの URL がサイトと同じ URL から始まっていないためです(www が欠けています)。

しかし、最近では example.com と www.example.com は同じサイトとして扱われることが多くなってきました。そこで、example.com または www.example.com のどちらかをサイトに追加していれば、リンクのドメインに www が付いていてもいなくても内部リンクのカテゴリに分類されるように変更しました。また、他のサブドメインからのリンクも内部リンクに含めるようにしました。ドメインを管理している方は多くの場合、サブドメインも管理しているからです。したがって、cats.example.com や pets.example.com からのリンクも www.example.com の内部リンクとなります。

www.google.com へのリンク 外部リンク 内部リンク
従来のカテゴリ分けでは... www.example.com/
www.example.org/stuff.html
scholar.google.com/
sketchup.google.com/
google.com/
www.google.com/
www.google.com/stuff.html
www.google.com/support/webmasters/
新しいカテゴリ分けでは... www.example.com/
www.example.org/stuff.html
scholar.google.com/
sketchup.google.com/
google.com/
www.google.com/
www.google.com/stuff.html
www.google.com/support/webmasters/

ただし、サイトがサブドメイン上(例: googlejapan.blogspot.com )やサブディレクトリ(例: www.google.com/support/webmasters/)内にあり、ルート ドメインにはない場合、内部リンク内にはそのサブドメインやサブディレクトリからのリンクのみが表示され、それ以外はすべて外部リンクとみなされます。これらの数がより正確になるように、いくつかの変更を加えています。

注意していただきたいのは、example.com や www.example.com などのルート ドメインでは今回の変更に伴って外部からのリンクの数が少なく表示される可能性があることです。これは前述のように、従来は外部リンクに分類されていた一部の URL が内部リンクに分類されたためです。リンクの合計数(内部リンク + 外部リンク)は、今回のアップデートの影響を受けません。

この記事に関するコメントやご質問は、ウェブマスター ヘルプフォーラム までお寄せください。

ウェブサイトがハッキングされた、さあどうする? - サイトがハッキングされた場合の対応方法

14 years 3ヶ月 ago
[本記事は 2008 年に公開された記事の抄訳です。また、ウェブマスター ツール ヘルプページで サイトがハッキングされた、またはマルウェアに感染した場合 の対処方法が掲載されていますが、日本でもハッキングの事例が増えてきているため、改めてご紹介します。]

ウェブサイトのハッキング被害は多くのウェブマスターが経験することで、気をつけて予防策を講じていたとしても発生してしまうことがあるものです。予防のためのアドバイスとしては、最新のソフトウェアやパッチで常にサイトをアップデートしておくこと、Google ウェブマスター ツール に登録して 、インデックスの状態をチェックすること 、ログファイルに目を配り、不審な動きが見られないか確認しておくことなどが挙げられます。(さらに詳しい情報は、2007 年に掲載した「Quick Security Checklist」(英語)の記事にまとめてあります。)

それでは、ハッキングされた時、どうすればいいでしょうか? サイトをハッキングされたときに最初にすべきことは、ホスティング サービスを利用している場合はそこに連絡をすることです。多くの場合、技術的に困難な作業のほとんどはホスティング サービス業者が対応してくれます。ウェブマスターの多くは共有ホスティング サービスを利用していますが、その場合以下に挙げていることを実行するのが困難な場合があります。アスタリスク(*)のついたアドバイスは、共有ホスティング サービスを利用しているウェブマスターのみなさんが、ホスティング サービス業者の協力を必要とする可能性が高いものです。サーバーに対して完全な管理権を所有している場合は、以下の 4 つの原則に従うことをお勧めします。

サイトをオフラインにする
  • サイトを一時的に、少なくとも問題を解決できたと確信できるまでは、オフラインにします(ネットワークから切り離します)。*
  • オフラインにできない場合は、クロールされないように 503 ステータス コード を返すよう設定します。
  • ウェブマスター ツールの URL 削除ツール を使用して、侵入者によって追加された可能性のあるページや URL を検索結果から削除します。こうすることで、ユーザーがハッキングされたページを閲覧してしまうことを防ぎます。
被害を分析する
  • ハッカーの侵入目的が何だったのかを把握するすることは重要です。
    • 狙いは機密情報でしょうか?
    • 他の目的のためにサイトを乗っ取ろうとしたのでしょうか?
  • ウェブサーバー上で、改変またはアップロードされたファイルを探しましょう。
  • サーバー ログから、ログイン認証の失敗、コマンドの履歴(特に root で実行されたコマンド)、不明なユーザーアカウントなどの不審な活動をチェックしましょう。
  • 被害の範囲を特定します。他にも影響を受けたかもしれないサイトはありませんか?
復旧する
  • 最善策は、信頼できるソースから OS を完全に再インストールすることです。ハッカーによる被害をすべて確実に取り除くには、これ以外に方法はありません。*
  • 再インストールが完了したら、最新のバックアップを使用してサイトを復旧します。この際、バックアップがハッキングの影響を受けていないことを必ず確認しましょう。*
  • インストールされたソフトウェアにパッチを当てて最新版にします。ブログ プラットフォーム、コンテンツ マネージメント システムや、その他サードパーティによるソフトウェアなどすべてが対象となります。
  • パスワードを変更します。
オンラインへの復帰
  • ウェブサイトを再びオンラインにします。
  • ウェブマスター ツールを使用している場合は、
    • サイトにマルウェアが存在すると検知された場合は、これらが排除されたかどうかを判断するために調査を申請してください。詳しい情報はヘルプ記事「 サイトがハッキングされた、またはマルウェアに感染した場合 」の「4: Google にサイトの再審査を依頼する」をご覧ください。
    • インデックスに入れたい URL に対して URL 削除ツールを使用した場合は、ウェブマスター ツールで削除を取り消してください。
  • ハッカーが再びサイトを攻撃する可能性がありますので、不審な動きに注意してください。
その他の質問と回答:

Q: クロールを防ぐためには、サイトをオフラインにするのと robots.txt を使用するのとでは、どちらが良いですか?
A: オフラインにする方が良いでしょう。マルウェアやバッドウェアがサイトの閲覧者に感染したり、ハッカーがサイトをさらに不正利用したりすることを防ぐことができます。

Q: サイトの問題解決後、どうしたら迅速に再度クロールしてもらえますか?
A: サイトがハッキングされたかどうかに関わらず、こちらの ヘルプ記事 にある手順を踏んでください。

Q: サイトをクリーンアップしましたが、ハッカーによって悪いサイトへリンクされていた場合、検索順位に影響はあるのでしょうか?
A: Google でもそのような事態は望んでいません。ハッカーやスパマーの行為によって、良いサイトの検索順位などに影響が出ないように務めています。念のために、ハッカーが追加した可能性のあるリンクは完全に削除してください。

Q: 自宅のコンピュータがハッキングされた場合はどうしたらいいですか?
A: その場合も、上記の対策が適用できます。復旧には細心の注意を払ってください。注意を怠ると、同様の被害が再発してしまう可能性が高くなります。OS を再インストールするのが最善です。

その他の役に立つ情報:
  • サイトが Google によってマルウェアに感染していると検知された場合、ウェブマスター ツール のページに警告メッセージを表示しますので、あらかじめウェブマスター ツールに登録しておくことを強くお勧めします。
  • Matt Cutts がブログに投稿した「Three tips to protect your WordPress installation」(英語)という記事にも実用的なコメントが多く寄せられています。
この記事に関するコメントやご質問は、ウェブマスター ヘルプ フォーラム までお寄せください。

ウェブサイトがハッキングされた、さあどうする? ー サイトがハッキングされた場合の対応方法

14 years 3ヶ月 ago
[本記事は 2008 年に公開された記事の抄訳です。また、ウェブマスター ツール ヘルプページで サイトがハッキングされた、またはマルウェアに感染した場合 の対処方法が掲載されていますが、日本でもハッキングの事例が増えてきているため、改めてご紹介します。]

ウェブサイトのハッキング被害は多くのウェブマスターが経験することで、気をつけて予防策を講じていたとしても発生してしまうことがあるものです。予防のためのアドバイスとしては、最新のソフトウェアやパッチで常にサイトをアップデートしておくこと、Google ウェブマスター ツール に登録して 、インデックスの状態をチェックすること 、ログファイルに目を配り、不審な動きが見られないか確認しておくことなどが挙げられます。(さらに詳しい情報は、2007 年に掲載した「Quick Security Checklist」(英語)の記事にまとめてあります。)

それでは、ハッキングされた時、どうすればいいでしょうか? サイトをハッキングされたときに最初にすべきことは、ホスティング サービスを利用している場合はそこに連絡をすることです。多くの場合、技術的に困難な作業のほとんどはホスティング サービス業者が対応してくれます。ウェブマスターの多くは共有ホスティング サービスを利用していますが、その場合以下に挙げていることを実行するのが困難な場合があります。アスタリスク(*)のついたアドバイスは、共有ホスティング サービスを利用しているウェブマスターのみなさんが、ホスティング サービス業者の協力を必要とする可能性が高いものです。サーバーに対して完全な管理権を所有している場合は、以下の 4 つの原則に従うことをお勧めします。

サイトをオフラインにする
  • サイトを一時的に、少なくとも問題を解決できたと確信できるまでは、オフラインにします(ネットワークから切り離します)。*
  • オフラインにできない場合は、クロールされないように 503 ステータス コード を返すよう設定します。
  • ウェブマスター ツールの URL 削除ツール を使用して、侵入者によって追加された可能性のあるページや URL を検索結果から削除します。こうすることで、ユーザーがハッキングされたページを閲覧してしまうことを防ぎます。
被害を分析する
  • ハッカーの侵入目的が何だったのかを把握するすることは重要です。
    • 狙いは機密情報でしょうか?
    • 他の目的のためにサイトを乗っ取ろうとしたのでしょうか?
  • ウェブサーバー上で、改変またはアップロードされたファイルを探しましょう。
  • サーバー ログから、ログイン認証の失敗、コマンドの履歴(特に root で実行されたコマンド)、不明なユーザーアカウントなどの不審な活動をチェックしましょう。
  • 被害の範囲を特定します。他にも影響を受けたかもしれないサイトはありませんか?
復旧する
  • 最善策は、信頼できるソースから OS を完全に再インストールすることです。ハッカーによる被害をすべて確実に取り除くには、これ以外に方法はありません。*
  • 再インストールが完了したら、最新のバックアップを使用してサイトを復旧します。この際、バックアップがハッキングの影響を受けていないことを必ず確認しましょう。*
  • インストールされたソフトウェアにパッチを当てて最新版にします。ブログ プラットフォーム、コンテンツ マネージメント システムや、その他サードパーティによるソフトウェアなどすべてが対象となります。
  • パスワードを変更します。
オンラインへの復帰
  • ウェブサイトを再びオンラインにします。
  • ウェブマスター ツールを使用している場合は、
    • サイトにマルウェアが存在すると検知された場合は、これらが排除されたかどうかを判断するために調査を申請してください。詳しい情報はヘルプ記事「 サイトがハッキングされた、またはマルウェアに感染した場合 」の「4: Google にサイトの再審査を依頼する」をご覧ください。
    • インデックスに入れたい URL に対して URL 削除ツールを使用した場合は、ウェブマスター ツールで削除を取り消してください。
  • ハッカーが再びサイトを攻撃する可能性がありますので、不審な動きに注意してください。
その他の質問と回答:

Q: クロールを防ぐためには、サイトをオフラインにするのと robots.txt を使用するのとでは、どちらが良いですか?
A: オフラインにする方が良いでしょう。マルウェアやバッドウェアがサイトの閲覧者に感染したり、ハッカーがサイトをさらに不正利用したりすることを防ぐことができます。

Q: サイトの問題解決後、どうしたら迅速に再度クロールしてもらえますか?
A: サイトがハッキングされたかどうかに関わらず、こちらの ヘルプ記事 にある手順を踏んでください。

Q: サイトをクリーンアップしましたが、ハッカーによって悪いサイトへリンクされていた場合、検索順位に影響はあるのでしょうか?
A: Google でもそのような事態は望んでいません。ハッカーやスパマーの行為によって、良いサイトの検索順位などに影響が出ないように務めています。念のために、ハッカーが追加した可能性のあるリンクは完全に削除してください。

Q: 自宅のコンピュータがハッキングされた場合はどうしたらいいですか?
A: その場合も、上記の対策が適用できます。復旧には細心の注意を払ってください。注意を怠ると、同様の被害が再発してしまう可能性が高くなります。OS を再インストールするのが最善です。

その他の役に立つ情報:
  • サイトが Google によってマルウェアに感染していると検知された場合、ウェブマスター ツール のページに警告メッセージを表示しますので、あらかじめウェブマスター ツールに登録しておくことを強くお勧めします。
  • Matt Cutts がブログに投稿した「Three tips to protect your WordPress installation」(英語)という記事にも実用的なコメントが多く寄せられています。
この記事に関するコメントやご質問は、ウェブマスター ヘルプ フォーラム までお寄せください。

リニューアルされたサイトリンクのご紹介

14 years 3ヶ月 ago
Google は先日、検索結果の更なる品質向上を図るため、サイトリンクをアップデート(英語)しました。サイトリンクとは、一部の検索結果や広告の下部に表示される 2 列のリンクのことで、ユーザーはこのサイトリンクを通じてサイトの深い階層にあるページに直接アクセスすることができます。尚、今回のアップデートでもサイトリンクの基本は変わらず、サイトのリンク構成に基づき、アルゴリズムによって作成および順位付けされ、特定の検索ワードに対して有用な場合のみ表示されます。

今回のアップデートによるサイトリンクの改善点は、次の通りです。:
  • 見やすく:リンクのテキストはフルサイズになり、通常の検索結果と同様に、緑色のURLおよび 1 行のスニペットが追加で表示されます。これによって、個々のサイトリンクおよびメインのサイトがより目立つことになり、検索ユーザーの目に止まりやすくなります。
  • 柔軟に:これまで、各サイトのサイトリンクのセットは固定されており、それら全てが表示される、もしくは全く表示されないの二者択一で、特定の検索ワードによってこの一覧の表示順が変動することはありませんでした。今回のアップデートで、表示されるサイトリンクおよびその表示順は検索ワード次第で変動するようになり、より最適な検索結果を提供できるようになりました。更に、サイトリンクの最大表示数が 8 から 12 に引き上げられ、表示される数も検索ワード次第で変化するようになりました。
  • わかりやすく:これまでは、サイトリンクが表示されているサイト内のページがサイトリンクだけでなく、サイトリンクが表示されていない残りの検索結果にも表示されるといった事がありました。今回のアップデートで、サイトリンクが表示されたドメインとその他のドメインの区別が、より明確にされるようになり、サイトリンクが検索結果トップに表示された場合、その下に表示される残りの検索結果はその他のドメインからのものとなります。例外は、ある検索ワードの検索結果トップが、あるドメインのサブページである場合です。例えば [the met exhibitions] と検索した場合、www.metmuseum.org/special/ が検索結果トップとして表示されます。ここで表示されるサイトリンクは、 www.metmuseum.org/special 以下等から抽出されます。その一方で、残りの検索結果は他のドメインのページが表示されますが、store.metmuseum.org や blog.metmuseum.org/alexandermcqueen/about のような、metmuseum.org ドメイン内のその他のページが残りの検索結果に表示される場合があります。
  • 品質の改善:これらユーザーの目に見える変更と同時に、目に見えない改善も図りました。具体的には、サイトリンクを生成したり順位付けしたりするためのデータ(ウェブサイトのリンク構成など)を従来のランキングシステムと統合して、より優れたアルゴリズムにしました。それによって、順位付けの観点から見て、「通常の」検索結果とサイトリンクの間に区別はなくなりました。

今回のアップデート実施後のサイトリンク

これらの変更点は Google ウェブマスター ツール にも反映され、自分のサイトについて表示されるサイトリンクを管理することができます。不適切、または不正確なサイトリンクに対して順位を下げるよう設定することもできるようになり、アルゴリズムはこれらの申請を考慮に入れて、リンクの表示および順位付けを行います(サイトリンクの削除が保証されるわけではありません)。サイトリンクは時間経過や検索ワード次第で変動するため、固定された一覧から選択する方法はもはや現状に即さなくなっています。今回のアップデートによって、いかなるページのいかなる URL に対しても順位を下げる設定ができるようになります。ウェブサイト毎に、100 件まで順位を下げるための設定を行えます。最後に、Google ウェブマスター ツールの現行のサイトリンクのブロック機能は、全て順位を下げるためのシステムに変更されます。詳しくは、ウェブマスター ツール ヘルプ をご覧ください。

ご質問、ご意見等ございましたら、ウェブマスター ヘルプ フォーラム にお寄せください。


Fetch as Googlebot ツールを使って Google へ URL の送信が可能になりました。

14 years 3ヶ月 ago
ウェブマスター ツールの Fetch as Googlebot ツールに、新しいページの URL や更新したページの URL を Google へ送信して、インデックス登録をリクエストできる機能が追加されました。Fetch as Googlebot ツールがページを正しく取得できた場合、その URL を Google のインデックスへ送信するオプションが表示されるようになります。ここで URL を送信すると、その URL は通常 1 日以内に Googlebot によってクロールされ、その後 Google でインデックスに追加するかどうか検討します。なお、URL をインデックスに加えるかどうかの判定は、正規のプロセス(Fetch as Googlebot 以外の方法で発見された URL に対して用いるプロセス)と同様に行われます。Fetch as Googlebot 経由で送信された URL がすべてインデックスに登録される保証はありませんのでご注意ください。

今回導入した新機能は、さまざまな場面でご活用いただけます。たとえば、サイトを新規開設したばかりのときや重要なページを追加したときなど、そのサイトやページが自然にクロールされるのを待つのではなく、すぐに Googlebot に発見・クロールされるようにリクエストすることができます。また、すでにインデックス登録されているページについても、その内容を更新したい場合に URL 送信を実施することも可能です。たとえば、今週末に開催が迫ったイベントに関する重要な告知を掲載し、開催までに表示されるようにしたい場合などに役立ちます。ほかにも、公開するつもりではなかった情報を誤って公開してしまったときも、その情報をサイトから削除した後に、サイトのキャッシュを更新するのに役立ちます。

URL の送信方法
まず、[診断]から Fetch as Googlebot を選び、Google に送信する URL を取得します。URL の取得に成功すると、その URL の横に「インデックスに送信」というリンクが表示されます。


「インデックスに送信」をクリックするとダイアログボックスが表示されるので、その URL だけを送信するのか、URL とすべてのリンク ページを送信するのか、どちらかを選択します。


URL を単独で送信する場合は、1 週間に 50 件まで送信可能です。URL とそれにリンクされているすべてのページを送信する場合は、1 カ月に 10 件まで送信できます。あと何件送信できるかは、Fetch as Googlebot のページで確認できるようになっています。送信する URL が示すコンテンツは、Google ウェブ検索に適したコンテンツでなければならないため、画像や動画のメタデータを送信する場合は、代わりに サイトマップ をお使いください。

オーナーの確認をせずに URL を Google へ送信する方法
Fetch as Googlebot ツールのアップデートに伴い、「Google に URL を追加」フォームも形を変え、URL のクロール フォーム になりました。ページをインデックスへ送信できる回数の上限は Fetch as Googlebot 機能と同じですが、対象サイトのオーナーかどうかの確認は求められませんので、クロールおよびインデックス登録を希望するあらゆる URL を送信できます。


新しいコンテンツを発見しタイムリーにクロールすることは、Googlebot がすでに得意とするところですので、サイトの変更や更新のたびに必ずこれらのツールを使わなければならないというわけではありません。URL のクロールやインデックス登録を急ぎたい場合に、今回ご紹介した URL のクロー ル フォーム、または ウェブマスター ツール にある Fetch as Googlebot の新機能を使って URL を送信してみてください。

この記事に関するコメントやご質問は、ウェブマスター ヘルプ フォーラム までお寄せください。

Google プレイスに登録できるお店やサービスとは

14 years 4ヶ月 ago
Google 検索や Google マップの検索結果に表示されるビジネスリスティング(Google プレイスのオーナーのページ)には、どのようなお店やサービスが掲載されているかご存知ですか?
あなたのお店やサービスを掲載するためには、まず Google アカウント を取得して、Google プレイス にサインインし、ビジネスリスティングを作成する必要があります(無料)。わかりやすく効果的なリスティングにするために、作成方法のヒントを紹介する 連載 第 2 弾として、今回はあなたのお店やサービスが Google プレイスの登録に向いているかを判断する参考情報を解説します。

Google プレイスに登録できるお店やサービス
Google プレイスは、実店舗を持つお店やサービスと、その潜在顧客を結びつけることを目的としています。このため、ビジネス リスティングが Google の定める 品質ガイドライン を満たすには、お店やサービスを代表するビジネス オーナーまたは従業員が実際の住所を保有している必要があります。

実際の住所を保有しているということは、お店やサービスに特定の住所(通常、番地を含む)が存在し、顧客やビジネス パートナーが訪問可能で、かつ営業時間中に連絡がとれる電話番号がその住所に存在することを意味します。ビジネス リスティングに住所を登録することで、ユーザーはあなたのお店やサービスを Google マップ上に見つけることができます。

Google マップに表示されるビジネス リスティングの例

Google プレイスに登録できないお店やサービス
次に、現在 Google プレイスに登録できないお店やサービスの例を紹介します。
  • インターネットのみで営業しており、顧客が直接訪問できる店舗が存在しないネットショップ
  • 実際の住所が存在しないお店やサービス(自宅のリビング、パラグライダーの講習を実施する飛行場、急流くだりツアーを行う河川などは、お店やサービスの住所としての要件を満たしません。)
  • 特定の住所を持たないお店やサービス(農作物の路面販売、移動式のホットドッグ屋台、またはカフェやレストランにおける 1 回きりのコンサートなど)
  • 物件として実際の住所は存在するが、顧客が直接訪問してもその場で契約できないサービス(不動産会社による紹介物件のリスティング登録など)
*上記具体例にあるサービスでも、それを提供する会社が特定の住所に存在し、顧客やビジネス パートナーが訪問可能で、かつ営業時間中に連絡がとれる電話番号がその住所に存在する場合、会社のリスティングとしてその住所を登録することは可能です。

上記のような営業形態の場合、実際の住所に関連した検索結果に表示されるよりも、他の Google プロダクトの方がビジネスオーナーのニーズに適している可能性があります。たとえば Google AdWords を利用すれば、お店やサービスの認知度を高めることができるでしょう。Google AdWords は投資対効果が高く、オンライン広告キャンペーンを通じてお店やサービス、ウェブサイトまたはイベントの情報を発信することができます。また、実際の住所は必要ありません。

Google プレイスに登録する方法(ビジネスリスティングの作成)
顧客が訪問できる実際の住所が存在し、通常の営業時間内は担当者の応対および電話での連絡の両方が可能なお店やサービスの場合、ぜひ こちら から Google プレイスに登録して、無料でリスティングを作成してください。たとえば、実際にオフィスがある不動産会社の場合、提供するサービス、売りに出しているアパートなどをリスティングの [説明] フィールドに記載することも可能です(最大200文字まで)。


作成にあたって注意していただきたいのは、1つの住所に対して複数のリスティングを作成しないことと、お店やサービスが実際に存在する場所のみにリスティングを作成することです。たとえば、あなたがケータリング サービス会社を経営していて、オフィスが東京都渋谷区神宮前4丁目にある場合、港区の西麻布4丁目や新宿区3丁目でサービスを提供していたとしても、Google プレイスにはオフィスの住所のみを登録し、サービス提供地域は下記で説明する方法で登録してください。

*なお、ビジネス リスティングの作成および編集には、Google アカウントが必要です。 まだお持ちでない方は、こちら からアカウントを取得してください。

サービス提供地域を指定する方法
開錠サービス、ピザの配達、清掃サービスなど、実際の住所は 1 つしか存在しないものの、別の場所でもサービスを提供する場合は、複数のリスティングを作成するのではなく、Google プレイス アカウントの「サービス提供地域」機能を使用してください。サービス提供地域を設定することで、顧客にサービス対象範囲を知らせることができます。


顧客の応対に移動が必要なビジネスの場合、お店やサービスの住所からの半径を指定したり、サービスを提供する地域を選択できます。リスティングに登録した住所が自宅のもので、ビジネス関連のメールや電話を受け付けるためだけに使用している場合、住所を隠してサービス提供地域だけを表示することもできます。これには水道管修理、家庭教師、ケータリングサービスなどのビジネス モデルが当てはまるでしょう。この機能の詳しい設定手順については、ヘルプ センター をご覧ください。

タクシー会社や宅配会社は、「サービス提供地域」機能を使用したほうがよいビジネス モデルです。これらのビジネス モデルは場所に依存しないサービスを提供しているため、Google マップ上の特定の位置に紐付けることができません。タクシーを駅や空港の前で見かけることはありますが、その場所をタクシー会社で保有しているわけではないからです。しかしサービス提供地域機能を使うことで、タクシーの営業地域を指定できます。タクシーが配車センターを介して配車される場合、配車センターを住所として設定できますが、そうでない場合は住所を隠すといいでしょう。

作成されたリスティングの認証方法
Google および Google マップにビジネス リスティングを表示するには、Google プレイスを通してお店やサービスが存在することを証明する必要があります。この認証プロセスはシンプルで、認証コード(PIN)が記載されたハガキ、あるいはオートコール(無人自動電話)によって行われます。認証プロセスで使用された電話番号は、リスティングに表示されますので、必ずお店やサービスに直接つながる電話番号を使用してください。

他にも Google プレイスに登録できるお店やサービスについて、ご質問がありましたら、Google プレイス ヘルプ フォーラム に投稿してください。

PageRank をこえて ― より実用的な指標へ

14 years 4ヶ月 ago
ウェブマスター トレンド アナリストの Susan Moskwa です。好奇心旺盛なインターネット ユーザーと同様、私も Google アラート を使い、自分の名前がネット上で話題になるたびに E メールを受け取るように設定しています。たいていは、自分の投稿したフォーラムでの発言 (英語)や ブログ記事 (英語)、Twitter でのつぶやき (英語)などに関して通知が少し届く程度なのですが、その中でも、ここ数年でもっとも反応が多かったのは、2009 年の PageRank に関するものでした。具体的には、ウェブマスター ツールから PageRank データの表示を削除 (英語)したことに関して、私が不用意な発言をしてしまったことによるものです。

あれから 2 年近く経ってもまだ、この件が取り上げているということから(よく「Susan Moskwa のショッキングな発言……」といった書き方をされます)、一部のウェブマスターの方にとって PageRank がいかに重要な指標となっているかということがよく分かります。サイト運営を始めたばかりのサイト オーナーの方たちからも 、話してみると口々に PageRank についてよく耳にするとか、自分のサイトにとってどんな意味を持つのかもっと詳しく知りたいといったような声が聞かれます。しかし 、ウェブマスター セントラル チームは何年もの間、ウェブサイトの成否を示す指標として PageRank にばかり注目すべきではないとお伝えしてきました。今回の記事では、このことについてより詳しく説明するとともに、PageRank に替わる実用的ですぐに使える指標をいくつかご紹介したいと思います。

なぜ PageRank ばかりが注目されているのか?
2008 年、Google の技術担当副社長の Udi Manber は、Google 公式ブログ で次のように述べています。

「Google ランキングのアルゴリズムの中で最も有名なのは PageRank であり、これは、 Google の創業者であるラリー ペイジとサーゲイ ブリンが開発したアルゴリズムです。PageRank は今日でも使われていますが、現在ではより大きなシステムの一部となっています。」

1998 年の Google 設立時、Google を検索エンジンとして有名にしたのは PageRank だったかもしれません。しかし、マンバーが述べているように、「平均で週に約 9 つ」という頻度で変更が加えられていることを考慮すると、この 10 年間でGoogle のランキング システムは幾度となく強化され、洗練されてきたと言えます。つまり、もはや PageRank はランキングの中核を担う要素ではないのです。

Google の テクノロジーの概要 をお読みいただければ、検索結果のランキングにおいてもっとも重要な要素の 1 つに「関連性」を強調していることがお分かりいただけると思います。ではなぜ、関連性は PageRank ほど取りざたされないのでしょうか。それは、おそらく PageRank が数値で表される一方で、関連性はそうではないからだと思われます。関連性も PageRank も、たくさんの複雑な要素(コンテキストや、検索の意図、人気度、信頼度など)から成り立っていますが、たとえば PageRank は 5 分もあれば簡単に時系列の変化をグラフにまとめて上司に見せることができます。しかし、関連性ではそうはいきません。このような PageRank の分かりやすさこそが、長年にわたってウェブマスターの方に注目されてきた理由ではないかと思います。しかし、分かりやすいからといって必ずしもその 指標がサイトの状態を正確に示してくれるとは限りません。

本来の目的は何か?
PageRank を、サイト運営の最終目標にしている人はいないと思います。あくまで PageRank とは、本来の目的を達成するための目安に過ぎません。たとえば、収益をもっと伸ばしたいとか、サイトの訪問者や見込み客、またはニュース レターの購読者を増やしたいといったようなことが本来の目的だったはずです。ここで注意していただきたいのは、PageRank が目標達成の指標としてきちんと機能するためには、PageRank が高いほどそのサイトが検索結果の上位にランクし、それがより多くのトラフィックを生み出し、さらに、そうやって獲得したサイト訪問者がこちらの期待するアクションをとってくれる ― というように、いくつかの前提を重ねる必要があるということです。これに加え、Google ツール バーに表示される PageRank は、年に数回しか更新されず、しかも、スパム行為を行っていると判断された場合には、そのサイトの ツール バー上に表示されている PageRank が下げられることがある という点にも留意する必要があります。つまり、公開されている PageRank は、Google のアルゴリズムが実際にランキングの算出に用いる数値とは異なっているのです。そうだとすれば、本来の目的からかけ離れた間接的な数値を気にするのは得策だとはいえません。目標がどのくらい達成できているのか直接、示してくれる指標が他にあるのなら、なおさらです。ご自身のビジネスに直結するような指標を見つけることで、本来の目的にさらに一歩近づくことができるでしょう。

PageRank に替わる指標は何か?
検索結果のランキングに関するものではなく、自分のウェブサイトやビジネスにとって意味のある成果に直接つながるような指標に目を向けてみましょう。また、PageRank のように更新頻度が年に数回というものではなく、毎日もしくは毎週更新されるような指標を用いるとよいでしょう。というのも、更新頻度が少なすぎると、サイトに加えた変更のうち、実際にどの部分が数値の変化をもたらしたのか正確には分からないからです。では、具体的にどのような数値を参考にしたらよいのでしょうか。以下、手始めに 3 つの指標をご紹介しましょう。いずれも、Google アナリティクスウェブマスター ツール といったサービスを利用して調べられるものばかりです。
  1. コンバージョン率
  2. 直帰率
  3. クリック率 (Click-through rate: CTR)
コンバージョン率
「コンバージョン」とは、サイトを訪れた人が、こちらの期待する行動を取ることを指します。たとえば、商品の購入やメーリング リストへの登録、文書のダウンロードなどがこれにあたります。なので、コンバージョン率とは、サイト訪問者のうちコンバージョンに至った人の割合を示します。これは、PageRank とは異なり、ビジネスの目的に直結した指標だと言えるでしょう。ユーザーがコンバージョンに至ると、直接的に利益が生まれるうえ、それを測定できるわけです。これに対して PageRank は、前述のように正確な測定が困難であり、また、ビジネスに直接関係することなく数値が上下する場合があります。

直帰率
「直帰」とは、サイトを訪れた人が他のページを見に行くことなく、そのサイトを離れることをここでは意味します。したがって、直帰率 とは、直帰するサイト訪問者の割合を示します。つまり、直帰率が高いということは、サイトを訪れたもののすぐに離れていったユーザーが多いということなので、サイトのコンテンツが魅力的ではないと捉えることができます。サイト内の各ページの直帰率を調べることで、パフォーマンスの低迷しているコンテンツを特定したり、改善が必要と思われる箇所を発見したりするのに役立つでしょう。

クリック率 (CTR)
オーガニックな検索結果に関する場合、クリック率(CTR)とは、検索結果に表示された回数のうち、どのくらいの頻度でそのサイトがクリックされたかを示します。CTR が低いということは、サイトがどれだけ上位に表示されたとしても、ユーザーがあまりクリックしていないということを意味しています。これは、おそらくそのサイトがユーザーのニーズに合っていないと判断されたか、あるいは他のサイトの方が良さそうに見えたのが原因だと考えられます。CTR を向上させるには、たとえば検索結果に表示されるサイトのタイトルやスニペットを確認してみるとよいでしょう。ユーザーが思わずクリックしたくなるような内容か?各 URL のコンテンツを正確に反映しているか?― など、検討してみることをお勧めします。 ">検索エンジン最適化 ( SEO ) スターターガイド では、スニペットを改善するためのアドバイスがいくつか紹介されていますので、ぜひ参考にしてみてください。また、ウェブマスター ツールの HTML のヒント も改善が必要なページを洗い出すのに役立つでしょう。繰り返しになりますが、いくらサイトのランキングが高くても、ユーザーがクリックしなければ意味がないということにご注意ください。

以上、入門的な内容を取り上げてきましたが、実は多くのブログや書籍で、ウェブの指標に関する解説や研究がされています。さらに詳しい情報をお知りになりたい場合は、たとえば、アナリティクス エヴァンジェリスト の Avinash Kaushik 氏のサイト (英語)が参考になるでしょう。少なくとも今回の記事で、サイトの成否を判断するのに、PageRank よりも直接的で効果の見えやすい指標が他にあることをご理解いただけたら幸いです。

最後にもう 1 点、お伝えしたいことがあります。PageRank に関心がある理由として、PageRank が高くないとそのサイトからのリンクを買ってもらえないということを挙げるサイト オーナーの方がいらっしゃいます。しかし、意図的に PageRank を操作する目的でリンクを売買することは Google のウェブマスター向けガイドラインの違反 となり、たいていはマイナスの結果しかもたらしません。したがって、そのような行為はやめていただくよう強くお願いするとともに、もし不正なリンク操作を目的にしている場合には、Google がそのサイトの PageRank を上げたり、サイトの改善についてアドバイスしたりすることはありませんので、あらかじめご了承ください。

有料リンクについての詳しい情報は、ブログ記事「Google が有料リンクを信頼しない理由」および「有料リンクでガイドライン違反にならないために」をご覧ください。
また、この記事に関するコメントやご質問は、ウェブマスター ヘルプ フォーラム までお寄せください。

schema.org のご紹介: より便利なインターネットのための検索エンジンの取り組み

14 years 4ヶ月 ago
今回は、Google、Bing、Yahoo!※ による新しい取り組みである schema.org をご紹介します。これは、ウェブページの構造化データのマークアップのための共通のタグ セットをつくる取り組みです。サイトが検索エンジンにとってより理解しやすいものになるよう、ウェブマスターの皆さんは個々のページに様々なマークアップを加えていることでしょう。しかし、今までは検索エンジンごとにマークアップを用意しなければなりませんでした。そこで私たちはウェブマスターのみなさんがワンストップでマークアップを追加できるよう、schema.org の開発に取り組みました。

Google では、2 年前から構造化マークアップをサポートしてきました。2009 年には 人物レビュー といったサイトのコンテンツを具体的に表すため、リッチ スニペットを導入しました。それ以降、Google では ショッピングと商品イベントレシピ などをはじめとして、様々な種類のリッチ スニペットを導入してきました 。


リッチ スニペットの例:
構造化マークアップによってページの説明が検索結果に加えられています。上の写真ではレシピの写真、調理時間とカロリーが追加されています。下の写真では、これから開催される花火の予定が表示されています。

このような構造化マークアップは今ではウェブマスターのみなさまに広く受け入れられ、おかげさまで現在ではリッチ スニペットを開始した 2 年前と比べると 10 倍以上の頻度で表示されるようになりました。

Google はインターネットをもっと豊かでもっと使いやすいものにし続けていきたいと思っていますが、ページにマークアップを追加するには時間も労力もかかってしまいます。ましてや各検索エンジンごとに使うデータの形式が異なると、それはさらに困難になってしまいます。そこで私たちは 2006 年に他の検索エンジンと協力して共通の サイトマップ プロトコル(英語)に対応したときと同様に、マークアップのための共通の仕組みをつくることにいたしました。この schema.org を使うことで、サイト オーナーの皆さんは Google だけでなく Bing や Yahoo!、また将来的には他の検索エンジンにおいても同様に、検索結果に表示されるサイトの内容をよりリッチにすることができます。

では、schema.org について、ウェブマスターのみなさんに関連のあるポイントをいくつかご説明しましょう。

1) schema.org では新しいマークアップを数多くご紹介しています
私たちは既存のリッチ スニペットに加えて、100 種類以上の新しいリッチ スニペットを用意しました。過去にリッチ スニペットのマークアップに興味があったものの、サイトに適用できそうなものがなかった、という経験をお持ちなら、schema.org がお役に立てるかもしれません。 例えば次のようなマークアップが用意されています。(リンク先はすべて英語です)
詳しくは、schema.org の全マークアップの一覧(英語)をご参照ください。この新しいマークアップはコンテンツをユーザーにとって探しやすくするための改善に使われる可能性があるほか、将来的に、リッチ スニペットに採用されるかもしれません。

2) schema.org は microdata を使用しています
これまで、構造化データのマークアップのために microdata、microformats、RDFa という 3 つのフォーマットが使われてきました。schema.org ではウェブマスターのみなさまの利便性のため、そして検索エンジン間の一貫性を高めるためにこれらのフォーマットを 1 つに絞ることに決めました。現在使われている規格のうちどれが最も適しているかに関しては様々な議論がありますが、私たちは RDFa の拡張性と microformats の単純さのバランスがとれる microdata を採用することにいたしました。

microdata の概要と仕様については、schema.org のガイド(英語)を参照してください。

3) 引き続き、既存のリッチ スニペット マークアップのフォーマットにも対応します
microformats や RDFa を使用したマークアップを既に済ませている場合でも、リッチ スニペットは引き続き機能します。これに関して 1 つ注意点があります。schema.org の新しいマークアップと、既存の microformats や RDFa マークアップのどちらを使用しても問題はありませんが、同一のウェブページ上でフォーマットを組み合わせて使用することは避けたほうが良いでしょう。それは構文解析ツールを混乱させてしまうことにつながります。

4) リッチ スニペットのテスト ツールでマークアップをテストしましょう
マークアップを行ったウェブページを検索エンジンが正確に解析できるかどうかテストすることはとても大事です。既存のリッチ スニペットのマークアップをテストするには、リッチ スニペット テスト ツール(英語)を使用してください。テスト ツールにはページから解析されたマークアップ情報が表示されますが、schema.org のマークアップはまだリッチ スニペットのプレビューとして表示されませんのでご注意ください。この機能は後日追加される予定です。

schema.org のウェブサイトとリッチ スニペットのテスト ツールは英語で提供されていますが、Google では様々な言語の検索結果でリッチ スニペットを表示しますので、今すぐにページをマークアップしても問題ありません。

リッチ スニペットの詳細な説明や schema.org との関連性については、schema.org FAQ (英語)をご参照ください。

※ いずれも米国法人。

HTTP ヘッダーでの rel="canonical" 属性に対応しました

14 years 4ヶ月 ago
みなさまからのご要望にお応えし、このたび、Google 検索は IETF RFC 5988 のセクション 5 (英語)に記載のシンタックスに従って HTTP ヘッダーで指定された link rel="canonical" 属性 に対応いたしました。rel="canonical" を有する HTTP ヘッダーを使用することで、HTML 文書だけでなく、それ以外の形式のコンテンツ(PDF ファイルなど)についても canonical URL(優先する URL)を設定することが可能になります。

では実際に、rel="canonical" を指定した HTTP ヘッダーがどのような働きをするか、HTML ページ版と PDF ダウンロード版の両方で文書を提供しているウェブサイトを例に見ていきましょう。HTML 版と PDF 版の URL はそれぞれ下記のとおりとします。
http://www.example.com/white-paper.html
http://www.example.com/white-paper.pdf

このケースでは、PDF ファイルが要求された時に rel="canonical" HTTP ヘッダーを使用することによって、優先する URL が上記 HTML 文書であることを Google に通知することができます。

記述例:
GET /white-paper.pdf HTTP/1.1
Host: www.example.com
(...以下、他の HTTP リクエスト ヘッダー...)

HTTP/1.1 200 OK
Content-Type: application/pdf
Link: <http://www.example.com/white-paper.html>; rel="canonical"
Content-Length: 785710
(...以下、他の HTTP レスポンス ヘッダー...)

他にも、rel="canonical" を設定した HTTP ヘッダを活用できる代表的なケースとして、ウェブサイトが同一ファイルを複数の URL から提供している場合(コンテンツ配信ネットワークを使用している場合など)に、Google に対して優先する URL を通知したいといったケースが挙げられます。
これらのリンク ヘッダー要素は、現時点では Google においては検索でしか対応していませんが、ウェブマスターのみなさまの利用状況を考慮しながら、Google の他のサービスにおいても対応できるようにしたいと考えております。

詳しくは、正規化 および rel="canonical" 属性 に関するヘルプセンターの記事をご参照ください。ご質問やご意見がありましたら、ウェブマスター ヘルプ フォーラム へお寄せください。

404 はサイトに悪影響を与えますか?

14 years 4ヶ月 ago
ある日、何気なくウェブマスター ツールを使って自分のサイトの調子を確認したところ、クロール エラーページ が、404(Not found)(英語)でいっぱいになっていました。こんな時、いったいどうしたらいいのでしょうか?



心配する必要はありません。今回の記事は、404 についてと、これらがサイトに対して影響をおよぼす点(あるいは影響をおよぼさない点)について取り上げます。

質問: ウェブマスター ツールのクロール エラー ページに表示される 404 (Not found)は、Google 検索での掲載順位に影響しますか?
答え: サイトの一部の URL が既に存在しない、または 404 を返していた場合も、サイトの他の URL (200(Successful)を返すもの)の検索結果内での掲載順位には影響しません。404 レスポンス コードは、インターネットにとっては正常な動作です。インターネットは常に変化しており、新しいコンテンツが作られ、古いコンテンツはなくなっていきます。コンテンツがなくなったとき、404 HTTP レスポンス コードを返すことが通常の動作です。検索エンジンはこのことを理解しています。上図にあるように、Google のサイトにも 404 エラーはありますし、404 エラーはインターネットのあちこちで見られます。サイトからページが削除された場合は、いわゆる「ソフト 404」よりも、正しい 404 または 410 レスポンス コードが返されるほうが検索エンジンにとっては望ましいのです。Google のクローラが URL の HTTP レスポンス コードを確認するためには、その URL をクロールする必要があることを覚えておいてください。該当の URL が robots.txt ファイルでブロックされていると、クロールができず、レスポンス コードを確認することができません。

質問: では、ウェブサイトにとって 404 はまったく影響のないものなのですか?
答え: サイトの一部の URL が 404 を返しているということ自体が、サイト運営者の評価や Google 検索の結果に影響することはありません。ただし、一部の 404 に対しては対処が必要かもしれません。たとえば、404 を返しているページがサイトにとって重要なページである場合は、なぜクロール時に 404 が出ているのか調査するほうがよいでしょう。URL のスペルミス(www.example.com/awesome を誤って www.example.com/awsome としている場合など)がある場合は、誰かがサイトにリンクしようとしてタイプミスをしていることが考えられます。その場合、404 を返す代わりに、301 リダイレクトを使用し正しい URL にリダイレクトすれば、そのリンクからのトラフィックを得ることができます。また、ユーザーがサイトの 404 ページにアクセスした場合、「404 Not found」とだけ表示するのではなく、ユーザーにとって有用なページを用意 することもできます。

質問: 「ソフト 404」について詳しく教えてください。
答え: ソフト 404 とは、ウェブサーバーが、存在しない URL に対して 404(または 410)以外の応答コードを返す場合です。一般的な例としては、サイト運営者が ユーザーにとって便利な 404 ページ (英語)を提供したいと考え、そのようなコンテンツを提供するには必ずレスポンス コード 200 を返さなければならないと思っている場合です。しかし、404 を返しても、そのようなコンテンツを提供することはできます。他の例としては、未知の URL に対して 404 を返す代わりにホームページにリダイレクトしている場合です。どちらの場合も、Google があなたのサイトを分析しインデックスを作成するのに支障が出る可能性があるため、存在しないコンテンツに関しては適切なレスポンス コードを返すようにしてください。ページに「404 Not Found」と書かれているからといって、本当に応答コード 404 を返しているとは限りません。ウェブマスター ツールの Fetch as Googlebot 機能を使用して、そのページをチェックしてみてください。サーバーが正しい応答コードを返すように設定する方法がわからない場合は、ホスティングサービスのヘルプページなどを参照してみましょう。

質問: URL が 404、301、410 のうちどれを返すべきか判断するにはどうすればよいのですか?
答え: サイトからページを削除するときに、そのコンテンツを別の場所に移動するのか、完全にサイトからなくすつもりなのかを考慮してください。コンテンツを新しい URL に移動する場合、古い URL から新しい URL へ 301 リダイレクトしましょう。こうすれば、ユーザーが古い URL を訪れた場合も、探している情報と関連があるページに自動的に誘導されます。コンテンツを完全に削除して、今後サイトに設置しない場合は、古い URL が 404 または 410 を返すよう設定しましょう。現在、Google は 410(Gone) を 404(Not Found)と同じように処理します。そのため、どちらを返してもかまいません。

質問: 404 のほとんどが、サイトに存在しない URL に対するものです。これは何ですか?どこから来たトラフィックですか?
答え: 通常 Google は、ウェブ上のどこかであなたのサイト内へ張られたリンクを検出すると、コンテンツの有無を問わずそのリンクをクロールします。もしその URL が存在しない場合には場合はサーバーは 404 を返す必要があります。こういった無効なリンクが発生する理由は、いろいろ考えられます。例を挙げると、サイトにリンクしようとした誰かがスペルミスをした場合、設定ミスの場合(CMS によってリンクが自動生成されている等)、Google のクローラが JavaScript や他の組み込みコンテンツ内のリンクを認識してクロールしようとした場合、サーバーが未知の URL をどのように処理するかを Google が確認しようとした場合などです。サイトに存在しない URL に対してウェブマスター ツールが 404 を報告した場合は、無視しても問題ありません。Google では、あなたのサイトにとって必要な URL と、404 を返すべき URL を判別できません。このため、サイトで検出されたすべての 404 を報告し、対応が必要かどうかはみなさんの判断に任せています。

質問: サイトをスクレイピングされたため、大量の 404 が発生しました。例えば「http://www.example.com/images/kittens.jpg" width="100" height="300" alt="kittens"/></a...」のような、実在する URL に他のコードが付け加えられたものです。これはサイトに悪影響を与えますか?
答え: 一般的に、このような「壊れた」リンクがサイトに悪影響を与えることはありません。Google は、サイトの運営者側ではスクレイピングを行う者や、普通でない方法でリンクしようとする者を制御できないことを理解しています。正規表現 を使いこなせる場合は、これらの URL をこのように(英語)リダイレクトすることもできますが、普通は心配しなくても大丈夫です。また、サイトからコンテンツが盗用された確信がある場合は、こちらから著作権侵害の申し立て を行うことができます。

質問: 先週、ウェブマスター ツールで報告された 404 をすべて修正したのですが、まだ一覧に記載されています。正しく修正できなかったということですか?エラーが表示されなくなるまで、どのくらいかかるのですか?
答え: 「クロール エラー」ページの「最終検出」列をご覧ください。これは各エラーが検出された最新の日付を示しています。列の日付がエラーを修正する前であれば、そのエラーはその日付から発生していないことを意味します。日付が修正後である場合は、クロール時に再び 404 に遭遇していることになります。

Fetch as Googlebot 機能を使用すると、クローラが新しいレスポンス コードを確認できているかどうかをチェックできます。いくつかの URL でテストして問題がなければ、それらはクロール エラーの一覧から消えていくはずです。

質問: アカウントから 404 エラーを早く消去するために、Google の URL の削除ツールを使ってもよいですか?
答え: いいえ、URL の削除ツールは Google の検索結果から URL を削除するためのものであり、ウェブマスター ツールのアカウントから削除するためのものではありません。404 を返すページはいずれ検索結果には表示されなくなるため、緊急の削除要請用のツールを使う必要はありません。URL の削除ツールを使用するべきである場合とそうでない場合については、この記事(英語)の後半を参照してください。

ご質問やご意見がありましたら、ウェブマスター ヘルプ フォーラム へお寄せください。

Google ウェブマスター ツールと Google アナリティクスで「+1」の効果を確認できます

14 years 4ヶ月 ago
[この記事は、Inside AdSense ブログ とのクロスポストです。]

先日世界中でリリースした +1 ボタン は、自分の信頼している人たちとインターネット上でつながりやすく (英語。日本語字幕付き)することを目指しています。あるユーザーが +1 ボタンを押すと、その情報はそのユーザーにつながっている友人達の間で共有され、検索結果に表示されます。そうした友人間のおすすめ情報は、きっと検索結果からどのサイトを閲覧しようかを決める際の貴重な参考となるでしょう。つまり、+1 ボタンによって、友人達があなたのサイトについてあなたに代わりおすすめしてくれることになります。

しかし、サイトを運営するウェブマスターのみなさまにとってこのような新しい機能の効果は、測定してはじめて分かることもあるでしょう。そこでこの度、+1 ボタンをサイトに導入した効果を測定するための機能をリリースしました。

トラフィックへの影響を測る 3 つの指標(ウェブマスター ツール)

まず、Google ウェブマスター ツール の +1 統計情報では、+1 ボタンがサイトへのトラフィックにどう影響しているかを確認できます。
  • 検索への影響 では、検索結果からの集客に「+1」がどう影響しているかを確認できます。+1 による友人からのおすすめ情報が検索結果にある場合とない場合とで、クリック数や表示回数を比較できますので +1 ボタンを押された場合にクリック率が変化しているかどうかがわかります。クリック率の変化の統計は、比較が行えるだけの表示回数がある場合のみ表示されます。
  • アクティビティ は、サイト内、あるいは他のページ(Google 検索など)で、あなたのページに対し何回 +1 ボタンが押されたかが表示されます。
  • 最後に、対象 にはページの +1 ボタンを押した Google ユーザーの地域情報やユーザー情報が表示されます。プライバシー保護のため、一定以上の人数のユーザーが +1 ボタンを押した場合にのみ、この情報は表示されます。
レポートを表示するには、ページの左側にある [+1 統計情報] メニューからご利用ください。Google ウェブマスター ツールで認証手続(サイトの確認)をしていない場合は、こちらの手順 を参照して Google ウェブマスター ツールへサイトの登録をしてください。

共有の効果を測る 3 つのソーシャル指標(Google アナリティクス)

Social Plug-in Analytics in Google Analytics (英語)を利用すると、+1 ボタン以外の方法でコンテンツが共有されている場合についてもその効果を確認することができます。Google アナリティクスの JavaScript を設定すれば、ソーシャル セクションのエンゲージ レポートから、ページで行われている様々なソーシャル上での共有(+1 ボタンのクリック、Twitter のつぶやきなど)を比較することができます。
  • エンゲージ レポート では、+1 ボタンのクリックやその他のソーシャル上での共有を行った訪問者について、サイトでのパフォーマンスがどのようなものだったかを確認できます。この機能を使用すれば、たとえば、ページを訪問して +1 ボタンをクリックしたユーザーが、クリックしなかったユーザーよりも長時間サイトに留まっているかなどを判断することができます。
  • アクション レポート では、サイトに対して行われたソーシャル上での共有の数(+1 ボタンのクリック、Twitter のつぶやきなど) をソーシャル サービスごとに確認できます。
  • ページ レポート では、ページごとにソーシャル上で共有された回数を比較し、どのページが最も共有されているかを確認できます。
Google アナリティクスの最新トラッキング コードをデフォルトの状態で使用している場合、サイトに +1 ボタンを追加 すると、あなたのアカウントで 自動的に「+1」の Social Plug-in Analytics が有効になります。また、簡単な手順で、他のサービスの Social Interaction Analytics を有効にする(英語)こともできます。

ソーシャル 関連のレポートはまだ始まったばかりです。ますますインターネット上でソーシャルなサービス、共有が盛んになっていく中で、この新しいレポートが皆様のビジネスのお役に立つことを期待しています。ぜひ「+1」をご活用ください!

Google ショッピングのフィード仕様とポリシーの重要な変更

14 years 5ヶ月 ago
2011 年も残すところ約半年となりましたが、Google ショッピング は、引き続き、より快適なショッピング環境を提供すべく努めてまいります。

Google ショッピングの目標は、ユーザーが商品情報をすばやく簡単に検索できるようにし、各ショップを訪れる買い物客を増やすことです。このたび、そうした取り組みの一環として、Google ショッピングのフィード仕様とポリシーを一部変更することになりました。2011 年 9 月 22 日時点で新しい仕様とポリシーの要件を満たしていないアカウントは停止となる可能性がありますのでご注意ください ( この変更は、日本、米国、フランス、英国、ドイツにおいて適用されます )。

変更点の要約

今回の変更によって、ユーザー エクスペリエンスが大幅に向上すると確信しています。以下に、日本でのフィード仕様の変更点をいくつか例示します。

  • 追加の商品画像リンク: 商品の画像を複数登録したい場合、これまでは商品画像リンク [image link] 属性に複数登録していましたが、これからは [image link] 属性に登録する画像はひとつだけとし、追加分は [additional image link] 属性を使って登録してください。
  • 在庫状況: 在庫がない商品も検索できるようにします。そのために、すべての商品アイテムの在庫状況 [availability] ステータスを必須の属性とします。
  • Google 商品カテゴリ: 新しい必須属性として Google 商品カテゴリ [google product category] を追加しました。この属性には、Google の分類に従って商品アイテムのカテゴリを指定します ( 現時点では一部の商品カテゴリに対してのみ必須です )。今後は、新しい属性と既存の商品カテゴリ [product type] 属性を併用することになります。
  • 価格: セールの期間と価格を [sale price effective date] と [sale price] 属性を使って指定できるようになりました。また、[price]、[sale price] 共に対象国の通貨単位も送信する必要がありますのでご注意ください ( 例: 150 JPY )。

ショップ向けの情報ドキュメント

新しいフィード仕様とポリシー、変更にあたって必要な準備など、詳しい情報へのリンクは以下のとおりです。


近日中に、変更点について詳しく説明した動画を公開する予定です。今後も詳しい情報を随時提供していきます。

Google ショッピングの新しいフィード仕様とポリシーの適用について

2011 年 9 月 22 日時点で新しい仕様とポリシーの要件を満たしていないアカウントは停止となる可能性があります ( 詳しくは上記のポリシーに関するドキュメントをご覧ください) 。なお、これらの変更は Google ショッピングにのみ適用されます。Google 商品広告Commerce Search には適用されません。


インスタント プレビューのトラブル シューティングはウェブマスター ツールで

14 years 5ヶ月 ago
昨年の 11 月、Google は インスタント プレビューを公開しました。この機能は、検索結果の中のどのサイトが検索したキーワードに関連があるかどうか、ユーザーがそのサイトをクリックすることなく確認できる機能です。公開以来、Google インスタント プレビュー チームは、ページのインスタント プレビューのレンダリング結果に関する皆様からのフィードバックや問題点に着目してきました。

プレビュー画像に問題がある場合の主な原因は次のとおりです:
  • robots.txt によりサイト上の画像などへのアクセスがブロックされていたため、画像が表示されなかった。
  • ユーザーに実際に表示されるコンテンツと、Googlebot に見せるコンテンツが異なる、クローキング 状態になっていた。
  • Flash が使用できない場合の代替コンテンツがきちんと作られていなかった。
皆様がこうした問題を診断するときに役立つよう、ウェブマスター ツール の [Labs] セクションにインスタント プレビュー ツールをご用意しました。


まず、インスタント プレビューを確認したいページの URL を入力します。すると Google はサイトからページを取得し、実際に Chrome ブラウザとインスタント プレビューで表示されるのと同様にそれぞれレンダリング (描画)します。なお、最新の WebKit ビルドを使用してレンダリングを行いますが、この WebKit ビルドには Flash や Silverlight などのプラグインは含まれていないことに注意してください。そのため、Flash などの表示箇所を空白にしないためには、代替コンテンツを用意する必要があります。代替コンテンツは、検索エンジンだけではなく、プラグインを持っていないサイト訪問者にも役立ちます。

レンダリング結果の下には、「リソースがない」、「リソースが robots.txt でブロックされている」など、レンダリング中に検出された問題が表示されます。今後も皆さまのインスタント プレビューの改善に役立つような情報をさらにお伝えしていけるよう改善を重ねたいと思います。

ご質問やご意見がありましたら、ウェブマスター ヘルプ フォーラム へお寄せください。

Google の検索結果からホームページが消えてしまいました。どうすればいいでしょうか?

14 years 5ヶ月 ago
ウェブマスター ヘルプ フォーラム には時折、「Google の検索結果から自分のホームページが消えてしまいました」、「Google の検索結果で順位が急に下がってしまいました」といったお問い合わせが寄せられることがあります。Google の検索結果でサイトが表示されなくなったり、順位が大幅に下がったりする原因は一つではありません。原因を特定するのに役立つ重要なガイドラインやツール、ブログ記事などをご紹介しますので、是非一つ一つご確認ください。
  • ウェブマスター向けガイドライン
    Google では、Google がウェブサイトをインデックスに登録する際にどのような点を重視しているか、そのポイントを ウェブマスター向けガイドライン として公開しています。その中でも「品質に関するガイドライン」には、ランキングやインデックスに変動のある対応(検索結果からの削除を含む) がとられる可能性のある不正行為について記述されています。ガイドライン違反のサイトは、Google や Google のパートナー サイトの検索結果に表示されなくなる場合がありますので、是非ご一読いただき、このガイドラインに違反していないかどうか、よく確認してみてください。

    ※Google と相性のよいサイトの制作方法 についてさらに詳しい情報は、ブログ記事「 初心者向け Google SEO 資料 」をご覧ください。また、「検索エンジン最適化 (SEO) スターターガイド 」では SEO のノウハウを、「 Google 検索エンジン最適化 (SEO) レポートカード 」ではご自身のサイトの SEO 診断の方法を公開しています。
  • ウェブマスター ツール
    ウェブマスター ツール はこうしたトラブルシューティングには必須のツールです。ウェブマスター向けガイドライン違反があった場合やマルウェアに感染した場合、さらにはクロールエラーが発生していた場合など、トラブルシューティングに必要な情報を確認することができますので、ウェブマスター ツールにあらかじめ登録しておくことをお勧めします。ウェブマスターツールについての詳しい情報は、こちらの ブログ記事 をご覧ください。
  • ブログ記事「アクセス数の減少とサイトの構造上の問題について(前段)
    アクセス数が減少する原因について、よくある誤解を紹介し、その間違いについて解説しています。重複するコンテンツが原因ではないか、アフィリエイトが原因ではないかとお悩みの方はこちらをご一読ください。
  • ブログ記事「アクセス数の減少とサイトの構造上の問題について(中段)
    第三者によって 隠しテキストや隠しリンク がサイトに埋めこまれたことにより、サイトが Google のウェブマスターガイドライン違反となり、サイトが Google の検索結果から除外されてしまうケースについて詳しく解説しています。
  • ブログ記事「アクセス数の減少とサイトの構造上の問題について(後段)
    皆さんのサイトが Google の検索結果に表示されるためには、サイトが適切に Google にクロールされ、インデックスに登録される必要があります。そのためにチェックすべき robots.txt の設定ミスの問題などについて解説しています。
最後に、再審査リクエストについてご紹介します。ウェブマスター向けガイドライン に違反していることが原因で、サイトが Google の検索結果に表示されなかったり、以前より掲載順位が下がったりしていると思われる場合は、 ペナルティがかけられている可能性があります。この場合、サイトをガイドラインに沿うよう修正し、再審査リクエスト を送信してください。再審査リクエストをお送りいただくと、Google で確認し、違反箇所が修正されていた場合は、与えられていたペナルティが解除されます。最近取得したドメインが、かつて別のウェブマスターに所有されていた際にウェブマスター向けガイドラインに違反していたと思われる場合などにもご活用いただけますので、是非覚えておいてください。再審査リクエストについて詳しい情報は、ブログ記事「 再審査リクエストを送信する際にご確認いただきたいこと 」をご覧ください。

ご意見ご感想は、Google が運営している公式ヘルプフォーラム、ウェブマスター ヘルプ フォーラム へご質問をお寄せください。

+1 ボタンが日本のウェブマスターの皆さまにもご利用頂けるようになりました

14 years 5ヶ月 ago
数ヵ月前、Google は +1 ボタン (英語記事)を Google.com の検索結果上でのみ開始しましたが、本日 +1 ボタンは Google.co.jp をはじめとして、Google.co.uk や Google.de、Google.fr など、より多くの検索結果に表示されるようになりました。これは今後数週間でさらに拡大されます。

このブログ記事では、ウェブマスターの皆様に向けて +1 ボタンの概要と、ご自身のウェブサイトへの導入方法をご紹介します。

+1 ボタンとは
+1 ボタンとは、Google ユーザーがインターネット上で友人や知り合い、そして世界中の人々と自分が気に入ったページをクリック一つで共有できる機能です。

検索ユーザにとっては、知り合いが+1ボタンを押しておすすめしているサイトが検索結果上でわかるため、検索結果の中からサイトを選ぶ際の手助けになります。


検索ユーザーは、友人が +1 ボタンを押したことが分かるようになります。

サイト運営者の皆さまにとっては、+1 ボタンにより、Google の検索結果から多くの質の高いトラフィックがもたらされることが期待できます。

+1 ボタンの導入方法
+1 ボタンを導入するには、ウェブマスター セントラルの+1 ボタンツール からコードを生成してページに設定してください。ボタンのサイズやスタイルも複数ご用意していますので、サイトのデザインに最も合うボタンを選んでください。



+1 ボタンを導入すると、ユーザーが検索結果からどのサイトを選ぶか決めている時に、検索ユーザーにとって親しい人からのおすすめ(= +1 ボタン)の情報が検索結果に表示されるため、あなたのサイトを目立たせることが可能となります。

+1 ボタンに関するさらに詳しい設定方法は、 Google Code サイト をご確認ください。

アフィリエイトを導入されているウェブマスターの皆さまへ

14 years 5ヶ月 ago
アフィリエイト プログラム を利用した、いわゆるアフィリエイト サイトは今では広く普及しており、多くのサイトが効果的にアフィリエイトを活用しています。しかし、中にはアフィリエイト プログラムが提供したコンテンツしかないようなアフィリエイト サイトも多く見受けられます。Google の ウェブマスター向けガイドライン には、「アフィリエイト プログラムに参加している場合は、サイトを訪れるユーザーにとって価値のある内容であることを確認する。独自性や関連性があるコンテンツ を提供して、サイトにアクセスする目的をユーザーに提供します。」といった記述があり、ご自身のサイトがガイドラインに違反しているかどうか気になる方もいるかもしれません。そこで、本日はどのようなアフィリエイト サイトがガイドラインに違反するか、具体的に考えてみたいと思います。

アフィリエイト サイトには様々なサイトがあり、独創性にあふれるコンテンツの中にごく一部分アフィリエイト リンクを掲載しているようなサイトもあります。しかし一方で、アフィリエイトによる宣伝の部分 がなければまったく中身がなくなってしまうようなサイトもあります。このようなアフィリエイト プログラムが提供したコンテンツしかないようなサイトは、ガイドラインに違反している可能性が高いといえるでしょう。なぜなら、そのようなサイトはアフィリエイト先のページで得られる情報以外に何の付加価値もユーザーに提供していないからです。

中にはユーザーに付加価値を提供するためではなく、ガイドライン違反をなんとか回避しようと、わずかにテキストを追加するケースも見られます。例えば、こんなサイトです。


このような短いエントリーが商品ごとに数十、数百も登録されたブログを見かけたことはありませんか?このようなテキストは誰でも(たとえその商品についてよく知らなかったとしても!)簡単に作成できるテキストであり、独自コンテンツがこれだけの場合、ユーザーにとって有益であることは少ないでしょう。こうしたサイトが長く Google の検索結果で上位表示されることはほとんどありません。アフィリエイトを利用し、検索結果にも表示させたい場合は、一度ユーザー目線でサイトを見直し、ユーザーが繰り返し訪れるようなサイトを目指しましょう。そのためにはまず、他のサイトにはない独自コンテンツを考えてみることをお勧めします。

では独自コンテンツを作るにはどうすればいいでしょうか。ここで独自コンテンツの作り方はこうです、とご紹介するのはなかなかの難問です。なぜなら誰でもたやすく作れるものが、価値ある独自コンテンツであり続けることは稀だからです。ですが、まずはあなたの専門性の高い領域について、他のサイトではまだ取り上げられていない情報や切り口を探してみてはいかがでしょうか?また、もしあなたが専門家でなかったとしても、たとえばあなたが宣伝するその商品の、あなた自身の体験談を写真付きでまとめてあれば、それは立派な独自記事です。あなたの記事を参考にして、あなたに感謝する人も出てくることでしょう。

もし皆様の周りに今回ご紹介したような独自性の少ないアフィリエイト サイトを作っている方がいましたら、ぜひこのブログ記事をご紹介ください。ご意見・ご感想は、ウェブマスター ヘルプフォーラム までお寄せください。

確認済み
2 時間 53 分 ago
Google フレンドリーなサイト制作・運営に関するウェブマスター向け公式情報Unknownnoreply@blogger.comBlogger443125
Google ウェブマスター向け公式ブログ フィード を購読

人気記事トップ10

人気記事ランキングをもっと見る