Neo Inspiration

本物っぽいですねぇこれ。無論誰も確証なんてだせませんが。
以下ちょー長文です。

ためしにこのＵＲＬをひっぱたくと

https://www.google.com/evaluation/search/rating/home

Forbidden
The user ******@gmail.com is not a member of EWOQ. Please ask your EWOQ contact for access.

とでるので、本物っぽい（このURLを知ってる時点で）ですねぇ。
まあぜんぜん確信できる証拠じゃないですが。
（やめた人がネタで書いてる可能性もあるしね～）

まあ本物だったらおもしろいなーってことで、部分的に意訳してみます。

とりあえず内容としては
Ｗｅｂサイト評価の方法と
そのツールであるEWOQの使い方
あとスパム判定系のお話ってところですね。

全部で43ページもあって長いので
面白そうなスパム系のとこだけ

————ここから————

Ｐ３２からのスパムサイトについて

Webサイトの評価はクエリーと共にするものです。
しかしスパムサイト評価はクエリーに依存しません。
怪しい技術を使ったスパムサイトはどんなクエリーに対してもスパムサイトです。
#ページ　match　検索クエリー　という考え

スパマーが報酬を得る方法

・PPC
・アフィリエイト

しかし、これらのサイトは付加価値がある場合はスパムサイトとはなりません。
（ようはオリジナルコンテンツとか役に立つコンテンツがあることかな）

スパムサイトじゃない例はこんなかんじ。

・価格比較サイト
・商品のレビュー
・レシピ
・歌詞や引用文
・連絡先のあるページ（特に住所とかが書いてあるページなど）
・クーポンやディスカウント系の情報

以下スパムサイトの例

PPC

・PPCのみのページ
・フェイクディレクトリ型検索エンジン（検索結果が全部PPCみたいな）
・フェイクブログ（PPCをクリックさせるためだけにあるブログみたいな）
・フェイク掲示板（書き込みがPPC広告みたいな）
・コピーコンテンツ＋PPC
#ようはコピー記事を全部とっぱらったら広告しかないサイトはダメですよ

見分け方

・文章をそのまま検索窓につっこんで検索
・Site:で検索して文章テンプレートとかを見てみる

確保してあるドメインの利用

確保したドメインを利用してこんなコンテンツを載せている

・スポンサードリンクのリスト
・どこにでもありそうなカテゴリリスト
・関連カテゴリのリスト

こんなサイトがいい例です
www.dasonet.com/todahfezkdk.htm
#これよくみますよね

またこれらのドメインを売買する
#ドメインの売買もＮＧっぽい雰囲気
#スパムドメインじゃない場合はどうするんだろ

見分け方

・インターネットアーカイブを見てみる
#まじだｗ

アフィリエイト

・PPCとほぼ同じ
アフィリエイトだけのサイトとか。
オリジナルコンテンツが重要
PPCと同じくアフィリエイト＋オリジナルな解説とかはOK

見分け方

・住所、電話番号があるかどうか
・フォーラムがあるかどうか
・ログイン機能があるかどうか
・アフィリエイトを展開（やるんじゃなくて広告主のほう）してる
・ショッピングカートのリンクが同じドメイン

隠しテキスト、隠しリンク

ユーザには見えない（見えにくい）がロボットには見えるたぐいのものすべて
#もちろん例外はあるみたい

見分け方

・CTRL+Aを押して全部みてみる
・ブラウザのJSをオフにして見てみる
・ブラウザのCSSをはずして見てみる

JSでリダイレクト

ユーザとロボットで表示を切り替えるようなやつのことかな

見分け方

・googleキャッシュと今みてるページとの差分をチェックする

キーワードスタッフィング

とにかくキーワード詰め込むやつかな

見分け方

・目で見れる場合はそのまま
・JSを使って隠してる場合はJSを切ってみよう

URLにキーワードスタッフィング
#サブドメインを切り出してページでも生成してるんだとおもう
⇒does not make sense だってｗ

100%フレームページ

・ページフルにフレーム使ってる場合

見分け方

・右クリしてフレームのURLをみて今のURLと違うことを確認

せこいリダイレクト

ようは一旦検索エンジン用のページを開いてその直後にリダイレクトして
他のドメインにあったりするページを見せるってことかな

見分け方

・ドメインが違う場合、whoisとか使ってドメイン所有者を見てみる
#これってURLが変わりましたってやつで5秒後にリダイレクトとかのあれが
#別のレンサバ（ドメインをレンサバ名義にしてるやつ）
#にしちゃうとNGってことですね

————ここまで————

雑感ですが、意外とGoogleですらできないことって多いんですね。
例えば アクセスしたURLと今表示してるURLの違いとか
FireBugがやってるようなこととか（レンダリングエンジンをそのまま積み込むわけにはいかないのか）
でもここまでやるから検索性能を維持できているんだろうなぁ。

まあ実装はしていても、人間の作ったものをプログラムで見分けるわけだから
100%じゃなくって、その100%じゃない部分の補完として使ってる可能性もありますが。

とりあえず spammy site という表現が気に入ったｗ

最後

信じるも信じないもあなた次第！（ぱくり

またまたSEOのお話

最近SEO BookMark なるものがあって
登録してみたんですが、見てるだけで色々新しい発見あって面白いです。
（SEOのナレッジのために自分はSEO Vertical Blog Searchを作ったんですが、
明らかにこっちのがクオリティも量も新規性も維持できますね～　カシコイ！もうこれやめよっかな。）

それはそうとまた面白い記事を見つけたのでちょっとエントリー

検索エンジンの５つのプログラム - スパイダーとクローラって別物？ in SEOブログ from SEO塾

よくよく考えてみると当たり前なんですが、
確かに言及するにいたってないですね。気づくことって重要ですね。
こういう時海外の情報をすばやく取得できる人がすごいです。
＊ちなみにSEO Vertical Blog Searchでもスパイダーとクローラは別になっています。
⇒が独立モジュールではありません。

ということで、どうしてこうなるかというお話。

スパイダーとクローラが別である理由

（スパイダーとかクローラとか名前はどうでもいいんですが、ようは
URLリストを作るプログラムと
キャッシュするプログラムってことです。）

開発者っぽい視点で検索エンジンを考えてみるとこうなります。

●ほしいもの
検索エンジンを作るためのDB作成

ブレイクダウン：WEB全体のページデータがほしい（できるだけ新鮮なのがいい）
　　　　　　　：ページを取得するためにURLリストがほしい（新鮮なページのために新鮮なURLがいい）
　　　　　　　：ページ全体を分析したい
　　　　　　　：分析したやつを超早く出力したい

⇒という要望なので、こんなかんじにしましょう
１：WEBのURLリストが最速でほしい（スパイダー）
２：URLリストを順に見て行ってデータをひとまず保存したい（クローラ＊キャッシュ）
３：WEBページを色々分析したい（インデクサ）
４：分析結果をすばやく検索結果として出力したい（アウトプット）

#なぜＵＲＬリストが最速で欲しいかというと、
#そのＵＲＬリストがそのままデータの鮮度に直結するからです。
#このリスト作成サイクルが早くなればなるほど、情報の鮮度がよくなります。

じゃあどうするかってことで、

スパイダーとクローラが同じ場合

プログラム１：URLリストDBを元にURLにアクセスして「以前と変更があったらキャッシュDBに格納」し、
　　　　　　　そのキャッシュにあるURLを抽出して、「既存にあるURLと重複がなければURLリストDBに格納」する
プログラム２：キャッシュDBのデータを色々分析
プログラム３：検索結果を出力

->この場合単純に１プログラムの負荷が高すぎるというのもありますが、
　ＵＲＬリストの作成とキャッシュを作成してＵＲＬリストを作成するのが同時なので、
　一回のプログラムの実行時間が長くなってしまい、ＵＲＬリストの鮮度が保てません。
　＊しかもこの場合、キャッシュしたページのURLを優先するのか、リストを優先するのかとか、
　　いろいろクローラー＜＞スパイダー間の関係が複雑になります。
　さらにプログラムのチューンアップとかも考えると、別モジュールにしたほうがよいです。

＊よくあるアルゴリズムを更新しました　とかのときに、
　　URLリストから生成しなくてはならないのも問題ですね。

スパイダーとクローラをわける場合

プログラム１：キャッシュDBを順番に見ていって「既存にあるURLと重複がなければURLリストDBに格納」する
プログラム２：URLリストDBからURLにアクセスして「以前と変更があったらキャッシュDBに格納」する
プログラム３：キャッシュDBのデータを色々分析
プログラム４：検索結果を出力

->プログラムが増えますが、URLリストを作りつつ別軸でキャッシュもできるので、
　優先的にキャッシュしたいURLなんかを設定したとしても、URLリストの作成に影響がでません。
　URLリストの優先順位とかキャッシュするしないの閾値とか、そういうチューンアップも
　別々に行えます。

おまけでインデクサとスパイダーをくっつける場合

プログラム１：URLリストDBからURLにアクセスして「以前と変更があったらキャッシュDBに格納」する
プログラム２：キャッシュDBのデータを色々分析する中で必要なURLを見つけてばURLリストDBに格納する」
プログラム３：検索結果を出力

->これもありっておもってます。
　メリットとしては必要なURLだけアクセスすることで、
　サーバの負荷を減らせること。
　デメリットはURLのリストが小さくなってしまうこと。
　あとチューンアップとか速度とかの問題。
　ちなみに SEO Vertical Blog Search はこの形態です。

＊補足1：プログラムとして他人のURLにアクセスすること　が一番負荷が高く
自分のDBにアクセスしてURLをチェックすることと比べるとコストは何倍にもなります。
（俺の感覚ですがｗ）

＊補足2：

３：WEBページを色々分析したい（インデクサ）

というのは極端な話、クロール最中にしてしまってもいいわけです。
＝URLにアクセスしてURLリストを作りつつインデックスしてもいいわけです。
（つまり　インデクサ＋クローラー＋スパイダーの１プログラム）
が　これは一番効率が悪いので分割してると思われるわけです。

そういう意味で、キャッシュ　というのは中間生成物なんですよね。（アーカイブとは違うわけです）
それを単にユーザにとって便利かもしれないということで、
YahooもGoogleも開示してるっていう。

プログラムが５こ？

当該のエントリーの引用元では５個のプログラムとなっていますが、
まあそれはないのかなーと思うので書きます。

上記の通りDBだけでも、
スパイダーが作ったURLリストDB
クロールしてキャッシュしたキャッシュDB
インデックスした後のインデックスDB
は必要なので、
DBもプログラムというなら５個以上になりますね。

ちなみにインデックスも仕方があって（これは長くなるので別エントリーにします）
ページ主体でインデックスする場合とワード主体でインデックスする場合で
DBの格納の仕方がかわるので、さらに増える可能性もありますね。
というかアメリカの人はDBをアプリというのか。。

おまけ

改めて気づいて考えてみると
なかなかおくが深いというかなんと言うか。

実際にGoogleが100%こうなっているとは思えませんが、
近いイメージなんではないでしょうか。

そうそう当たり前ですが、規模が小さい場合クローラとスパイダーを一緒にしてる場合が結構あります。
そういうのは結構出回っているので、自分で使ってみるのもいいかもしれませんね。
しかし、めちゃくちゃでかい（WEB全体とか）をやろうとおもったら、
分離しておくのが普通の発想なのかもしれません。
（というか普通のサーバじゃWEB全体をクロールとかむりだｗ）

ちなみに検索したらsouceforge にスパイダー＋クローラーのPHPクラスがおいてありました。

http://sourceforge.net/projects/phpcrawl/

挙動は確認してません。

ってういか・・・

エントリー長すぎだしまとめるのが不能になった・・・

最近SEOのエントリーばっかりですが。。
こちらのエントリーをみて気になったので。

http://e-club3.hyperposition.com/seoblog/terminology/20080308083139.html

まあ気になったのは

「肝心の検索エンジンの日本語キーワードの解析力はどうなのだろうか？」

というところです。

yahooでは形態素解析をつかって　日本語を分解して文脈で理解しているのは
APIを公開してるとこからみてほぼ間違いないんだけど、
Googleはそれはやっていません。（それっていうのは日本語を「解析」するということ）

一応ソース
Google の鵜飼文敏さんによる講演会の内容
http://nanto.asablo.jp/blog/2008/01/25/2578762

国ごとに検索をローカライズしていく＝その言語の研究をめちゃくちゃしなければいけない
というのは　スマートではないわけで、
Googleが考えそうなことというのは、言語に依存しないページからのナレッジの抽出技術
みたいなものだったりするのかなと。

言語に依存せずに文脈を理解するっていうのはすごいなー。
まあただそれは　Googleのスケーラブルで巨大なインフラがなければ無理な話だとおもいますが。
まあそういう意味で、Googleは検索ワードがすごい重要なんだなと思います。
（n-gramモデルを公開したことには実はすごい意味があるのかもしれませんね）

あと以下おまけで下記疑問に答えてみます

その分母であるべき総単語数から違っている。

以下簡単なHTMLでためしてみた結果です

a ALT読み込み　strip_tags してる

b ALTは読み込んで（というより日本語だけ抽出してるかんじ）　strip_tags してる
javascript も文字数としてカウントしている

c -

d -

e ALTよまない strip_tags してる

文字数のカウントには　カウントする対象を決める必要があって、
そのカウントする対象によって文字数がかわってしまうということですね。
bのjavascriptをカウントしてるのはさすがに問題だと思うけど。。。

「SEOウェブセミナー」は、「SEO + ウェブセミナー」となるケースが多く、「セミナー」を抽出できてないツールが多い。

通常、形態素解析には段階があって、
一番簡単にできるものでは　ウェブセミナー　を　ウェブと　セミナー　にわけることができません。
それは単純にスクリプトでばらしているからであって
これはまあ簡単にいえば　形態素ばらし　ってとこなんですよね。
なので、逆にいえば　最低限　ウェブセミナー　をばらせないと
形態素解析できるということにはならないんですが。

ちなみにYahooApiを使えば簡単にウェブセミナーをばらすことは可能です。