URL（パーマリンク）の検討（構成要素編）

URLにどんな要素を含めるかを考えます。

WordPressのURL（パーマリンク）構成要素に使える変数

WordPressではパーマリンクの設定に使える変数として，次の構造タグを規定しています。

  1. 投稿日時に関するもの
    • %year% ，%monthnum%，%day%，%hour% ， %minute% ， %second%
  2. 投稿の固有ID
    • %post_id%
  3. 投稿名（slugで上書き可能）
    • %postname%　
  4. カテゴリ
    • %category%
  5. 投稿者
    • %author%

推奨されるURL構造はどんなものか

W3C掲載文書「Cool URIs don’t change」の例

かなり昔の文書ではありますが，W3Cに掲載された文書「Cool URIs don’t change」（日本語訳「クールなURIは変わらない」では，「作成日以外は、どんな情報を名前に加えても、なんらかのトラブルの原因になります」として作成日による記述を推奨しています。でも，その直後に挙げられた改善例は

http://www.w3.org/1998/12/01/chairs

あれ？最後になにかついてますよね。

そもそもこの文書のURLが

https://www.w3.org/Provider/Style/URI.html

作成日要素はまったく入っていません。しかも拡張子付き。

当時は理想を実現できなかったのかもしれないと思ってW3Cの2017年8月現在のサイトを見に行ったのですが，作成日のみのシンプルなURL構造は採用されていないようです（拡張子もブログには付いていないけどメーリングリストのアーカイブには付いているなど混在）。

Google Search Console 「シンプルな URL 構造を維持する」の例

Googleの提供するサービスの1つ，Search Consoleのヘルプ「シンプルな URL 構造を維持する」では，「 URL 構造はできる限りシンプルにします。論理的かつ人間が理解できる方法で（可能な場合は ID ではなく意味のある単語を使用して）URL を構成」することを推奨しています。また，単語をつなぐときにアンダースコア（_）ではなくハイフン（-）によることが勧められています。

WordPress Codex

WordPressのデフォルトのURL構造は

サイトのURL/?p=投稿ID

となっています。記事を呼び出すクエリに忠実な表現なのかもしれませんが，WordPress Codex では「Ugly」と呼ばれてしまっています（uglyの日本語訳は「醜い，不細工な」）。投稿IDをURL構造に使うにしても別の構造にしたほうがよさそうです。

また，デフォルトに代わる選択肢として次の4つがあらかじめ用意されています。

* サイトのURL/年/月/日/投稿名/ 
* サイトのURL/年/月/投稿名/
* サイトのURL/archives/投稿ID
* サイトのURL/投稿名/

これら以外を使おうとする場合は，カスタム構造を選択して，自分で設定することになります。

各要素の特徴の検討

投稿者

最初に外せるのは「投稿者」。個人で運営するサイトの場合，管理人は1人または少数ということがほとんどでしょう。このサイトでも1人で管理・執筆を行っています。したがって，URLに投稿者を含めるのは過剰な情報です。

複数人で執筆を行っていて執筆者ごとに記事を分類したい場合は個別記事ではなく，投稿者のアーカイブページを使うとよいと思います。

カテゴリ

カテゴリは記事の分類を表しているので「サイトのURL/カテゴリ名/投稿名/」のようなURLがよいといった記事も見かけます。

記事内容が推測しやすく，たしかに優れた面もあるとは思いますが，カテゴリを変更するとURLが変わってしまいます。

また，複数のカテゴリが付いた投稿の場合は一番小さいカテゴリIDのカテゴリ名が使われますので，意図しないURLになるおそれもあります。

永続性という観点からはちょっと弱いかなという印象です。

投稿の固有ID

デフォルトで用意されているURLはUglyなどと呼ばれてしまっていますが，自動で付与されて通常は勝手に変えられない（変更を可能にするプラグインもあるようですが），といった点で，なかなか強靭な要素かもしれません。

以前は引越しの際に変わってしまうといわれていて，それがネックでしたが，解消されたという情報もあります（自分では検証していません。）。

保存や画像のアップロードの度にふられてしまうため，URLを連番でつけたいといった用途には向きません。

投稿IDがわかると管理に役立つという意見もあります。

投稿日時

投稿された日付や時間を利用したURLは「クールなURIは変わらない」でも推奨されていましたし，レンタルブログサービスなどで目にすることもあるURL構造です。

原則として変わらないはずなので,永続性に優れています。また，いつごろに書かれた内容なのかURLから判断できるのは便利かもしれません。

一方で，投稿の内容が推測できないといった弱点もあります。

また，好みの問題だと思いますが「年/月/日/時…」のようにスラッシュで区切っていくとディレクトリが深くなりすぎるように思います。間にどのようにスラッシュを入れるかの検討も必要でしょう。

WordPressでは「%year%%monthnum%%day%」というURLは日付別アーカイブになってしまうので，個別投稿へのリンクは，日時だけを要素にするときは少なくとも 「%year%%monthnum%%day%%hour%」 にする必要があります（WordPress Codex 日本語版）。%day%の後ろに%postname%などの日時以外の要素をつけるときも%day%までで大丈夫です。

なお，公開日を変更するとURLも変わってしまうので注意が必要です（あまりやらないと思いますが。）。

投稿名

投稿のタイトルをURLに使うと，URLから投稿の内容を推測することが容易になります。これはGoogle Serch Consoleで推奨されている方法に近いでしょう。
ただし，タイトルは本文ほどではないものの比較的修正の対象になりやすいものでもあります。タイトルをそのまま使う方法は永続性の面ではあまり強いとはいえません。

WordPressではslugを設定すると%postname%の値を上書きすることができます。%slug%という構造タグが別にあったほうがいいような気もするのですが，現状では%postname%が投稿名とslugの両方に対応しています（slugが優先）。

投稿の内容がわかるようなslugを設定し，それを変えないようにすれば，永続性について解決することができます。

なお，他の投稿とslugが重複した場合は自動で「-2」のような枝番が振られます。

採用した構造

以上のような分析をふまえて，このサイトではURLの構成要素を次のようにすることに決定しました。

年月日-slug

構造タグで書くと

%year%%monthnum%%day%-%postname%

例
20170818-url-structure

W3CとGoogleの2文書いいとこどりのような感じでもありますが，日付を入れたのはW3Cの文書を意識したというよりは，WordPress等の動的にページを生成するCMSの使用をやめて静的ファイルでサイトを構築することにしたとき，ディレクトリ内のファイルが公開日順に並んでいると見やすいと考えました。1日に複数の記事を公開した場合はその中で前後することもありますが，そのくらいは許容することにしました。

きちんと公開順を保つために投稿IDを含めることも考えたのですが，投稿IDは投稿数が増えると桁数が増えてしまうので，ファイル名の先頭から何文字目からがslugに対応という形式を保てなくなるためにあきらめました。

ディレクトリの階層を増やしたくなかったので，途中でスラッシュを入れず，1つの階層で収まるようにしています。

年月日とslugの間はハイフンでつなぎます。また，slugが複数の単語から成るときも単語間をハイフンでつなぎます。どちらかをアンダースコアにしようかとも思ったのですが，リンクに下線がつくような表示だとアンダースコアは見えなくなってしまうので，つなぎ文字はハイフンに統一しました。

次の記事ではURLに拡張子を付けるかどうか，付けない場合はスラッシュをつけるかどうかを検討します。

参考