web>SEO

4月25日に開催された、HTML5とか勉強会の第29回、「HTML5ビジネス最前線（B2C編）」のパネルディスカッションにパネラーとして参加しました。

HTML5とか勉強会は、HTML5の世界で高名な白石俊平さんが主催されている勉強会で、申し込み開始してもあっという間に100名以上が申し込んで満席になってしまう人気の勉強会です。
HTML5は私も勉強したいテーマですので、何度も申し込もうとしていましたが毎回撃沈。それを裏口参加(?)できただけでも嬉しいものでした。

私が参加した第28回は「HTML5ビジネス最前線（B2C編）」という内容。

全体のレポートはgihyo.jpの記事「第28回　HTML5とか勉強会　HTML5ビジネス最前線（B2C編）」活動報告」に詳しいので、宜しければ御覧ください。

パネルディスカッションはHTML5に様々な立場から関わる5名がパネルとして「HTML5でビジネスはどう変わった？どう変わる？」がテーマ。モデレータの白石さんを始めとしてHTML5の専門家やHTML5に日々関わられている方の話は、私にも勉強になるものでした。
私は門外漢でしたが、SEOの観点でのHTML5についてはひと通りお話できたかなと思っています。

その場でお話した事や、改めてSEOとHTML5について考えた事をまとめておきます。

SEOとHTML5

以前「SEOで大事な事を3つ上げると？」と聞かれたときに、「キーワード」「リンク」「論理構造化」の3つだと回答しました。

HTML5はより論理的なHTMLを書く事ができるわけですので、ページを論理構造化しやすいHTML5とSEOは本来非常に相性が良いもののはずです。
しかし現段階ではGoogleの順位評価においてHTML5をプラスにもマイナスにも使っていない、ということが繰り返し語られています。

複数の経験上、この事は現段階で信頼に足る情報と考えています。

しかし、HTML5はSEO観点で何も考えなくていいわけではありません。
私が考える「HTML5とSEOを考える際に注意すべきポイント」は、3つあります。
「現状プラスもマイナスもない」「リッチスニペットでは重要」「リスクもある」です。

現状ではHTML5の新規要素はSEOにプラスもマイナスも無い

HTML5をSEO観点で考える上で一番目を引くのは、nav要素やaside要素などの、論理的な意味を持った要素の追加でしょう。
またsection要素の入れ子でHTMLで論理構造を作りやすくなってもいます。

しかし現段階ではHTML5の新要素を検索エンジンが評価しない、と考えるべきでしょう。
論理的な意味を持つ新要素をGoogleが評価した場合、HTML5とHTML4では明らかな有利不利が現れます。
当然ながら、HTML5で書かれたWebページはHTML4で書かれたものに比べて価値があるわけではありません。検索ユーザが検索したいのは役立つコンテンツであって、新しい仕様を使ったり綺麗なHTMLコードで書かれたWebページではないでしょう。
もしもHTML5を有利にしてしまった場合、順位上で一部の先進的Webサイトが有利になることになりますが、それは検索ユーザが望むものにはならないはずです。

また、HTML5などの内部要因はスパムへの転用も簡単です。ページの構造認識のような重要な部分の操作を簡単に出来るようになった場合、一番喜ぶのはスパマーでしょう。

これらの事は、ユーザの検索体験を良くすることに繋がらない事は明白です。

そのため、現状ではHTML5を大きな検索順位の評価には使いづらいと言えます。
現段階での、順位上昇を目的としたHTML5化は無意味なものになってしまいます。

リッチスニペット観点では重要

Googleにおいてリッチスニペットを表示させる場合、Googleの定める独自仕様またはschema.orgで定義された仕様でセマンテックに記述する必要があります。
その記述方法で、最も容易に行えるのはHTML5のmicrodataです。

もちろん、HTML5でないと記述できないわけではありません。
Googleは、schema.org発表前のRDFa等のサポートを今後も継続すると発表しています。
さらに、現段階ではHTML4にmicrodataを書いても、Googleは一応認識してくれます。
また、schema.orgはRDFaにも対応するという発表も2011年11月に行なわれています。

しかし、microdataのみに対応しようとしていた時期が有りました。2011年8月にGoogleが発表して、英語環境では検索結果への表示も行われている「音楽」のリッチスニペットでは、microdataしか使えないschema.orgでしか対応できなかった実例もあります。

今後の流れ次第では変わる可能性はありますが、最もリッチスニペットと適合性があるものはmicrodataであることは確かでしょう。
もしも、様々なコンテンツの展開を予定しているWebサイトであれば、今後の検索エンジンの対応が最も確実なmicrodataが記述できるHTML5としておくのが安全と言えます。

HTML5はSEO観点でのリスクもある

GoogleはHTML5をプラスにもマイナスにも評価しない、という事を何度も述べていますが、一部状況においてはマイナスにはなる可能性はあります。

下記の2点には、特に注意が必要です。

h1多用は怖い(かも)

正しいHTML5を書くと、ひとつのページに複数のh1要素を含む事になりがちです。

昔「h1にキーワードを含めると順位が上がる」などと言われていた時期もありますが、今はそんなことありません。しかし文書の構造の解析において検索エンジンがhx要素を活用していることは明らかですので、h1要素はSEOでは重要な部分となります。

ページに一つだけのページテーマを示す場合が多かったh1要素を複数持つ事は、以前はSEO観点でマイナスとなることがありました。
現段階で、Googleが正しく組まれたHTML5での複数のh1要素を、結果的にマイナスに扱っていると判断できる事例は見たことがありません。
しかし以前はマイナスだったことを行うのは、いつアルゴリズムが調整されるか分かりませんし恐ろしい事です。また、Googleより劣った検索エンジンが正確に評価できるとは限りません。

HTML5を正しく記述する上で複数のh1記述は避けづらいですが、やはり若干注意を払うべきと考えます。

これは私見ですが、ユーザにわかりやすいページをHTML5で正しく論理構造化した場合、非常に多くのh1要素を含むようなページにはならないのではないでしょうか。あまりに多くのh1要素を含むようなページだった場合、ページの情報の論理構造から見なおしてみるべきかもしれません。

iframeの不安

HTML5では新しい要素が追加されただけではなく、復活した要素もあります。
その中で、HTML4のstrict条件で排除されていたiframe要素が復活する予定なのはSEO観点では大きな不安があります。

iframe要素は、検索エンジンが認識しづらい要素です。検索エンジンのiframeの扱いは複雑なので一概には書けませんが、検索エンジンに評価されたい部分をiframeで表現するのは避けるのがSEOでの常識です。

しかし、HTML5でiframeが復活したことが影響しているのか、最近のWebサイトでiframeが使われているのを見ることが増えたように感じます。

今後、検索エンジンがiframeを正しく解釈できるようになることもあるかもしれません。しかし、やはり現段階では評価しづらいものであって、それを評価するのは相当先だろう、と私は推測しています。
たとえHTML5の仕様が許したとしても、検索エンジンに認識させたい部分をiframeで記述するのは避けるべきでしょう。

HTML5とSEOの今後

これまで書いてきました通り、現段階ではHTML5化はSEOにはプラスは無い、という事が言えます。

しかし「現段階」に限った話です。

最初に述べた通り、SEO観点で重要な論理構造化をHTML5では行いやすいです。今後、HTML5で記述すると検索エンジンがより的確にページを認識してくれるようになる可能性は極めて高いと考えられます。

さて、その今後はいつになるでしょう？
私にはわかりません。それはHTML5の普及次第と考えます。HTML5がより普及して、多くのWebページがHTML5の論理構造化とセマンテック化が行われた状態で記述されるようになれば、検索エンジンもより精度の高い検索結果を作るために、それらの情報を使い出す事でしょう。

WebページをHTML5対応は、レガシーブラウザ対応が難しいなど困難な部分もあります。しかしHTML5としておくことで今後高い確率でプラスとなるのであれば、充分に検討の余地はあるはずです。

長期間使っていくWebサイトであれば、今後行う新規構築・リニューアル時にHTML5としておくことは、長期的なSEOの観点でも是非お勧めしたい事です。

---

最後に、この勉強会に参加くださっていた方々、お聞き下さって有難うございました。
また、パネルディスカッションにお声掛けいただいた白石さん、本当に有難うございました。

canonicalは、GoogleとYahoo!、マイクロソフトが共同で策定した仕様です。
正しいサイトのURLを検索エンジンに指定することができるもので、これをうまく活用すると重複コンテンツやリンク価値の分散、無駄なインデックスのなどの様々な問題を防止することができます。
特に大量の動的ページを含む大規模サイトでは様々な意図でcanonicalが活用されていて、canonicalは無くてはならないものになっているサイトも少なくありません。

しかしcanonicalを活用しているのは検索エンジンだけではありません。Facebookやはてなブックマーク、Twitterなどソーシャルメディアもカノニカルを参考にしています。
そのような中、canonicalを検索エンジン対策、SEOのためだけに使っているとソーシャルメディア側で問題が起きる場合もありますので注意が必要です。

実際にどのような形でフェイスブックがcanonicalを使っているのかを紹介します。

Facebookとcanonical

Facebookは、2012年5月現在、canonicalを使っています。

少しわかりづらいですので、実例で見てもらおうと思います。
下記をテストでやってみました。

1. nothing.htmlはog:urlもcanonicalも指定していません。
2. onlyogurl.htmlはog:urlをog_url_saki.htmlに指定して、canonicalは指定していません。
3. both.htmlはcanonicalをcanonical_saki.htmlに、og:urlをog_url_saki.htmlに指定しています。
4. onlycanonical.htmlはcanonicalをcanonical_saki.htmlに指定して、og:urlは指定していません。

当然ですが、通常FacebookのタイムラインでURLをシェアすると、シェアしたURLのタイトル・説明文・サムネイルが表示されます。
では、上の場合にはどのURLのタイトル、説明文、サムネイルが表示されるでしょうか？

Facebookとcanonical実験結果

og:urlもcanonicalも指定しない場合

og:urlもcanonicalも指定しない場合、当然ながらシェアしたページのサムネイル、タイトル、説明文が現れます。

og:urlだけを指定した場合

上のページと同じソースで、og:urlだけを追加したものがこちらです。

og:url先のタイトル、説明文に変化しました。元のURLは無視して、og:urlのOGPで指定した内容が表示されます。
なお、この場合、表示される内容がog:url先になりますが、クリックした場合に飛ぶリンク先は、シェアしたURLのままになります。

og:urlとcanonicalを指定した場合

今度はog:urlとcanonicalを追加してみました。

両方指定しても、og:url先のタイトル、説明文が表示されています。

canonicalだけを指定した場合

og:URLを外してcanonicalだけ残してみました。

og:urlが無く、canonicalを指定した場合には、canonical先のタイトル、説明文が表示されます。
なお、この場合、表示される内容がcanonical先になりますが、クリックした場合に飛ぶリンク先は、シェアしたURLのままになります。

なお、上記のテストを試すときは、それぞれ下記のページを公開範囲を自分のみなどにしてシェアしてみてください。

• og:urlもcanonicalも指定しない場合
• og:urlのみを指定した場合
• og:urlとcanonicalの両方を指定した場合
• canonicalのみ指定した場合

Facebookは一部状況でcanonicalを使っている

上記の実験の通り、現在のFacebookは下記の仕様としてcanonicalを使っています。

• og:urlを設定せずにcanonicalを設定していると、タイムラインに表示されるサムネイルや文章はcanonical先が表示される
• 変化するのはタイムラインに表示されるサムネイル、タイトル、説明文だけで、リンク先は変更されない。

この仕様が問題になる事はあまり無いと思いますが、canonicalの使い方によっては充分に有りえます。

紫色のシャツのページを「この色は趣味悪いね」とシェアしたつもりが、Tシャツの総合ページと白いＴシャツのサムネイルが表示されてしまうかもしれません。

また、以前Googleが推奨していた方法で、多国語展開するWebサイトは一つの代表的な言語のページにcanonicalを指定するべきケースが稀にあります。「イギリス版ページをシェアしていたはずが、アメリカ版のタイトルが表示されていた」という事もあるかもしれません。

さらに、失敗したcanonical設定だと様々な問題が発生し得るでしょう。

情報が異なるページに対してcanonicalを指定する時には、セットでog:urlを指定するようにするべきでしょう。

はてなブックマーク・Twitterとcanonical

検索エンジン以外でcanonicalを見ているのは、Facebookだけではありません。

はてなブックマークは、Chrome等の拡張機能でブックマークをするときにcanonical先のURLを提示して「このページには別のURLが提示されています」と推薦してくれます。

通常でははてなブックマーク数が集中しやすくなるので便利ですが、無料ブログのBloggerなど特殊なcanonicalの使い方をしている場合や誤ったcanonicalの使い方をしていると、はてなブックマークユーザを混乱させてしまいます。

また、Twitterも一部canonicalを使っています。
Twitter公式のツイートボタンにはツイート数が表示されるものがありますが、canonicalを指定しているとcanonical先のツイート数も配慮して表示してくれます。

ソーシャルメディアをふまえたcanonicalの注意点

canonicalは「ほぼ同じ情報のページに指定するもの」という仕様でありつつ、本質的に同じ情報ならばある程度違う情報でも問題ありません。

また、ほぼ異なる情報であったとしても検索エンジンが許容する場合もあります。例えばコンテンツを100ページに分割したものと、それを1ページにまとめたものがあった場合、それぞれの1/100のページから1ページに指定する事もGoogleが公式に認めています。情報としてはcanonical元はcanonical先の1%の情報しか含んでいないにもかかわらず、です。
さらに、GoogleのMatt Cuttsのブログのカテゴリページの2ページ目以後から1ページ目にcanonicalを指定している例をみましても、インデックスの制御のためにcanonicalを使うことも充分に許容範囲のようです。

もちろんスパムを意図としたcanonicalはリスクがあるのは当然でしょうが、canonicalは様々な用途で使うことができます。
しかし本来は「本質的に同じ情報」に指定するものです。

canonicalは実装当初の異様なまでの強力さは少し抑えられてきました。しかし現状でもまだまだ強力です。その分、乱用や指定ミスは致命的な事態を招きます。
そして、本来の仕様とは異なる使い方をしていると、今回のような検索エンジン以外が使う場合に問題が発生する可能性もあります。

canonicalは非常に便利ですので多くのサイトで採用されています。今後canonicalが更に多く使われるようになると、そのデータを様々なWebサービスが使うようになっていくのかもしれません。
非常に便利であっても、自信がない場合は利用は避けるべきでしょう。

Webサイトがマルウェアに感染した場合、検索結果や一部ブラウザからアクセスできなくなります。
これはGoogleも協力しているstopbadware.orgのデータを検索エンジンやブラウザが使ってマルウェア・ウィルス感染がさらに広がらないようにするセキュリティ対策です。

時々、検索結果でサイトがマルウェア扱いとなっているのを見ることがあるでしょう。しかし、実際にウイルスに感染した側の立場になることは少ないはずです。実験で感染サイトを放流して攻撃サイトを作るのも微妙ですので、試すのも難しいです。

2月上旬に友人の運営しているサイトがMalwareに感染してしまい、検索結果に下のような表示、「このサイトはコンピュータに損害を与える可能性があります」と表示される状況になりました。

私がGoogleウェブマスターツールでの対応をして復旧させたのですが、その際の挙動を公開しても良いという許可をもらえましたので、経緯と、気づいた点を書いておきます。

これは2月上旬段階の話で今は変わっているかもしれませんし、サイトの規模や状況によっていろいろと変わってしまうかもしれません。しかし、感染時にどうなるのかを共有している記事はあまり見ませんでしたので、少しはご参考になるかもしれません。万が一、自分のサイトが感染した時のために、どうぞご覧下さい。

マルウェア感染対応の経緯

感染したサイトは、友人が運営するWebサイト。約100ページのメインサイトと、サブドメインで展開されている400ページ強のブログ、別ドメインで展開されている300ページ弱のECサイトが含まれています。
今回、ブロックされていたのは、メインサイトとブログ。ドメイン全体がブロックされた形で、別ドメインは無傷でした。

検索結果でのブロック開始後数時間でその事に気付けました。おそらくは、マルウェア感染後半日も経っていないのでは、と思われます。

検索結果では「このサイトはコンピュータに損害を与える可能性があります」と表示されてアクセスできませんし、直接URLを叩こうとしてもマルウェア対策機能が付いているFirefox、Chromeともにアクセスできません。
Firefoxで開こうとすると「この Web ページ(URL)は攻撃サイトであると報告されており、セキュリティ設定に従いブロックされました。」というような表示でアクセスできなくなっています。
最新のブラウザでは、このようなマルウェアやバッドウェア、フィッシングサイトなどをブロックするようになっています。
……ちなみに、私の環境のIE9ではアクセス出来ました。

慌ててFTP情報を持つ友人と手分けして作業を開始。ミイラ取りがミイラにならないよう注意しつつ問題を特定。HTMLファイルをダウンロード。マルウェアのコードを全部消して再アップロードをする作業を友人が開始します。

その間に、私の方でGoogleウェブマスターツールに新規登録。
登録した段階でこのようなアラート画面が表示されていました。

ウェブマスターツールのメッセージは届いておらず、Googleウェブマスターツールのトップと、このマルウェアページだけに警告が表示がされています。

その後すぐに友人の作業が終わり、マルウェアのコードを削除済な事を確認してマルウェア専用の再審査依頼を送信しました。

その後4時間経ちましたが検索結果でのブロックは解除されません。
再度Googleウェブマスターツールを見ると、上記画像の表示が少し変わって具体的に感染した1ページのURLが表示されていました。
初期には上のキャプチャのように感染していることだけが表示されますが、少し時間が経つと具体的にURLが出るようです。

確認するとそのページはまだ感染したままでした。

そのページの修正後、また再審査依頼を送ろうとしたものの「再審査依頼を受けたばかりなので受け入れられない。数時間待て」というようなメッセージが表示されて送信ができません。

マルウェアは削除済なので、再審査を送らなくても回復するかな？と思っていましたが、いつまで経っても検索結果・ブラウザでのブロックは継続しています。
結局、最初にマルウェアの再審査リクエストを送った12時間後にまた再審査依頼を送れるようになりましたので送信します。

その後、9時間後に検索結果でのブロックが解除され、ブラウザでのアクセスも可能になりました。
ブラウザでのアクセス可能化と、ほぼ同時刻でしたのでブラウザのマルウェアブロックに使われているstopbadware.orgのデータとGoogleのデータは連動しているのかと思います。

検索結果とブラウザでアクセスできる事を確認後Googleウェブマスターツールにログインすると、上の警告は消えていて下のようなアラートが「メッセージ」に到着していました。

解決後に確認できた、ちょっと遅い通知でした。

結局、ブロック開始後24時間強で復旧できたことになります。

マルウェア感染時のGoogle対応のポイント

マルウェア感染対応は今回が初めての経験でしたが、いくつか新しく発見したことがありました。
一度だけの経験ですので毎回同じようになるかはわかりませんが、感染した時のために覚えておいて下さい。

マルウェアの再審査依頼は12時間に1度

これが、今回の私の対応で失敗したポイントです。
マルウェアが1ページでも残ってしまっている状態でマルウェアの再審査依頼を投げた場合、その後12時間は再審査依頼が送れなくなります。

可能な限り早く復旧させたいと慌てて再審査依頼を送り、1ページでもマルウェアが残っていた場合には、さらに12時間余計にブロックされるということになります。
再審査依頼を送るときには、完璧に直してあるかをしっかり確認するのが、結果的に時間の節約になるでしょう。

Google ウェブマスターツールは重要

今回、一度全部マルウェアを削除したと思っていましたが、Googleウェブマスターツールのお陰で残っていることに気づくことが出来ました。
もしもGoogleウェブマスターツールに登録していなければ、更に数日「マルウェアを消したのにブロック解除されない！」とやきもきすることになっていたはずです。

Googleウェブマスターツールが様々な面で有益なことは明らかです。もしも登録していないWebサイトがありましたら直ちに登録されることをお勧めします。

ブロックされる範囲はドメイン全体

今回感染していたページは、サブドメイン無しのページ(例:http://example.com/)だけでした。しかし感染していない別のサブドメイン(例:http://hoge.example.com)もブロックされました。

サブドメインだけが感染した場合はサブドメイン無しのページがブロックされないのではと思いますが、自信がある事ではないです。そんなことができたら無料ブログサービスを簡単に潰せますし。
しかし、親から子へはブロックが引き継がれるのは確認できました。

マルウェア感染に備えてドメインを分けておくなんて事は笑い話でしょうが、万が一のときにはそうなる事を覚えておくべきでしょう。

Googleウェブマスターツールのアラートメールは遅い

検索結果でブロックされて、Googleウェブマスターツールで警告が表示されるようになっても、まだ「メッセージ」にアラートは到着していませんでした。おそらくはメール転送のアラートも送信されていないと思われます。

今回Googleウェブマスターツールの「メッセージ」にアラートが届いたのは、ブロックが開始されてから最短でも10時間以上経ってからになります。

こちらのGoogleウェブマスターヘルプの記述によると、様々なメールアドレス宛に別途メールが流れているようです。この記述を信じるのであれば、このメールは比較的早く来るのではないかと思います。

今回はこのアドレスのメールを受信していなかったため、直ちに感染に気づくことはできませんでした。
スパムメールも来てしまうアドレスではありますが、万が一に備えて、受信出来るようにしておくべきでしょう。

マルウェア削除後、再審査依頼を送ると数時間で復旧

今回のサイトの場合、再審査依頼の後10時間弱でブロックが解除されました。
百ページしか無いWebサイトなので10時間だったのかもしれませんが、思ったよりも短い復旧です。

マルウェア感染とGoogle

マルウェア感染時には「完璧にマルウェアを削除した後」で「Googleウェブマスターツールで再審査依頼を出す」ということが重要なポイントです。

自分は大丈夫と思っている人でも、なにかの機会に感染してしまうかもしれません。FTPの接続情報を誰かに預けている場合、その人からの感染もありえます。
誰でも「ありえない」と言い切れないと思いますので、もしも感染された際には参考にしてください。

数年前はWebページ感染型のマルウェアは、あっという間に広がっていって大騒ぎになっていました。しかし今は簡単には感染しづらくなりました。最新のブラウザでは危険なサイトを表示することができませんし、古いブラウザでも検索結果という訪問経路が閉ざされて、感染した人への通知も行われるようになりました。その多くの部分を膨大な量のクローラを保持していてウェブマスターへの連絡もできるGoogleが果たしているのかと思います。

マルウェア感染する機会が減りましたので、多くの方にとってマルウェアの問題に絡む事は滅多に無いか思います。そのようなあまり発生しないけれども発生すると大きな問題となる部分で、Googleがその役目をしっかりと果たしているのですね。

今回、「このサイトはコンピュータに損害を与える可能性があります」の解除を実際に体験することができましたが、まだ私が気づいていない部分で非常に重要な役割を果たしている部分もあるのかもしれません。
やはり、Google先生は流石です。

さて、マルウェア感染対策について今からできることは、感染をしないように注意することはもちろんですが、万が一感染した時にすぐに対応出来るように、Googleウェブマスターツールにしっかり登録した上で、いざというときにすぐにログインして対応出来るようにしておくことをお勧めします。