パーマリンクの使い方

出典: WordPress Codex 日本語版

目次


パーマリンクとは、ブログの個々の投稿記事、カテゴリーなどの記事一覧ページへの恒久的（半永久的）な URL です。パーマリンクは、他のブロガーがあなたの記事（やセクション）にリンクを張るときや、あなたの記事へのリンクを Eメールで送ったりするときに使います。個別の記事への URL は常に存在して決して変らないようにすべきです。そういう訳で、「perma」リンクといいます。

WordPress の基本的なパーマリンク形式 3種類：

デフォルト： "Ugly"

デフォルトでは、記事番号が N のときに 
http://example.com/?p=N
のようになります。全てのサーバ環境で動くように、新規インストール時のデフォルトはこうなっています。しかしながら、他のオプションが付くと見苦しくなるので好ましくありません。

mod_rewrite: "Pretty Permalinks"

mod_rewrite や lighttpd を使用すると、より良いパーマリンクにすることができます。フォーマットは様々ですが、最も一般的で万能なのは次のような形です。 

http://example.com/category/post-name/

あるいは 

http://example.com/year/month/day/post-name

短いパーマリンクにするために、日付の要素（日・月・年）の全部か一部を取り除く人もいます。

注意:mod_rewrite パーマリンクには Apache の mod_rewrite モジュールが必要です。これがないサーバ環境の WordPress では使えません。lighttpdについては、外部資料 を参照してください。

PATHINFO: "Almost Pretty"

PATHINFO パーマリンクは、途中に /index.php が挿入されるという差異の他は、mod_rewrite パーマリンクによく似ています。 

http://example.com/index.php/yyyy/mm/dd/post-name/

のようになります。それ以外は "pretty" mod_rewrite と変わりなく、柔軟さも同じです。mod_rewrite パーマリンクができることは、/index.php の部分のおかげで PATHINFO パーマリンクでも可能です。

使用しているパーマリンクの形式およびWordPressが使用している内部書き換え規則の詳細を表示する便利なプラグインがあります。

管理画面の設定→パーマリンク設定(WordPress2.5以前ではオプション→パーマリンク設定)で、 一般的な設定から1つを選択するか、構造タグを使用して、カスタム構造に記述することができます。

PATHINFO パーマリンクを有効にするには、パーマリンク構造がindex.php/で始まるようにします。

構成タグ

"Pretty" と "Almost Pretty" パーマリンクのカスタマイズには、次のタグが使えます。以下のヒントも参考にしてください。

  • パーマリンクが%post_id%あるいは%postname%(例えば、/%year%/%monthnum%/%day%/%postname%/等)で終わるようにして、個々のパーマリンクが個別記事を示すようにください。
  • パフォーマンスの観点から、パーマリンク構造がカテゴリ名、タグ名、著者名、投稿タイトルフィールドから始まるのは好ましくないです。これらはテキストフィールドなので、パーマリンク構造の先頭に用いると、WordPress が投稿とページ(ページは常にページスラッグを URL に含みます)を区別するのに時間がかかり、代償として、WordPress が余計な情報をデータベースを蓄えることになります(多くのページがあるサイトは大変でしょう)。したがって、パーマリンク構造は、投稿年あるいは投稿 ID のような数字フィールドから始まるようにするのがベストでしょう。
%year% 
投稿年・4桁 （例）2004
%monthnum% 
投稿月 （例）05
%day% 
投稿日 （例）28
%hour% 
投稿時刻の「時」 （例）15
%minute% 
分 （例）43
%second% 
秒 （例）33
%postname% 
サニタイズされた投稿タイトル(投稿スラッグ)。タイトル「This Is A Great Post!」だったら URI は「this-is-a-great-post」になります。 %postname% のみの使用参照。
%post_id% 
投稿の一意な ID 番号（例）423
%category% 
サニタイズされたカテゴリー名(カテゴリースラッグ)。入れ子であるサブカテゴリは、URI でも入れ子のディレクトリとして表されます。
%tag% 
サニタイズされたタグ名(タグスラッグ)。
%author% 
サニタイズされた著者名

カテゴリーベース

カテゴリーベースは、カテゴリーパーマリンクの前に置かれます。 

 category_base/category_name

カテゴリーベースのデフォルト値は、categoryです。

これらのパーマリンクはほとんどのシステムで問題なく動作しますが、問題が生じる環境もあります。

%postname% のみの使用

example.com/post-titleのように、パーマリンク構造に%postname%だけを使用する場合、書き換え規則により、(これと似た URI 形式の)スタイルシートや/wp-admin/ディレクトリへアクセスできなくなる可能性があります(WordPress 2.0以降でそうなるのでしょうか？)。この問題を防ぐため、パーマリンクに(例えば記事IDや日付のような)数値データを含めると良いでしょう。また、WordPress v1.2.x では、カレンダー等いくつかの機能が正常に機能するために、日付構造を用いることが必要です。/%year%/%monthnum%/%day%/%postname%/は、どんなときでも、良い形式です。

複数カテゴリにした投稿記事の %category% と %tag%

一つの投稿に複数カテゴリを指定していても、パーマリンクには一つしか表示できません。一番小さいカテゴリ ID（カテゴリ管理 参照）が使われます。アクセスはどのカテゴリからでも普通にできます。

パーマリンク構造に %tag% を使用している場合も、同様です。

要件：

  • mod_rewrite モジュールがインストールされた Apache ウェブサーバー
  • WordPress のホームディレクトリで、
    • FollowSymLinks オプションが有効にななっている。
    • FileInfo directives が許可されている(例 AllowOverride FileInfo, AllowOverride All)。
    • .htaccess ファイルが存在する(存在しない場合は、"pretty" パーマリンクを有効にしたときに、WordPress は .htaccess ファイル作成を試みます)。
    • .htaccess ファイルを自動的に更新するには、WordPress が書き込み権限を持っている必要があります。
  • lighttpdについては、外部資料 を参照してください。

"pretty" パーマリンク構造を作成する(更新する)とき、WordPress は書き換え規則を生成し、適切な .htaccess ファイルに挿入します。挿入できなかった場合、「.htaccess を更新する必要があります」のようなメッセージが表示され、ファイルにコピーアンドペーストする(ファイルの最後に付け足す)書き換え規則が表示されます。

WordPress 2.0以降では、WordPressが内部で書き換え作業を行うので、この作業は一度行うだけで済みます。WordPress のホームディレクトリ(ブログのアドレス)を移動させるときは、この作業を再度行う必要があるでしょう。

WordPress は既存の .htaccess と共存できます。既存の書き換え規則や他の指示を削除しません。他に mod_rewrite 規則がある場合は、WordPress の規則よりも前に記述してください。

.htaccess ファイルはどこ？

Wordpressの index.php と .htaccess ファイルは一般設定のブログのアドレス (URI)設定で指示されたディレクトリに置く必要があります。ファイル名がドットで始まるため、FTPクライアントソフトウェアでは、隠しファイルを含む全ファイルを表示するように設定していないと、ファイルが見えないかもしれません。 一部のホスティングサービス(例：Godaddy)では、Godaddyホスティング接続インストールを利用して WordPress をインストールした場合、.htaccess が表示されず、編集することもできません。

.htaccessの作成と編集

.htaccess ファイルが存在しない場合は、新規作成してください。サーバーにシェルあるいは ssh アクセスできる場合は、touch .htaccess コマンドで作成することができます。FTP を用いてファイル転送する場合は、ローカルコンピュータ上で 1.htaccess のような名前でファイルを作成し、WordPress ディレクトリのルートにアップロードし、.htaccess にリネームしてください。

.htaccess ファイルは、FTP、シェル、あるいは(可能ならば)ホスティングサービスのen:Using_cPanelから編集することができます。

.htaccess ファイルに("Internal Server Error (500)")をもたらすエラーが含まれている場合は、FTP またはホスティングサービスのen:Using_cPanel を使用して欠陥のある .htaccess ファイルを削除する必要があります。

.htaccessの自動更新

WordPressが .htaccess ファイルを自動更新できないときは、オプション → パーマリンク画面の下部に「あなたの .htaccess が書き込み可能ならこの操作は自動的に行われますが、そうでない場合は…」というメッセージが表示されます。

WordPress に自動更新させたい場合は、ファイルパーミッションの変更 が必要になります。おつかいのサーバーの設定によって、適切なパーミッションが異なります。まずは所有者に書き込み権限を与えて試してください。駄目なら次はグループ、その次は全ユーザーに書き込み権限を与えて試してください。WordPress がファイル編集できるようになったら、書き込み権限をそれ以上付与しないでください。

パーマリンクを適用した後は、他者が .htaccess にアクセスするのを防ぐために、660 あるいは 644 のような制限の厳しいパーミッションに変更してください。

"Pretty" パーマリンクには、通常は mod_rewrite が必要です。(Windows サーバーでよく使われている) IIS は、mod_rewrite をサポートしていません。(Windows 上で Apache 2.0.54 を使用している場合は、apache\conf\httpd.conf で有効にすることにより、mod_rewrite が動作するかもしれません。)

IIS 7 を使用していて、サーバーの管理者権限をもっている場合は、マイクロソフト社の URL Rewrite Module で代替可能です。mod_rewrite と全く同じとはいきませんが、WordPress の pretty パーマリンクをサポートしています。インストールしたら WordPress フォルダの web.config ファイルを開き、次のルールを system.webServer に追加してください。 

<rewrite>
    <rules>
        <rule name="Main Rule" stopProcessing="true">
            <match url=".*" />
            <conditions logicalGrouping="MatchAll">
                <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
                <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
            </conditions>
            <action type="Rewrite" url="index.php" />
        </rule>
    </rules>
</rewrite>

IIS のウェブサイトに インストールガイド が掲載されています。このモジュールは、x64 および x86 システムで利用可能です。 この方法が使えない場合は、PATHINFO パーマリンクを試してみてはいかがでしょう。パーマリンク構造の最初に、index.php/ と記述してください。 

 /index.php/%year%/%monthnum%/%day%/%postname%/

この方法は、常に上手くいくとは限りません。特に IIS 6 上で WordPress を実行している場合はそうです。IIS 上でこの方法を用いるには、php.ini ファイルに次の2行を追加して、webroot に置いてください。([1]) 

 cgi.fix_pathinfo = 1
 cgi.force_redirect = 0

その他にも、IIS のカスタム 404 リダイレクトを使用する方法があります。この方法は、カスタム 404 リダイレクトを追加する権限が必要ですが、サードパーティ製の mod_rewrite をインストールする必要がありませんし、パーマリンク構造を /index.php/ で始める必要もありません。

サーバーの管理者権限を持っている場合は、以下のような方法も良いかもしれません。

.htaccess 生成時の問題

WordPress のインストール時に.htaccess ファイルが生成されない場合や、既存の .htaccess ファイルに新しい規則が追加されない場合は、いろいろな原因が考えられます。以下の手順を1つずつ実行してください。もし問題が解決しない場合は次のステップに進んでください。

  1. ファイルパーミッションの変更。 WordPress en:Editing_Files#Using_the_Built-in_Editor で .htaccess ファイルを編集するには、.htaccess のパーミッションを　666 に変更する必要があります。しかしこの方法はお薦めできません。あなたのブログのユーザーで、テンプレート編集権限を持つユーザーなら誰でも .htaccess を編集できてしまうからです。パーミッションをサーバーが書き込み可能な 660 に変更することもできますが、同様の制限があります。
  2. サーバーブロック。 ホスティングサービスによって SERVER_SOFTWARE 変数がブロックされているため、WordPress が .htaccess を生成できていない可能性があります。サーバー上で Apache が実行されていることが確かであれば、wp-includes/vars.php ファイルを変更することで、Apache が実行されていると WordPress に信じさせることができます。これらの変更を実装するには、以下の手順を行ってください。
    • WordPress 管理パネルのビルトイン・エディタを使用して wp-includes/vars.php を開く。WordPress にログインし、「管理」をクリックし、「ファイル」をクリックし、画面を下までスクロールし、「その他のファイル」テキストボックスで wp-includes/vars.php と入力してください。
      $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;
      という部分を探して、
      // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;
      に置き換えてください。
    • 次の部分の下に一行追加し、
      // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;
      次のように入力してください。
      $is_apache = 1;
  3. XAMPP (Windows)を利用する場合。XAMPP のバージョンによっては、デフォルトでは mod_rewrite が有効になっていません(コンパイルはされています)。mod_rewrite を有効にし、さらに WordPress が pretty パーマリンク作成するのに必要な規則を .htaccess に書き込みできるようにするために、apache/conf/httpd.conf を開き、LoadModule rewrite_module modules/mod_rewrite.so の行のコメントを外す(行頭の「#」を消す)必要があります。

パーマリンクと .htaccess と マイクロソフト・フロントページ

マイクロソフト・フロントページについてのメモ。いろいろなホスティング会社で構築され管理されている(共有および専用)サーバーの多くは、Apache ビルドと共にmod_frontpageがコンパイルされています。そして多くの場合、各々の仮想サーバー上に、フロントページエクステンションがインストールされています。最近では、ほとんどのホスティング会社がサーバービルドプロセスで使用する多く／ほとんどのバイナリーディストリビューションに、mod_frontpageとフロントページエクステンションの両方が含まれています。たとえあなたがフロントページを使用していないとしても、エクステンションが Apache と(そして httpd.conf とも)相互作用するため、WordPress インストール時に、(管理パネルは正しく動作しているが)500 エラーや、真っ白なページになってしまうのは、単にサーバー上に extensions/mod_frontpage が存在するからです。

WordPress は、フロントページエクステンションがインストールされていても利用できます。しかし、パーマリンクは機能せず、管理画面からパーマリンクに少しでも変更を加えると、.htaccess ファイルに mod_rewrite を追加したために、フロントページエクステンションと衝突します。しかし、この問題には解決法があります。

フロントページの応急処置： パーマリンクは気にせず、MS フロントページエクステンションが動作するようにしたい場合は、.htaccess ファイルを編集して、書き換え規則の WordPress の部分を削除します。

パーマリンクを使うには： (ホスティング会社がエクステンションをインストールしているが、)あなたがフロントページに興味が無い場合

あなた(あるいはホスティング会社)が、MS フロントページエクステンションを削除するか、.htaccess ファイルからフロントページに関する行を全て取り除き、WordPress の mod_rewrite だけを残す必要があります。

最終的な解決策。

この件について、サポートフォーラムにいくつかのスレッドがあり、今まで解決していませんでした。

通常、マイクロソフト・フロントページエクステンションがインストールされた Unix サーバーでは、WordPress は正常に動作し、(フロントページで)ページを編集し公開することができます。パーマリンクに変更を加えさえしなければ(例えば 2005/04/etc 等のように日付ベースにする等)。私はパーマリンクについて質問した人たちに、この種の URI 形式を勧めています。というのも、w3c が推奨している方法だからです(http://www.w3.org/Provider/Style/URIを参照)。

問題は、フロントページが .htaccess ファイルを使用して投稿およびウェブオーサリング設定を行うことです(WordPress の mode_rewrite 規則もこのファイルにアクセスする必要があります)。WordPress の mode_rewrite 規則が追加されると、以下の2つの事態が発生します。パーマリンクが動作しない、フロントページエクステンションが落ちる。

私はこの問題について何度となく試しました。フロントページが使用する %{HTTP_USERAGENT)% を無視すするように書き換え規則を用いる、httpd.conf ファイルで2つ目のアクセスファイル .wpaccess を使用する、等々です。フロントページの使用と、WordPress のパーマリンクの使用の両方を満たすものはありませんでした。

解決策は実は簡単なものでした。私は偶然発見しました。

フロントページを使用しているか使用したい場合(あるいはホスティングパッケージでそのように設定されている場合)、WordPress と共存するには、あなたは(あるいはホスティング会社は)以下の手順を実行する必要があります。

MS フロントページが次のディレクトリを作成する。 

_vti_bin
そのディレクトリの下に 
_vti_adm
と 
_vti_aut
とを作成する

サイト(あるいは WordPress)のルートディレクトリだけでなく、これら全てのディレクトリに、.htaccess ファイルを追加する。

これら3つのディレクトリとルートディレクトリの .htaccess ファイルの先頭に次の1行を追加する。 

Options +FollowSymlinks

既に次のように記述されていることがあります。 

Options None

各 .htaccess ファイルを編集して保存すれば完了です。フロントページ、あなたの選んだパーマリンク、全てが動作します。

メール、コメント投稿やチャット等で、長いパーマリンクを使うと、途中で切断されたり、最初のセクションだけがリンクと認識されて残りの部分がテキストと認識されたりします。例えば、

http:⁄⁄yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog

が下のようになります。

http:⁄⁄yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog

この例の下側のリンクをクリックすると、「404 ページが見つかりません」エラーが発生するでしょう。長いパーマリンク記事タイトルを使いたい場合は、この問題を避けるために以下の手順を実行してください。

  1. パーマリンクの使い方を使用していることを確認する。
  2. .htaccess ファイルを編集して、以下を追加する。
     RewriteRule ^post/([0-9]+)?/?([0-9]+)?/?$ /index.php?p=$1&page=$2 [QSA]
  3. 試してみる。記事の投稿 ID を調べて、ブラウザで以下のように記述する(ID の部分はあなたの環境にあわせる)と、リダイレクトされるはずです。
    http://yourdomain.example.com/post/(the ID #)

ほとんどのメール閲覧ソフトは、山括弧(< と >)で囲まれた URL を切断しません。メールに URL を貼り付ける場合は、以下のように書くと良いでしょう。

私のブログ記事<http:⁄⁄yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog>をごらんください。

さらに、メールクライアントによっては、テキスト形式メールを作成するときに「プリフォーマット」オプションが用意されています。リンクを貼り付けるときに「プリフォーマット」オプションを使用すると、リンクの間に改行を含まないようにすることができます。

その他の問題点

.htaccess ファイルが正しく生成されているにも関わらずパーマリンクが動作しない場合は、以下のような問題が発生しているかもしれません。問題が解決されない場合は、 WordPress Forum'sの "How To" (日本語フォーラムはWordPressフォーラムの「使い方全般」)に投稿してください。

AllowOverride が無効

あなたのサーバーでは、AllowOverride ディレクティブが有効になっていないかもしれません。Apache の httpd.config ファイルで AllowOverride ディレクティブが None に設定されている場合は、.htaccecc ファイルは全く無視されます。この場合、サーバーは .htaccecc ファイルを読むことすらしません。このディレクティブが All に設定されている場合は、全ての .htaccecc コンテキストが許可されます。httpd.config ファイルで AllowOverride ディレクティブが有効になっている例を示します。 

 <Directory />
    Options FollowSymLinks
    AllowOverride All
 </Directory>

ルートディレクトリでも、AllowOverride を有効にする必要があるかもしれません。 

 <Directory /var/www/html>
    # ... other directives...
    AllowOverride All
 </Directory>

サイトの AllowOverride 設定も変更する必要があるかもしれません。Mac OS X サーバーの場合は必ず行う必要がりますが、他のシステムでも同様にする必要があるかもしれません。サイト設定ファイルは、通常 /etc/httpd/sites/ ディレクトリ内にあります。

(上の例では all に設定していますが)AllowOverride を all に設定したくない場合は、AllowOverride のリストに、FileInfo ディレクトリを含める必要があります。httpd.config の設定を変更後、それらを有効にするには、Apache サーバーを再起動する必要があります。どのような上書きが許可されるかについては、Apacheコア機能を参照してください。

ページナビゲーションが動かない。

記事の2ページ目(以降)へのナビゲーションが、期待通りに動作しないことがあるかもしれません。記事へのリンクに、以下のいずれかの URI を生成しているかもしれません。 

 http://www.example.com/page/2/
 http://www.example.name/category/categoryname/page/2/
 http://www.example/year/month/day/page/2/
 http://www.example/year/month/page/2/

これらのリンクをクリックすると、ページが読み込まれ、周り(ヘッダー、フッター、サイドバー)が表示されます。しかし、記事は表示されず、「該当する投稿は見つかりませんでした」というエラーメッセージが表示されます。

これは、WordPress が生成する .htaccess の欠陥によるものです。これを修正するには、.htaccess を削除して、再度作成します。

  1. 管理パネルで、「管理」「ファイル」と進む。(en:Editing_Files)
  2. .htaccess ファイルへのリンクをクリックして、編集する。
  3. テキストエディタで、ファイルの内容をコピーして貼り付ける。これは、.htaccessファイルにリダイレクトやアクセス拒否等が手動で書き込まれている場合に備えておくためです。handy htaccess tricks
  4. .htaccess ファイルの全ての内容を削除し、「ファイル更新」ボタンをクリックする。
  5. 管理パネルで、「オプション」「パーマリンク」と進む。
  6. 「パーマリンク構造の更新」ボタンをクリックして、新たに書き換え規則を生成する。.
  7. 以前は動作しなかったリンクを用いて試してみる。
  8. あなたの .htaccess ファイルに記載されていたエントリを書き込む。 (# BEGIN WordPress の前か、# END WordPress の後に追加してください。)

.htaccess ファイルをサーバーから削除し、新たに .htaccess ファイルを作成し、パーミッションを 666 に変更し、「オプション」「パーマリンク」で「パーマリンク構造の更新」ボタンをクリックして新しい .htaccess 規則を生成することも可能です。

これでも上手くいかない場合は、WordPress サポートフォーラムのthis support post を参照してください。

「ページ」へのパーマリンクが効かない。

新しく作成したPageへ移動するときにエラーが発生する場合は、en:Permalinks_Options_SubPanel を行う必要があるでしょう。WordPress で新たに静的 Page を追加するたびに、新しく書き換え規則を作成し、.htaccess (WordPress 1.X)か、内部書き換え配列(WordPress 2.X)を更新する必要あります。

Ultimate Tag Warrior のタグページへのパーマリンクが効かない。

WordPress 2.X で UltimateTagWarrior プラグインを使用していてローカルタグ URL で 404 エラーが発生する場合は、WordPress の生成する内部書き換え規則がでしゃばり過ぎて UTW の書き換え規則よりも先に呼び出されるからです。この現象は通常、(/%postname%/ のような)カスタムパーマリンク構造を使用している時にのみ起こります。これを修正するには、en:Permalinks_Options_SubPanel を「日付と投稿名」にするか、UTW プラグインを改造して内部書き換え配列で UTW 書き換え規則を最初に配置するかします。詳細は、http://www.naturalsearchblog.com/archives/2007/01/20/getting-404-errors-on-ultimate-tag-warrior/ を参照してください。

パーマリンクは動作・ページが存在しないと返される。

PHP 4.4.x および 5.x のいくつかのバージョンには、Apache 2.X のあるバージョンで使用すると mod_rewrite が落ちるバグがあります。 詳細は http://bugs.php.net/bug.php?id=35096 および http://bugs.php.net/bug.php?id=35059 を参照してください。

その他のヘルプ

これらの手順で上手くいかない場合は、Codex日本語版、FAQ/トラブルシューティング、あるいはサポートフォーラムで検索してください。 最後の手段として、バグの報告を行ってください。

ヒントと小技

サイトを Google ニュースに掲載したい場合、条件の 1 つとして各 URL の末尾に 3 文字以上の識別子が必要です。

これは %postname%-%post_id% 構造を使用することで容易に実現できます。http://mysite.com/cooking-tips-tricks-344 のように、投稿 ID を URL の末尾に付加します。

投稿記事の末尾に .html を付けるには

投稿記事の末尾に .html 拡張子を付ける簡単な方法は、上で解説した構造タグを使用することです。適切な末尾を持つパーマリンクの例に従えば、次のルールで、http://yoursite.com/2006/01/01/happy-newyear.html のような表記が得られます。 

 /%year%/%monthnum%/%day%/%postname%.html

これによって、静的な .html ファイルが生成されるわけではありません。.html 拡張子を付け足すだけであり、動的生成されることには変わりありません。こうすることの SEO 効果については議論されていますが、WordPress から移行しなければならないときには、URL 構造を保持したまま静的ファイルにできるので便利でしょう。

WordPress 2.3 以前では、標準 URL が無かったので、.html を加えることは(URL を強制的に標準化することになり)非常に有益でした。現在では SEO 効果があるとしても限られたものでしょう(詳細は外部資料を参照してください)。

一日に一記事しか投稿しないので %year%%monthnum%%day% というパーマリンクを使用したいと思うかもしれませんが、このリンクは、その日の全投稿へのアーカイブとして生成されることに注意してください。個別記事へのリンクは、少なくとも %year%%monthnum%%day%%hour% にする必要があります。

参考

外部資料

最新英語版： WordPress Codex » Using Permalinks （最新版との差分）

"http://wpdocs.sourceforge.jp/%E3%83%91%E3%83%BC%E3%83%9E%E3%83%AA%E3%83%B3%E3%82%AF%E3%81%AE%E4%BD%BF%E3%81%84%E6%96%B9" より作成
他の言語