2022年05月09日に初出の投稿

Last modified: 2022-05-09

If you make your own website, consider making short URLs.

Short URLs: why and how

確かに、これは URL 短縮サービスの話ではない。URL 短縮サービスが致命的に危険であることは分かり切っており、SMS で届くにしろ、問い合わせフォームにクラウド・ワーカーがコピペした文面のメールを受信するにせよ、まともな情報セキュリティ・マネジメントを運用している会社で、未知の相手が示す短縮 URL をクリックすることを許可する CPO や CISO なんていない。逆に言えば、そういうことに無頓着で CPO や情報セキュリティ部長を名乗ってる奴は3流ということだ。上場企業なら、IR の開示書類に「わが社のリスク」としてそういう馬鹿がいることを記入していなければ、株主に対する背任を疑われるほどの無能と言ってよい。

きちんと記事の筆者が "This is not about a URL shortener. This is about making your original URLs short in the first place."(これは URL 短縮サービスの話ではなく、そもそもあなたのサイトの URL が短くなるように制作するという話なのだ)と書いているとおり、bit.ly などのフィッシング攻撃サポート・サービスについて勧めているわけではない。わざわざ注意書きを冒頭に掲載しているのだから、この筆者も短縮 URL サービスがロクでもないという理解は持っている筈だ。

しかし、だからといって最初からウェブサイトの URL を短くする必要はあるのだろうか。たとえば当サイトで言えば、既に "markupdancing.net" というホスト名そのものが長いと言えば長いので、取り合いになるのは当然だが「プレミアム・ドメイン」と呼ばれる更に短い(そして高額の)ドメインを取得するのが第一の手順になろう。md.net というドメインは、もちろん実際にアクセスすれば CTI Networks という会社がドメインを所有しており、僕が当サイトを md.net という短いドメインで運用しようとすれば、このプレミアム・ドメインを CTI Networks から購入しなくてはいけない。たぶん、個人として払うには途方もなく高額な費用となるはずだ。ムームードメインなどでプレミアム・ドメインを調べたら分かるように、3文字で、かつ .info のような gTLD のドメインでも数万円がかかる(ドメインの取得・更新費用ではなく、ドメインのリセラーが自由に値段を設定できる「移管」手続きの費用だから、他のドメインと異なるコストがかかる)。ということで、いくらでも短くできるわけがないのは当然だ。

そして、それ以外にも上記の記事には疑問の余地が多い。

まず、URL を短くすると「覚えられる」などと言うが、なんで覚える必要があるのか。たとえば、当サイトの記事は、「論説」として公開しているページだけで70ページほどある。これに、この「落書き」を加えたら、こうやって毎日のように増えていくため、今年の落書きだけでも370本を数えるから、過去の落書きも再び公開すれば1,000は超える。これを、そもそも覚えなくてはいけない理由など誰にあろうか。そして、覚えて何になるというのか。検索しなくても思い出せばいいなどと言っているが、それは自分が覚えていられるていどの少ない文章しか書いていないからだろう。

次に、短いと誰にでも伝えられる("You can tell someone.")というが、これもそんなことをする必要が分からない。どのみち教えられたページにアクセスする方法はブラウザなのだから、メールやチャットで長かろうと URL をペーストすれば、そこから簡単にアクセスできる。もし伝える手段が口頭しかないとしても、ドメインさえ分かれば、あとはリンクを張っておけばいい(知ってる人しかアクセスできなようなページを、誰でもアクセスできる状態で公開するのは、基本的にインデックスされることを妨げていないので、愚かという他にない)。

"They look nicer." というのも、ただの個人の好みにすぎない。メールや掲示板にペーストされた URL が長いとか短いとか(短縮 URL で短くなり過ぎた場合は気を付けなくてはいけないが)、そんなことは大抵の人にとってはどうでもよいことだ。ウェブのデザイナーによくある、見栄えの問題を過剰に考える性癖のようなものだろうが、実際には大半のユーザというのは、デザイナーが考えるほどデザインなんて気にしてもいない。それは、アダルトサイトや情報商材サイトが稚拙なビジュアルでも堂々と有効に(あまり褒められない)実績を上げている事実でも分かる。多くの場合、ビジュアルはコンテンツに負けるのだ。同じく、URL の長さなんてコンテンツやアクセスする動機とか目的とか経緯にとって、殆ど影響がない筈である。

"They remove the middle-man." は、確か分からなくもない。長すぎる URL は、場合によっては短縮 URL サービスを利用したくなる動機付けを与えるかもしれないからだ。しかし、そういう愚かな人々がいるからというだけで、オリジナルのソースを URI として短く設定したり、情報デザインとしてディレクトリ構造の複雑性を(コンテンツやファイルの整頓という事情を無視してまで)減らしてよいという理由にはならないだろう。問題は、長すぎる URL ではなく、短くしか書けない Twitter のようなサービスで URL をペーストせざるをえない状況を放置することにある。Twitter で URL を添付したいなら、恐らく Tumblr のように URL を添付する専用の枠を用意するのが妥当だろう。

そして、"They’re enough." という点についても、最初に述べた点と同じである。少ない大小英文字と数字だけで2文字のディレクトリかファイル名を作ると、それだけで300パターンを超えるというが、逆に "9a.html" とか "T4.html" なんてものを、どうやって特定のページのファイル名だと覚えたらいいのか。

最後に加えておくと、そもそも URL が長くなる元凶の一つは、ウェブサイトの URI つまりリソースまでのパスが長くなるだけではなく、要するにマーケティングが目的のクエリ文字列(ファイルの拡張子の後に付く "?fbid=9870987098789" といったロクでもない文字列のこと)が長すぎるせいでもあろう。多くのサイトで最も効果的に URL を短くしたいなら、いまどきクエリ文字列などを使う解析サービスを使わないことだ。クエリ文字列なんてものは、JavaScript や Cookie を拒否された最後の手段として、情報そのものをシリアル・データとして URL にぶら下げる、お行儀の悪い実装でしかない。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook