記事本文
もしかしたら多くの人にはどうでもいいかもしれない疑問、あるいは過去の自分のテンプレートの否定
最新記事とキャッシュで Redirect のことについて触れたときに思ったのですが、 Redirect を用いて
<$MTBlogURL$>latest
にリクエストがあった際に、リクエスト時点の最新記事の URI を返すというのはいかがなものかという疑問を抱きました。
もちろん、最新の記事へのアクセス手段を常に /latest という URI で提供することによって得られる利便性を否定するわけではありません。
しかし、
古い URL を新しいものへマップ
するという目的である Redirect ディレクティブを最新記事の URI に提供するってのはいいのだろうか……という後ろめたさを抱いたのです。
Latest Entry Redirect Template の記事を見ての推測ですが、 Redirect /mt_2x/latest.html http://hxxk.jp/mt_2x/2004/09/03/2346 という記述なら HTTP ステータスは 302 Moved Temporarily なので latest という URI で検索ロボットが拾うのは正常のはずです。
リダイレクト後の URI を拾ってもらうには 301 Moved Permanently を返す必要があるので Redirect permanent /mt_2x/latest.html http://hxxk.jp/mt_2x/2004/09/03/2346 とすれば思い通りの結果になってくれるはずです。
べるさんは 最新記事とキャッシュのコメントでこのようにアドバイスを下さいました。
そして permanent ステータスの説明を見ると、
永久にリダイレクトをするステータス (301) を返します。
これはリソースが永久に移動したということを意味します。
とあります。
これだと、確かに検索ロボットはリダイレクト後の URI を取得するでしょう。
しかし、リダイレクト後の URI がタイミングによって異なるというのは
「それって永久に移動した状態なの ? 」
と問われると自信がありません。
「いや
<$MTBlogURL$>latest
っていう URI からは永久に移動してるよ」
「でも昨日示された移動先と今日示された移動先が違うってのはどうよ ? 」
と突っ込まれると返答できないと思います。
解決策は分かっているけれど
まあ、 最新記事とキャッシュ - キャッシュを拒否できないケースで自分の勘違いに気付かされたので、何が何でも Redirect で対処する必要も無いのですが。
<$MTBlogURL$>latest
の内容に
<MTentries lastn="1">
を配置するようなインデックステンプレートを作れば良いのです。
これまではそういったテンプレートを作っておくと、 index に最新記事を配置することのデメリットで述べたような弊害が出てくると思い込んでいたのですが、
User-agent: *
Disallow: /latestと robots.txt に記述すればそれも防げます。
検索ロボットではなく、人間が手動で
<$MTBlogURL$>latest
にリンクを張ってしまう可能性もありますが、そこまで考えていたらキリがありません。
近々サイト自体の構成も含めてテンプレートを書き換えるつもりなので、それまでには自分の方針を固めておこうと思います。
Redirect seeother という解
またもべるさんのコメントに助けられました。
HTTPステータス・コードに 303 See Other というものがあり、
リクエストに対するレスポンスは異なるURIの下で発見でき、そのリソースをGETメソッドを使って検索することが望ましい
と定められています。
これを Redirect ディレクティブを用いて
Redirect seeother /latest http://hxxk.jp/2005/04/14/2230
のように指定すれば、「あなたがリクエストした /latest にあるはずの実体は http://hxxk.jp/2005/04/14/2230 にあるので、そちらを参照してください」といったナビゲートをされるイメージになり、またそれは Latest Entry Redirect Template によって常にリクエスト時における最新記事へのナビゲートを行うことができます。
