検索エンジンから流れてくるユーザがどのような情報を元に自分のサイトに来ているのかを知ることは重要だ。googleとyahooの検索演算子をつかって、自分のサイトが自分のサイトについてどのような情報を持っているのか知ることが出来る。
このような情報は定点観測するべき情報だと思うのではてなアンテナに登録しておくべきだろうな。はてなアンテナの登録は検索を提供しているGoogleやYahooの仕様変更にそってアドレスを変更しなければいけないという点で面倒。Googleアラートへの登録はキーワードしか設定できないために検索結果ページの詳細な設定が出来ない。どちらも一長一短なので、両方に登録しておくのが吉。
googleのsiteとlink、yahooのsiteとdomainlinkとlinkを使ってこのサイトについて検索してみた。まずはAdvanced Google Search Operatorsのページを元にgoogleで検索
次にYahoo!検索 ヘルプ - コマンド（link:, site: など）の使い方を元にyahooで検索してみた。
またもはてなアンテナ。はてなアンテナではアンテナを立てるURLを指定できるので、このURLにgoogle検索のURLを入れてみる。例えば、このページについてやってみた。キャッシュされているかのチェックはうまく行くような気がする。しかし内容チェックに関してはうまくいかないかもしれない。ドメインの部分とq=の後ろが固有のものなのかそれとも変わりうるものなのかが良くわかっていないからだ。これらがタイミングなどによって変化してしまうとうまくいかないと思う。
ドメイン部分についていえばどうやらwww.google.comで置き換え出来そうなので置き換えてみた。
うちのサイトのデータとしてgoogleがキャッシュしている情報は72.14.235.132にあるということはわかっているのだけれど、検索するタイミングによってはこのアドレスが異なる。この違いがどこから生まれたのか僕はさっぱりわからないのだけれど、もし72.14.235.132が変わってしまう可能性について考えると、せっかくはてなアンテナに登録したURLを変更しなければいけなくなってしまう。物は試しと、http://google.com/searchに行ってみると、同じものが見える。とりあえずはてなアンテナのURLを全部換えて数ヶ月たったが、403 Forbiddonがたまに出てくることを除けば成功しているといえそうだ。ほんとに可換なのか調べてみた。72.14.235.132の逆引きで出てきたfqdnを正引きして複数のIPアドレスが出てきたなら、fqdnを登録しておいたほうがよさそうだ。
まずは逆引きするときのネームサーバをチェックしておく。どうやら、72.14.235.132のネームサーバはns1.google.comでよさそうだ。
$ dig -x 72.14.235.132 ns ; <<>> DiG 9.3.4-P1.1 <<>> -x 72.14.235.132 ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16696 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;132.235.14.72.in-addr.arpa. IN NS ;; AUTHORITY SECTION: 235.14.72.in-addr.arpa. 4443 IN SOA ns1.google.com. dns-admin.google.com. 2008110401 21600 3600 1209600 10800 ;; Query time: 8 msec ;; SERVER: XXX.XXX.XXX.XXX#XX(XXX.XXX.XXX.XXX) ;; WHEN: Wed Feb 4 21:22:07 2009 ;; MSG SIZE rcvd: 104
得られたネームサーバを使って72.14.235.132の逆引き。これでtw-in-f132.google.comが72.14.235.132に対応していることがわかる。
$ dig @ns1.google.com -x 72.14.235.132 ; <<>> DiG 9.3.4-P1.1 <<>> @ns1.google.com -x 72.14.235.132 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9278 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;132.235.14.72.in-addr.arpa. IN PTR ;; ANSWER SECTION: 132.235.14.72.in-addr.arpa. 86400 IN PTR tw-in-f132.google.com. ;; AUTHORITY SECTION: 235.14.72.in-addr.arpa. 86400 IN NS ns2.google.com. 235.14.72.in-addr.arpa. 86400 IN NS ns1.google.com. 235.14.72.in-addr.arpa. 86400 IN NS ns3.google.com. 235.14.72.in-addr.arpa. 86400 IN NS ns4.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 345600 IN A 216.239.32.10 ns2.google.com. 345600 IN A 216.239.34.10 ns3.google.com. 345600 IN A 216.239.36.10 ns4.google.com. 345600 IN A 216.239.38.10 ;; Query time: 39 msec ;; SERVER: 216.239.32.10#53(216.239.32.10) ;; WHEN: Wed Feb 4 21:25:54 2009 ;; MSG SIZE rcvd: 215
次にfqdnの正引き。対応アドレスは72.14.235.132だけ。これで72.14.235.132とtw-in-f132.google.comは一対一にに対応していることがわかる。
$ dig @ns1.google.com tw-in-f132.google.com ; <<>> DiG 9.3.4-P1.1 <<>> @ns1.google.com tw-in-f132.google.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39522 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;tw-in-f132.google.com. IN A ;; ANSWER SECTION: tw-in-f132.google.com. 86400 IN A 72.14.235.132 ;; AUTHORITY SECTION: google.com. 345600 IN NS ns3.google.com. google.com. 345600 IN NS ns1.google.com. google.com. 345600 IN NS ns2.google.com. google.com. 345600 IN NS ns4.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 345600 IN A 216.239.32.10 ns2.google.com. 345600 IN A 216.239.34.10 ns3.google.com. 345600 IN A 216.239.36.10 ns4.google.com. 345600 IN A 216.239.38.10 ;; Query time: 41 msec ;; SERVER: 216.239.32.10#53(216.239.32.10) ;; WHEN: Wed Feb 4 21:26:51 2009 ;; MSG SIZE rcvd: 191
ということで、http://72.14.235.132/searchとhttp://tw-in-f132.google.com/searchは同じページを返す。でも、dns的に同じものをさしていない以上、72.14.235.132とgoogle.comは可換でないはずだ。
dns問い合わせのトラフィック考えれば72.14.235.132のほうが「軽い」ということになる。googleはすごいね。ここまで軽さを求めるとは。
一つ上で、自分のサイトがそれぞれの検索エンジンでどのようにインデックスされているかわかった。このとき気づいたことは、かなり昔に作ったと思われるページまでインデックス化されていたことだ。そのようなページは、4つに分類できた。それぞれについてユーザに対して恒久的に有効な情報を提供するための自分なりの(弱小サイトでページ数も少ない場合の)取扱指針を考えてみる。
基本的に何もすることは無いと思う。このようなページは、ユーザがどのような形でブックマークしていても、どのような形でリンクが張られていても、鮮度の高い情報を提供することが出来る。ただし、リンク元につけられたリンクの説明とリンク先の内容が変化している可能性もある。そのようなことが無いようにする現実的な解法は、内容にぶれが生じないようにページ編集を心がけることだと思う。
基本的に何もすることは無いと思う。情報の鮮度が低いが、検索エンジンからのユーザはヒットした内容を必要としている。一つの問題点は情報の鮮度が低い点だ、同じアドレスで情報の鮮度を高めることが重要なように思う。その際に情報を付け足すことはあっても削除するようなことがあってはいけないと思う。
取扱要注意なページである。このような場合、直リンクをクリックした検索エンジンからのユーザ、ブックマークしたユーザ、どこかのリンク元からのユーザ、はリンク先の文書が見つからないという旨の文書を目にすることになる。このようなユーザはアドレスが変わった先を参照すること無しに別のサイトに流れてしまうかもしれない。そもそもの問題は、アドレスを変えてしまったことと其の事実をユーザが知らないこと、である。httpヘッダで301や302を返したりsitemap protocolを用いて検索エンジンやユーザにアドレス変更の事実を伝えることは出来ても、伝えられた内容をどのように取り扱うかは検索エンジンやユーザに任されているわけで、ユーザや検索エンジンの挙動までサイト管理者の思いのままには出来ない。
そこで、baseタグとシンボリックリンクを用いてモデラートに検索エンジンやユーザの挙動を制御する指針を考えた。もちろん気が付くユーザや検索エンジンもいるだろう。しかし、リンク切れではないし、そこからもし自サイト内の別ページに遷移してそこがブックマーク登録されてもインデックス化されても構わない。
具体的に言えば、下のようにして行う。
$ cat after.html <html><head>... <base href="http://zatugakuou.hp.infoseek.co.jp/" /> ....</head> <body>... <a href="hoge/hoga.html">baseのhref属性値+aのhref属性値の指すアドレス(http://zatugakuou.hp.infoseek.co.jp/hoge/hoga.html)に飛ぶ</a> ...</body></html> $ ln -s after.html before.html
例えば、このページなら、以前はhttp://zatugakuou.hp.infoseek.co.jp/SoftwareRaid.htmlで書いていた内容がhttp://zatugakuou.hp.infoseek.co.jp/VineRaid.htmlにアドレス変更になり、そこで更新が続いている。このようなページを列記すると下のようになる。
| アドレス変更前 | アドレス変更後 |
|---|---|
| BricolageCgi.html | PerlBricolageCgi.html |
| MakePdfFromLaTeX.html | VinePdfLatex.html |
| Physics.html | MemoPhysics.html |
| SingleParagraphDiary.html | MemoSingleParagraphDiary.html |
| ToDo.html | MemoToDo.html |
この情報を元にシンボリックリンクを張る操作は下のようになる。
$ ln -s PerlBricolageCgi.html BricolageCgi.html $ ln -s VinePdfLatex.html MakePdfFromLaTeX.html $ ln -s MemoPhysics.html Physics.html $ ln -s MemoSingleParagraphDiary.html SingleParagraphDiary.html $ ln -s MemoToDo.html ToDo.html
インデックス化されていることには価値があるので、これを期にコンテンツを復活させる。もしくはユーザを裏切ることになるかもしれないが、サイトのホームかサイトマップにシンボリックリンクを貼るのも一つかもしれない。
