SEO vs ユーザビリティを超えた情報アーキテクチャ

SEOとユーザビリティをどう両立させるかという話は昔からある話ですが、共にテクニカルな話に落とし込まれがちで、ともすれば本質を見失ってしまうケースも意外にあるのではないでしょうか。今回は、SEO、ユーザビリティ、その両立、共にもう一歩上のレベルで実践していくための情報アーキテクチャについて勉強できる記事をサーチエンジンランドからお届けします。 — SEO Japan

1995年以来、私が遭遇した最もコストが高くついたSEOの過ちは、劣悪な情報アーキテクチャを採用してしまったことだ。ファインダビリティ(見つてもらえる能力)における重要な課題は、ウェブサイトの情報アーキテクチャだとクライアントに指摘すると、私が与えた情報はすぐにテクノロジーを担当するチームに伝えられた。

すると、テクロノジーチームの誰かが、コンテンツはクロール可能であり、アーキテクチャは問題がないと親切にも教えてくれた。こうなると私にはグーグルのアルゴリズムの知識があまりないため、自分が誤っていたと判断するしかなくなる。

その結果、劣悪なアーキテクチャを持つウェブサイトが生まれ、検索エンジンのビジビリティはほとんど得られず、クライアントをイラつかせ、私の自尊心はことごとく踏みにじられた。

どのような経緯でそうなったのだろうか?どこでつながりは途切れ、どこでミスコミュニケーションは生まれたのだろうか?

信じられないかもしれないが、多くのSEOのプロ、開発者、そして、その他のITのエキスパート達は、SEOのプロセスでの情報アーキテクチャ(IA)の役割を理解していない。事実、彼らはウェブ開発のプロセスにおけるIAの役割も理解していないことが多い。

このような誤解および誤った概念により、自尊心はズタズタに引き裂かれ、クライアントのフラストレーションはピークに達したのであった。そこで、今回の投稿では、全てのウェブのエキスパートに理解してもらうため、違いと混乱の原因を見直していく。

情報アーキテクチャを理解する

インフォメーション・アーキテクチャ・インスティテュートのウェブサイトに掲載されている定義は、最もシンプルで最も分かりやすいと私はおもう。情報アーキテクチャは、ユーザビリティおよびファインダビリティを支援するために、ウェブサイトのコンテンツを整理、またはラベルを張る取り組みである。

情報アーキテクチャのプロジェクトに取り組む際は次の4つの用語が鍵を握る:

  • 整理
  • ラベル
  • ユーザビリティ
  • ファインダビリティ

ウェブサイトの情報アーキテクチャの特定は、サイトのコーディングおよびプログラミングを行う遥か前に行っておくべきである。

事実、次のようなギークな発言を目にするまたは耳にしたら、その情報アーキテクトが仕事に適任だとは思わない:

  • クローラビリティ
  • インデックス
  • 301 リダイレクト(.htaccess等)
  • カノニカライゼーション
  • ロボッツエクスクルージョン
  • URL ワークアラウンド
  • NOFOLLOW アトリビュート

上述した用語は、テクニカルなアーキテクチャの一部であり、情報アーキテクチャとは異なる

ウェブのエキスパート達は、情報アーキテクチャとテクニカルアーキテクチャを混合してしまう。そのため、テクニカルアーキテクチャが、情報アーキテクチャを決定してしまう – これは致命的なミスである。ユーザー中心デザイン(UCD)とアーキテクチャは、テクノロジー中心のデザインよりも遥かにコスト面でも時間の面でも効率が良いと私は考えている。

「長い目で見ると、テクノロジー中心のデザインは、プロジェクトやビジネスの目的に対して非生産的である。」

~ ジェームズ・カールバック デザイニング・ウェブナビゲーション(2007年ワイリー)の著者

それでは、情報アーキテクチャの役割の理解に話を戻そう。オーガニゼーション(整理)は、関連するコンテンツを分類して、グローバル、ローカル、そして、コンテクスチュアルなナビゲーションを介して、コンテンツにユーザーフレンドリーなアクセスを提供する取り組みである。

コンテンツを整理する方法は数多くあり、以下に挙げる方法以外にも存在する:

  • 日/時間
  • アルファベット順
  • 地理/場所
  • トピック
  • ターゲットのオーディエンス
  • タスク/プロセス
  • アトリビュート/ファセット
  • 組み合わせ

なぜ、情報アーキテクトは、ファセットやターゲットのオーディエンスを通して、整理したり、ラベリングすることに決めたのだろうか?情報アーキテクトは、主要なペルソナにフィットする参加者を考慮して整理、そして、コンテンツのラベリングを行っただろうか?これは情報アーキテクトの仕事である。 情報アーキテクトは、クローラビリティや「リンクジュース」の流れを基にコンテンツの整理を決定するわけではない。

ピーター・モービル氏とルイス・ローゼンフェルド氏によるワールドワイドウェブに対する情報アーキテクチャを脚色させてもらった。許可を得ている。

ウェブサイトの情報アーキテクチャのプロジェクトに取り掛かった際に、私が知っておきたかったポイントを挙げていく:

  • プライマリ・ナビゲーション。 プライマリ・ナビゲーションで提示されているラベルは何か?プライマリ・ナビゲーションにはナビゲーションラベルが幾つあるか?プライマリ・ナビゲーションのラベルはどのような順番で提示されているか?プライマリ・ナビゲーションはどこに配置されているか?
  • セカンダリ・ナビゲーション。 各プライマリ・ナビゲーションのラベルに対するセカンダリ(ローカル)ナビゲーションは存在するか?それはどのラベルか?どのような順番でラベルは提示されているか?セカンダリ・ナビゲーションはどこに配置されているか?ページにセカンダリ・ナビゲーションがない場合、ページのレイアウトはどのようになっているか?
  • サード – フォースレベルのナビゲーション(必要に応じて)。以上の規則に則り、ラベルが提示されている順序、そして、ラベルの数。
  • コンテクスチュアル・ナビゲーション。 異なるページのテンプレートにどのようなタイプのコンテクスチュアル・ナビゲーションが配置されるのか(カテゴリー、ヘルプ、サービス、フォーム等)?代わり、グレードアップ、最も人気の高い等のコンテクスチュアルなリンクやその他の関連するリンクは、プライマリのタクソノミや関連するローカルのリンクと同様、ファインダビリティにとって重要である。シブリング-シブリングのリンク、そして、ペアレント-チャイルドのリンクの効果的なバランスは存在するのか?
  • ページ当たりのリンクの本数。 どれほどリンクがあるとユーザー/検索者にとって多過ぎるのか?例えば、私ならカテゴリーページ、サイトマップ(ウェイファインダー)、そして、サイトのインデックスには、製品ページやヘルプページよりも多くのリンクがあると推測する。反対に、どれだけのリンクの本数は少な過ぎるのか?孤立したページは、検索エンジンの目には重要性が低いと映る(1本しかリンクがないため)。また、孤立したページのコンテンツはユーザーに目には重要ではないと映る。なぜなら探し出し、発見するのが難しいからだ。

お気づきのように、このリストにはカノニカライゼーション、301 リダイレクト、NOFOLLOW アトリビュート等を載せていない。ただし、これらのテクニカルなアーキテクチャがSEOとサーチャーエクスペリエンスにとって重要ではないと言っているわけではない

テクニカルアーキテクチャを却下しているように思えるかもしれないが、そういう意図はない。私は閲覧および検索を介してコンテンツにアクセスしてもらう重要性を理解している。ピーター・モービル氏も「アンビエント・ファインダビリティ」(2007年 ワイリー出版)の中で指摘しるように、“見つけることが出来ないものは使うことが出来ない”。

テクニカルアーキテクチャ & ファインダビリティ

私もモービル氏と同じ意見だ。大勢のテクニカルアーキテクトもまた同意するだろう – しかし、誤解は解けていない。完全にデザインされ、利用可能なウェブサイトであっても、検索エンジンのスパイダーにアクセスすることが出来るとは限らない。テクニカルなSEOの判断を考慮し、実行に移す必要があるのだ。

ウェブディベロッパーとして、私はクライアントのために以下のような様々なテクノロジーの判断を下さなければならない:

  • サーバーのタイプ
  • コンテンツ管理システム(CMS)
  • ナビゲーションのタイプ(テキストリンク、イメージ、メニュー)
  • コーディングおよびスクリプティング
  • 個別のページのトラブルシューティング

最終的な判断を私が下さない場合でも、検索ユーザーと検索エンジン側からの視点でこれらの決定について相談を受けることが多い。検索エンジンがナビゲーションのシステムとコンテンツを解釈する仕組みだけを考慮して、テクノロジーの決断を下すわけではない。

まず、IA、マーケティング、そして、ユーザビリティを担当するチームが何を決定したのかを把握する。その後、テクノロジーの判断を下す。つまり、情報アーキテクチャがテクニカルアーキテクチャを導くべきだと私は考えているのだ。

例えば、重複するコンテンツの提供は、営利目的のウェブ検索エンジンを介した求めるコンテンツへの直接的なアクセスを制限する可能性がある。また、重複するコンテンツの提供は、通常、ユーザーを困らせ、苛立たせる。ユーザー生成型のタグやファセット化された分類は、重複するコンテンツの提供に結びつくことがよくある。

従って、私、もしくは別の適任の情報アーキテクトが、ウェブサイトのコンテンツはファセット分類やユーザー生成タグによって問題なく整理されていると判断した場合、ネガティブなSEOのインパクトを最小限に抑えるため、開発プロセスの早い段階でテクニカルアーキテクトに参加してもらう必要がある。

もう一つ例を紹介する。メニューだ。メニューをナビゲーションシステムに採用するメリットとデメリットをよく耳にする。SEOとしては、テクニカルチームがメニューを実装したがる理由は理解している。メニューはスクリーンのスペースを保ち、一部の検索エンジンはクロールすることも可能であり(コーディング/プログラムによる)、そして、“ユーザーが愛用”しているからだ。  troll Bridge Ahead - Must Solve Google's Algorithm to Pass (image)

情報アーキテクトおよびユーザビリティのエキスパートとしては、各種メニューの失敗率(フライアウトメニューはドロップダウンメニューよりもエラーが起きる可能性が高い)、選択の矛盾、そして、コンテンツにアクセスするために用いられるテクノロジーを考慮しなければならない。

ユーザビリティ界の重鎮、ジャレッド・スプール氏は、人間とテクノロジーの双方の観点から、「巨大なメニューと戦う6つの大きな力」を説明している。

情報アーキテクトは、グーグルのアルゴリズムや最新のURLのワークアラウンドの知識を得て、SEOのガイダンスや効果的なラベリングのアドバイスをテクニカルチームに与える必要はない。コンピュータの学位を持っていなくてもよいのだ。しかし、ランキングにマイナスの影響が出る可能性があるため、情報アーキテクチャとユーザビリティのガイダンスを断固として受け入れないテクノロジーチームが多過ぎる。

現実には、情報の整理とラベリングは売り上げ、コンバージョン、そして、(その通り!)検索エンジンのビジビリティも高める効果がある。ルイス・ローゼンフェルド氏は、そろそろIをITに戻そうと呼びかけている。

お仕置きの時間: より重要なのはどっち?

効果的な情報アーキテクチャと調和するテクニカルアーキテクチャを組み合わせたシステムが、ウェブサイトのアーキテクチャの理想だと私は思う。テクニカルアーキテクチャが情報アーキテクチャに勝るとは思わない。また、情報アーキテクチャがテクニカルアーキテクチャに勝るとも思わない。テクニカルアーキテクトと情報アーキテクトはお互いに耳を傾けて、支え合わなければならないと私は思う。

「情報アーキテクチャは、コンテンツの構造と整理を考慮し、その多くは実装の知識がほとんどない状態で行われる可能性がある」とインフォメーション・アーキテクチャ・インスティテュートのコンサルタントであり、現役員の一人であるドリアン・テイラー氏は述べている。「テクニカルアーキテクチャは、システムの実装を考慮し、その多くはコンテンツの知識がほとんどない状態で行われる可能性がある。」

「SEOは、機械 – この場合、検索エンジンを指す – にとって意味のある構造を作成する取り組みだとも言える。機械が人々にとって意味のある構造を作り出せるようにするためだ。」とテイラー氏は続けている。

「SEOと言うよりもよりも、UXだな」と情報アーキテクトを罵り、情報アーキテクチャのファインダビリティへの貢献が、テクニカルアーキテクチャよりも低いが如く振舞うのではなく、お互いに耳を傾ける必要がある。素晴らしいテクニカルなスキルを持つ情報アーキテクトはとても多い。彼らは、テクニカルアーキテクトの人達が思っている以上にファインダビリティとSEOを熟知している。

この記事の中で述べられている意見はゲストライターの意見であり、必ずしもサーチ・エンジン・ランドを代表しているわけではない。


この記事は、Search Engine Landに掲載された「SEO Smackdown: Information Architecture vs. Technical Architecture」を翻訳した内容です。

「効果的な情報アーキテクチャと調和するテクニカルアーキテクチャを組み合わせたシステムが、ウェブサイトのアーキテクチャの理想」、、、読めば納得の話ですが、実際の実践はそれなりの経験と知識が求められそうですね。専門家を雇えればいいのかもしれませんが(日本に何人の情報アーキテクトがいるか知りませんが)、SEOとの両立は両立でまた課題も多そうですし、そこまでの余裕は無い場合は、ある程度基本的な知識を学んだ上で自ら実践していくしかなさそうです。 — SEO Japan
Page Top

投稿ナビゲーション