このサイトは先日、サイト内のURL設計を見直し、サイト内のほぼすべてのURLを変更しました。こうしたことは本来すべきでないことですが、そこに至った経緯や、作業にあたって感じた疑問、役に立ったツールなどについて記していきます。

URL構造の変更に至った経緯

ここ2〜3ヶ月にわたって、サイトにいろいろと手をかけてきました。古くなったコンテンツを更新したり、新しいコンテンツを追加したり、デザインの細部を見直したり。そうした作業を実施している間ずっと、このサイトのURL構造が不満でなりませんでした。

しかし僕はその不満に目をつむってきました。URLは基本的に、そうやたらと変更するべきものではないからです。長くやっているサイトならいくらかの不満なんてあって当然です。それよりもむしろ、URL構造を変更することのデメリットのほうが無視できないと考えてきました。

ところが最近、URLの設計に関する新しい記事を準備しているうちに、いよいよ我慢がならなくなり、ついに全面的にサイト内のURL構造を刷新してしまいました。自分のサイトのURL構造のひどさに頭に来て、記事を書くどころではなくなったからです。

不満だったこと

従来のURL構造について何よりも気に入らなかったのは、各記事のURLがカテゴリ分類に縛られていて、分類に柔軟性を持たせることができなかったことです。従来のURL構造は次のようなものでした。

/category_name/subcategory_name/article_name.html

このURL構造だけを第三者が見たら、この作者はハイパーリンクやURLで構成されるWebというものがよくわかっておらず、MS-DOS などのファイルシステムから脳が進化していないのではないか、という疑念を発生させそうです。

というよりも、率直に言えば僕自身が恥ずかしさを感じていたのです。10年前にあまり熟考することなく決めただけあって、このURLの構成はいかにも古くさく、まるで FAT16 ファイルシステムのようです。

とはいえこれはよく見かけるヒエラルキー構造で、短期的には論理的かつ整然としたものでもあります。多くの(レガシーな)サイトで採用されているのもそうした理由からでしょう。しかしこの構造は、やはり長期的にみれば問題だらけです。

具体的な問題点

どんな問題があるかといえば、それはおよそ次のようなものです。

  • 長い間に文脈が変わってきた記事について分類を見直そうとしても、分類の見直しがURLの変更に直結するため気軽に分類を見直すことができない
  • ファイル名がカテゴリ名やサブカテゴリ名の後にくるため、どうしても各記事のURLが長くなってしまう
  • 記事のURLの最後に「.html」とついているが、.html なんてファイルをあと何年使うか疑問。将来確実に変更または拡張子の偽装をすることになる
  • 10年前からの惰性で単語の区切りにアンダースコアを使い続けてきたが、区切り文字にはハイフンを使用するほうが望ましい
  • こうしたことのそれぞれに起因する格好悪さがそこはかとなく漂ってしまう

最初のもの以外はまあ、気にしないようにするか、または場当たり的に対処すればどうとでもなりますが、やはり最初のものが気になります。

このサイトの基本的な運営スタイルは、記事をどんどん追加していくのではなく、過去の記事をアップデートしていくというものです。このため、時間の経過と共に古い記事の文脈が変わってしまうことは避けられません。

例えば、もともとはブログ記事として公開したものを後からメインコンテンツに移す、などのように、記事のカテゴリを移動しようとすると、従来のURL構造ではURLの変更が避けられないというようなことが起きてしまいます。

または、古くなりすぎて修正のしようがなくなった記事を /old/ とか /past/ とか /archive/ みたいな項目に移動しようとしても、それをすれば記事のURLが変更になるために、簡単には実施できません。これはURL設計上のミスです。

実施したこと

ここまで述べてきた問題についての解決策として、次のようなURL構造を新しく採用しました。リンク構造は従来と同じヒエラルキー型を採用していますが、ファイルの構成はフラットなものになっています。

記事のURL
/document-name
カテゴリページのURL
/category-name/subcategory-name/

変更した点は主に次のようなものです。

  • 記事はすべてルート直下に置くようにした
  • 記事のURLから拡張子を取った
  • カテゴリページでは目次だけを提供するようにし、カテゴリと記事のURLの依存関係を排除した
  • 単語の区切りをハイフンにした
  • 上記の結果として全体的に短く意味のあるURLになった

これで、例えばある記事が属するカテゴリを別の場所に移したとしても、それはカテゴリのインデックス(目次)を書き換えるだけで済みます。また、新しい記事を追加する際に「どこに追加しようか」などということで悩む必要はなくなりました。

また、今の記事ファイルはほとんどが普通の静的なHTMLですが、拡張子を取り去ったことで、将来どんなものにでも変更できます。これで、将来利用できるシステムを柔軟に選ぶことができるようになりました。

URLの設計と永続性について

今回の作業を通じて、やはりサイトの設計をするときは最初の段階で、10年後・20年後でもURLに変更を加えることなくそのまま使えるように、記事と目次の関係やファイル名などをよく考えておくことが必要だと、強く感じました。

上の2つのページはそれぞれ、前者が1998年、後者は2003年に書かれたものです。前者については有名な日本語訳(クールなURIは変わらない – Style Guide for Online Hypertext)もあります。

こうしたものは知ってはいたものの、僕はそれほど重要視していませんでした。10年も20年もサイトを運営するようなことを想像できていなかったからです。ところがいつのまにか、僕のこのサイトは運営期間が10年を超えました。

今では上で紹介した記事にあるようなことを実に強く実感できるようになり、過去、ろくに考えもせずにURL構造を設計した(設計と言えるほどの大層なことはしなかった)ことをとても悔やんでいます。

URLを変更すること

一度公開されたURLは、世界中の誰もがそれを参照(リンク)することができます。これは、URLを公開することは、リンクしてくれた人やそのリンクをたどってくる人たちに対して、URLの永続性についての一定の責任を負うということです。

たとえサーバ側でリダイレクトが可能だとしても、そうそう安易にURLを変えるべきではありません。URLとは本来そういうものです。

また一度公開したURLは、たとえそのページで扱っていたトピックが古くなったり商品が廃番になったとしても、不用意に削除すべきでもありません。古い情報を探している人もいるでしょうし、新しいものを必要としている人には新しい情報への動線を提供すればいいだけです。

そのようにURLに永続性を持たせた運用をするためには、そもそもですが、サイトを公開する時点で、将来にわたって変更することなく運用できるURLを設計しておくことが必要です。このサイトはそれができていませんでした。

ソーシャルメディアがもたらす現在の問題

実際のところ、ブラウザのブックマークや、検索エンジンを含む外部のサイトからのリンクについては、リダイレクト処理を行うことで新しいURLに誘導することができます。この意味ではURLの変更はそう重大なことではないかもしれません。

しかしこのことが、URLの構造について深く検討することを邪魔し、適切な構造に作り替えることなく、不適切な構造のまま長く運営する結果を招いたのだと今では考えています。

以前なら、リダイレクトの設定さえすれば、URLを変更しても何の問題もありませんでした。しかし現在は違います。それぞれのURLは、ソーシャルメディア上での共有の履歴という資産を積み上げてきているからです。

URLの変更や削除についての現在の最大の問題は、変更前のURLについていた数多くの共有の痕跡をすべて見えなくしてしまうことです。これはサイト運営者にとって残念であるだけでなく、共有した人々にとっても残念なことです。

リンク先としての信頼性

例えば僕は一人のユーザーとして、新聞社系ニュースサイトの記事のように数日から数ヶ月後には消えてしまうことがあらかじめわかっているURLをオンラインで共有することについて、それをするたびに微妙な気分を味わいます。

うまく伝えるのが難しいのですが、永続性が担保されないURLを共有するというのは、それが大手新聞社が運営しているサイトですら、何かしら据わりの悪い気分になります。Facebook などの流れ去っていくタイプのメディアに共有する場合であってもそれは変わりません。

つまり極端に言えば、URLの変更や削除を行うサイト、URLの永続性が担保されないサイトというのは、リンク先としての信頼性に欠ける、という気がするのです。

最近では Google のパンダアップデートの関係から、サイト内の低品質なページを別ドメインに分けるとか、思い切って削除してしまうとか、なんだか気軽にURLの変更や削除をする風潮があるようです。

しかし僕は先述のような理由から、この種のことには賛成しかねるというのが個人的な意見です。URLとは Uniform Resource Locator の略であり、一度公開したURLはリソースの場所を統一的に指し示し続ける必要があるというのがWebにおける暗黙のルールです。

一方、10年前になんとなく決めたURL構造はいずれ破綻し、いつか変更するときがきてしまうことは避けられません。これは残念がってばかりいても仕方のないことです。そして、僕のサイトのURL構造は破綻していました。

いずれ変更するときがくるのならば、できるだけ早くやってしまったほうが、同じURLを保ち続ける期間が長くなります。そう考えて僕は、URLの変更に踏み切りました。これは僕にとってはかなり大きな決断でした。

ウェブサイトとしての適切さ

このサイトは中心的なテーマにSEOを扱っていますから、利用者のお手本になるような「SEO的に」適切な運営が望まれているのではないかと思います。その意味では、サイト内のほとんどすべてのURLを変更するなどという暴挙は、望ましいものではないでしょう。

それこそ「SEO的に」は、URLをリダイレクトするとリンクポピュラリティが15%ほど失われるというのが定説です。リンクポピュラリティの損失は、SEOを重視していればしているほど、あってはならないことです。この作業により、ランキングの低下も起きるでしょう。

そしてもちろん、たくさんの人々に共有してもらった履歴が隠れてしまうというのも、非常に残念なことの一つです。また先述したように、URLを変更するサイトというのはリンク先としての信頼性を低下させます。これも「SEO的に」は不適切でしょう。

しかし、こうした各種の問題が存在する一方で、僕は一人のサイト運営者として、より適切な形にサイトを整えたいという気持ちがあり、どちらかというとSEOよりもその気持ちを大切にしたいという考えに傾くことを止められませんでした。

リダイレクト設定で役に立った「paste コマンド」

今回のURLの変更は規則性のないものだったため、リダイレクトの設定は正規表現が使えず、それぞれのURLごとに手動で設定する必要がありました。このとき役に立ったのが、Mac OS X(または多くの Unix系OS)の「paste コマンド」でした。

paste コマンドはMacの場合ターミナルからCUIで操作するもので、ちょっとばかり取っつきにくい印象ですが、2つのテキストファイルを行ごとに結合できるというシンプルながら素晴らしい機能を持っています。

これをどう使ったかというと、変更前のURL一覧を出力したテキストファイルと、変更後のURL一覧を出力したテキストファイルを用意し、それを行ごとにマージすることで、リダイレクトのための .htaccess 記述の大半を自動化しました。

ちなみに新旧それぞれのURLの一覧は、それぞれの XML Sitemaps のXMLを整形して作成しました。これはテキストエディタ(JEdit X)の正規表現による検索置換で一瞬で終わりました。

内部リンクのチェックで役に立った「integrity」

.htaccessを使ったURLのリダイレクト設定は上述の形でわりとすんなり片付きましたが、サイト内のそれぞれの記事内のリンクは基本的に手動(検索置換も一部使いながら)で修正する必要がありました。

リンクが機能する、ということだけを重視するのであれば、各記事からの内部リンクもリダイレクトするので、個別の修正まではしなくても動作に支障はありません。

しかしサイト内でページを遷移するたびにリダイレクトがかかるというのでは、パフォーマンスの点で不満が残ります。僕のサーバ環境では、ページ遷移ごとに0.04秒くらい遅くなるからです。

そこで内部リンクを手動で変更していったのですが、このとき役に立ったのが「integrity」というリンク切れ検出ツールです。この種のソフトは多々ありますが、この integrity は実にすごいです。

  • 動作がおそろしく速い。仕組みはわからないものの、1分足らずでサイト内のすべてのリンクを解析し終えてしまう
  • ステータスコード404や200だけでなく、301も標準でレポートされる
  • 404や301が返った項目をダブルクリックすると、いつものブラウザに問題のあったページが開き、問題のあるリンクの場所をブラウザ画面上に表示してくれる

僕が特に便利だと思った機能は上記のようなもので、ほかは同種のソフトと同じようなものですが、とにかく上記3点の素晴らしさには驚きました。今後同じような作業が必要になったら(ないほうがいいですが)またこのソフトを使うと思います。

作業を終えて思ったこと

今回僕は、10年前に自分でやったURL設計のまずさによって、あまり面白くもない余計な作業と、いくらかのリンクポピュラリティの損失、そしてソーシャルメディアで共有された履歴の喪失、という犠牲を払いました。

別の見方をすれば、まあ今後は気持ちよくサイトの運営ができるということで、気分的にスッキリしたような部分もあるのですが、やはり URLの変更というのはいろいろ気持ちの上で整理のつかないものがあります。

そこで疑問なんですが、最近のWeb制作の現場(制作会社でも内製でも)では、URLの設計に際して、その永続性を担保するための明確な指針とか規則とかみたいなものがあるんでしょうか?

実はこの作業を始める前に、わりと詳しくURLの設計について調べたのですが、どうやらほとんどの会社は10年前の僕と同じように、永続性なんて考慮しておらず、運用における分類上の柔軟性なども無視したURL設計をいまも続けているようでした。

一方、ブログベース(特に WordPress)で作られている個人のサイトは、永続性も分類の柔軟性も十分に確保されており、素晴らしいものが多い印象でした。

これはつまり、制作会社が作るものは所詮よそ様のサイトであり、個人サイトは自分のものですから、いろいろと意識の違いが出てくるのかなあ、などと思いました。実際はどうなんでしょうね。