大量のリンク否認が完了するまでには9か月かかることもある
海外のSEO/SEM情報を日本語でピックアップ
大量のリンク否認が完了するまでには9か月かかることもある
再クロール・再処理が必要だから (English Google Webmaster Central office-hours hangout)
大量のリンクを否認した場合は、すべての処理が完了するまでに3~9か月ほどかかることがある。
グーグルのジョン・ミューラー氏は、Google+のハングアウトオンエアを利用して開催したウェブマスター向けオフィスアワーでこのようにコメントした。
リンクが実際に否認されるには、そのリンク元ページの再クロールがまず必要だ。そして否認ファイルそのページが含まれているかどうかがチェックされ、含まれていれば実際の否認処理に入る。
ページによってはクロール頻度が低く、数か月に1回程度しかクロールされないこともあるだろう。リンク元ページの数が多ければ多いほどその確率は高まる。このような理由で、膨大な数のリンクを否認が実行されるまでには、非常に長い時間を要することがあるのだ。
否認ファイルを今日アップロードして、明日すぐに否認が処理されるということでは決してない。
過去に犯した悪事を清算するには多大な労力に加えて、長い長い待ち時間も必要になりそうだ。もっとも健全にサイトを運営してきたウェブ担当者には関係のない話だが。
Bingが採用している3つのモバイル検索ランキング要因
GoogleのモバイルSEOでも重要 (Bing Webmaster Blog)
米Bingは、モバイル検索結果を向上するための取り組みを公式ブログで説明した。
モバイル向けサイトのランキングを決定する際にBingが判断しているという項目は、次のようなものだ(捕捉は筆者による)。
コンテンツの互換性 ―― PCからでもモバイルからでも、同じコンテンツをユーザーが入手できるようにすること
コンテンツの読みやすさ ―― フォントの大きさや色、行間スペースなどに気を払い、画面の小さなモバイル端末でも読みやすくすること
モバイルの機能性 ―― モバイル端末に対して不適切に構成しないこと。モバイルだけに404を返す、モバイルで再生できないFlashを使う、すべてトップページにリダイレクトするなどをやってはいけない
また、Bingはこのようにアドバイスもしている。
理想的なのは、モバイルフレンドリーなURLとPC向けのURLを同じにすることです。サイトが、コンテンツやレイアウトなどすべてを端末に応じて自動的に調整するということです。
これが理由で、モバイル向けの別URLのサイトよりもレスポンシブウェブデザインを私たちは推奨し続けるのです。すべてのデバイスのユーザーに優れた体験を確実に提供し、互換性と読みやすさ、機能性の問題が起こるのを防ぎます。
またモバイル用のクローラが必要なリソースにアクセスすることを許可する推奨事項にも、必ず従ってください。
グーグルと異なり、Bingは絶対的にレスポンシブウェブデザインを推奨しているのが特徴だ。別々のURLで構成されたモバイル向けサイトを勧めていない。
そうはいえど、Bingがランキング要因にしているという3項目は、ユーザー体験を高めるために検索エンジンの違いを問わず重要なものなので、理解しておいてほしい。
また、モバイル向けサイトのレンダリングに必要なJavaScriptやCSS、画像などのリソースへのクロールはrobots.txtでブロックしてはいけない点も、Bingにおいてもグーグルにおいても共通だ。
400番台と500番台のHTTPステータスコードの違い
403と404、410はインデックスから消えるので注意 (Gary Illyes on Google+)
エラーを示すHTTPステータスコードの違いについてグーグルのゲイリー・イリーズ氏がGoogle+で説明した。
エラーを示す400番台と500番台のHTTPステータスコードは、グーグルではそれぞれ異なるかたちで処理される。
たとえば、「403」「404」「410」のステータスコードは、かなり速くインデックスから削除する要因になる。なぜなら、それらのページではユーザーは何も手に入れられないからだ。
一方「503」のステータスコードをページが返すと、しばらくの間はそのページをインデックスに保っておく。なぜなら、503は一時的なサーバーの問題を意味し、そのページにユーザーは再びアクセスできると思われるからだ。
異なる状況でどのステータスコードを返すかを決める際にはこうしたことを覚えておいてほしい。503の代わりに403のステータスコードを返していたために、大量のページが インデックスから消えてしまった大規模サイトがあった。
原則的に、意図的にページを削除したときは404か410を返す。メンテナンスなどで一時的にアクセスを停止するときは503を返す。これが基本だ。
Web担当者としてよくわからない場合でも、サーバーを管理している人にこうしたことを理解するように伝えておくことは重要だ。
特定のJSとCSSだけのクロールを許可したいがrobots.txtはどう書けばいい?
robots.txtでAllowを使えば簡単 (WebmasterWorld)
最近の公開されたグーグルの推奨に従ってJavaScriptとCSSへのクロールを許可しようと思う。ところがクロールさせたくないリソースも同じディレクトリに一緒に入っている。
どうしたらいいだろうか?
このような質問がWebmasterWorldフォーラムに投稿された。
拒否ではなく許可を明示するAllow構文をグーグルはサポートしているので難しいことではない。
たとえば、「resources」ディレクトリは全体としてはクロールを拒否するが、そのなかにある、ページのレンダリングに必要なabc.jsとxyz.cssへのクロールだけは許可するとする。次のようにrobots.txtに書ける。
# resourcesディレクトリのクロールを拒否
User-Agent: *
Disallow: /resources/
# abc.jsとxyz.cssのGooglebotのクロールを許可
User-Agent: Googlebot
Allow: /resources/abc.js
Allow: /resources/xyz.css
現在のグーグルのrobots.txtに関する仕様では、「Allow」と「Disallow」の順序は関係なく、より具体的な指定のほうが優先される。上記の例では、「/resources/」よりも「/resources/abc.js」「/resources/xyz.css」のほうがより正確な指定なので、そちらが優先される。
期待どおりに動作するかどうかはウェブマスターツールのrobots.txtテスターで事前に検証するといい。またrobots.txtを実際に更新したら、robots.txtテスターから通知しておくといい。
Firefoxの検索エンジンがグーグルからヤフーへ切り替わる(少なくとも米国では)
米国向けサイトでは影響があるかも (The Mozilla Blog)
Firefoxブラウザの既定の検索エンジンがグーグルからヤフーに切り替わることになった。Mozillaと米ヤフーの間における、12月から今後5年間の提携になる。
ただし米国に限った話だ。欧州や中国、ロシアには関係しない。日本にも関係ないはずだ。
これまでは、Firefoxの検索ボックスでウェブ検索をする際に利用される検索エンジンとしては、長らくグーグルがデフォルトになっていた。それがヤフーに変わるということだ。
米国向けのサイトを運営しているならば、多少なりとも影響を受けるかもしれない。StatCounterのデータを参照すると、米国におけるFirefoxのシェアは現在約15%になっている。今年に入って減少してはいるが、無視できる数字ではないように思える。
米ヤフーは米Bingを検索エンジンのシステムとして利用している。グーグルだけでなく、Bingにどのように管理サイトが評価されているかも把握する必要が今後は出てきそうだ。
SEO Japanの
掲載記事からピックアップ
SEO記事がなかったので、コンバージョン率アップの参考になる記事を今週はピックアップ。
- コンバージョン率改善で最初、二番目、三番目にテストするべき3項目
コンバージョン率改善の基本ステップ
ソーシャルもやってます!