高速表示可能なGoogleのAMPページを提供者の本物のURLで表示できる仕組み

ウェブサイト運営者はGoogleのAMPページを必ずしも愛していないが、読者は確実にそのスピードを喜んでいるし、運営者がGoogleの強権の肥大をどれだけ嫌っても今やほとんどの有力サイトがこの形式をサポートしている。でも運営者にとって絶対に嫌なAMPの奇癖が、ついになくなるようだ。米国時間4月16日からは、Googleの検索でAMPのリンクをクリックすると、ブラウザーは「http//google.com/amp」のリンクではなくパブリッシャーの本当のURLを表示する。

この変更は、1年以上かけて準備されていた。昨年1月に同社は、Googleのamp URLを表示せずにGoogle AMPのキャッシュからAMPページをロードする、複数カ月を要する取り組みを開始すると発表した

この取り組みの中心的存在はWeb Packagingという規格だ。これはデジタル署名を使う署名交換であり、Web Packagingによってブラウザーは、ドキュメントをパブリッシャーのオリジナルページに属するかのように信用する(Googleが送ったAMPページであっても)。本来ならブラウザーはデフォルトで、同じオリジナルページからではないデータにアクセスしようとするウェブページ内のスクリプトを拒絶する。そこでウェブサイト運営者はちょっと余計な仕事をして、ストーリーの署名ありバージョンと無署名のバージョンの両方を公開しなければならない。


2018年11月にGoogleが運営者にこの変更を告げてからは、かなりの数の運営者すでにこれをやっている。今は、このサービスの背後にある中核的な機能をサポートしているのはChromeだけだが、そのほかのブラウザーも近くサポートを加えるだろう。

運営者にとっては、ドメインネームが自分のブランドの重要な一部だから、これはかなり重要なことだ。自分自身のURLを使えれば、アナリティクスを得るのも容易だし、AMPページの上部にあるグレーのバーが出ても、URLバーには正しい名前があるからユーザーは安心する。

この新しい機能のローンチにあたってGoogleは、Cloudflareとパートナーした。後者は今日、そのAMP Real URL機能をローンチした。すべてのユーザーに行き渡るのはもうちょっと時間を要するが、いずれ誰もがクリック一発でそれを有効にできる。これにより企業は、GoogleのAMPキャッシュに送るすべてのAMPページを自動的に署名する。当面は、この機能をサポートするCDNはCloudflareだけとなるが、他社もこれに続くだろう。

CloudflareのCEOであるMatthew Prince氏はこう言っている。「AMPはインターネットの性能をアップする素晴らしいプロジェクトだから、AMP Projectに協力してAMPの最大の問題の1つを取り除きたかった。それは、パブリッシャー本人がサーブしたページのようにならないことだ。今回の新しいソリューションは今のところうちだけが唯一のプロバイダーだが、うちのスケールはグローバルだから、どこにいるパブリッシャーでも、自分のコンテンツをより高速かつブランドを大事にするモバイル体験で送ることができる」。


画像クレジット: Joan Cros/NurPhoto/Getty Images

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

Google AMP for Emailでメールの高速表示が可能に、ダイナミックなメディアに変身

AMP
米国時間3月25日、GoogleはAMP for Email正式にスタートさせた。AMP for Emailは現在の固定的なメールをウェブページのようなダイナミックなメディアに進化させることが目的だ。AMPブログによれば、まずGmailがサポートされるがYahoo Mail(ちなみにTechCrunchの親会社の所有)、Outlook 、Mail.ruのようなメジャー・サービスもAMP for Emailをサポートすることになるという。

AMP(Accelerated Mobile Pages)はGoogleが中心となって開発された新しいHTML規格で、モバイルのウェブページの高速表示を実現している。Googleがメールへの導入プロジェクトを発表したのは1年以上前だ。Googleの慎重さを考えても長い準備期間だが、この機能を正しく働かすためには膨大なバックエンド作業が必要だったということだろう。

AMP for Emailが目指すのは現在の固定的なメッセージ・システムを仕事を本当に効率化するツールに変えるところにある。Gmailのプロダクトマネージャ、Aakash Sahney氏はこう述べている。

この10年間で、静的でフラットなコンテンツは対話的なアプリケーションへと進化した。これによってわれわれのウェブ体験は決定的に変わった。しかしメールは相変わらず静的メッセージのままで、時代遅れなシステムになりつつある。メールの本文にリンクが含まれている場合、内容を確認したければそれをクリックしてブラウザに新しいタブを開き、別のウェブサイトにアクセスしなければならない。

AMP for Emailが実現すれば、メールはダイナミックかつ対話的なスペースになる。つまりOutlookに実装されている返信メニューをポップアップさせるRSVPボタンのような機能をメール本文に埋め込むことができる。アンケートに答える、ストアで在庫を確認する、コメントに返信するといった作業がメール・クライアントを離れることなく実行できるわけだ。

このフォーマットは、ホテル予約のBooking.comやスケジュール設定のDoodleを始めFreshworks、Nexxt、OYO、Rooms、Pinterest、redBusなどの有力企業がすでに採用している。こうしたサービスからメールを受け取ることを許可している場合、今後数週間のうちに対話的コンテンツを含むメールが届く可能性が高い。

デベロッパーにとってメールをAMP化するのはさほど難しくない。ウェブサイトでAMP化ページを作った経験があればなおさらだ。 フォーマットには画像カルーセル、フォーム、リストなど多数のAMPマークアップ機能が含まれている。こうしたメールには標準的な HTMLマークアップも含まれているのは重要なポイントだろう。これはなんらかの理由でAMPが作動しなかった場合のバックアップとなる。.

最初の発表以来、GoogleはグーグルはAMP for Emailをサポートするパートナーを多数集めることに成功した。これにはメールの配信および分析プラットフォームのSparkPost、メールのデザインおよびマーケティングツール化のLitmus、Twilio Sendgrid、AmazonのSES、Pinpointのユーザー向けメールとマーケティングツールなどがある。

ただしTechCrunchのDevin Coldeweyを含めて、メールへのAMPの導入に反対する意見も根強い。AMPを利用するには新しいマークアップ言語を習得し、かつサポートするインフラを必要とする。シンプルなページをすばやく構築するために必須の要素ではない。

現行のメールシステムにはさまざまな欠点があるものの、シンプルであるためにあらゆるベンダー、ユーザーの間で確実にメッセージ交換機能を果たす数少ないシステムの1つだ。メールにAMPを持ち込むことに誰もが無条件に賛成していない理由は、このメリットを帳消しにする恐れがあるからだ。しかしマーケティングや広告関係者はAMPメールを使うようにならざるを得ない。必要な作業をスピードアップすることができるなら、デベロッパーたちはメールのシンプルさを守るべきだという理想論にはあまり関心を払わないだろうと思う。

原文へ

(翻訳:滑川海彦@Facebook

このCSSベースのWeb攻撃は、iPhoneをクラッシュ&リスタートさせる

一人のセキュリティー研究者が、あらゆるiPhoneをクラッシュしてリスタートさせる方法を発見した——必要なのはわずかなコードだけだ。

Sabri Haddoucheがツイートしたわずか15行のコードからなる概念実証ウェブページは、そこを訪れたiPhoneまたはiPadをクラッシュして再起動させる。macOSの利用者も、このリンクを開くとSafariがフリーズする。

このコードは、iOSのWebレンダリングエンジンであるWebKitの脆弱性を利用したもので、Apple はこのWebKitをあらゆるアプリやブラウザーで使うことを義務付けている、とHaddoucheはTechCrunchに言った。同氏によると、CSSのbackdrop-filterプロパティーに<div>のようなタグを大量にネスティングすることで、端末のリソースを食い尽くしてカーネルパニックを引き起こすことが可能で、システムはダメージを防ぐために自らシャットダウンして再起動する。

「iOSでHTMLをレンダリングするものは何であれ影響を受ける」と彼は言う。つまり、誰かがFacebookやTwitterにリンクを送ったり、訪れたページにこのコードが入っていたり、誰かがリンクをメールで送ってくれば、被害に遭う可能性があると彼は警告する。

TechCrunchは、最新のiOS 11.4.1でこのコードを試し、iPhoneがクラッシュして再起動することを確認した。セキュリティー会社、MalwarebytesのMacおよびモバイル担当ディレクター、Thomas Reedは、最新のiOS 12ベータでも同じ現象が起きることを確認した。

運がよければ、クラッシュせずにホーム画面がリスタート(リフレッシュ)されるだけのこともある。

興味のある人は、実際にクラッシュを起こすコードを実行することなく、ここでしくみを理解できる。

幸いなことに、このアタックは厄介ではあるものの、悪意あるコードを実行するために利用することはできない。つまり、このアタックを利用してマルウェアが動いたりデータが盗まれることはない。しかし、このアタックを防ぐ簡単な方法は存在しない。罠の仕掛けられたリンクをクリックしたり、そのコードをレンダリングするHTMLメールを開いただけで、あなたのデバイスは即座にクラッシュするかもしれない。

Haddoucheは金曜日(米国時間9/14)にAppleと接触し、現在同社が調査中であると言われた。本誌は広報担当者にコメントを求めたが、すぐに回答はなかった。

[原文へ]

(翻訳:Nob Takahashi / facebook

この新しいマルウェアはWindowsのクリップボードを乗っ取り、暗号通貨アドレスを書き換える

その驚くほど極悪非道というべきマルウェアは、230万人分の価値の高い暗号通貨ウォレットを監視して、Windowsのクリップボード内のアドレスをハッカー集団のアドレスに置き換える。つまり、ユーザーが自分のウォレットのアドレス(例えば、3BYpmdzASG7S6WrpmrnzJCX3y8kduF6Kmc)をクリップボードに入れると、マルウェアは狡猾にそれを自分たちのプライベートウォレットのアドレスに書き換えてしまう。すべてはクリップボードの中で行われるため、ほとんどの人はコピー&ペーストの間に起きた変化に気づかない。

BleepingComputerのセキュリティー研究チームは、以前同様のハイジャック事例を見つけたが、この最新版は価値の高いウォレットを積極的に監視して、アカウントを入力するところでコインを奪おうとする。問題のマルウェアが動作しているところを以下に示す。


このマルウェアは83MBの巨大なDLL(Direct Xサービスに偽装している)を使う。そのDLLは250万行のテキストからなり、bitcoinアドレスで埋め尽くされている。上記のテストでHTMLページから切り取ったアドレスをWordPadに貼り付けると、アカウントがひそかに書き換えられているが、アドレスの先頭部分は変わっていないため気づかくい。

複数のアンチウィルスエンジンがこのDLLを危険であると認識しているのでウィルス対策を最新にしていれば危険はないはずだ。しかし、Bleeping Computrerが指摘するように、自分のBTCが安全であることを確認する唯一の方法は、貼り付けるアドレスをひとつずつ慎重にチェックすることだけだ。同誌はこう書いている:

この種のマルウェアはバックグラウンドで実行し、実行中であるという兆候も見せないため感染したことを見つけるのは容易ではない。このため重要なのは、常に更新されたアンチウィルス対策をインストールして自分を保護することだ。

もうひとつ非常に重要なのは、暗号通貨ユーザー全員が、暗号通貨を送る前にすべてのアドレスを念入りにチェックすることだ。こうすることで、アドレスが意図しないものに置き換えられたかどうかを見つけることができる。

[原文へ]

(翻訳:Nob Takahashi / facebook

このハックは音声を利用する仮想モデムでインターネットに接続する

伝説のプログラマーMartin Kirkholt Melhusは、インターネットのない会社で仕事をしていたことがある。でも、そこでの仕事はStackOverflowからコピペすればできるようなものばっかりなので、彼はネットを使いたいと思った。そこで彼は、彼のスピーカーとマイクロフォンを(理論上は使えるはずの)モデムに改造した。“それはギミックであり、概念実証のつもりだった。仕事で実際に使うものではなくて”、と彼は書いている。“コメントでぼくを非難する前に、そのことを理解してもらいたい”。

そのシステムはHTML5のWeb Audio APIを使用し、テキストをモデムのトーンに換えた。スピードは当然遅いが、Pythonの大きなコードを盗んでVisual Editorへドラッグするには十分なはずだ。

Melhusは書いている:

最近ぼくは、開発用コンピューターがインターネットに接続されていない顧客のところで仕事をしていた。GoogleやStack Overflowにアクセスできないと生産性がガタ落ちになるので、とても困った。実はぼくの仕事の大半は、ブラウザーからVisual Studioへコピペすることだったんだ。

そこでは、1台のラップトップがインターネットに接続されていたし、ぼくの開発用コンピューターには3.5mmのオーディオジャックがあった。これで、問題を解決できる! Web Audioを利用して、この会社の、インターネットの「有る」と「無し」のギャップを填(う)めたのだ。

で、このお話の教訓は? おもしろくて賢いことは、いつでも人生の難関を切り拓く良い方法だ。コードはここにあり、モデムのインタフェイスはここにある。

Instagram Photo

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

【ポッドキャスト】交通政策の研究者が予見する自動運転車が普及したときの都市交通

今週のTechnotopiaでは、ニューヨーク大学Rudin交通政策研究所のアシスタントディレクターSarah Kaufmanにお話をうかがった。Kaufmanは、ニューヨーカーのための、そして世界の、新しい交通手段について研究しており、未来はきわめておもしろいものになる、と予想している。

彼女の予言はこうだ。自動運転車の普及とともに、これまでになかった新しいタイプのパラトランジット(paratransit, さまざまな補助的交通手段)がいくつも登場する。これまでの公共交通を利用できなかった人たちのためのサービスも、生まれるだろう。そしてそれらの新しいサービスは、効率が良くて、私たちをA地点からB地点へ安全にはやく、より安い費用で運んでくれるだろう。ぜひ、彼女の予言を聴いてみよう。

Technotopiaは、John Biggsによる、より良き未来に関するポッドキャストだ。SticheriTunes、あるいはMP3をここでダウンロードして聴ける。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

テンプレートを廃しブロック方式で自由度を高めた、一般人のためのWebデザインツールTilda

img_9478

メイカーに代表されるような、いろんなプロジェクトに次から次と手を出すタイプの起業家は、Webサイトも次から次とたくさん作らなければならない。そのための便利なツールとして、Bootstrap(これはやめた方がよい)やSquarespace、WordPressのクールなプラグイン、などなどがかねてからある。ここでご紹介するTildaも、そのひとつだ。

Tildaは使いやすくて応答性の良いページビルダーで、ふつうのランディングページだけなら月額15ドルで利用できる。FunkyPunkyというデザインスタジオをやっているロシアのWebデザイナーNikita Obukhovが、自分たちで使うためにTildaを作り、最近それを一般公開した。画像やテキストのレイアウトはドラッグ&ドロップ方式だから、何かを貼り付けるのは数秒で終わる。

その差別化要因のひとつが、Zero Blockと呼ばれる“Webエディター内のWebエディター”的なツールで、文字やフォントの管理(タイポグラフィー)、図形を描く、アニメーションを作る、などの作業ができる。いわばこれは、Tildaの秘密兵器だ。

Obukhovはこう説明する: “ユーザーは、予(あらかじ)めデザインされているブロックを組み合わせてWebサイトを作る。テンプレートはない。その方が柔軟性があり、ユーザーの自由度も大きい。ブロックは、わが社のプロたちの作品だから、ルックスがよろしい”。

試してみたら、こんなプロジェクトを15分で作れた。既存の写真とテキストを、ちょっと使っただけだ。終わったらすぐにそれをアップできるし、公開できる。ドメインを割り当てるのも簡単だ。とにかく、使用体験はとても快適だ。

Tildaはまだ自己資本のみで、今リピーターの顧客が約4000名いる。

あなたはまだ、Bootstrapから完全に抜け出せないかもしれないし、Tildaの月額15ドルは高いと感じるかもしれない。でも、ぼく自身の証言としては、とても使いやすいから捨てられないツールだね。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

HTML5開発ホスティングのDivshotをGoogleが買収、前に買収したFirebaseと一体化して強力な開発環境に

divshot

Googleが、HTML5によるWebホスティングプラットホームDivshotを買収した。Divshotは、“パフォーマンスとデベロッパの生産性のための最適化”、を謳っている。

同サービスは12月14日に閉鎖し、チームはGoogleが昨年10月に買収したFirebaseに加わる。

同社はホームページでこう言っている:

DivshotはGoogleでFirebaseのチームに加わることになりました。FirebaseはGoogleがデベロッパに提供している総合的なプロダクトスイートで、私たちのビジョンはその一員として加わり、Divshotのミッションはこれまでよりも大きなスケールで前進し、継続します。

私たちが加わることにより、Firebase Hostingがデベロッパにとってすばらしい体験になりますから、これまでのDivshotのプロダクトとサービスはすべて、2015年12月14日(月曜日)に閉鎖します。Divshotの現在の顧客は、移行ガイドをお読みのうえ、アプリケーションをFirebase Hostingへ移してください。ご心配なく。二つのプロダクトは完全に互換性があります。

私たちのすばらしいユーザのみなさまへ: これまでのサポートを感謝いたします。そして、もうじき、Firebaseでまたお会いしましょう!

FirebaseチームのMichael Bleighは、この件についてこう述べている:

両チームは最高のデベロッパ体験を作りたいという情熱を共有している。これからは両者が一体となって、共通の目標を目指していく。DivshotとFirebaseは、前にもチームを組んだことがある: DivshotのハッカソンStatic ShowdownをFirebaseがスポンサーし、参加したデベロッパの50%以上がFirebaseを利用した。

Divshot社はサンタモニカにあり、これまで118万ドルの資金を調達している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa)。

9月1日はChromeがFlash広告の再生を停止した日

1643830

インターネット上で50%以上の人が利用するブラウザであるChromeが、本日(9月1日)より正式にFlash広告の動作を停止させることとなった。標準的メディアプレイヤーとしての地位を失ったFlashは、ついに歴史的遺物となる道を歩み始めた。Googleによる発表時の言葉を引いておこう。

6月にChrome上にてFlashによる広告の動作を停止させる旨をアナウンスしていました。これは利用者のパフォーマンスを改善することを狙ったものです。2015年9月1日より、Flash広告は初期状態で再生されなくなります。

Googleは警告を発し、そしてFlash広告をHTML5に自動変換するツールなども提供してきた。今回の変更により、たいていのウェブページでのFlash広告は動作しなくなる。Flashを利用した広告が「静物」化するわけだ。広告制作者が作ったFlashコンテンツは利用者に届かなくなる。

なお、AmazonでもFlash広告を制限する方向に進みつつあり、Flashビデオを再生する広告はほぼなくなっている状況だ。そうは言ってもこれまでの蓄積もあり、Flashコンテンツはあちこちで目にする。しかし(ようやく)Flash広告は作られなくなり、そして消え去っていくこととなりそうだ。

原文へ

(翻訳:Maeda, H

【初心者向け】クローラビリティを改善し、サイトのコンテンツを検索エンジンに正しく発見・認識させる

SEOの文脈で「クローラビリティ」という言葉を聞いたことがある方は多いと思います。クローラーがどのように情報を発見し、受け取るかを理解することで、サイトの改善に役立ててみて下さい。初心者向け記事として大学生の佐々木くんにまとめてもらいました。

検索エンジンの仕組み

検索エンジンは大きく分けてクロール、インデックス、ランキングの3つで成り立っています。検索エンジンはまず数兆ものWebページを「クローラー」と呼ばれるソフトウェアがリンクを辿って巡回しながら各Webページの情報を取得し、その情報をサーバーにインデックスします。

インデックスされた情報は検索エンジン独自のアルゴリズムによってランキング付けされ、そのランキングが検索結果に反映されます。

今回のテーマは「クローラビリティ」ですが、クローラビリティを改善することは、必要なコンテンツを正しく検索エンジンが発見できるようになることに直結します。数十ページのサイトが気にする必要はほとんどありませんが、比較的規模の大きなコンテンツを有しているWebサイトであれば、クローラビリティを考慮したサイトの設計は極めて重要なポイントとなります。

検索エンジンの仕組みに関しては検索エンジンの仕組みを説明しているGoogleの公式ページが説明しているので、まずはそちらをご覧頂ければと思います。

具体的なページを例に比較

検索エンジンは進化し、ユーザーと同じような目線でコンテンツを評価できるようになってきている、という話をよく聞きます。もちろん、人間が良いと思うものを検索エンジンが同じように良いと評価できるように仕組みの改良が行われていますが、現実を見ればまだまだそこには乖離があります。

ということで、当社が運営しているアプリに関する記事を例に、人間が見た場合と検索エンジンが見た場合の両方で比較してみたいと思います。

人間が見た場合

日刊Applivのキャプチャ画像、記事タイトルやキャッチとなるサムネイル画像、記事ランキングなどが画面に表示されている

人間が見た場合はみなさんそれぞれの見方があるとは思いすが、タイトルや本文の内容を見つつ新着記事や月間PVランキングにさらっと目を通す感じかと思います。

検索エンジンが見た場合

ここではGoogleの検索エンジンを例に、Googlebotがどの様にサイトを理解しているのかをSearch Engine Spider Simulatorというツールを使って見てみます。

同じ日刊Applivのページですが、レイアウトも画像もなく、ただひたすら文字情報だけが列挙されている

分かりづらいかもしれませんが、この画像の様に検索エンジンはページ内のテキスト情報のみを取得していると考えて下さい。厳密にはHTML全体を取得し、読み取れたテキスト情報をHTMLタグから分離して解析している、という方が正しいかもしれません。

※実際にGoogleのクローラーがサーバーから受け取っている情報は、ステータスコードやメタ情報などの付加情報と、HTMLファイルそのものです。このあたりの仕組みについては次の記事を参考にしてみてください。

参考:よく見るHTTPステータスコード一覧とその意味を理解する

また、次のように検索エンジンはテキストの他にリンク(link)や、キーワード(keyword)、スニペットに採用される可能性のあるディスクリプション(description)に関する情報をクローリングしてサーバーに情報をインデックスします。ここで発見され取得できたリンクURLは、クローラーの巡回リストに登録され、クロール対象URLとなります。

日刊Applivの記事内で発見されたリンクのURLが羅列されている

メタキーワードやメタディスクリプションといったメタ情報。この記事では特に記述がありませんのでnot foundと表示されている

この様に、人間と検索エンジンではWebページの見方が全く異なる事が分かります。

例を挙げますと、alt属性という、画像の代替となるテキスト情報を入れましょうという話はよく有りますが、このようにテキスト情報としてコンテンツを見た時に、文脈として意味が通るような代替テキストを含めることが正しい、ということは理解できると思います。

例えば、意味を持たない画像情報にはalt属性はalt=”"(空っぽ=意味情報なし)として記述しないといけませんし、逆に、豊富な意味情報を持つ画像であればその意味情報をそのままalt属性に付与しないと文脈として意味が通らなくなってしまいますね。キーワードを含める含めないとかいう話ではなく、こういう使い方を心がけると良いと思います。

検索エンジンの性能とクローラビリティ

Googlebotを例に検索エンジンがサイトをどう理解するのかについて説明しましたが、検索エンジンはGoogle以外にもYahoo!、BinggooBaiduInfoseekAskLycosCUIL!などなど数多く存在し、これらの検索エンジンは決してGoogleと同等の性能がある訳ではありません。

ユーザー体験の検索に特化したり検索ワードの関連性に特化したりと、特定の分野に強みを持つ検索エンジンも存在しますが、総合的に現時点ではやはり、Googleが最もユーザーが見つけたい情報を表示してくれている検索エンジンと言えるような気がしますね。
出典:4大検索エンジン+Cuilの性能を比較してみた

Googleはもちろん、様々な性能の検索エンジンがある中でどの検索エンジンに対しても正確にサイトの情報を理解してもらうには、「クローラビリティ」を考慮する必要があります。

クローラビリティとは
サイトにに対するクローラーの回遊性の事
引用:クローラビリティを100点に仕上げてURLを検索エンジンに正しく伝える

つまり、クローラーがどれだけWebサイトの中を巡回しやすいかの度合いを表す言葉です。クローラビリティが強固なWebサイトは、常に重要なコンテンツが検索エンジンに発見される状態を維持できますので、検索エンジンにとっても優しいサイトだと言えます。

リンクのURLが発見されて巡回リストに登録されなければそのコンテンツが検索結果に表示されることはありませんし、クローラーが読み取れるテキスト情報が不足または不適切な状態では、正しい内容を検索結果に反映できないかもしれません。

特に多くのコンテンツを有するサイト、動的にコンテンツを吐き出すような仕組みを持つWebサイトにおいては、このようにクローラーが正しく情報を発見できて内容を理解できることを前提に作らないと、せっかく公開しているコンテンツが検索結果に反映されないということになりかねません。

参考:SEOで本当によく見る”もったいない”内部リンク設計

さて、クローラビリティを考慮する上でWebサイトを設計するには、

  • クローラーがクローリングしてきた際に正しいHTTPステータスコードを検索エンジンに返す事
  • URLを整理してWebサイトのもつコンテンツをクローラーに過不足なく発見させる事
  • リンクには<a>タグと適切なアンカーテキストを記載する

などといった施策があります。(より詳しい内容はWeb担当者フォーラムの”クローラビリティを100点に仕上げてURLを検索エンジンに正しく伝える“や”titleタグ、metaタグおよびURLの構造 – 『検索エンジン最適化の初心者ガイド』改訂版#4-2“の記事に記載されています)

結び

今後、良質なコンテンツをより多くの人に見てもらう機会を作るには、検索エンジンの性能を過信し過ぎないのが無難ですが、もちろん検索エンジンの性能は歴史を辿ってみてもその性能は確実に高まっているので必要以上に最適化する必要は無くなってきています。

しかし、クローラビリティが軟弱だと検索エンジンによってはサイトの情報を正しく理解してもらえず評価に悪影響をもたらしたり、そもそも情報をクロールされないなど負の結果を招く原因になり得るので、性能の低いクローラーでも情報を理解出来る様に、という考えの元で最適化をする事で、より強固なクローラビリティを実現出来ると言えます。

参考:GoogleのJavaScript理解に100%頼るべきではない、JSなしでも入手できる最小限のコンテンツが必要

重要なコンテンツのクローラビリティを確保することは、検索エンジン最適化における基本的な施策であり、にも関わらずここを疎かにしていることで大きな機械損失を生んでいるサイトは決して少なくないのではないでしょうか。

ユーザーだけでなく、検索エンジンにも優しいWebサイトの構築を目指していきましょう。

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

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の歴史を振り返る

地方で大学生活を送っているうちの内定者の佐々木君(平成生まれ)に、お勉強がてらインターネット黎明期の検索エンジン事情などについて色々調べてまとめてもらいました。

今や人々のライフスタイルの一部として当たり前となっている検索エンジンですが、今回は少し振り返ってその歴史やSEOの移り変わりについてまとめました。

SEOと日本の検索エンジン

SEOとは「Search Engine Optimization:検索エンジン最適化」ですので、検索エンジンの仕組みの変化に伴い、最適化の方法も変化します。

例えば、以下の大手の検索エンジン(Google、Yahoo!JAPAN、MSNjapan(Bing)、goo)に対して、シークレットモードで「SEO」と検索してみると、

SEO(google)
図1.Googleによる「SEO」の検索結果

SEO(yahoo)
図2.Yahoo!JAPANによる「SEO」の検索結果

SEO(Bing)
図3.Bingによる「SEO」の検索結果

SEO(goo)
図4.gooによる「SEO」の検索結果

見づらいと思いますがGoogle、Yahoo!JAPAN、gooの検索結果がほぼ同じ結果となっています。これは、Yahoo!JAPANとgooの裏側でGoogleの検索システムが動いているためです。つまり、現在はBingなどを除き、ほとんどの日本国内の検索はGoogleのシステムによって処理されているのです(BingはMicroSoftの自社開発の検索エンジンです)。

しかし、インターネット黎明期と言われていた2000年前後などでは、今とは全く状況が違いました。ここからはその歴史について振り返っていこうと思います。

検索エンジンの歴史

主な検索エンジンの登場年表

表1. 1990年代の検索エンジンの歴史
1990年代の検索エンジン年表

この年代はあれやあれやと新しい検索エンジンが登場しています。(オレンジで記載しているのが相当)そんな中、Yahoo!JAPANの登場によって日本国内はそれ一色でした。僕が初めて見たOSはWindows98で当時保育園の年長でしたが、トップページはYahoo!JAPANしか見た覚えがありません。

編集者注:↑衝撃

2000年に差し掛かってくると検索エンジンに初めから他社のものを採用したポータルサイトが出現してきます。(緑で記載しているのが相当)
では次に2000年以降はというと、、

表2. 2000年以降の検索エンジンの歴史
2000年代の検索エンジンの歴史

2000~2005年あたりで買収が盛んになってきます(青で記載しているのが相当)。2001年のYahoo!JAPANがロボット型検索エンジンにGoogleを採用した事によってGoogleの知名度は上昇していきます。そして米Yahoo!が独自のロボット型検索エンジンを開発したのが2004年、Yahoo!JAPANがGoogleと提携するのが2010年です。当時からSEOに関わっていた方々からすると、この統合は非常に大きな変化であったと思います。

※出典

検索エンジンの群雄割拠からGoogleが首位を勝ち取るまで

1990年代年代後半は、Webサイトの爆発的な増加に伴い多くの検索エンジンが登場するまさに群雄割拠の時代でした。

Googleが出る以前は検索エンジンサービスを持つ会社のサイト又は、他の企業の検索エンジンを採用して立ち上げたサイトはポータルサイトとしてのサービスが主流で、そこには検索窓以外にも多くのコンテンツ(天気、メール、ニュース、広告など)を含む様になりました。

中でも、前述の通り日本においては1996年に登場した「Yahoo!JAPAN」が主流となります。

yahoo!1997
1997年のYahoo!JAPAN( 出典:Yahoo! JAPANのトップページザイン15年史 )

当時の検索エンジンは決して性能が良いとは言えませんでした。

人気のYahoo!JAPANはディレクトリ型検索エンジンを採用していた為、予め登録しておかないとそもそもサイトが表示すらされないし、検索してもユーザーの求めている情報とは異なったものを表示させています(これには最適化の手法に関する問題があるのですが、最適化については後述します)。

それでも当時はインターネットなんて馴染みが無かったのでトップ画面上に表示された豊富な情報量に感激し、「検索」はあくまでサブの機能でYahoo!JAPANも検索エンジンを重要視していない状況だった事もあり、「検索結果に悩まされる」という人は少数だったのではないかと予測出来ます。

そんな中、Googleがリリースしたサイトは検索窓のみ、広告も無しといった極めてシンプルなものでした。

google_1997
1998年に米Googleがリリースした検索サイトページ( 出典:Google.com 1997-2011)

え、なにこれ?って当時の人は思ったのではないでしょうか?GoogleのWebサイトを開いても何もコンテンツが無い、質素な検索窓のみです。コンテンツが満載だったポータルサイトの利用者からすると、何の面白味もないサービスだと感じた方も多かったのではないかと思います。

しかし、Googleの検索エンジンは

  • ユーザーの検索ニーズにより応えれる独自のロボット型検索エンジン技術
  • 価値のあるサイトか否かを指標付けするページランクの導入

という他の検索エンジンには無い価値により、次第に多くの人がGoogleの検索エンジンを好んで使う様になります。

そして2000年にはGoogle日本語版が上陸し、2001年にはYahoo!JAPANの検索エンジンに採用され、どんどん知名度を上げていきます。

google2000
2000年のGoogle検索サイトページ( 出典:Google.com 1997-2011)

しかし、Googleも検索エンジンを世に送り出した当初は殆ど収益性がありませんでした。そんな中、1998年に米Yahoo!が考え出した検索連動型広告を参考に2001年にリリースした「Google Adwords」が、多くのユーザーが使っているGoogleに広告を出稿する事への価値を高める効果を発揮し、ここからGoogleは多額の広告収入を得る様になります。

その他、Googleは

  • Google AdSense
  • Google drive
  • gmaiL
  • Googleカレンダー
  • Google Web Designer
  • Googleアナリティクス
  • Googleウェブマスターツール

こうした仕組みやツールを世に出しさらに多くの利用者を集め、急速にシェアを拡大してきました。その結果、日本だけでなく、実質現状としてはGoogleが世界の検索エンジン市場の大半を占めています。

最近ではGoogleの検索エンジンのアルゴリズムが変更されたという情報に対して多くのメディアや業者が敏感になっています。他の検索エンジンの内容が変わってもほとんどと言っていい程、問題視されていません。それだけSEOにとってもGoogleの変更は多大な影響を与えるということです。

Googleの近年の検索エンジンアルゴリズムの変更内容に関しては、以下のサイトが(英文ですが)見やすいので興味のある方はご覧下さい。
Google Algorithm Tiemline

Yahoo!JAPAN以前の検索エンジン

少し余談ですが、Yahoo!JAPANが日本に登場する前にも日本に検索エンジンは存在していました。

senrigan
出典:Google以前の検索エンジン

こちらは早稲田大学村岡研究室の学生であった田村健人さんが1994年11月に立ち上げた国内初のロボット型検索エンジン「千里眼」です。独特なデザインのアイコンが目に止まります。

この千里眼は検索の対象が.jpをドメインに持つWebサイトのみでした。Yahoo!JAPANを始めとするポータルサイトに需要を奪われて最終的に1999年にサービスは終了してしまいますが、千里眼にはサイトにリンクしているページ(=被リンク元)を表示させる機能がありました。

今でこそフリーソフトで被リンク元を調べる事も出来ますが、当時の検索エンジンで被リンク元を調べれるというのは画期的だったのではないでしょうか?

※出典

日本のSEOの歴史

1990年代後半(Google登場前)

さて本題となるSEOの歴史ですが、SEOという言葉そのものは検索エンジンがWebサイトを認識した瞬間から始まっています。

インターネットの世界が始まると、Webサイトの持ち主は自身のサイトに検索エンジンを通じてのアクセス数が増加した事により、オーガニック検索の価値を高く評価する様になりました。

1990年代後半になりWebサイトの数が爆発的に増加してからはより一層、どうしたら自分のWebサイトが検索エンジンにとって最適になるのかを考える様になります。そこに対して、Webサイトを上位表示させる為に必要な技術や知識が求められるようになり、それが現在でいうSEOということですね。

リリース当時のYahoo!JAPANはディレクトリ型検索エンジンが主流で、Yahoo!JAPANにサイトを登録する必要がありその審査は厳選されていた為、個人規模のサイトが検索結果に反映される事はあまり無かった様です。

1998年には検索エンジンにロボット型の「goo」を採用しますが、1990年代後半時点でのSEOの手法は

  • ページの中にキーワードがいくつ含まれているか
  • サイトのページ数はどのくらいあるのか
  • HTMLの最適化が出来ているのか

といった内容でした。alt属性にキーワードを盛り込んだり、隠しテキストとしてキーワードを盛り込んだり、(内容が薄い可能性が高い)Webページを大量生産したりといった施策が頻繁に行われます。今考えればただの内的スパムです。当時は、サイトのコンテンツを充実させるとかリンクを集める、などということがなくてもちょっとした小手先のテクニックで上位表示させられる時代だったということですね。

2000年〜2010年(Google登場後)

2000年になりGoogleの検索エンジン日本に上陸してその利便性が広く浸透する様になってからはGoogleの検索エンジン導入されているページランクの判定基準である被リンクが注目される様になり、

  • 外部リンクの数を増やす
  • 質の高いサイトからリンクを貰う

といった内容がSEOの施策として注目されます。今のようにブログやTwitterをはじめとするソーシャルメディアが普及していなかった当時は自然にリンクを集めることは今に比べ難易度が高く、リンクを自前で作る為にWebサイトを大量生産するには労力的に割に合わないことなども起因となり、リンク提供型のSEOサービスの需要が2000年代後半に向け徐々に高まることになります。

SEO会社の多くはこぞってクライアントのサイトにリンクを与えて上位表示させていました。内容が伴っていないサイトであってもお金さえ払えば上位表示出来る、SEO会社もリンクを張るためのサイトさえたくさん持っていればとりあえず仕事が出来る時代と言えました。

同様に、コンテンツの品質を評価する仕組みが未発達だったことから、ただページ数だけが多いようなサイトが検索結果で多く露出されているという状況でもありました。

Googleのページランクの導入により検索結果がだいぶ改善されたとは言え、今と比べればまだまだ検索結果は粗かったと言えます。

2010年以降

Yahoo!JAPANが2010年に検索エンジンにGoogleを採用した事でSEOは事実上Googleの検索エンジン最適化とほぼ同義になりました。

編集者注:ここでは書かれていませんがそれまではシェアから考えてもYahoo!検索エンジン(YST)のSEOが主流でしたね。Yahoo!とGoogleどちらの動向も追う必要があった(しかもどちらも全然不完全で意味わかんないことも多かった、TDPとかTDPとか、、)頃に比べるとかなり最適化難易度としては易しくなっているとも感じます。

また、2011年にGoogleが行ったパンダアップデートよって低品質なコンテンツが上位表示されにくくなりました。

同様に2012年のペンギンアップデートの導入や、によるガイドライン違反に対するペナルティ対応の強化などにより、それまでのようにリンク集め

以降、SEOの手法に関しては、もちろんHTMLの最適化や被リンクは必要ですがそれよりも、本質的にユーザーにとって価値のあるサイトを作れているのかどうか、という方向性に徐々に興味がシフトしていくようになりました。

まだまだユーザーの求める情報を完璧に提供出来ているとは決して言えない状況ですが今後、よりユーザーの求めるサイトが上位表示される世の中になる事は間違いありません。

※出典※

最後に

SEOの歴史はまだ約20年と浅いものですが、スピード感のあるWeb業界においてこれからのSEOに関する環境もさらに変化していきます。

この様な時代において新しい発見や知識を得るには「温故知新」という諺がある様に歴史を知る事も必要なのかもしれません。

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

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で何ができるか?を知っておくことは、誤った使い方によるリスクを避けたり、取りうる選択肢を増やすという意味で重要と言えるのではないでしょうか。

ヴォラーレ株式会社 若松

ウェブアプリケーション用インタフェースビルダーを提供するDivshot、シードラウンドで110万ドルを調達

サンタモニカのDivshot発表によると、同社はシード資金として110万ドルを調達した。Divshotはウェブアプリケーションのインタフェースをドラッグ&ドロップで作成するためのサービスを提供している。本ラウンドはRincon Venture Partnersが主導したもので、500 Startups、Daher Capital、Floodlight Ventures、Cooley LLP、Drummond Road Capital、そしてEric Hammondが参加している。

Divshotが運用を開始したのは、カンザスで開催されたStartup Weekendというイベントがきっかけだ。イベントにおいて、他の開発者たちからの絶賛を受け、共同ファウンダーのMichael BleighおよびJake JohnsonがDivshotにフルタイムで専従することを決意したのだった。またCrowdStart LAにも参加して、Right Side Captalから設立資金の25万ドル及び、将来的な資金調達についても相談し得る地位を獲得した。また最近までLaunchpad LAにも属していた。

Divshotはさまざまな経験の中で、サービスの外観をシンプルでかつ実用的なものに変更してきている。そうした方が開発者たちからの評価が高くなることを発見したのだそうだ。

当初、DivshotではTwitterによるUIフレームワークのBootstrapを利用していた。そのフレームワーク上で動作するWYSIWYGエディタを提供してインタフェースやモックアップの開発速度を向上させるというサービスを提供していたのだ。しかし「私たちの目的はひとつのフレームワークでのみ動作するニッチなツールを開発することではないのです」とBleighは述べる。その発言通り、DivshotはZURB Foundationおよびモバイル用CSSフレームワークのRatchetのサポートをアナウンスしている。

「ウェブ開発における標準ツールの地位を獲得し、ビジュアルデザインの世界でAdobeのCreative Suiteが占めているような立場に立つ可能性もあると考えているのです」とのこと。

2000名以上の開発者とのプライベートテスト段階を経て、昨年10月に一般公開となった。その当時で9000人以上の開発者が利用を希望していたのだそうだ。口コミなどによる評判が広がり、今では40000名以上の人が利用している。

最近は「Divshot Docs」というオープンソースのドキュメントサイトも公開して、ここにガイド、チュートリアル、Tips、ちょっとしたトリック系の使い方などの情報を掲載している。オープンソースというやり方に非常に積極的であるようだ。

Divshotの公開ベータには、こちらより、現在のところ無料で参加することができる。

原文へ

(翻訳:Maeda, H)


フィリピン発の簡易サイトビルダーInfinite.ly, 途上国市場を目指す

infinite.ly logo

モバイル、HTML5、といった新しい動向とともに、このところ、アプリやサイトの制作を簡易化し大衆化するツールがまた続々と登場している。今回ご紹介するフィリピンのInfinite.lyも、その一翼だ。

同社はWix.comなどと同じく、今からHTMLなどを勉強するのは面倒、という人たちに、ドラッグ&ドロップによる簡易なWebサイト制作方法を提供する。

ユーザはまず、提供されているテンプレートの中から気に入ったのを選び、それをカスタマイズしていく。そして完成したら、通常バージョンとモバイルバージョンを同時にパブリッシュできる。Facebookの統合も可能だが、その機能は別のタブにしなければならない。私はモバイルで試してみたが、工程全体がとても迅速で円滑だ。

ドメイン登録サービスと提携しているので、ユーザはこのツールの中から自分のドメインをサインアップできる。

Infinite.ly screenshot

ライバルのWixは昨年の10月に、サードパーティのデベロッパ向けにSDKの提供を開始した。つまりサードパーティデベロッパの力を借りて、Wixの内容を一層充実させようという腹だ。そのときWixにはすでに、2500万のユーザがいた。

Infinite.lyのファウンダLuis Buenaventuraは、Wixのような強敵は多いけど、フィリピンなど途上国はまだこれからだ、と言う。今後はフィリピンの大手銀行に口座を開き、彼らと提携して中小企業の顧客を紹介してもらう戦略を考えている。

Infinite.lyのチームは正社員が4名、フィリピンの投資家Winston Damarilloからの50万ドルのシード資金により、2010年に創業した。Damarilloはロサンゼルスのクラウドインフラ企業Morphlabsと、フィリピンのソフトウェア開発企業Existのオーナーでもある。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))