RIAの検索エンジン最適化テクニック
作成日
13 March 2009
ページ ツール |
必要条件
ユーザーレベル
すべて
現在、リッチインターネットアプリケーション（RIA）を開発するためには、AjaxやCurl、JavaFX、Microsoft Silverlight、Adobe Flash Platformなどの様々なテクノロジー・プラットフォームが用いられています。RIAは、検索エンジンにとって悩みの種であることは言うまでもありません。この問題の重要性を認識したアドビでは、GoogleおよびYahoo!と協同して問題の根本的な対策を検討し、Adobe Flash Platformだけではなく、今後の技術革新にも影響を及ぼせるような原則および解決策の提示に向けて努力しています。
これと同様の課題は、既に数年前にPDF形式で問題となっていました。当時、検索エンジンはPDFドキュメントのコンテンツ認識に難がありましたが、今では比較的に手軽にPDFファイルも巡回およびインデックス化できるようになっています。つまり、この問題もゆくゆく解決されるというのが重要なポイントです。アドビ、Google、Yahoo!はこの最前線にいるのです。
昨年、アドビは最適化済みのAdobe Flash Playerテクノロジー（のちに「Flash Player for Search Engines」と命名）をリリースするという非常に重要な発表を行いました。このプレイヤーは、SWFコンテンツのステートを変化させ、コンテンツ内のテキストにアクセスすることを可能にする、いわば「ヘッドレス」バージョンのFlash Playerプレイヤーです。Flash Player for Search Enginesの仕組みの概要紹介は、Duane Nickull氏のビデオブログエントリーに掲載されています。
アドビ、Google、Yahoo!が協同でこの問題に取り組む間も、読者側でSWFコンテンツの検索精度を高めるためにできることはあります。この記事では、読者がデベロッパー、デザイナー、コンテンツ所有者、Webサイト所有者、プロジェクトマネージャー、あるいはSEOエキスパートのいずれであるかを問わず、どのような課題に注意し、どのような方法でこれらに対処すればよいかについて解説することにします。
例えば、仮に読者がAdobe Flashテクノロジーを用いたサイトを完成させたとします。このサイトのしゃれたデザイン、スムーズなアニメーション進行、充実したユーザー体験全般に関してはクライアントからの評価も高く、独創的なブランド体験が見事に確立されているとともに、サイトの更新も簡単にできるような、とてもクールなサイトであったとします。納期、予算、コンテンツの課題点といった懸案事項もすべてクリアーし、誰もが達成感に満ちあふれていることでしょう。この記事では、プロジェクトの初期段階で見過ごされがちな、最も重要な質問の1つに対する答えを提供することにします。その質問とは、「ところで、このサイトは検索エンジンとの相性に問題がありませんか」という質問です。皆さんも、このような状況に直面したことがあるのではないでしょうか。
通常、この質問は制作作業が完了し、クライアントが自らのブランドをキーワードに検索し、サイトの検索ランキングが期待したほど高くないことに気付いた時点で発生しがちです。大半の場合、検索エンジンとの親和性に優れたサイトを制作することは業務の範疇として含まれていなかったり、情報アーキテクチャーやデザインおよび機能面の仕様を決定する際に、この親和性が検討事項や議題にあがることはありません。
RIAを開発するにあたっては、クライアントの期待、デザイン上の判断、コンテンツの要件、機能面での判断など、様々な要素を検討・優先付けする必要がありますが、RIAにどの程度の検索エンジンとの親和性を求めるかを、計画段階で具体的に検討しておくことが非常に重要です。あらかじめ時間を割き、検索エンジンとの親和性が高いRIAを開発しておくことで、長期的には様々なメリットを享受できるようになります。この記事では、読者に新たな試練を与えるのではなく、開発サイクルの一環として取り入れることができる、検索関連のベストプラクティスを解説することを目指しています。検索エンジンとの親和性を高めることは実際に可能です。
この記事を効率よくフォローするには、Adobe Flashテクノロジーおよびリッチインターネットアプリケーションに精通し、Web開発テクニックに対して高度な知識を有している必要があります。
RIAと検索エンジンの課題
検索エンジンがRIAに直面した際、どのような問題・課題が発生するかを理解しておくことが重要です。つまるところ、ここで重要なのはスタティックコンテンツとダイナミックコンテンツの違いです。HTMLには最初と最後、そしてその間の部分があります。大半のRIAの場合は最初があり、様々な中間部分が存在するものの、必ずしも最後が存在するわけではありません。SWFコンテンツに遭遇した検索エンジンにとって一番の問題となるのが、ユーザーのインタラクティビティーに基づいてロードおよび表示されるダイナミックデータです。HTMLおよびSWFコンテンツが当初ブラウザーに読み込まれるのとは異なり、ダイナミックデータのロード・表示は実行時に行われます。通常、検索エンジンはこの前者のコンテンツを巡回しています。
仮に、SWFアプリケーションを主なインターフェイスとして採用するWebサイトにアクセスしたとします。SWFが埋め込まれたこのHTMLページをブラウザーで読み込み、その時点で表示されるもの、つまり、HTMLソース自体に記載されている内容が、検索エンジンによって確認されます。検索エンジンは当該コンテンツを巡回した後、他のコンテンツを巡回するために別のURLへと移動します。つまり、検索エンジンにはSWFコンテンツを操作する術もなければ、ユーザーが当該SWFコンテンツを操作するのを待つようなこともなく、単に自らに課された作業を行い、次へと進んでいきます。
次のようなケースも考えてみましょう。アクセスしたSWFアプリケーション上のボタンをクリックすると補足的な情報が表示されるようなケースがあったとします。この際、SWFアプリケーションはクリックされたボタンに応じて外部データソースからコンテンツを要求し、適切なコンテンツを表示していたとします。この場合、新たなダイナミックコンテンツは作為的なインタラクティビティーに基づいて表示されることから、検索エンジンはこれらのコンテンツを一切目の当たりにすることができません。これまで、検索エンジンのスパイダーは自らの力でRIAのステートを変化させることができず、単にSWFアプリケーションに含まれているテキストを、その構造・構成にかかわらず取得することしかできませんでした。この問題はAjaxや他のダイナミックWebアプリケーションプラットフォームにも言えることであり、やり取りされるダイナミックデータは、検索エンジンには一切見ることができません。
Adobe Flash Player for Search Enginesが対処しようとしているのは、まさしくこの状況です。ユーザーのインタラクティビティーによってどのような変化が起こり、どのダイナミックコンテンツが表示されるのかといった、SWFアプリケーションのさらに詳しい情報を検索エンジンに提供するのです。
検索エンジンとURLの関係
SWFアプリケーションの重要なコンテンツエリアに対しては、独自のURLを割り当てることが非常に大切です。仮に、Adobe TVデベロッパーセクションの人気ビデオコンテンツである「Flash in a Flash」ビデオにユーザーを誘導したかった場合、単にクリック可能なURLを配布する代わりに、次に示すような、一連のナビゲーション手順を紹介しなければなりません。
- Adobe TVにアクセスする。
- 「Developer」チャンネルをクリックする。
- 並び順の変更ポップアップメニューから「Most Popular」を選択する。最も人気度の高いビデオとして、いくつかの「Flash in a Flash」エピソードが表示される。
- 視聴したいエピソードを選択する。
検索エンジンはこれと同じような悩みを抱えています。つまり、個々のページになかなかたどり着くことができないのです。検索エンジンが自力で所定のページに到達できないのであれば、当然、当該ページ上の情報を取得・分析できないことはもちろんのこと、検索結果のページに情報を掲載することもできません。
SWFコンテンツのステートとディープリンキング
URLの問題をさらに詳しく検討するために、次のようなケースを想像してみてください。仮に読者のSWFアプリケーションが、商標のキーワード（つまり、他のWebサイトがヒットすることのないキーワード）の検索結果としてランキングされていたとし、この検索キーワードがSWFアプリケーションの5つ目のインタラクション（ステート）に現れていたとします。この場合、ユーザーが検索結果（URL）をクリックするとブラウザーにはSWFアプリケーションの最初のステートがロードされるため、ユーザーの検索内容にあったコンテンツは即座に表示されず、所定のコンテンツが表示されるまでアプリケーションを（複数回クリックして）操作し続けなければなりません。これではユーザーにストレスを与えるだけでなく、ページが完全に閲覧されないような事態になりかねません。この状況は非常に長々としたHTMLページを提示したり、検索キーワードに関わるコンテンツを表示するDHTMLがあるのと同じようなことです。これではユーザーが要求したコンテンツを即座に閲覧できるのではなく、必要なコンテンツを探すの一苦労することになります。通常、ユーザーはこのような余分な操作が必要であることにさえ気付いておらず、検索結果が誤りであったと理解することでしょう。
また、対外的な観点から考えた場合も、サイトには第三者に伝えやすいリンクを用意しておくことが重要です。例えば、仮にあるユーザーが、読者のサイトにある商品をクリスマスプレゼントとして目を付け、このリンクをFacebookのページで公開したとします。このユーザーの友人がリンクをクリックすると、追加のクリック操作なしに、所定のWebページが即座に表示されなければ意味がありません。これは優れたユーザビリティー機能であることはもちろんのこと、サイトにポイントするリンクの数と質を表す指標の「リンクエクイティー」を向上させる上でも重要です。検索エンジンは（コンテンツとともに）リンクを用いて検索結果のランキングを評価・決定します。読者のサイトにポイントするリンクは、ポケットに入っている小銭と同じようなものです。つまり、その量が多ければ多いほど、サイトの価値が高まるというわけです。ただし、量より質の方が大切であることにも注意が必要です。例えば、筆者が風邪の対処法を個人のブログに掲載したとしても、これはメディカルサイトのWebMDに掲載された同じトピックの記事には重要度でかないません。それよりもWebMDの掲載記事からリンクを張ってもらうことの方が、検索結果のランキングを高める上で有効です。
この記事で紹介するテクニックを利用すれば、検索エンジンによってSWFアプリケーションのインデックス作成が行われる確率を高めることができます。さらに、著名なドメインからSWFアプリケーションへとリンクが張られることによって、リンクエクイティーが高まり、検索結果のランキングに関しても競争力が高まるようになります。
検索ランキングの向上を目指したSWFアプリケーションの最適化
ここまでは検索エンジンに関する課題や問題点を紹介してきたので、ここからは検索エンジンがコンテンツをより確実に認識、インデックス化、ランク付けできるようにするためのテクニックをいくつか紹介することにします。
サイトにおける目標の制定
計画段階においては、検索関連の目標をある程度設定しておくことが重要です。例えば、特定の用語のランキング位置を向上させる、業務上重要な5つの用語をランク付けする、検索サイトからのトラフィック量をx％向上させるといった目標が例として挙げられます。サイトトラフィックの目標を制定する際には、検索エンジンを一番の貢献者として考えるべきです。こうすれば、SWFアプリケーションを構築し始める際に、どのような技術面およびコンテンツ面での判断を下せば良いかといった、重要な目標が明確になってきます。
HTMLソースへのSWFコンテンツの配置
Flash Player for Search Enginesが現状を変化させようとしてはいるものの、本記事の執筆時点、SWFファイル内に収められたコンテンツおよびSWFアプリケーションに外部ソースから読み込まれるコンテンツを検索エンジンが巡回・インデックス化するためには、当該コンテンツがHTMLのソースに配置されていなければなりません。単にそれだけのことですが、これを避けることはできません。したがって、サイトを計画する上での第一歩は、これらのコンテンツをHTMLのソースに含めるようにすることです。
これはアプリケーションのすべてのセクションに対して、別のHTMLページを作成しなければならないということではありません。例えば、「連絡先」セクションのコンテンツを検索するユーザーはほとんどいないはずです。検索サイトのユーザーは商品やサービスに関する詳しい情報を求めているはずです。したがって、アプリケーションのどのコンテンツセクションが重要であるか（つまり、どのページを検索結果のランキングで高く表示させたいか）を特定し、検索エンジンが巡回・インデックス化することのできるHTMLに当該SWFコンテンツから抽出したコンテンツを配置していくようにします。
ここでは、ユーザーがFlash Playerをインストールしていなかったり、JavaScriptをオフにしている場合に代替コンテンツを表示するという、ブラウザーの機能を利用することになります。Googleとアドビでは、SWFファイルを巡回できるようにするために、SWFObject内の検索性向上につながるいくつかの技術進化に成功していますが、JavaScriptに関してはほぼ全面的に検索エンジンが内容を読み取ることができません。現在、HTMLソースにSWFファイルを埋め込む際にはSWFObject 2を用いる方法が推奨されています。この方法を有効に利用すれば、検索エンジンにも理解できるコンテンツを供給することができます。
方法としてはいくつかの選択肢があります。1つは<div>タグを利用してHTMLソースにコンテンツを含めるやり方です（SWFObject 2はこの操作を自動的に処理します）。この方法でも期待した効果を得ることは可能ですが、検索業界の一部からは（<div>を利用して）コンテンツを隠すようなやり方は適切ではないという声も聞かれます。
期待した効果を得ることのできるもう1つの方法としては、<nonscript>を用いる方法があります。この場合、SWFファイルのコンテンツ（テキスト、リンク、画像など）は、ブラウザーがJavaScriptがオフであると判断した際（つまり、SWFコンテンツが表示できないと判断した際）に表示されるタグの中に配置します。
<noscript>
<!-- alternative SWF content -->
</noscript>
ここでは所定のコンテンツがHTMLソースに含まれているため、検索エンジンが難なくコンテンツを巡回し、ページの内容を把握するために必要な情報を入手できるというメリットがあります。このような情報把握は、タイトル、見出し、本文、リンクテキストなどに、適切なキーワードを含めておくことで実現可能です。ただし、非SWFコンテンツを閲覧するユーザーが必ずいることに注意が必要なので、HTMLにおいてもSWFコンテンツ上で使用したデザイン要素を取り入れることが賢明です。これは簡単なCSSを使うことで実現できるはずです。
この方法の成功事例としては、Procter & Gamble社のPUR Water Filtration SystemWebサイトが挙げられます（図1参照）。
このページの<noscript>を使ったバージョンは、ご利用中のブラウザーのJavaScriptをオフにすることで確認できます。JavaScriptをオフにし、つまりSWFなしでこのサイトを表示しても、コンテンツと大半のユーザーインターフェイスがそのままであることが確認できます（図2参照）。このサイトのソースコードを表示してみると、SWF上のコンテンツと同じものが、単にHTMLでフォーマットされ、<noscript>タグ内に配置されていることが確認できるはずです。これなら検索エンジンもコンテンツを巡回し、各ページの内容を把握することができます。
メモ： JavaScriptのオン・オフはChris Pederick氏が作成したMozilla Firefoxプラグインの「Web Developer」を使うことで簡単に切り替えられます。WebサイトのQA時にはこのツールが重宝します。
上図に示すとおり、HTMLバージョンにはSWFバージョンと同様のコンテンツが配置されています。このやり方が検索エンジンにリッチコンテンツを提示する際の最適の方法です。SWFバージョンを表示できるユーザーの体験と検索エンジン最適化の絶妙なバランスが取れていることから、この方法は既にDisneyやP&Gといった大手ブランドによっても採用されています。
一見すると、この方法は複雑で、余分な費用と時間がかかるように思われることでしょう。確かにこの方法は余分な制作時間とQA時間を必要としますが、時間を節約するとともに他のプロジェクトにも流用できるような効率アップ策は他にも存在します。例えば、HTMLとSWFファイルの両方のコンテンツを単一のXMLソースでコントロールするというのはどうでしょう。XSL（Extensible Stylesheet Language）を使用すれば、XMLデータをHTMLだけではなく、ブラウザーでの表示に適した他のフォーマットにも加工することができます。この方法なら修正などのメンテナンス作業も手軽にできるようになり、コンテンツの正確さをさらに高めることが可能です。文章の修正やコンテンツの更新は、一度行うだけで両方のフォーマットに適用されるようになります。
検索エンジンのSWFアプリケーション認識力を高めるためのもう1つの要素として、メインナビゲーションをHTMLコードで作成することも重要です。検索エンジンはサイトコンテンツの理解を深めるための手がかりとして、Webサイトのメインナビゲーションを利用してサイト内のリンクを巡回します。この記事の冒頭でも触れたとおり、Flash Player for Search Enginesは、GoogleやYahoo!がSWFコンテンツを巡回する作業を支援するためのものです。このソリューションの進化・進歩がもう少し進むまでは、メインナビゲーションをHTMLで作成するのがベストプラクティスです。
重要なセクションごとに個別のURLを作成
重要なSWFコンテンツをHTMLソースに配置することは、問題の解決に向けた一歩に過ぎません。これだけではURLとディレクトリー構造の問題に対処することができません。例えば、大半のSWFアプリケーションでは、サイト全体に対して1つのURLしか用意されておらず、この1つのURLに対しては、同じタイトル、H1、本文というように、（ブラウザーがリフレッシュすることがないため）同じHTMLソースしか存在しません。検索エンジンのベストプラクティスに適合させるためには、個々のURLに対してそれぞれ別のタイトル、H1および本文が必要となり、しかもこの中に検索結果としてランキングされるキーワードが含まれている必要があります。
ご存知のとおり、WebページにSWFファイルが埋め込まれている場合、ユーザーがそのコンテンツを操作するためにブラウザーの表示をリフレッシュする必要はありません。たとえSWFアプリケーションの「製品紹介」セクションにある3つ、4つのリンクをクリックして製品の詳細ページにたどり着いたとしても、これらのクリック操作によってブラウザーに表示されているURLが変化することはありません。つまり、製品のカテゴリー表示、概要紹介、詳細ページ、購入ページといった個々のセクションに対しても、常に同じHTMLソースが使われていることになります（検索エンジンは常にこの同じHTMLソースを巡回することになります）。<div>を使ってSWFアプリケーションの全セクションのテキストおよび関連コンテンツを検索エンジンに見せる方法は、とても簡単な解決策にみえたかもしれません。この方法が抱える問題点は、個々のセクションの全アイテムの製品情報を単に1つのHTMLソース上に列挙した場合（つまり単一のURLしかなかった場合）、検索エンジンは当該コンテンツを巡回できるものの、様々な情報が混在しているがためにページ自体にどのような内容が記載されているかを的確に判定できなくなるということです。様々なカテゴリーの情報が多数配置されていることが原因で、何が重要であるかを判断できなくなってしまうのです。
一部のWebサイトではこの方法がホームページで使われています。このようなサイトにはHTMLのランディングページがあり、そのページにSWFコンテンツの再生を開始するための「Flashサイトを起動」ボタンが配置されています。そして、HTMLのランディングページには、すべてのサイトコンテンツのSWF代替コンテンツがHTMLソースに配置され、これで検索エンジン対策が済まされたかのようになっています。もちろん、検索エンジンはこのようなコンテンツを巡回することができるものの、ページのどのトピックが重要であるかを読み取ることができないため、あくまでデータが列挙されているだけの状態になってしまいます。要するに、様々なキーワードが数多く散らばっているだけなのです。
サイトのどのセクションが重要であるかは、検索面での目標から割り出すことができます。例えば、ランキングさせたい重要なビジネスキーワードが15個あると判断したとします。この場合、15個の個別のURLが必要になります。これは、キーワードの検索後にユーザーにクリックさせたいURL（PLP: Preferred Landing Page（優先ランディングページ）とも呼びます）とそのキーワードに1対1の相対的な関係をもたせることが重要だからです。仮に読者のサイトが靴を扱っているのであれば、「バスケットボールシューズ」と検索した結果は靴全般のページではなく、バスケットボールシューズ専門のページにアクセスできるようにすることが当然と言えるでしょう。こうすれば、ユーザーは読者のサイトにアクセスしてから必要な情報にたどり着くためにクリック操作を行う必要がなくなり、ユーザー体験の向上につながります。これはあたかも、講義の聴講者が手を挙げ、特定の情報を知りたいという意見を述べているのに対して、適切な情報をサイトで提供できるようにするのと同じようなことです。より的確な情報を提供すれば、ユーザーがサイトにとどまる確率は飛躍的に高まり、検索エンジンに戻って他の検索結果へとユーザーを逃すような事態を軽減することができます。ここでは、ユーザーの求めるコンテンツが、手間暇かけずに見られるようにすることが肝心です。
このような問題を認識しているアドビでは、Adobe Flex 3において様々な進化を実現しています。Adobe Flex 3では、SWFアプリケーション内でのディープリンキングが許可されています。これはユーザビリティーとソーシャルメディアの両方の側面からみて有効な機能です。ただし、Flex 3またはSWFAddressでのディープリンキングテクニックを用いても、同じような問題は発生します。どちらのテクニックもブラウザーのリフレッシュを必要としないことから、巡回可能なソースHTMLコンテンツは存在しないという問題です。
したがって、サイトマップやワイヤーフレームを作成する際には、これについても検討を重ねることが重要です。まず、ディレクトリー・URLの構成を計画することから始めるようにします。PLP（優先ランディングページ）とキーワードに1対1の関係が生じるように計画するとともに、当該SWFコンテンツの要件を検討するようにします。例えば、次のようになります。
- キーワード1 – http://www.example.com/example1.html
ここではexample.swfが、デフォルトでキーワード1に関する情報を表示するように設定 - キーワード2 – http://www.example.com/example2.html
ここではexample.swfが、デフォルトでキーワード2に関する情報を表示するように設定 - キーワード3 – http://www.example.com/example3.html
ここではexample.swfが、デフォルトでキーワード3に関する情報を表示するように設定
ディレクトリー構造の計画が完了したら、次はSWFコンテンツをどのような構成で制作するかを検討します。URLごとに個別のSWFファイルを作成することは推奨されません。これはメンテナンスが手に負えなくなってしまうからです。個々のSWFファイルを用意する代わりの方法としては、毎回同じSWFファイルを埋め込み、どのステートを表示させるかを変数を渡すことでSWFに指示する方法があります。この指示はSWFObjectにも用意されているFlashVarsを使って処理することができます。
Objectタグの記述例：
<PARAM NAME=FlashVars VALUE="state=1">
Embedタグの記述例：
<EMBED src="display.swf" FlashVars="state=1"></EMBED>
可能であれば、FlashVarsへの書き込みをPHP、Adobe ColdFusionまたはASPで処理するようにしておくことが推奨されます。この方法なら、URLごとに新たなSWFを作成することなく、個別のURLを割り当てられるようになります。次に示す2つのURLには、単に同じSWFを埋め込むだけで良いことになります。
http://www.example.com/example1.html
http://www.example.com/example2.html
アニメーション化されたコンテンツへの配慮
読者の皆さんは、Adobe Flash ProfessionalまたはAdobe Flexを利用してアニメーションコンテンツをオーサリングし、Webサイト上で何らかのアニメーションを表示していることでしょう。ホームページにヘッダーとしてバナーのアニメーションを配置しているケースもあれば、アニメーションコンテンツを表示するための様々なオプションがクリックできるような、インタラクティビティーを用意しているケースもあることでしょう。また、画面テキストがアニメーション化されていたり、画像の説明文がフェードイン・フェードアウトするといったトランジション効果や、ユーザーのインタラクションによって変化が起こるような仕掛けがなされているケースもあります。どのような形であれ、アニメーション化されたコンテンツを含むSWFファイルがHTMLソースに埋め込まれていることは間違いないので、これらのコンテンツもHTMLソースに確実に含めておくことが肝心です。
特にバナー方式のヘッダーや大規模なホームページアニメーションにおいては、重要なマーケティングキャッチコピーがSWFファイル内に記されていたり、ロードされるSWFファイルに含まれていることがよくあります。これらのアニメーションを作成する際には、実際の文字を使うようにすることが重要です。SWFアプリケーションでテキストを表示する際、画像やフラットにしたシンボルを使用したり、ActionScriptでテキストを生成するようなケースが見られますが、これはよくある誤りです。Flash Player for Search EnginesはSWFアプリケーション内のコンテンツを読み取ることができます。したがって、実際に読み取ることが可能なテキストを配置するとともに、HTMLソースにこれと同じものを配置しておくことが重要です。
SWFアニメーションに含まれたどのコンテンツ、リンク、画像説明文が重要であるかを検討・判断するようにします。これができたら、SWFコンテンツの一部を抽出し、この記事で紹介した<noscript>の方法を利用してHTMLに必要なコンテンツを配置していきます。
デザイン上およびアニメーション上、どのような決定を下すかによって、検索エンジンによるコンテンツのインデックス作成時に、良い方向にも悪い方向にも影響が及ぶことがあります。重要なPLP（つまりURL）においては、アニメーション、およびセクション・ページ間の画面遷移を必要以上にデザインしすぎないように注意する必要があります。例えば、商品を紹介するWebサイトの場合、ユーザーがリンクをクリックして商品を選択すると、別のページが表示されます。ここではブラウザーによって新たなページがリロードされるので、ユーザーにシームレスな視聴体験をするために入念に作り込む余裕がない場合は、手の込んだ画面遷移エフェクト（アニメーション、フェードイン・フェードアウト、およびその他のエフェクト）は控えるようにするのが賢明です。また、これらのアニメーションや各種機能がユーザー体験に欠かせないものであるかどうかも、入念に検討する必要があります。アニメーションは商品のズーム表示といった特殊なユーザー機能や、検索エンジンにランキングされる必要のないページのためにとっておく方が良いでしょう。
ここで注意しなければならないのは、RIAのクールな機能をすべて取り除くということが目標ではないと言うことです。ここで紹介した例の場合は、読者が選んだ15個のビジネス的に重要なキーワードに対して、15個のURLがマッピングされます。仮にサイトに合計45個のセクションがあったとしたら、残り30個のセクションで存分にアニメーションや画面遷移エフェクト、その他の独創的なリッチインタラクティブ要素を表示することができるのです。
画像ビューワーおよびビデオプレイヤーアセットの組み込み
検索エンジンのベストプラクティスに適合させるためには、重要なURLごとに別々のタイトル、H1および本文を用意し、これらにそれぞれ検索結果としてランキングさせたいキーワードを含めるようにします。これはユーザーが画像を閲覧したりビデオを視聴できるようにするためのSWFアプリケーションにおいて、特に重要となります。
画像ビューワーやビデオプレイヤーが用意されている場合、そこにはユーザーがクリックして拡大表示できる数百の画像およびビデオサムネイルが含まれていたり、他にもリンクや説明文といった補足的な情報が含まれていることもあります。ここでの難題は、単一のHTMLページ（つまり単一のURL）に単一のSWFファイルが配置されているが故に、検索エンジンは単一のHTMLソースしか目を通せないということです。仮に前出の<noscript>の方法を利用したとしても、HTMLのソースには競合的な情報が大量に含まれるため、検索エンジンは何が重要であるか（ページの主要トピックが何であるか）を判断することができません。以前にも述べたように、キーワードとPLP（優先ランディングページ）の間には1対1の関係を築くことが重要です。
これらのアセットに個別のURLを用意しなかった場合、「ユニバーサルサーチ」の恩恵を受けられなくなってしまいます。皆さんも、今日の検索が返すことのできる結果が多岐にわたることに気付いているはずです。Webサイト、ビデオ、画像、ショッピングなど、検索の結果としては様々なものが表示されます。「ユニバーサルサーチ」とは、検索クエリーに対して様々な種類のコンテンツをヒットさせられることを意味しています。だからこそ、重要なコンテンツごとにランキング付けが行われるよう、URLの構成を入念に検討することが肝心です。
その他の最適化テクニック
検索エンジンがSWFアプリケーションのインデックス付けを確実に実行できるようにするためには、以下の点にも注意が必要です。
ポップアップウィンドウの使用を避ける
Webサイトで頻繁に用いられるテクニックとして、SWFコンテンツを含むポップアップウィンドウを表示するケースがあります。例えば、mywebsite.comにアクセスするとブラウザーが通常の検知スクリプトを実行し、その後、SWFコンテンツを含むポップアップウィンドウが表示されるようなことがあります。また他にも、SWFコンテンツが配置されたポップアップウィンドウを起動する、「Webサイトを表示」リンクが備わったHTMLのオープニングページを採用するサイトも数多く存在します。
ポップアップウィンドウに関する問題は、皆さんもご存知のとおりです。この手のウィンドウはやっかいであるとともに、広告の象徴として捉えられがちです。しかも、ポップアップをブロックするためのツールは既に多数存在しています。ここで特に注意しなければならないのは、検索エンジンのスパイダーがポップアップウィンドウを巡回できないということです。SWFコンテンツを制作する際には、ポップアップウィンドウに頼らなくても済むような構成にすることが重要です。
XMLサイトマップを作成する
ここまでで紹介したアドバイスに従えば、検索エンジンが巡回できるHTMLコンテンツが配置された、いくつかのURLができているはずです。次の手順としては、検索エンジンに巡回させたいWebページを記述したXMLサイトマップを作るようにします。XMLサイトマップは、サイトのルートディレクトリーに配置しておく簡単なXMLファイルのことです（図３参照）。ご覧のとおり、<loc>ノードはユーザーの独自のURL、<lastmod>ノードはこのURLのコンテンツが最後に更新された日時をそれぞれ示し、<changefreq>ノードは検索エンジンにコンテンツがどの程度の間隔で更新されているかを示しています（この情報によって検索エンジンがコンテンツを巡回しに訪れる頻度が変わります）。<priority>ノードは各URLの重要度を規定する数値を示しています。
以下に示すのがXMLサイトマップの例です。
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>http://www.example.com/</loc>
<lastmod>2009-01-01</lastmod>
<changefreq>monthly</changefreq>
<priority>0.8</priority>
</url>
<url>
<loc>http://www.example2.com/myexample</loc>
<lastmod>2009-02-01</lastmod>
<changefreq>weekly</changefreq>
<priority>0.3</priority>
</url>
</urlset>
このセットアップを行うために必要なのは、Googleウェブマスターツールアカウントと、一連の個別URLの情報だけです。XMLサイトマップ、およびそのガイドライン、指示、提出方法などについて詳しくは、Googleウェブマスターヘルプのサイトマップについてのセクションを参照してください。
HTMLサイトマップを作成する
HTMLサイトマップとは、サイトの全セクションへのリンクが記載された、サイトに配置されるページのことです。このサイトマップの目的は読者が設定した個々のURLに対して、追加のリンクを作成することです。これはサイトのランキングが判断される際に、リンクが重要な役割を担っているためです。HTMLのサイトマップは既に皆さんも何度も目にしていることでしょう。HTMLサイトマップを見たことがない場合は、適切な作成例としてAppleのサイトマップを参照すると良いでしょう。
ビデオサイトマップを作成する
この方法はビデオアセットを多用するWebサイトで有効です。XMLのサイトマップ同様、ビデオのサイトマップも単なるXMLファイルに過ぎません。このファイルにはURLを規定できるだけでなく、ビデオのサムネイルプレビュー画像の位置を規定することができます（図4の<video:thumbnail_loc>ノードを参照）。
以下に示すのがビデオサイトマップの例です。
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
xmlns="http://www.google.com/schemas/sitemap-video/1.0">
<url>
<loc>http://www.example.com/videos/some_video_page.html</loc>
<video:video>
<video:content_loc>http://www.example.com/video123.flv</video:content_loc>
<video:player_loc allow_embed="yes">http://www.example.com/videoplayer.swf?video=123</video:player_loc>
<video:title>My Video</video:title>
<video:thumbnail_loc>http://www.example.com/thumbnails/123.jpg</video:thumbnail_loc>
</video:video>
</url>
<url>
<loc>http://www.example.com/videos/some_other_video_page.html</loc>
<video:video>
<video:content_loc>http://www.example.com/video1.mpg</video:content_loc>
<video:description>My Amazing Video</video:description>
</video:video>
</url>
</urlset>
このセットアップを行うために必要なのは、Googleウェブマスターツールアカウントと、一連の個別URLの情報だけです。ビデオサイトマップ、およびそのガイドライン、指示、提出方法などについて詳しくは、Googleウェブマスターヘルプの動画サイトマップを作成ページを参照してください。
robots.txtファイルを作成する
robots.txtファイルは、検索エンジンが巡回できるコンテンツを手軽に制御できる方法です。robots.txtはWebサーバーのルートディレクトリーに配置するテキストファイルであり、検索エンジンのスパイダーに対して当該サーバー上のどのファイルが閲覧可能であるかを示します。このファイルには2つの命令文のみ記述できます。
- User-agent:
user-agentステートメントは、次のdisallowステートメントが適用される対象のスパイダーを指定します。ユーザーエージェントをアスタリスクで指定した場合、すべてのスパイダーが適用対象になります。 - Disallow:
disallowステートメントでは、スパイダーに巡回させたくないファイルを指定します。個々の詳細なファイル名だけでなく、名前の一部やディレクトリー名を指定することも可能です。例えば、「e」を対象として指定した場合、「e」から始まるファイル、および「e」から始まるディレクトリー上のファイルすべてが巡回対象外となります。「/」を指定すると、すべてのファイルが対象外になります。
次のrobots.txtのコードサンプルの場合、 cgi-bin と java ディレクトリーがスパイダーの巡回対象外になります。また、「roguespider」のスパイダーに関しては、すべてのファイルの巡回が禁止されることになります。
User-agent: *
Disallow: /cgi-bin
Disallow: /java
User-agent: roguespider
Disallow: /
より詳しいドキュメンテーションについては、Googleウェブマスターヘルプのrobots.txtファイルを作成ページを参照してください。
次のステップ
SWFアプリケーションを検索エンジン向けに最適化する際の手順は、以下のとおりです。
- 他社と競争しなければならないビジネス上重要なキーワードを特定し、これらのキーワードがコンテンツに与える影響などを検討して、検索面での目標を制定する。
- 制定した検索面での目標に基づいて、サイトの重要なセクションごとに個別のURLを作成する。
- SWFファイルに変数を渡し、個々のURLでどのコンテンツまたはステートを表示するかを指示する。
- 利用しているデータ構造に応じて、個々のURLにおいて、HTMLソースでも必ずSWFのコンテンツが表示されるようにする。可能であればXSLを利用してXMLのソースを加工し、HTMLとSWFのコンテンツを作成するようにする。必要なテキストは
<noscript>を用いる方法で、HTMLのソースに埋め込む。 - メインのナビゲーションをHTMLで作成する。
- サイトの重要なセクション間の画面遷移を過度に作り込まないようにする。これは別のURLに移動する際に、ブラウザーが表示をリフレッシュしなければならないからです。アニメーション、画面遷移時のエフェクト、およびその他のインタラクティブ要素の使用は、サイトの最も重要なページ・セクションでは避けるようにするのが賢明です。
- ポップアップウィンドウの使用を避ける。
- XMLサイトマップを作成する。
- HTMLサイトマップを作成する。
- ビデオアセットを使用している場合は、ビデオサイトマップを作成し、これを送信（提出）する。
- robots.txtファイルを作成する。
- クイックリファレンスとして、RIAの検索エンジン最適化チェックリストを参照する。
リンクと関連リソース
この記事で紹介したトピックについてさらに詳しくは、以下の関連リソースを参照してください。
