まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:seo

ケースバイケースではあるのですが、まだ自分の中で明確な答が出ていない問題です。

ウェブサイトを作る時に、そのサイト内のページや情報を検索するための「サイト内検索」、これを用意するべきかどうか、用意するとしたらどうやって用意するか、という問題です。
2014050301
↑こういうやつね


普通は「え?そりゃ無いよりあった方がいいでしょ?」と思いますよね。ではサイト内検索機能を用意する前提でもう少し細かく考えてみます。


サイト内検索を自前で用意する場合、開発コスト/運用コストによって選択肢はいくつかあります。まず手っ取り早いのは「DB内を全文検索する」ような検索実装です。端的に言えば SQL で select * from XXX where title like '%キーワード%' or category like '%キーワード%' or body like '%キーワード%' みたいなのを実行する、というやり方です。これだとウェブ/DBサーバーの負荷はその分上がりますが、サーバー構成の変化をあまり意識する必要がなく、懐にやさしい実装と言えます。

ただし、このやり方はいわゆる「ゆらぎ」や「同義語」に対応した検索ができないので、指定したキーワードにピッタリマッチした場合だけヒットします(近いキーワードではヒットしません)。そのため利用者視点では期待するような検索結果にならず、必ずしもユーザビリティはよくありません。また RDB の SQL を使うこの方法は複雑な条件での検索に対応できる一方で、検索速度については(KVS 型などと比較して)遅くなってしまいます。速度低下を避けるためにディスク高速化やメモリキャッシュを使うなどハードウェアで対処することもできますが、これはサーバーコストにまともに跳ね返ってしまうので、経済的というメリットが薄くなってしまいます。またクラウドサーバーでの運用を考えている場合、そもそもクラウドベンダーがハードウェア高速化を提供しているかどうかも事前に調べておく必要があります。そこまでして実現しても、利用者が検索にグーグル並の使い勝手を期待しているような場合、ちょっと残念な検索機能という印象を持たれてしまうかもしれません。


検索専用に別サーバーを用意してもいい、という費用感であれば、検索サーバーを立ち上げて検索機能に関しては検索サーバーに一任する、という方法も考えられます。このケースでは検索サーバーをオープンソース製品などを使って自前で用意してもいいし、商用の検索サービスを提供している業者と契約する方法も考えられます。検索サーバーの細かな機能や得意・不得意機能は千差万別ですが、対象レコード数や検索クエリー頻度、検索速度で検索サーバーの規模を概算して、それに見合ったサーバーを用意することになります。検索専用サーバーであればほとんどの場合で「ゆらぎ」や「同義語」にも対応できますが、その辞書メンテナンスを含めた管理を自分達で行うのか、そこも業者に任せるのか、どこまで任せるのか、そしてそれはいくらかかるのか、というコスト感と合わせて判断することになります。

この方法の問題点として、検索サービス専用業者との契約はその他のサーバー運用費と比較して結構高コストになる、という印象を持っています。また検索エンジンは途中から「やっぱりいらない」とは(アプリ設計から見直すことになるため)しにくいのです。したがって、一度導入すると定常的に(安くない)運用コストがかかる要素と言えます。


そして、個人的にはここが一番気になるのですが、「そもそもサイト利用者はサイト内検索をどれだけ必要としているのか?」という問題があります。上記のようにユーザビリティの高いサイト内検索を(コストもかけた上で)用意したとして、ユーザーのサイト内検索にはどれだけの需要があるのでしょうか?

これは提供するサービスの内容にもよるとは思います。例えば有名人のブログやニュースサイトなど読み物コンテンツ中心だったり、利用者が特定の何かの情報を探しに来ているのであれば、利用者はトップページから参照して、過去の情報も含めてサイト内を検索する、という行動も珍しくないと思っています。そのようなケースに該当する場合、サイト内検索は必要と考えるべきでしょう。 

でも現実問題として、多くのケースで利用者はトップページから情報を探すわけではなく、グーグルなどの検索エンジンから見つけたコンテンツに直接(トップページを経由せずに)訪問してきます。そうして訪問してきた利用者を同じサイト内の他コンテンツにも誘導したい気持ちは分かるのですが、そこでどれだけの利用者がサイト内を検索するのでしょうか? 例えば人気コンテンツや関連コンテンツ、リコメンドといったリンクを用意しておいて、そこから誘導させる手段は(自分の行動を顧みても)ある程度の効果があると思うのですが、グーグル検索結果からふと訪れたサイトで、わざわざ再度サイト内検索をしてまで別の情報を探すか?と言われると、ほとんどしていないように思うのです。


ここで改めて冒頭の疑問にたち戻ります。サイト内検索機能は比較的高いコストを要して用意することになるのですが、本当にサイト内検索はコストに見合うだけ使われるのでしょうか?それともコストをかけて用意するだけの必要性はないと考えるべきでしょうか? これが自分の中で答の出ていない問題なのでした。

そしてもう1つ。ユーザーはサイト内を検索することはなくても、グーグルなどのウェブ検索をすることは一般的と言えます。であれば SEM/SEO 対策を効果的に行ってユーザーの検索結果に自分達のコンテンツをある程度うまく表示させることができていれば、グーグルをサイト検索代わりにすることができるようになります。検索時に「検索キーワードに続けてサービス名も入れてもらう」とかであれば比較的すぐに検索結果を上位に持ってくることもできると思うし、グーグル検索であればかなり複雑なゆらぎにも対応した検索を提供してくれるし、その実装については悩む必要もありません。

極端な言い方かもしれませんが、検索エンジンにコストをかけるのであれば、その分を SEO 対策やマーケティングに費やしてもいいのでは? と考えてしまうのでした。


ただ例外もあります。キーワード以外で、例えば位置情報や画像やらユーザー名やらで検索するような場合はグーグル検索に任せられないので、こういうのは自前で用意しないといけないですよね。


というわけでまとめると、サイト内検索機能というのは、、
- 実装・運用にコストがかかる割には
- あまり使われない可能性があって、
- しかも SEM/SEO 対策次第でグーグル検索の方が高い精度でサイト内検索の代わりになるかもしれない

といった傾向が考えられるのです。 
そんな中でもコストをかけて柔軟なサイト内検索を実装/実現すべきなのか? という問題を考えていたのでした。簡易的な全文検索にするか、それ以上を求めるならグーグルの SEO 対策を強化する、でもいいのかな、と。

あらためて色んなサイトを見直してみると、サイト内検索を実装していない所も珍しくないですよね。このブログにもありません。最近は「意外となくてもいいんじゃないかなあ」と思うようになってきたのでした。

#っていうか、検索の SaaS って高すぎて個人サービスレベルじゃ手が出せない・・・ (x_x )
 

まずはこの2つのスクリーンショットを見比べてください:

(スクリーンショット1)
2014031401

(スクリーンショット2)
2014031402


どちらもアマゾンのウェブページを同じ Chrome ブラウザで見ている時に取得したものです。全般的に似たような内容ですが、パッと見で「同じではない」ことはわかりますよね。

でもどちらも全く同じページ(同じURL)を指しています。どちらのページもアマゾンのトップページから "ThinkPad" を検索した時の結果ページです。PC 用とモバイル用、というわけでもなさそうですよね。 ではこの違いはなんでしょう?



・・・答は User-Agent の違いでした。(1)は普通の Windows 向け Chrome 標準の User-Agent でアマゾン内を検索したものですが、(2)は Google のクローリングボットの User-Agent(Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)) に偽装してから検索したものです。
2014031403

ここからわかることはおそらくアマゾンはGoogle のクローリングボットが来た時用の、なんらかの手を加えて結果を返すようにしている、ということです。そしてそれはおそらく SEO 対策であろう、と推測されます。

普通に人間がウェブページを見る時に見やすい〈求める)情報と、SEO 対策を重視した画面が同じとは限りません。SEO 的に有利なページを作りたい一方で、ユーザーにはパーソナライズやレコメンドを表示するなど使い勝手を損ないたくもない。そのためにはこのような表示出し分けの対策をしている、ということだと思います。

ちなみに (1) の HTML は約80Kバイト、(2) は約110Kバイトでした。SEO 対策済み(?)のサイトの方が3割程度情報量が多いと考えるべきなのか、人間向けのサイトの方が情報をまとめていると考えるべきなのか。


詳しい内容を調べたわけではないのですが、とりあえずこの2つのページの大きな違いとして、(1) は Shift_JIS 、(2) は UTF-8 で記述されていました。まあ根本的に違うエンジンが使われていると考えるべきでしょうね・・・



このページのトップヘ