Google、スマホ対応サイトをモバイル検索結果で優遇するアルゴリズム変更を発表、4月21日から適用

Googleは、スマートフォン利用に最適化されたサイトが「モバイルでの」検索結果で優遇されやすくなるように変更すると発表しました。この変更は2015年4月21日より実施されます。

2015年、確実に成果を出すためのSEOの方程式

土居です。この記事では僕がSEOに携わるときにほぼ例外なく考えているイメージを可視化してお伝えします(脳内整理も兼ねて)。初心者の方は全体観を把握するために、実務者の方は思考の整理に、それぞれ一助になれば幸いです。

「クロールバジェット」という言葉について

何やら「クロールバジェット」という言葉が最近お客様の一般的に使われているのを聞くということで先週くらいに社内でちょいちょい話題になっていました。

クロールバジェット(Crawl Budget)って何ですか

簡単に言うと、「このサイトは1日あたりこれくらいクロールしますよ」という上限値(Budget)をPageRankなどの指標を元にGoogleが割り当てており、このバジェットが低いとサイトが十分にクロールされません、みたいな雰囲気で使われる言葉です。

耳慣れない方には耳慣れないと思います。かくいう自分も業務上使ったことはないですしそんなに話題になることもありません。たまに海外のフォーラムなどで話題になっていることはありますね。

で、そもそもGoogleの公式で出ている言葉でしたっけと思って英語圏の公式サイト巡ってみましたが現時点ではGoogleの公式情報では確認できていません。Googleの技術的な用語というよりも便利な造語という捉え方をした方が良いかもしれません。

諸情報によると以前行われたWeb系のイベントでGoogleの方が「(クロールバジェットという概念は)Googleには存在しない」と発言もされていたようでして。ということで、まあ言葉としてはなかなか曖昧なものとして捉えておいて良いのかなと考えています。

で、言葉の説明についてはそれくらいにしまして、ここから本題。

あろうがなかろうが、考え方としては重要

仮にクロールバジェットなるものが存在するとした場合、単純に考慮すべきポイントは以下です。

・より多くのクロールバジェットを確保するためには多くのリンク(=高いPageRankやAuthority)を得ていることが重要
・クロールリソースは無限ではないので、無駄遣いさせない工夫が必要

そしてこれはクロールバジェットなるものがあろうとなかろうと、とても大きなサイトを運営している方にとっては非常に重要なSEOの要素だと認識しています。

クロール絶対量を増やしてサイトを十分にクロールさせる

ページがクロールされるのはクローラーがリンクを辿る中でURLを発見できるからであり、ほとんどリンクを得られていないページと多くのサイトからリンクをされているページでは後者の方がクロール対象になる確率は高くなります。

全体のクロールリソースが一定だとすれば、クロール対象になる確率が高い(=クロール中にリンクURLが発見される機会が多い)ということはクロールされる絶対量が増えるということです。

つまりクロールの絶対量を増やすのであれば、より多くのリンクを獲得することがそれに直結すると考えて良いでしょう。これはクロールバジェットの考え方と相反することはありませんね。

注意:SEOにおいてリンクを軽視する傾向はダメ

話題がそれるので別途まとめようと思いますが、コンテンツ重視の流れになってきているなか、逆にリンクが軽視されつつあるように思います。これは全くもってダメな流れと思います。

誤解を恐れずに言いますと、今のGoogleはまだまだ“Link is King”を否定できない検索結果です。すなわち今のSEOにおける最重要業務の一つは以前と変わらずリンクを獲得することと断言して良いと思っています。

変わってきているのは、そのプロセスとして人工的な簡易サイトからリンクをもらって順位を上げるような旧来の施策がGoogleには淘汰されつつあり、その分なおさらコンテンツやプロモーションによってリンクを構築していくことが重要になっている、という話です。

リソースを無駄遣いさせないための工夫

仮にクロールリソースが有限だとした場合、全てのURLが確実にクロールされる保証はありません。従って、不要なページにリソースが割かれないよう、重要なページのクロールに集中させる工夫が必要です。

それは例えば無駄な重複コンテンツを発生させない仕組み、理論上URLが無限に生成される仕組みが存在するのであれば運営側でのコントロール、(本当に)クロール不要なコンテンツへのrobots.txtなどの制御、などです。

少なくとも、例えば全くリンクも得られていなくてクロールされる絶対量が十分でないのに、本来クロール不要なコンテンツばかりクローラーがたどっているといった状態は避けるべきでしょう。

注意:不適切なクロール制御は単なる逆効果

クロールを制御することはコンテンツの認識に大きく影響する施策です。テクニカルな意図でrobots.txtを乱用するとかnofollow埋め込みまくるなどは基本的にはほとんどのサイトで考えなくて良いはずです。

あくまでも「クロール不要なURL」とか「制御しきれないほどの大量の重複コンテンツや空ページ量産」などへの制御を場合によっては検討する、レベルで十分と思います。

単純な絶対量(Budget)の割り当て、というよりもクロールされる確率と優先度の問題かなと思いますがどうなんでしょうか

見出しの通りなのですが。絶対量ではなくて「URLが見つけられてクロールされる機会の多さ」「クロールされる優先度」なのかなと。優先度は、「重要な情報どうか」だけではなく「クロールに支障がないか」などによっても決められるんではないかと感じています。

  • 獲得しているリンクが多ければ、その分クロールされやすくなります。
  • どちらにせよサイトが無限にクロールされることはありませんのでリソースは有限です。
  • 有限なリソースなら、より効率よく重要なページがクロールされる工夫をしましょう

ということに加えて、例えばサーバーサイドでエラーが頻発するとか待機時間が鬼のように長い、みたいなことがあればそれは有限なリソースを食いつぶすことにも繋がりますので、そうしたサイトは必然的にクロールの優先度を下げられると考えて良いと思っています(これは体感でめっちゃ感じるところ)。

個人的にはこの(特にサーバサイドの)速度改善もクロール優先度を上げるために必要な施策と思っております。特に新規のサイトでコンテンツ量は多いけどリンクは集まってないし速度も遅い、みたいなサイトだと本当にSEOは全く機能しないなという印象です。

なんだかとりとめないですがここまでまとめますと、

  • 多くのリンクを集める
  • クロール負荷をかけないよう速度改善する
  • クロールを制御する(その必要があれば)

大きなサイトで重要なページのクロール絶対量を増やすために特に重要なポイントはこの3点でしょうか、と思っています。なんだか当たり前な感じになりましたけども。

以上です。ちょっとライトな話題ですが社内用メモとして書いておきました。(この辺り実務レベルでしっかり語れる方で補足頂けるようでしたら是非ご遠慮なくお願いします)

Googleより容赦無し?Appleのアプリランキング操作の『即アウト』的な排除規制が、実際わりと厳しい模様

同じ”ランキング”に関わるテーマでも、今回はiPhoneやiPadを代表とするiOSアプリを主題とした話題です。つまりGoogleでの検索ではなく、「App Store」の中の話です。とりわけ新情報というわけではありませんが、「本格的な動きが見られた」という意味では新しいかなと。

App Storeのランキング操作に関わる仕組みを持つiOSアプリがゴッソリとストアから排除されるように規制強化

ランキングの人為的な操作を排除することでユーザーの利便性の向上を図りたいのは、なにもGoogleだけではありません。ランキングの品質改善は、ユーザーにランキングを提示する仕組みを持つ多くのプラットフォームにとって、避けては通れない課題の一つなのです。

Appleのアプリストア「App Store」でも、ランキングの公正化のための取り組みとして、人為的にランクの操作をする目的のプロモーションを排除する動きが厳しくなっているということがつい先日、話題になりました。まとまっている記事としてはこのようなところをご覧頂ければと思います。

※2つ目、3つ目のURLについては、訂正も入れられていますが「規約がずいぶん厳しくなった」ではなくて「もともと言われてたことが本格的に実行されてきているようです」という意図ですね。タイトル内の「規約厳格化」の表記で誤解する人も中にはいそうでしたので、念のため補足。

“記事の公開時、「規約を発表」とありましたが、「すでにある規約を厳密に運用し始めた」の誤りでした。”

“以前からAppleはリワード付きの広告を禁止していた。しかし、実際には規約は厳格に運用されず、「厳密には違反しているようだが、何も言われない」という状況になっていた。”

 
さて、挙がっている話題をまとめますが、

“規制の対象となるのは、報奨で誘ってビデオの視聴をすすめるツール、ソーシャルに共有するとおまけがもらえるもの、プレイしているゲームの中でほかのアプリを見つけさせるもの、などだ。この規制はアプリ業界全体に影響を及ぼし、アプリの成長や市場拡大のためにこれまで一般的に使われていた方法を“リセットする”効果を持つだろう。”
ビデオを見たりソーシャルな共有で“ごほうび”をくれるアプリはApp Storeから締め出しへ…iOS 8の大改革

ということで、何かしらのインセンティブ(報酬)と引き換えにユーザーに何らかのかアクション(広告の閲覧、アプリのインストール、Facebookでのシェアなど)を求める仕組みを持つアプリは、アプリストアからリジェクトされる、つまりストアに掲載されなくなるということですので、その間は一切新規のインストールを獲得出来ません。重めです。

そういう規制がここにきて本格的に運用され始めたようです、というのが今回の話題の主旨となります。ここからは、この話題を背景から掘り下げて行きましょう。

App Storeの人気ランキングってどうやって決まるの

Appleのアプリストア「App Store」は、利用したことがある方は分かると思いますが、アプリの人気ランキングには、「総合」「有料アプリ」「無料アプリ」のような全体的なランキングと、「仕事効率化」「ビジネス」のようなカテゴリ毎のランキングが存在します。

アプリのランキングには、総合的なランキングとカテゴリごとのランキングがあり、有料アプリ、無料アプリ、どちらも含むランキングから探すことが出来ます

こうしたランキング決定ルールについてはGoogleと同様公表されてはおりませんが、やはり「一定期間内にどれだけ多くの人がインストールしたか」という要素は大きいようです

※もちろんGoogle検索と同じで、インストール数が全てではありませんが、主たるランキング決定要因の一つにはなっている、ということです。だからApple側としても本腰入れて規制をせざるを得ないわけです。

 

そして、iOSでアプリをインストールするユーザーのうち、App Storeの人気ランキングを参考にインストールするアプリを選ぶユーザーはやはり多く存在します。

従って、「一定期間のうちにどれだけインストールされるか」でランキングが上がるか上がらないかが決まり、ランキングが上がればその後のインストールの促進にもなるわけです。

つまり、iOSアプリにおいて継続的にインストールを増やすために、

  • 短期間でのインストールを増やし、人気ランキング上位に食い込む
  • App Storeユーザーへのリーチが増え、オーガニックなインストールも増える
  • その後も継続的に一定量のインストールを獲得し続け、ランキングを維持する

大きくこのような施策が一般的に行われています。

従って、まずは「短期間でのインストール促進」というのはこの流れの起点となることですので、ここが上手くいくかどうかがアプリマーケティングの鍵を握る、と言っても過言ではない状態でした。

何かしらの報酬を対価としてアプリのインストールを促進するプロモーションが普及

「何かしらの報酬を対価としてアプリのインストールを促進するプロモーション」て何やねん、ということですが、砕けて言えば「ここからこのアプリをインストールしてくれたら、コイン○枚プレゼント!」みたいなやつです。

逆に、「コイン○枚あげるから、その代わりこのアプリインストールしてよ」とも言えますね

そしてこういう形式でインストールを増やしまくったアプリが人気ランキング上位にいるというのは、何か本質的な「人気ランキング」と言うには違和感ありますよね、というのはWeb検索に関わる仕事をされている方であれば慣れ親しんだ文脈だと思います。

また直接的なインストール促進以外にも、同じような意図で、ポジティブなレビューの投稿やソーシャルメディアでのシェアを報酬付きで促すようなプロモーションも広く行われています。

とにかく、このようなランキングの人為的な操作につながるような行為を何かしらの報酬を対価としてユーザーに促すような仕組みについては、実はもとから規制するとされていました

しかし、Googleのかつてのガイドラインと同じく、「そんなこと言ったっていくらでもやれちゃうし、やってるやつたくさんいるし、現にランキング上がりまくりじゃん」状態であった、ということですね。

Google検索とApp Storeの違い

Google検索ランキングとの大きな違いとして、掲載されているコンテンツ(アプリ)は全てAppleの規定に基づく人的な審査を通過したものですので、Web検索よりも掲載時点でのコンテンツ品質をある程度は担保しやすい、という点が挙げられるかなと(App Storeの場合は審査時に体裁整えて通してしまえば、、という抜け道はあるのでしょうけど、さすがにいずれはその辺も対応されるかと思いますし)。

また、それに付随し、コンテンツ量はGoogleのように”兆”とかの規模にはなり得ませんので、あくまでアナログな規制であっても機能しやすいという点も今回の話題には直結します。(ちなみにApp Storeの場合は特定の仕組みを自動検出する精度とかはどうなんでしょうかね?)

したがって、Googleのようなアルゴリズム依存ではなく、プラットフォーム側の運用ルールをどのように引くか、どのように運用するか、という改善のみで大きく規制を加速することが可能ということです。

その前提で、Google検索のリンク売買のアレと比較すると

若干こじつけだったりしますが概ねこんな対比は分かりやすいかなと思います。

App StoreとGoogleで対比して考えます。  App Storeの事情。 ・インストールが多いアプリは人気があるというロジック ・だからインストールが増えるとランキングが上がりやすい ・何らかの報酬と引き換えにインストールを促す機能を持つアプリがある ・何らかの報酬を払って得たインストールでランキングをあげようとしているアプリがある ・ユーザーの自発的なインストールでないのであればランキングに反映したくない ・報酬と引き換えにユーザーにアクションを促す機能を持つアプリに規制を入れる ・アプリストアからのリジェクト(排除):ストアに掲載されない ・問題となる部分を修正して再審査を行い、問題がなければ規制解除  Google側の事情。 ・リンクがたくさんあるサイトは人気があるというロジック ・だからリンクが増えるとランキングが上がりやすい ・何らかの報酬と引き換えにリンクを提供しているサイトがある ・何らかの報酬を払って得たリンクでランキングを獲得しているサイトがある ・ユーザーが自発的に貼ったリンクでないのであればランキングに反映したくない ・報酬と引き換えにリンクを提供しているサイトに規制を入れる ・検索結果からのインデックス削除:検索結果に表示されない ・問題となる部分を修正して再審査を行い、問題がなければ規制解除

という感じですね。Googleに慣れている方であれば特に違和感なく飲み込める話題だと思います。

今回のケースはGoogleのリンク売買の例に例えれば「リンクを売っているサイトは問答無用でインデックス削除ね(=検索結果に表示されなくなるよ)」ということになりますので、Googleで言えば最も重度のペナルティを、割とバシバシ行っているということです。

現実には、Googleのインデックス削除は、本当に低品質なサイト(アフィリエイトリンクばっかりとかリンク提供以外の目的がないとか)を除いては、よほどのことがない限りは一般的なサイトでそう起こりうるものではないのですが、Appleの場合はその辺は容赦ないみたいですね。

しかもGoogle検索で言えば、大事に作ってきたメインのサイトがそうなる、とかそういうレベルのことですので、アプリ関係者としてはそれなりに大きい変更と言えそうです。

ちなみに:実際この規制運用の強化によりどうなったか

ちょっと又聞きの情報なので不確かではありますが(関係者の方、もしも不適切でしたら訂正追記しますのでご指摘頂けますと幸いです)、結構色々話は聞きます。

結論から言えば、とりあえず、Appleは割と本気出してきているようです。

少なくとも上記の規制の対象と言われている

  • インセンティブ付きで他アプリのインストールを促進する仕組みを持つアプリ
  • インセンティブ付きでソーシャル拡散等を促す仕組みを持つアプリ

のような代表的な規制対象の仕組みを持つアプリは割とガシガシリジェクトされているみたいです。

また、ユーザーにインセンティブ付与が有りだろうと無しだろうと、アプリの中で他のアプリインストールを推奨するようなものも含めてアウトになっている的な噂もあります(これはあくまで噂)。

インセンティブの有無に関わらず、アプリの中で他所のアプリをプロモーションするのはヤメレ、という意図がそもそもあるのかもしれません。ぶっちゃけそれくらいはええやんとか思ってしまいますが。普通に広告してるだけだし。。(※もちろんそれ以外でアプリ内に表示される通常の広告ネットワークなどは特に規制の対象ではありません)

ちなみに、Webを通じたインセンティブ付与の広告とかについては特に規制とかないんですけどね。アプリの中にそういう仕組みを持ってたらダメよ、ということなので。

※この辺については、アプリ内でのインセンティブ付与の排除の背景として、「ランキング操作の禁止」だけではなく「そんなところでインセンティブとして付与しちゃったら、Appleに課金してもらえないじゃないの」という意図も多分にあるのかなと思いますがどうなんでしょうね。媒体(アプリ)としてはアドオンで課金されるより広告で得られる報酬が高いのであれば普通そちらを選びますし、事実今でもインストール成果報酬型の広告って単価かなり高く設定されますし。

 

まとめ

アプリの関係者の方々にとっては何だかんだ言ってもそれなりにはインパクトのある規制強化なのではないかなと。少なくともGoogleがここ何年もかけて取り組んできた規制レベルを、それに比べれば結構な短期間でズバンと進めてきたのが今のAppleということですので。

実際には、監視をかいくぐってうまいことやることが出来ないわけではないと思いますので、どこまで厳密にこの規制をAppleが運用していけるか分かりませんが、Googleのそれに比べれば現実的に運営側の努力と工夫である程度対応できるコンテンツ量ではないかな、などと考えますと、

アプリマーケティングの世界では、定められたルールの中でちゃんとプロモーションするにはどうしたらよいか、というのを考えていかなきゃ行けないよね、がキレイ事ではない時代はそんなに遠くないかもしれないですね。

※今回の件、おそらく「そういうプロモーションをしてるアプリを規制する」だとめちゃくちゃハードル上がると思うんですけどね。外的要因が絡むので検知と判断が難しいので、今Googleが右往左往してることと似たようなことを何だかんだすることになると思いますし。あくまで、「そういう仕組を持っているアプリ」への規制、ということで、根本からそういうプロモーションをやりづらくしようとしているのが現状でしょう。Googleも、最近のリンク系ペナルティの話題を聞くに、表面的なリンク対策への対応よりも、根本的な原因の検出と排除に注力するポイントをシフトしてきているようにも見えますし。

 

ともかく、GoogleにしてもAppleにしても、特定のプラットフォームに依存したビジネスを行うにあたっては、プラットフォームが許容する中でどうやって勝っていくか、を考えるのは普通です。

その中で、現時点での勝ちパターンを追求することで勝てている勝負も多くあると思いますが、一方で、プラットフォーム自体のルールや仕様の変更によりその勝ちパターンが一気に破綻する、といった可能性は常に考慮しておかないといけませんよね。

ということで、普段と違った話題をお伝えしました。別事業でアプリ紹介サービスを運営しておりますのでたまにはアプリ界隈の話題も良いかなと。(長い割に薄い内容ですみません)

最後に:SEOセミナーのお知らせ

すみませんただの告知でしかないのですが6月24日(火)に僕とグループマネージャーの實川の2人でセミナーやります。Googleのこれまでとこれから、SEOのこれまでとこれから、実際に業務としては何をしていくべきか、事例を交えてポイントに分けてお話します。ご興味ある方は是非。
セミナー詳細:“リンクを買わないSEO”を成功させるための、Web担当者向け実践SEOセミナー

外部サイトへのリンクには漏れなく”nofollow”とか、いい加減やめませんか

「外部サイトへのリンクには、PageRankが外に流出するのを防ぐために”nofollow”を入れるように、とSEOの人からアドバイスをもらったことがあり、実践している」という方が今でも多いように思います。というか多いです。

無意味です

ほとんどの場合、大切なPageRankの流れを意味もなく断ち切っているにすぎず、プラスになることはなくマイナスでしかありません。この記事で紹介するような事情が無い限りは外すことをおすすめします。

まず前提として、ユーザー投稿型のサイトなどではない一般的な企業サイトを運営していて、nofollowをテクニカルに駆使する必要のあるシーンというのはごく限られたケースだという認識です。正直ほとんど使いドコロはないと思っています。

普通はほとんど使わなくて良いものですし、個人的にもここ数年でnofollow付与を提案したケースは自社で運営するメディアも含めて数えるほどしかありません。(某氏のように大規模なサイトのSEOばかりをガッツリ見ている人はそうではないと思いますがそんな人、何人もいないと思います。)

ということで記事タイトルについての話はもう完了したので、ここからはrel=”nofollow”について解説します。

rel=”nofollow”の意味

nofollowって何よ、という方に簡単に解説しておくと、「nofollow指定されたリンク先にPageRankを渡さない」「nofollow指定されたリンクをクロールの対象リストから除外する」というものです。簡単にいえばSEO上そのリンクの価値がなくなるということですね。

nofollowの意味を図示しています

nofollowが作られた目的は、検索エンジンのランキング評価対象としたくないページへのリンクにPageRankをを受け渡さないようにする、といったことを簡便に実現するためです。

もしnofollowがなければ、例えばリンクをクロールさせたくない場合、robots.txtでブロックされた中間ページにリンクし、中間ページから本来リンクしたいページのURLにリダイレクトをする、など何かしらの面倒な作業が必要となります。

なぜnofollowが必要になったか

その当時に検索業界にいたわけではありませんでしたので、その時代を生きていた方から何か補足がありましたら是非お願いしたいのですが、考えられる点としては主に以下のものかなと。

SEOを目的とした有料リンク掲載への対策

ユーザーが(何かの対価としてではなく)自発的に掲載したリンクに限定して評価対象としないと本来のPageRankの概念それ自体が意図した通りに機能しなくなります。

そこで、Googleとしては「金銭などを対価として掲載するリンクにはnofollowを付与する」というルールを設けることで、有料リンク等による順位操作を規制しようとしたことが背景としてあげられると思います。

ユーザー生成型コンテンツ(UGC)の普及に伴う、”リンク先ページの信頼度をサイト運営者が保証できないリンク”のクロール制御

1つ前の項目とほとんど同じじゃないかと思うフシもありますが。

Wikipediaを代表として、Yahoo!知恵袋や無料ブログサービスなどでは外部サイトへのリンクに自動的にnofollowが付与されるようになっています。身近なところではtwitterの投稿のリンクも同様です。nofollowが付与されているので、これらのサイトにリンクが掲載されたとしても直接的なSEOの価値はありません。

もともと、大半のリンクはサイト運営者の意思の元で掲載されていたはずです。しかしUGCが普及し、サイト内にユーザーが自由にコンテンツを投稿したりリンクを掲載できたりするようになると、サイトへの誘導目的や、SEO目的のリンクの掲載も一定割合発生します。

それがまともなサイトならまだしも、アダルトサイトやウィルスを拡散させるためのサイトでないとも言い切れません。そうしたサイトへのリンクを検索エンジンが評価対象&クロール対象としない、とすることで、少なくともSEO目的のリンクの投稿の価値をなくすことが出来ます。

まとめてしまえば、SEOを目的としたリンクへの対処法として、と言えそうですが。

PageRankスカルプティング

僕がこの業界に関わりだした2009年には、ギリギリそういうテクニックがありました。最近SEOの勉強を始めた人だとあまり聞き慣れないかもしれません。

イメージだけ説明すると、”100″のPageRankを持ったページがあったとして、そのページから10本のリンクが均等に掲載されていた場合、各ページに10ずつのPageRankが流れます(あくまでもイメージです)。

pagerankが均等に10ずつ配布されるとします

そのうち2本のリンクにnofollowを付与することで、PageRankを受け渡す対象が8本になりますね。すると、各ページには12.5ずつのPageRankが受け渡されることになります。つまり8本に渡るPageRankが増えるのです。

nofollowで指定したリンクの分だけ、他のページへのPRの受け渡し分が増える

このように、nofollowを活用して重要なページにPageRankを集中させようとするテクニックを、PageRankスカルプティングと呼びました。

でもこれは既に2009年時点で機能していません。あるリンクにnofollowを掲載した場合、PageRankを破棄することになり、そのほかのリンクに充当されるわけではない、という仕様変更が行われたためです。

仮にnofollowで指定したとしても、それは破棄することに同義。他が増えるとかそういうわけではない

変更の意図としては、もともとサイトのPageRankを調整するためのテクニックとしてnofollowが作られたわけではなく、ユーザーにとっては無関係な施策でしたので、そういう使われ方をされることは本来の目的と異なる、という判断のもとの変更という話だったのかもしれません。

どちらにせよ現時点では、nofollowを付与すればPageRankが重要なページに集中します、ではなくなっているのです。

nofollowはいつどんな時に使うか?

一部曖昧なところもありますがこのようなイメージで問題ありません。

ユーザーがリンクを自由に掲載できる場合の不正リンクへの対策

先述の通り、ユーザーが投稿できるタイプのコンテンツで、誰でもリンクを掲載することが許可されている場合、信頼できないサイトへリンクが向けられる可能性があるため(出会い系やアダルトサイトなどのスパムコメントなどが良い例)、それをGoogleに辿らせない&評価の対象としないために使います。

昔はUGCがここまで普及していたのでほぼ全てのリンクはサイト管理者の制御のもとで掲載されていましたが、UGCが普及したことで誰でも簡単にリンクを貼ることが出来るようになり、その中で自作自演やスパムなどが増えてくると、外部サイトへのリンクには一律でnofollowなどの対応を取らざるを得ません。

※事実、近年では不正リンク対策として、有料ディレクトリ登録サービスや無料ブログサービスの外部サイトへのリンクの多くもnofollowを付与するように変更されてきています。

検索エンジンがデータ収集する価値のないページへのクロールの制御

よく言われているのはログインページなど、Googlebotがそのコンテンツの中身を収集出来ない場合です。砕けて言えば「そこクロールしても何も見れないから他のとこ見に行ってちょうだい」という意味ですね。

それであれば使う意味は確かにあるような気がしますが、いちいちそんな細かいこと考える必要もないんじゃないでしょうかとも思っています。大きな効果があるとは思えませんし。

あとこの意図で使うとすると、ほとんどのサイトは意識する必要はないと思うのですが、大規模なサイトを運営していて、本来クロール不要なURLへのリンクが不可避に大量に生成されるがrobots.txtでブロックする必要がない、或いはrobots.txtでリアルタイムに弾いていくのが運用上現実的ではない、などの場合でしょうか。

※ただし不要なはずのURLが大量に生成されるというのは、それはnoindexとかnofollowでどうこうじゃなくてその仕様を適切な形に変更すれば良い、というケースも割合多そうですが。。

よほどのことが無ければ、ほとんどの場合はウェブマスターツールのパラメータ制御機能で上手く調整すれば良いレベルだと感じています。(すみません、ここは正直言いきる自信がないです。)

Google的には”真っ黒”な完全アウトサイダーなサイトへリンクをせざるを得ない場合

これは正直ちょっと自分でも確信はなくて、賛否両論あると思うのですが。

仮に自社の関連サイトだったとしても、リンク先のページが大規模な不正リンクプログラムなどの中心にいる場合、或いは重度のペナルティを受けている場合など、リンクを掲載することでそのサイトとの(リンクの繋がりとしての)距離が近くなってしまいます。

こいつはくせぇーーッ!スパムのにおいがプンプンするぜーーーッ!!

でも関連サイトですし、Google的に真っ黒であることとユーザーに見せたくないことは全く違いますので、リンクを外す理由にはなりません。放置でも良いのかもしれませんが、個人的にはこういうリンクの繋がりの全体像を想像するとこれはちょっと気持ち悪いし嫌なのですね。

それを避けるためにnofollowを掲載するよう提案したことはあります。

nofollowを付与することでリンクグラフから相互リンクを無効化する

どのケースも多少の効果はあったように見えましたが、正直言えば因果関係は曖昧ですのでここは参考程度にして下さい。冒頭でも書きましたが、ほとんどの場合は有効なPageRankを破棄することでもありますのでこんなことしない方が良いのは間違いありません。

とまあ、いくつか挙げてみましたが、少なくとも一般的な中小規模の商用サイトでnofollowを当然のように使う、どこでnofollowを付与するかをじっくり考える、などということはほとんど無いなあとは思っています。

なぜ、テクニカルなことをしたがるのか

ドラクエで新しい呪文を覚えると、誰もが”絶対に必要ないけど使わざるを得ない”みたいな精神状態に追い込まれます。

例えば敵グループが複数に分かれていて、どう考えても賢者としてはヒャダインかイオラあたりで対応するようなシーンなのに、1ターン目でなぜか敵単体に向かって新しく覚えたベギラゴンを唱えてしまうなどの事例が挙げられます。

特に画面演出のないドラクエ4以前であっても、同様の現象が必ずと言っていいほど起きますね。

それと全く同じです。少し勉強して知識がつくと、絶対に必要ないのにcanonicalとかnoindexとかnofollowとかrobots.txtを駆使してクローラーの色々制御してみようなどと思ってしまったり。しかしほとんどの場合が「しかしなにもおこらなかった」です(逆に大ダメージを受けることはありえます)。

例えば、昨年にrobots.txtについて詳細に記事にまとめられていたブログがありましたが、(おそらく記事執筆時に調べながら追記したであろう)robots.txtの記述が誤っていて、全てのページがクロール拒否になっていたということは記憶にあたらしいです。ちなみにその後きちんと修正されていました。

まとめ

普通にサイトを運営していれば「ほとんどのページはクロールされ、インデックスさせるべきコンテンツ」なはずです。外部サイトであっても、nofollowを付与する必要のあるようなサイトにリンクすることは滅多にないはずです。

少なくとも、敵グループが多数に分散していたら、多くの場合は素直にイオ系呪文で対応しておくのが良いかと思います。

ヴォラーレ株式会社 土居

知っておいて損はない!Googleの検索エンジンに関する「特許」まとめ

以前に検索エンジンとSEOの歴史について書いてくれた大学生の佐々木くんに、次のテーマで「Googleの検索に関する特許」についてまとめてもらいました。

Googleの特許は「何がしたいの?」を理解する手がかりに

Googleの特許を知る事はSEOを考える上でとても重要な事です。何故ならSEOを実施するにあたって、検索エンジンとしてのGoogleの考えや方針は必ず理解しておく必要があり、Googleが持っている特許の内容は、その考えや背景を読み取るための材料になるからです。

この記事ではGoogleの特許の中から検索エンジンに関する特許を一部ピックアップし、紹介します。

※年代は申請日で記載しています。
※発明者もしくは譲受人がGoogle Inc.になっている特許を記載しています。
※ここに挙げられていないものも含め、特許を取得していることと、それがランキングに反映されていることは別問題です(特許はとったが使っていない、があり得るということ)。

PatFT:認定された特許

※PatFTとは公式に認定されている特許を指します。
 

リンクされたデータベース内におけるノードのランキングに関する方法

(1998年1月 特許番号:6285999)
検索技術に関わる特許の中で最も有名かもしれません。いわゆる”PageRank”のアルゴリズムに関する特許です。特許権の所有者はスタンフォード大学ですが、Googleが独占で使用する権利を持っています。

※参考1:ページランク(wikipedia)
※参考2:SEOの最重要特許ベスト10 その1 ページランクとは?

 

検索エンジンの音声インターフェース

(2001年2月 特許番号:7027987)
音声による検索システムに関する特許です。以下の参考URLをご覧いただくとわかりますが、現在少しずつ普及してきている音声検索について、今から10年以上も前から、それが使われるシーンを想像されていたわけですね。

ちなみに「特許の一部は製品化・サービス化するが、そうでないものもある」というのはこの記事の最後にも書かれています。

※参考:米Google、検索エンジンの音声インターフェースに関する米国特許を取得

 

曖昧な検索クエリに対して検索結果を提供する為に修飾されたインデックスを使用する方法及び装置

(2003年3月 特許番号:6529903)
ユーザーが検索する時にサイトの管理者が想定した具体的なキーワードを打ちこまず”曖昧な言葉”での検索をしてしまった場合を想定した施策に関する特許です。

※参考:「Google」の知的財産戦略

 

ユーザーの行動や特徴のデータに基づいた文章のランキング

(2004年7月 特許番号:7716225)
いわゆる”リーズナブルサーファーモデル”の特許です。全てのリンクを均等に扱うのではなく、データや特徴に基づきリンクに妥当な重み付けをして扱う、という考え方です。

※参考:GOOGLE’S REASONABLE SURFER: HOW THE VALUE OF A LINK MAY DIFFER BASED UPON LINK AND DOCUMENT FEATURES AND USER DATA

 

ソーシャルネットワーク内の関連メンバーを評価する為の方法とシステム

(2004年8月 特許番号:8010459)
SNSでの友人のクールさ、セクシーさ、信頼度などによって評価が出来るシステム、といった少し変わった特許です。

参考:知人の「セクシーさ」を評価:Googleが特許出願

 

カメラ付き携帯電話用の画像ベースの検索エンジン

(2005年5月 特許番号:7565139)
“画像での検索”に関するシステムの特許で、内蔵カメラ付きケータイの普及が背景にあります。携帯電話で撮影した画像そのものを検索に利用するための技術です。
 

フレーズベースの情報検索システム内のスパムドキュメントを検出する

(2006年6月 特許番号:7603345)
文書内の関連フレーズの数に基づいてスパム文書を特定するシステムに関する、とする特許。スパム文書にありがちな「キーワードの集合体」のような文書のパターンを検出し、スパム文書と非スパム文書を識別します。

参考:http://www.seobythesea.com/2006/12/phrase-based-information-retrieval-and-spam-detection/

 

コンテンツに基づいた広告サービスの提供

(2006年7月 特許番号:7734624)
サイトの内容に近いジャンルの広告を表示する技術の特許です。コンテンツを閲覧しているユーザーに関連性の高い広告を表示することで、より高い広告効果を実現することができます。
 

強化された検索結果

(2006年1月 特許番号:7624101)
電話番号または住所を含んだクエリ検索に応じる事と、クエリに関連のある住所のリンクを示す事が出来るといった検索機能の強化に関する特許です。この特許にはWebの膨大な情報量に対して、ユーザー(特に新規でWeb検索に不慣れなユーザー)が求めている情報を探す為に労力を使ってしまう可能性が高いという背景があります。
 

電子メール環境内でのメッセージランキング

(2008年9月 特許番号:8095612)
自分の受信メールの内容を検索結果にランク付けして反映する方法に関する特許です。以下の記事で詳細に紹介されていますが、ウェブページとは異なり、メールならではのシグナルにもとづいてランク付けされます。

※参考:Googleの新特許「メールランク」であなたのメールが格付けされる?

 

AppFT:出願した特許

※公式に認定されていないが、公開されている特許を指します。

MapReduce内のフレームワークデータの処理

(2011年4月 特許番号:20120254193)
MapRuduceというGoogleのサーバー処理に用いられている分散処理アルゴリズムで、「処理速度の向上→検索結果反映までの時間短縮」の技術に関する特許です。

※参考:GoogleのMapReduceアルゴリズムをJavaで理解する

 

ポリシーに違反してるかをチェックするシステム

(2012年8月 特許番号:20130110748)
過去の”問題あり”なデータと比較して、ポリシーや法律に抵触するような悪意のある書き込みを事前に防止出来るようにする技術ですが、以下の記事にもあるように「道徳的な判断をGoogleが行う」というところに賛否が分かれそうな技術とも言えます。こちらも製品化されるとは限らないとのこと。

※参考:Google、「検閲システム」の特許を導入

 

ソーシャルネットワークオブジェクトランキング

(2013年10月 特許番号:20140108428)
ブログやコミュニティなどのソーシャルネットワーク内のコンテンツのランク付けには、一般的なウェブページとは異なるシグナルも利用するべきだ、といった主旨の特許です。例えば友達やファンの数、プロフィールの閲覧数、投稿へのコメント数、最新の話題かどうか、などです。

※参考:HINTS OF HOW GOOGLE MAY RANK SOCIAL NETWORKS?

補足:特許の探し方

Googleの特許は登録までしている特許(PatFT)も公開までしかしていない特許(AppFT)もすべて米国特許庁データベースで検索する事が出来ます。
特許番号や譲受人、発明者など様々な条件で検索する事が出来ます。

america_patents_engine

しかし、こちらの検索ページはそんなに見やすい訳ではないので私はGoogleの特許検索エンジンをオススメします。

google_patent_engine

一番の違いは、実際に特許の概要が説明してあるページにアクセスして自動翻訳をした時です。米国のデータベースだと活字がひたすら並んでいて見づらいですが、Googleの方だと項目が分かれていて見やすいです。

america_trans
▲米国データベースの説明内容を翻訳したらこうなる

google_trans
▲Googleだとこんなに見やすい

出典

まとめ

検索技術に関する様々なテーマからピックアップして、ごく一部を紹介させて頂きました。これらの特許内容はGoogleがこれからの検索エンジンをどうしていきたいのかを知る材料になり、ひいてはSEOをどのように考えていけばいいのかを知る材料になります。

こうした技術を読むにあたり、「どういう技術なのか」はもちろん大切ですが、「こび技術が開発された背景はなにか」「何が実現できるのか」「利用者にどういう利点があるのか」などを考えてみると、テクニカルな解釈ではなく、Googleが本質的に目指す方向性などを理解するのに役立つと思います。

しかし、前述の通りGoogleが特許を取得していてもその特許内容を検索エンジンに全て反映させているという訳ではないので注意して下さい。

参考:特許取得=Googleの検索アルゴリズムに組み込まれている訳ではない

ヴォラーレ株式会社 佐々木

非エンジニア向けSSL解説:OpenSSLの脆弱性「HeartBleed」とは?

GoogleのMatt Cutts氏が「SSL(https)のサイトを優遇するかも」のような発言をしたことや、4月にはOpenSSLの致命的な脆弱性についても話題になりました。今回の記事では、非エンジニア向けにSSLや、指摘されている脆弱性「HeartBleed」について解説します。開発室の坂田による執筆です。

2014年は”SSL”が何かと話題に

以前からGoogleが強制的にSSLで接続するようになったり、2014年に入り、GoogleがSSLのサイトを優先しようか検討している、といった話が出てくるなど、SEO関係者の中でもたびたびSSLが話題に出てくるようになりましたね。

今年の4月ごろ、SSLでの通信を可能にしているOpenSSLというソフトウェアに、個人情報などの通信内容がサーバーから流出する重大な欠陥(脆弱性)が見つかったことが話題となりました。

この脆弱性は、サーバーからの情報流出が、心臓(Heart)から出血(bleed)するほど深刻に捉えられたため、「Heartbleed」と呼ばれています。

どんな形であれ個人情報を扱うようなサイトはセキュリティを担保することが求められます。今回は、SSLの仕組みを改めて理解していただいた上で、この脆弱性「Heartbleed」について解説します。

編集者注:冒頭の「GoogleがSSLのサイトを優先」の話は、Googleでも検討が始まったばかりの未確定事項

SSLの役割と仕組み

SSLは、主に2つの機能を提供しています。1つは、信頼性を担保することです。SSLを使用しているウェブサイトはSSLの証明書を有しています。

この証明書は、第三者機関である認証局(CA)によって発行されています。この証明書により、利用者が、ウェブサイトを信頼できることが保証されています。

もう1つは、暗号化により安全性を担保することです。通常のウェブサイトを表示するために使用するhttp通信は暗号化されていません。そのため、第三者に通信が見られた際、通信している情報が容易に読み取られてしまいます。

ここでいう情報の中には、IDやパスワードなどの会員情報や、住所や名前など、お問い合わせの内容など個人に関わる重要な情報が存在します。

こうした情報を第三者に読み取られないように、暗号化する必要があります。SSLは、通信情報を暗号化する機能を有し、安全な通信を確立する役割を担っています。

SSLの説明

OpenSSLの脆弱性「Heartbleed」とは

OpenSSLとは、実際にこの暗号化を行っているプログラムの一つです。SSLを可能にしているソフトウェアはOpenSSLの他にもNSSやGnuTLSといったプログラムの存在しますが、OpenSSLは非常に高いシェアを占めています。

ところがこのOpenSSLの脆弱性が先日指摘され話題になりました。それがHeartbleedです。

SSLに限らず、サーバーは通信を行うと、メモリに通信内容を一時的に記録します。本来メモリに記録されたデータは、通信が終了すると破棄されます。

ところがHeartbleedという”バグ”により、メモリ上のデータが破棄されず、サーバー外部に流出してしまう場合があります。この流出したデータの中に、個人情報が含まれていると、個人情報の流出といった事態になります。

Heartbleedはサーバーの秘密鍵が流出する場合もある

ここで大きく問題なのは、Heartbleedによる影響は、通信データの一部流出にとどまらず、「サーバーの秘密鍵」の流出の恐れがある点です。

詳しい解説はここでは割愛しますが、SSLでは、共通鍵暗号方式と公開鍵暗号方式の2つの暗号方式を利用して安全性を担保しています。

SSLでサーバー送信した情報は、これらの方式を用いて暗号化されます。この情報は、サーバーの秘密鍵という鍵のみで復号化することが可能です。逆に言えば、この「秘密鍵」さえあれば、第三者でも容易に通信内容を読み取ることができます。

情報流出の危険性

サーバーはひとつの秘密鍵を使用しているため、一度秘密鍵が流出してしまうと、ウェブサイトの利用者の通信内容を継続的に読み取られる可能性があります。例えるなら、隣の人にパソコンのパスワードを知られてしまった状態です

対処法

実際の作業はサーバーなどの環境に依存しますので、具体的には触れませんが、以下の手順を取るとよいでしょう。

Heartbleedかどうか調べる

まずは、OpenSSLのバージョンを調べます。この際、以下のバージョンに当てはまる場合、Heartbleedの脆弱性があります。

またこれらのバージョンに該当しなくとも、古いOpenSSLを使用している場合は、他の脆弱性やバグが存在している可能性もあるので、最新のものにバージョンアップすることをおすすめします。

  • OpenSSL 1.0.1 から 1.0.1f
  • OpenSSL 1.0.2-beta から 1.0.2-beta1

Heartbleedを取り除く

OpenSSLのバージョンを確認し、Hearbleedの影響を受けている場合は、早急に取り除くましょう。最も簡単な方法は、OpenSSLのバージョンを最新のものにします。

また、レンタルサーバー等OpenSSLの設定を変えることのできない場合は、サーバーの管理会社に連絡し、この脆弱性を解消してもらう必要があります。

証明書を再発行し、以前の証明書を失効させる

OpenSSL脆弱性を直したら、SSLの証明書を再発行します。主なSSL発行会社は、無償での再発行を受け付けています。証明書を再発行したら、その設定をサーバーに反映させます。最後に、SSL発行会社を通じて古い証明書を失効させましょう。

まとめ

SSLは、個人情報を取り扱うウェブサイトを安全に運営していく上で、重要な役割を担っています。ウェブサイトの利用者が安心して利用できる環境を整えるためにも、SSLだけでなく、利用している技術やその仕組みを理解し、脆弱性やバグに柔軟に対応していくことが重要です。

最後に、私たち開発室もブログを書いておりまして、技術トピックを中心に、幅広い内容を紹介しています。こちらも参考にしてください。
Catcher in the tech – ヴォラーレ株式会社開発室ブログ

ヴォラーレ株式会社 坂田

「構造化データ」がよく分かる!初心者向け徹底解説

SEOの文脈においても頻繁に話題になる「構造化データ」。意外にそこまで詳細に理解されている方は多くないのでは?と思います。ここでは構造化データやリッチスニペットの概要から、HTMLでの記述方法、テストツールなど、全体像を掴んで頂ければと思います。今回はコンサル部門サブマネージャーの巣鷹による執筆。

目次

セマンティックWebについて
構造化データとは
構造化データを使用するメリット
ボキャブラリーとシンタックス
構造化データをマークアップする方法
HTML上で直接マークアップする方法
データ ハイライターを用いる方法
テストツールのご紹介
まとめ

セマンティックWebについて

構造化データとセマンティックWebという考え方は切っても切り離せないものです。今回は構造化データを説明する前にセマンティックWebというものに簡単に触れておきたいと思います。

「セマンティックWeb」は、例えば以下のように説明されています。

Webページおよびその中に記述された内容について、それが何を意味するかを表す情報(メタデータ)を一定の規則に従って付加することで、コンピュータが効率よく情報を収集・解釈できるようにする構想。インターネットを単なるデータの集合から知識のデータベースに進化させようという試みがセマンティックWebである。
引用元:http://e-words.jp/w/E382BBE3839EE383B3E38386E382A3E38383E382AFWeb.html

コンピュータ(検索エンジン)は従来、テキストを単なる”文字”として認識し情報として蓄積していました。しかし、それでは検索エンジンは文字を記号としてしか認識することができず、その意味を推し量ることはできません。

そこで、文字を”意味”としてその背景や文脈まで解釈し、それを蓄積していこうというのがセマンティックWebの考え方です。

構造化データとは

セマンティックWebを実現するための手段として、構造化データがあります。構造化データは、言葉に対して意味をメタデータとして持たせることで、ロボットがそのもつ内容の解釈を容易にし、検索エンジンはより有用な検索結果をユーザーに提供できるようになります。

わかりづらいので例を。例えば、以下のような例を考えます。

--</pre>
<div>私は土居 健太郎 (天照SEO)です。</div>
<pre>
--

私達がこれを見た時に、この人は土居健太郎という”名前”の人物で、天照SEOという”ニックネーム”を持っているのだとある程度推測することができます。

検索エンジンもその推測ができないわけではありませんが、これを明確にニックネームだと定義することは難しいのです。そこで、そうした情報の「意味」を検索エンジン等に明確に伝えてあげましょうというのが構造化データの考え方です。

構造化データはHTMLに直接マークアップする、もしくはウェブマスターツール上で設定しますが(設定方法は後述します。)、上述した土居健太郎の例でいうと以下のような記述となります。

--</pre>
<div itemscope="" itemtype="http://schema.org/Person">私は<span itemprop="name">土居 健太郎</span> (<span itemprop="nickname">天照SEO<span itemprop="nickname">)です。</span></span></div>
<pre>
--

nameやnicknameという値が含まれているのが御覧頂けるかと思いますが、特定の情報に対してHTMLマークアップを行う(メタデータを付与する)ことでその情報の説明が付与することができるようになります。

構造化データを使用するメリット

検索エンジンがサイトコンテンツの把握を容易に行えます

上述した通り、特定のテキストあるいは画像がどういう情報なのかを指し示すことで、検索エンジンはコンテンツの内容がどういう意味を持つものか、容易に把握できるようになります。

構造化データを用いることで、前述した文章は、「私の名前は土居健太郎で、ニックネームは天照SEOです」のように、情報の持つ意味がより明確に検索エンジンに伝わり、適切に認識されるようになります。

リッチスニペットが表示されます

通常の検索結果においてサイトが表示される際には青色のリンク、その下meta descriptionやサイト内テキストから引用したスニペットが表示されますが、構造化データを用いることで、リンクの下に通常とは異なる情報が表示されることがあります。これを「リッチスニペット」と言います。

リッチスニペットの画像

こういった検索結果を見たことがある方は多いのではないかと思います。

これにより検索結果で目につきやすくなり、クリックされやすくなるなどのメリットがあります。リッチスニペットに対応されているコンテンツは、上の画像のレビュー情報やレシピ、筆者情報以外にも音楽や映画、イベント、パンくずなどがあります。

ボキャブラリーとシンタックス

構造化データを理解する上で、この2つの言葉についてきちんと理解しておく必要があります。

ボキャブラリー

冒頭の例では文章全体に”http://schema.org/Person”という値を、土居健太郎に”name”、天照SEOに”nickname”という値を付けました。その指定する値を定義している規格のようなものがボキャブラリーです。

ボキャブラリーの代表的なものにschema.orgがあります。schema.orgはGoogle、yahoo!、Microsoftの大手検索エンジン企業が共同で取り組んでおり、値の数は日々拡張されています。

先ほどの例では人物の説明でしたが、人物の説明には名前やニックネームはもちろんのこと、所属する団体や誕生日なども情報として持つことがあるかと思います。そういった部分もある程度網羅されており、こちらのページ(※リンク先は英語です)にてまとめられています。propertyという欄で人物の説明に対してマークアップ可能な値が表示されています。

なお、schema.orgで構造化データマークアップに対応している情報のタイプはこちらでまとめられています。実際にHTMLをマークアップする際にはこれらの中からコンテンツに合致するタイプを選択し、実装します。
※マークアップしたい項目について、リンク先に利用可能な値が記載されています。

また、見て頂くとわかるかと思いますが、プロパティは階層構造となっています。

例えば「Thing(もの)」という大項目の子として「Book(本)」や「Event(イベント)」という項目、「Event(イベント)」の子として「BusinessEvent(企業向けイベント)」といった階層を形成しています。

シンタックス

ボキャブラリーは値を定義しているだけのものですので、HTMLにマークアップする際にはどうマークアップするかの仕様が必要ですが、その仕様がシンタックスです。

--</pre>
<div itemscope="" itemtype="http://schema.org/Person">私は<span itemprop="name">土居 健太郎</span> (<span itemprop="nickname">天照SEO<span itemprop="nickname">)です。</span></span></div>
<pre>
--

ちなみにこの文章でいうとitemscopeやitemtypeの部分がシンタックスで決められている仕様です。

シンタックスには代表的なもので以下の4つがあります。

  • Microdata
  • RDFa
  • Microformats
  • JSON-LD

Googleが推奨しているのはMicrodataです。

また、JSON-LDはHTML上で各情報に直接マークアップするその他のシンタックスとは異なり、スクリプトを用いて記述するため、各データに直接マークアップする必要がなく、一箇所で構造化データを記述できるとぃう利点があります。

先ほどの例

再度、土居健太郎の例を用いて詳しく見てみましょう。
※以下の例はボキャブラリーにschema.orgとシンタックスにMicrodataを用いています。

--</pre>
<div itemscope="" itemtype="http://schema.org/Person">私は<span itemprop="name">土居 健太郎</span> <span itemprop="nickname"> (天照SEO) <span itemprop="nickname">です。</span></span></div>
<pre>
--

1. itemscope
itemscopeという属性がdivに付与されています。これはこのdivに構造化データが付与されているということを意味します。

2. itemtype
itemtypeはitemscopeで示された構造化データが何に関するものなのかを示すために用います。上述したデータでいうとhttp://schema.org/Person という人物を表す値が用いられているためdiv内の情報が人物を表す情報であると確認できます。

人物以外にも組織や会社を表すhttp://schema.org/Organization や、商品であればhttp://schema.org/Product などが定義されています。

3. itemprop
itempropはitemtypeで示された人物や組織・会社などの詳細な情報を示すために用いられます。

上の例ではdivに対してitemtypeで人物の情報であると提示されているので、itempropがnameと指定されているspan内の情報は、人物の名前であることが読み取れます。また、その次のnicknameが記載されているspanはニックネームを表しています。

構造化データをマークアップする方法

構造化データを検索エンジン(Google)に伝える際には大きくわけて2つの方法があります。

  • HTML上で直接マークアップする方法
  • データ ハイライターを用いる方法

前者のHTMLに直接マークアップする方法は文字通り上述した土居の例のようにHTMLタグに構造化データの要素を追加します。

一方でデータ ハイライターを用いる場合、ウェブマスターツールのページ上でクリックすることによりページの構造化データを(HTMLをいじることなく)Googleに伝えることが可能です。

Googleヘルプには以下のように書かれています。

■HTML の使用が適しているケース:
・サイト上のイベント、レシピ、その他の各種データの Google による認識方法を明確にコントロールしたい場合。
・HTML マークアップを一貫してすべてのデータ項目に追加できる場合。
・サイトの構造が頻繁に変わる場合。
・Google 以外の検索エンジンでもウェブサイトのコンテンツが認識されるようにしたい場合(データ ハイライターで抽出されたデータを利用できるのは Google のみです)。

■データ ハイライターの使用が適しているケース:
・サイトで表示するデータが、イベントに関するものである場合。
・サイトで構造化データやリッチ スニペットを使用することを検討しているが、HTML マークアップを更新するためのリソースの準備がまだできていない場合。
・HTML マークアップを記述するよりも、ウェブページをポイントしてクリックするほうがよい場合。
・サイトで HTML マークアップを変更できない、またはデータ項目を一貫してマークアップできない場合。
引用元:https://support.google.com/webmasters/answer/99170?hl=ja

どちらの方法もメリット・デメリットがありますので、運営されている体制やサイトの状況などにより、どちらを使うか検討することが望まれます。

ではそれぞれ実際に説明していきましょう。

HTML上で直接マークアップする方法

この方法には大きく分けて二つあります。それぞれ説明します。

ボキャブラリーとシンタックスを参考にHTMLにマークアップしていく方法

今回はボキャブラリーにschema.orgとシンタックスにMicrodataを用いてマークアップする方法を紹介します。

一般的に構造化データがマークアップされている情報は人物や商品、パンくずが多いですが、こちらにまとめられている通り、マークアップできる情報は他にも沢山あります。

今回は以下の文章について考えてみましょう。

--</pre>
<div>ヴォラーレ株式会社は五反田に位置する企業です。2007年1月15日に高橋飛翔が創業しました。企業情報はこちらのサイトから御覧ください。<a href="”">http://www.volare.jp/</a></div>
<pre>
--

①まずはitemscopeを入れましょう。

上述した通り、構造化データであることを示すはじめの一歩はitemscopeを該当するタグに入れることです。

--</pre>
<div itemscope="">ヴォラーレ株式会社は五反田に位置する企業です。2007年1月15日に高橋飛翔が創業しました。企業情報はこちらのサイトから御覧ください。<a href="”">http://www.volare.jp/</a></div>
<pre>
--

②itempropで何を示している情報なのかを指定しましょう。

今回はヴォラーレ株式会社の情報ですので、itemtypeで企業情報であることを示すhttp://schema.org/Corporationを用います。

--</pre>
<div itemscope="" itemtype="http://schema.org/Corporation">ヴォラーレ株式会社は五反田に位置する企業です。2007年1月15日に高橋飛翔が創業しました。企業情報はこちらのサイトから御覧ください。<a href="”">http://www.volare.jp/</a></div>
<pre>
--

これでこのテキストは企業に関する情報であることをマークアップできました。

③itempropを使って各情報についてそれぞれマークアップしていきます。
企業に関する情報の際に使えるitempropはこちらのページで挙げられています。マークアップしてみると以下のようになります。

--</pre>
<div itemscope="" itemtype="http://schema.org/Corporation"><span itemprop="”name”">ヴォラーレ株式会社</span>は<span itemprop="”lacation”">五反田</span>に位置する企業です。<span itemprop="”foundingDate”">2007年1月15日</span>に<span itemprop="”founder”">高橋飛翔が創業しました。企業情報はこちらのサイトから御覧ください。<a itemprop="”URL”" href="”">http://www.volare.jp/</a></span></div>
<pre>
--

「ヴォラーレ株式会社」は企業名なので「name」を、「五反田」は住所にあたるので「lacation」を、その他創業日や創業者、コーポレートサイトへのURLもマークアップしています。

構造化データマークアップ支援ツールを用いた方法

ウェブマスターツールには、構造化データマークアップを支援する機能があります。

先に説明した方法だとschema.orgなどを理解した上でマークアップする必要がありましたが、こちらの方法はそれよりも容易に構造化データを用いることが可能になります。

ここでは弊社の開発室が運用しているブログを用いて説明します。

①構造化データマークアップ支援ツールに該当するページのURLを入力し、今回マークアップするデータを選択した上でタグ付け開始をクリックします。

構造化データマークアップ支援ツールの画面「

今回はブログ記事のマークアップですので、記事を選択しました。

②実際にマークアップしてみましょう。

ブログ記事ページイメージ

タグ付けはツール内でページが読み込まれた画面で行います。右にタグ付けできるデータが並びます。この例で言うと、前の画面で記事を選んだため、著者や公開日など、記事に関連するデータが並んでいます。

ではまず一番上にある「名前」(今回の場合は記事タイトルです)をマークアップしてみましょう。

タイトルがハイライト

タイトルに当たるところをドラッグすると、選択肢が出てきますのでそこから「名前」を選択しますと右側にマークアップしたいテキストもしくは画像が追加されます。著者情報や公開日なども 同様の要領で指定していきます。

データの指定が終わったら右上にある「HTMLを作成」をクリックするとそのページのHTMLが出力されます。

イメージ

③出力されたHTMLをサイトに反映させます。
どういったサイト運用をされているかにもよりますが、出力されたHTMLでマークアップされた部分(黄色くハイライトされています)、もしくはソース全てをコピーしてHTMLを実装しましょう。これでマークアップは完了です。

データ ハイライターを用いる方法

データハイライターを用いた場合には 直接HTMLをいじる必要がなく、構造化データマークアップ支援ツールのようにブラウザ上でクリックすることで構造化データをGoogleに伝えることが可能です。

①ウェブマスターツールでデータハイライターを開きます。

データハイライター画面

ハイライト表示を開始しましょう。

ハイライト表示

先ほどと同様に構造化データを設定したいURLを入力し、タイプを選択します。今回は天照SEOブログを用いますので、タイプに「記事」を選択しました。

また「このページをタグ付けし、他のページも同様にタグ付けする」の場合は(幾つかのサンプルページにてタグ付けを行うことで)同様のページ群もGoogleが学習して構造化データを認識してくれるようになります。一方で「このページだけをタグ付けする」場合はGoogleに学習させず選択したページのみをタグ付けしたい場合に用います。

ブログ記事のように同じようなページ群がある場合には前者、そうでない場合には後者が望まれると思います。
今回はブログ記事ですので前者を選択しました。

②タグ付けを行います。

アイテムを選ぶ

上述した構造化データマークアップ支援ツールと同様に、タグ付けしたいところをクリックもしくはドラッグし、タグ付けするデータを選択します。タグ付けが終了したら右上の「完了」を選択しましょう。

③Googleに自動でタグ付けして欲しいページを選択します。
※この選択肢は「このページをタグ付けし、他のページも同様にタグ付けする」を選択した場合にのみ表示されます。

ページセットの作成画面

左の項目ではGoogleが同様だと判断したページ群が選択肢として表示されます。それでは問題がある場合は「カスタム」で設定しましょう。※ページ群の設定は正規表現で行います。

これらを選択したら「ページセットを作成」に進みましょう。

④サンプルページで上手く設定できているか確認します。

確認画面

Googleは最初にタグ付けした設定から他のページでも同様の構造化データをタグ付けします。このページでは③で選択した構造化データを設定したいページ群の中から、構造化データ部分をハイライトした状態でサンプルページが表示されます。自分の意図通りに設定されている場合には、右上の「次へ」をクリックしましょう。

次々にサンプルが表示されますので、問題がある場合には手動で設定を修正しましょう。5ページ分のサンプルを確認すると、「完了」という項目が右上に表示されるので次に進みましょう。

⑤最終確認画面

採取確認画面

最後に確認したサンプルページを再度見直して、問題が無い場合は右上の「公開」ボタンを押しましょう。これでデータハイライターによる構造化データの設定は完了です。

テストツールのご紹介

構造化データ テスト ツール

構造化データ テスト ツールで正しく構造化データが記述できているかを確認できます。URLもしくはHTMLを入力することでそのページに設定した構造化データが正しく設定されているか、どの項目が設定されているかに加えて、検索結果上でどういう表示がなされるページなのかを確認できます。

テストツール

構造化データのマークアップを行った後には出来る限りこのツールを用いて、正しく設定されたかを確認するようにしましょう。

※なお、このツールで表示される検索結果プレビューが必ずしも本物の検索結果で表示されるとは限らないようです。

ウェブマスターツールの「構造化データ」項目

ウェブマスターツールの構造化データでは、構造化データの設定にエラーが無いか一覧で確認することができます。検索結果のプレビュー機能は無いですが、構造化データにエラーがあるデータタイプやページが一覧で確認できますので、URLを何度も入力する必要のある構造化データテストツールよりもその点は便利です。

まとめ

ここ最近の検索エンジンまわりの動きを見ても、構造化データを利用する重要性は高まるはずなので、サイトによっては是非チャレンジされると良いかと思います。しかし、サイトの全体的なマークアップに構造化データを適用するというのはコスト的に現実的でない場合が多く、そのあたりのバランスは今はまだなかなか難しいのかなと思います。

最後に、こちらも参考にどうぞ。

皆様のお役に立ちましたら幸いです。

ヴォラーレ株式会社 巣鷹

SEOに有利?不利?エンジニアが見るHTML5とSEO

弊社はSEOのサービスを提供している関係上、直接コンサルティングには直接携わらないエンジニアでも、時折SEOに関する質問をされる機会は少なくありません。なかでもしばしば尋ねられるのが、SEOとHTML5の話題です。いまさらという感は否めませんが、本記事ではHTML5とSEOの関係についてざっくりと述べてみたいと思います。

HTML5とは

「HTML5」と言う場合、単純なマークアップ言語としてのHTML5をさす場合と、その関連技術を含む広義のHTML5をさす場合があります。

狭義のHTML5は、HTML4.0、XHTML1.1などと同列の、テキストを構造化するマークアップ言語です。要素の追加や変更、新たに導入された概念などの違いがあります。ただし既存の(X)HTMLとの互換性もある程度維持されており、本質的にはこれまでの(X)HTMLと大きな違いはありません。

一般的にHTML5といった場合、単純なマークアップ言語としての側面だけでなく、WebStorage、WebSocketなどのAPIも含めてHTML5と言われることが多いと思います。文脈によってはCSS3やSVG、WebGLといった技術も含めてHTML5と呼ばれることもあるようです。

本記事では、初めにマークアップ言語としてのHTML5について述べ、後半ではAPIの話題にも軽く触れておきたいと思います。

マークアップ言語としてのHTML5とSEO

マークアップ言語としてのHTML5を見たとき、HTML5にはどのような特徴があるのでしょうか?主な特徴として以下のようなものがあると考えています。

  • コンテンツ・モデルとカテゴリーの導入
  • 要素の追加、廃止と意味付けの変更

以上の点を、以下で少しだけ解説します。

コンテンツ・モデルとカテゴリーの導入

HTML4.0で定義されていた要素には、ブロック要素とインライン要素があり、インライン要素の中にブロック要素を入れてはいけないなどのルールが存在しました。例えば、インライン要素であるa要素を、ブロック要素であるdiv要素の中には入れることができないといったルールです。

このルールに従った場合、例えば以下のようなマークアップは認められません。

<a href=“http://www.seohacks.net/”><div>SEO HACKS</div></a>

例. HTML4.0における間違った要素の配置

HTML5では、このブロック要素とインライン要素に代わり、カテゴリーとコンテンツ・モデルという概念が定義されました。

カテゴリーとは、その要素が定義された目的を示すものです。例えば、body要素の中に設置できる要素はフロー・コンテンツというカテゴリーに属しますし、文章の章や段落を定義する要素は、セクショニング・コンテンツというカテゴリーに属します。

それぞれの要素で、中にどのカテゴリーの要素を含めてもよいか?というルールを表したのがコンテンツ・モデルになります。例えば、section要素のコンテンツ・モデルはフロー・コンテンツとセクショニング・コンテンツなので、このいずれかのカテゴリーに該当する要素を中に含めてよいことになります。

要素の追加、廃止と意味付けの変更

HTML5では、新たに追加された要素、廃止された要素、そして引き続き存続し続けるものの、意味付けの変更されているものが存在します。

追加された要素としては、article、section、header、asideなど文章構造を表現する要素や、embed、video、audioなどのインタラクティブな要素を表すものなどが追加されています。こうした要素の追加により、より文章の構造的意味を明確に示すことができるようになったり、インタラクティブなページの構成ができるようになりました。

一方で廃止された要素もあります。廃止された要素は、big、center、fontなどの見た目を定義していた要素や、frame、framesetのようなフレームに関する要素などです。これらの要素はCSSを使用したり、他の代替候補となるタグをすれば問題ないでしょう。

b、iなど、廃止ではないものの、以前のバージョンのHTMLから、意味付けが変更された要素もあります。例えばb要素はこれまで太字を現す要素で、かつ太字で現すという意味での仕様は非推奨とされていますが、HTML5では他と区別して表記すべきフレーズを示す要素となりました。

具体例 – hx要素のマークアップ

さて、HTML5によって変わる具体的な例として、SEO上も重要といわれる見出し要素のマークアップを考えてみましょう。見出しを表すh1〜h6要素はHTML4.01の場合、1〜6という数字でそのランクを示します。

<h1>見出しレベル1</h1>
<div>
  <h2>見出しレベル2</h2>
  <div>
  </div>
  <h2>見出しレベル2</h2>
  <div>
  </div>
</div>

例. HTMLの見出しレベル分け(HTML5でも有効)

最上位の見出しであるh1要素はSEO上、1つの文書内で1度しか利用できないというルールがありました。HTML5の場合も、このルールに従っていれば何ら問題はありません。

一方でHTML5の場合、新たに追加されたsection要素のようなセクショニング・コンテンツの深さを使ってセクションを表現することもできます。以下のようなケースでは、h1要素を複数使用されていても、それぞれのセクションにおける見出しのレベルを区別できるようになっています。

<section>
 <h1>見出しレベル1</h1>
 <section>
  <h1>見出しレベル2</h1>
 </section>
 <section>
  <h1>見出しレベル2</h1>
 </section>
</section>

例. HTML5ではこのような見出しの使い方も認められる

とはいえ、HTML5では既存の方法によるマークアップも可能です。当然の疑問として、どちらの方法を使うのが良いか?ということになりますが、上述の2つの例に優劣はありません。単に選択肢が増えただけなので、使いやすい方を選べばよいでしょう。

HTML5はSEOに有利なのか?

ここまで、HTML5におけるマークアップ言語として変わった点をごく簡単に記載しました。HTML5はSEOに対してどういった影響を与えるのでしょうか?結論だけ先に述べますと、HTML5の使用は、SEOに有利とも不利ともいえないと考えています。

確かにHTML5を使用することで、以前のバージョンのHTMLに比べ、より文章構造を明確することができ、サーチエンジンにとってもより文章の示す意味を解釈しやすくなったのは事実です。また、HTML5に追加されたインタラクティブ・コンテンツや、後述するAPIを利用すれば、よりリッチなコンテンツを記述することができます。

しかしながら単なるフォーマットの違いです。XHTMLで記述していた文書が、HTML5になることによって、ページそのものの価値が高くなったりすることはあるでしょうか?利用するサイトがHTML4.01なのかHTML5なのか、を気にする一般ユーザーはほとんどいないはずです。

新規でサイトを作る場合や、サイトのフルリニューアル時にHTML5を選択するのはありだと思います。しかし、SEO目的で既にHTML4.0やXHTMLで構成されているサイトをそのままHTML5に書き直すといったことは全く必要ないでしょう。

Web周辺技術としてのHTML5

HTML5のカバーする領域は非常に幅広く、マークアップ言語の側面のみならず、JavaScriptを介して扱うAPIや、WebSocketなどの関連技術もその範囲に含まれます。例えばWebStorage、WebSocket、Paging APIといったものが該当します。非常に幅広い領域のAPIが定義されており、全てを紹介しきることは到底できませんので、少しでもSEOに関係のありそうなAPIを簡単に紹介させていただこうと思います。

表示速度を計測する「Navigation Timing API」

Webサイトを見るときには、リンクをクリックしたり、アドレスバーにURLやキーワードを打ち込んだりすると思います。大抵のサイトでは、1秒〜せいぜい数秒の内にページが表示されるはずです。利用するユーザにとっては一瞬のできごとですが、ブラウザ上で見たいページをリクエストしてから実際にWebサイトが表示されるまでには、いくつかの段階を経ています。Navigation Timing APIとは、一言で言えばこの”いくつかの段階”として示しているものを共通化して、表示速度の記録・参照が可能なAPIです。

W3Cから拝借したNavigation Timing APIについてのドキュメント図では、以下のようなフェーズに分けられています。

Navigation Timing API

Navigation Timing API

このAPIは、通常のWebサイト上で利用するものではありませんが、Chromeのデベロッパーツールなどではこのフェーズを閲覧することができます。またGoogle Analyticsの「サイトの速度」で表示出来る時間も、このNavigation Timing APIにより測定されているものだと思います。

SEO上は小さなファクターであるものの、ユーザーエクスペリエンス的な側面も考えると、サイトの表示速度は決して無視できるものではありません。

以前、別の記事でWebサイトの高速化に関するトピックを紹介しました。このAPIを利用すると、こうした高速化による改善状況などを定量的に計測することができます。具体的な利用例としては、弊社開発室のブログでNavigation Timing APIを利用したツールでパフォーマンス測定を自動化するというトピックを紹介しておりますので、よければそちらも参照ください。

より詳しい解説は外部のサイトに譲りますので、このようなAPIも利用できることだけ知っていただければ十分です。

画面遷移せずに履歴を操作する「History API」

いわゆる“Ajax”を多用したサイトでは、画面の遷移なくコンテンツを書き換えたりすることが行われます。一方で、クローラーは1つのURLを1ページとして認識するため、このようなサイトのコンテンツを意図通りにインデックスさせることが困難でした。

上述のようなAjaxを使用したページをインデックスさせる方法として、Googleは#!(hashbang)を使ってAjaxアプリケーションをクロールさせる方法を提示していましたが、複雑な仕様で誰しもが利用できる仕様とはいえませんでした。

これを代替する手段として、近年はpushStateの利用を推奨しているようです。

pushStateは、HTML5で定義されているHistory APIの機能の1つで、画面遷移せずにブラウザの履歴にURLを追加することができる機能です。画面遷移をせずにAjaxを使ってコンテンツの書き換えを実現したい場合、pushStateを使えばコンテンツの書き換えと同時にURLも変更することができます。

もちろんAjaxを使わずとも閲覧できるサイトのほうが検索エンジンライクなのは間違いないと思いますが、必ずしもSEOが最重要のファクターである、というケースばかりではないと思います。検索エンジンには独立したページとしてインデックスさせたいといったニーズがある場合、利用を検討してみるのも良いのではないでしょうか?

まとめ

本記事では、HTML5の概要や、HTML5とSEOとの関係、HTML5に含まれるAPIの一部を紹介しました。すでに述べた通り、HTML5を使うことそれ自体がSEO上特別有利になるとか、不利になることはないと考えています。

とはいうものの、HTML5について正しく理解しておくことや、HTML5で何ができるか?を知っておくことは、誤った使い方によるリスクを避けたり、取りうる選択肢を増やすという意味で重要と言えるのではないでしょうか。

ヴォラーレ株式会社 若松