最新記事とキャッシュ

http://hxxk.jp/2005/04/08/0300

記事データ

投稿者

望月真琴

投稿日時

2005-04-08T03:00+09:00

タグ
概要

常に最新の記事が配置される ( 言い換えれば内容が常に変更される ) ページにおいてはキャッシュは便利です。しかし、私は常に最新の記事の本文が配置されるページを作っていないのに検索結果として残されているため、できればそのリダイレクトページだけはキャッシュを拒否したいのですが……。

リプライ

3 件のリプライがあります。

記事本文

キャッシュ自身の話とはまた違うけど

意図的に削除したページではないサイトでも偶にキャッシュは便利です。 (検索に引っかかりやすくと言うと語弊があるでしょうが、そういうテンプレートを使用している)ブログでは、トップページから漏れたエントリーを閲覧しようとするとコツの要る場合があります。 検索で引っかかったはずなのに目的のアーカイブが容易に見られない。 そういうときにキャッシュで見ると便利です。

Google キャッシュと Yahoo キャッシュの相違点では Google と Yahoo の違いについてを中心に述べていましたが、涼さん ( 徒波 | 波間の浮遊物 ) の仰ることも私の言いたいことに通じているので、今回はそれを取り上げてみようと思います。

これはキャッシュがどうとかという話よりも weblog の構成についての話ですが、以前に index に最新記事を配置することのデメリットにて

検索エンジンのキャッシュ機能を使えばその記事を目にすることはできますが、逆にその機能を使わなければ、既に index から消え去った記事を求めてサイト内を探し廻らなければなりません。 もちろん個別記事ないし時系列アーカイブ・カテゴリ別アーカイブは存在していますし、それが検索にひっかかることもあるでしょうが、 ( 記事追加ごとに内容が変化する ) index もひっかかってしまうというのが現状です。

と述べたように、ある意味検索エンジンのキャッシュに頼らざるを得ない状況を皆で作り上げてしまっているという見方もできます。 本来なら 「目的のサイトのサーバがダウンしている等の理由で見られない時でも、ページの閲覧を可能にする」 という目的のはずのキャッシュが、 「検索語句を含む、もしかしたら別のアーカイブに移動してしまっているかもしれないエントリを確実に表示する」ためのものにシフトしてしまっているのです。

もちろん、これは weblog が流行する以前から存在していた問題なのですが、構成が画一化されている weblog サービスが流行したためにより顕著に感じられるようになったことは否定できません。

キャッシュを拒否できないケース

私自身は、検索エンジンのキャッシュの意義やそれの運営、また一般利用者の利用形態に対してはあまり賛成できませんが、 hxxk.jp 自体のキャッシュを作成されること自体は特に拒否などはしていません。 共用のレンタルサーバを使わせていただいているため、稀にダウンすることもあり、キャッシュを取られていることがメリットになるからです。 ミラーリングになろうとどんと来い。 ですが、ただ 1 点だけ拒否したいケースがあります。

hxxk.jp は前項で述べた理由などから、 index となる部分には記事の内容そのものを書くことは行っていません。 よって、常に最新の記事の内容を表示する URI もありません。 ただし、 http://hxxk.jp/latest のような、最新の記事へリダイレクトする URI は準備しています。

あくまでその URI にリクエストがあった場合に、 .htaccess でリダイレクトするためだけに準備したものですので、実際には latest.html や latest.php はファイルとしては存在しません。 存在させていなければ、常にその ( リダイレクト先の ) 内容が更新されようと、リダイレクト後の実態のある URI で検索結果にインデックスしてくれるだろうと考えていたためです。

しかし、実際はリダイレクト前の URI でインデックスされることもあります。 Google 検索: latest site:hxxk.jp を見ると、 .../latest という URI が検索結果に現れています。 そして、その結果に当たってしまい、 .../latest に実際にアクセスした人は、検索で得ようとした情報が .../latest からは参照できないことを知り、改めてキャッシュの方にアクセスするという行動を起こすということをアクセスログから読み取りました。 閲覧者が目的の記事に辿り着きやすくなるように考えていたつもりですが、リダイレクト前の URI を拾われてはその考えも効果は表れません。

Redirect ディレクティブの status 引数を指定しなければ、 リダイレクトは "temporary" (HTTP ステータス 302) になります。 これはクライアントに リソースが一時的に移動したということを示します ので、 status 引数に permanent を指定しないと、私の望む結果は得られません。 べるさん、コメントでのご指摘ありがとうございました。

そして、前述の通り実際のファイルとしては存在していないため、 meta 要素を使ってクロールやインデックス作成を拒否することはできません。 そのページ以外はキャッシュを拒否したくないと考えているので、 robots.txt による拒否という手段は取れません。 どなたか良い方法を知りませんでしょうか…… ?

Google のイメージ検索からの画像を削除するを見ると分かりますが、 Disallow: の後ろにクロールを拒否したいリソースのパスを示せば良いようです。 私は Disallow: / として、全体を拒否することしかできないと思い込んでいました。 DeepGreen さん ( 深緑色 -DeepGreen Color- ) 、コメントでのご指摘ありがとうございました。

リプライ

3 件のリプライが送られています。

2005-04-08T04:39+09:00 - DeepGreen

> そのページ以外はキャッシュを拒否したくないと考えているので、 robots.txt による拒否という手段は取れません。 使えば良いのでは? 例えば"hxxk.jp 全体の最新記事"を拒否したいのならば、 User-agent: * Disallow: /latest とすれば良いだけの事ではないでしょうか。

2005-04-08T07:34+09:00 - べる

Latest Entry Redirect Template の記事を見ての推測ですが、 Redirect /mt_2x/latest.html <a href="http://hxxk.jp/mt_2x/2004/09/03/2346">http://hxxk.jp/mt_2x/2004/09/03/2346</a> という記述なら HTTP ステータスは 302 Moved Temporarily なので latest という URI で検索ロボットが拾うのは正常のはずです。 リダイレクト後の URI を拾ってもらうには 301 Moved Permanently を返す必要があるので Redirect permanent /mt_2x/latest.html <a href="http://hxxk.jp/mt_2x/2004/09/03/2346">http://hxxk.jp/mt_2x/2004/09/03/2346</a> とすれば思い通りの結果になってくれるはずです。

2005-04-12T00:18+09:00 - 真琴

> DeepGreen さん <a href="http://www.google.co.jp/remove.html#images">http://www.google.co.jp/remove.html#images</a> を参考にすれば robots.txt で特定のリソースだけを拒否することができるって分かりますね……。どうも注意力が低下していたようです、ありがとうございます。 >べるさん ステータスの違いはあまり気に留めていませんでした。 302 だと拾う方が正常な挙動というのは納得できます。 ……が、ここでちょっと別の疑問が出てきました。後日別記事にまとめようと思います。

この記事に対するご意見やご質問、ご感想などありましたらこのフォームに簡潔に記入して下さい。 簡潔に記入できない場合や、関連記事にてご意見をお寄せいただく場合は、ご自身の weblog にて記事を書かれた上で あてにトラックバックとして送信してください。

記入フォーム

補足情報

著作、講演、制作実績など