当サイト、Codex 日本語版は今後積極的な更新は行わない予定です。後継となる新ユーザーマニュアルは、https://ja.wordpress.org/support/ にあります。
万が一、当サイトで重大な問題を発見した際などは、フォーラムWordSlack #docs チャンネルでお知らせください。</p>

パーマリンクの使い方

提供: WordPress Codex 日本語版
2008年11月16日 (日) 14:37時点におけるMizuno (トーク | 投稿記録)による版 (その他のヘルプまで翻訳済)

移動先: 案内検索

このページ「パーマリンクの使い方」は途中から未翻訳です。和訳や日本語情報を加筆してくださる協力者を求めています

このページ「パーマリンクの使い方」は情報が古くなっている可能性があります。最新版英語)も合わせてご覧ください。翻訳にご協力くださる方はぜひご相談ください

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

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

デフォルト: "Ugly"

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

mod_rewrite: "Pretty Permalinks"

理想的なパーマリンクです。フォーマットは様々ですが、最も一般的で万能なのは次のような形です。

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

or

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%/等)で終わるようにして、個々のパーマリンクが個別記事を示すようにください。

%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 でも入れ子のディレクトリとして表されます。
%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%

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

要件:

  • 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 が動作するかもしれません。) 代わりに、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/ で始める必要もありません。

If you have administrator privileges on your server, you may be interested in these solutions:サーバーの管理者権限を持っている場合は、以下のような方法も良いかもしれません。

.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 と マイクロソフト・フロントページ

マイクロソフト・フロントページについてのメモ。いろいろなホスティング会社で構築され管理されている(共有および専用)サーバーの多くは、アパッチビルドと共にmod_frontpageがコンパイルされています。そして多くの場合、各々の仮想サーバー上に、フロントページエクステンションがインストールされています。最近では、ほとんどのホスティング会社がサーバービルドプロセスで使用する多く/ほとんどのバイナリーディストリビューションに、mod_frontpageとフロントページエクステンションの両方が含まれています。たとえあなたがフロントページを使用していないとしても、エクステンションがアパッチと(そして 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 を調べて、ブラウザで以下のように記述すると、リダイレクトされるはずです。

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 ディレクティブが有効になっていないかもしれません。アパッチの 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コア機能を参照してください。

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

記事の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日本語版トラブルシューティング、あるいはサポートフォーラムで検索してください。 最後の手段として、バグの報告を行ってください。

ヒントと小技

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

There's an easy way to having your posts end in a .html extension, using the structure tags above. Following the example used on properly terminating permalinks, you could have a page like http://yoursite.com/2006/01/01/happy-newyear.html with this rule:

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

Note that this does not generate actual .html files. It is only an illusion. There is no benefit to this... some people mistakenly think it offers search engine benefits, and some want their permalinks to emulate those of another publishing system.

外部資料

最新英語版: WordPress Codex » Using Permalinks最新版との差分