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

パーマリンクの使い方

提供: WordPress Codex 日本語版
2008年11月12日 (水) 14:59時点におけるMizuno (トーク | 投稿記録)による版 (.htaccess 生成時の問題 まで翻訳)

移動先: 案内検索

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

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

パーマリンクとは、ブログの個々の投稿記事、カテゴリーなどの記事一覧ページへの恒久的(半永久的)な 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 と マイクロソフト・フロントページ

A note about Microsoft Frontpage: many servers (shared and dedicated) maintained and built by various hosting companies come with mod_frontpage compiled with the apache build, and in many cases with the Frontpage Server Extensions installed, on each virtual server. This is more common than not, many/most binary distributions used in the server build process at most hosting companies these days include both mod_fronpage and the server extensions. Even if you're not using Frontpage, because of the way that the extensions interact with apache (and the httpd.conf file) you'll likely get something like a 500 error or blank white page when trying to view your WP install (although the admin panel may operate correctly) simply because extensions/mod_frontpage exist on your server.

Wordpress will operate correctly with the Frontpage Extensions installed, however permalinks will not function at all and ANY change to the permalinks section from the Wordpress admin interface will cause corruption of the Frontpage server extensions due to the addition of the mod_rewrite rules to the .htaccess file. There is however now a fix for this situation.

Frontpage Extensions Fix: If you don't care about permalinks and just want to make the MS Frontpage server extensions work again, simply edit your .htaccess file and remove the wordpress section with the rewrite rules.

To Use Permalinks: If you don't care about Frontpage(but your hosting company has the extensions installed)

You will need to remove (or have your hosting company do so) the MS Frontpage server extensions, or simply edit the .htaccess file to removed all of the Frontpage Lines, leaving only the wordpress mod_rewrite code.

Finally, A solution.

There have been a number of threads on this issue in the support forums, and until now, no solution to the problem.

Normally, on a Unix server with the Microsoft Frontpage Server extensions installed wordpress works just fine and you are able to edit and publish pages (with MS Frontpage) - UNTIL - you make a change to the permalinks (for example to the date based kind that I like /2005/04/etc). I often suggest that type of URI to folks asking about permalinks etc, as that is the method recommended by the w3c (see http://www.w3.org/Provider/Style/URI ).

Now, the problem is that MS Frontpage uses the .htaccess file (which the wordpress mod_rewrite rules must go into) for it's "publishing" and "web authoring" configuration. As soon as the wordpress mod_rewrite code is added to the file, two things happen — the permalinks don't work and the MS Frontpage Server extensions become corrupted.

I have tried countless ways to get around this, including trying to use rewrite rules that "ignore" the %{HTTP_USERAGENT)% used by Frontpage, to using a second AccessFilename .wpaccess to the httpd.conf file, and a host of other things, and nothing worked so that a person would be able to both use MS Frontpage to manage the website and use the permalinks for wordpress at the same time.

The solution is acctually quite simple, and I kind of figured it out by accident.

If you are using or wish to use MS Frontpage (or that's just how your hosting company has things configured) along with wordpress you'll need to take the following simple steps on your server (or have your hosting company do it for you).

MS Frontpage creates the following directory

_vti_bin
Nested within that it creates both
_vti_adm
and
_vti_aut

In addition to in your website (or wordpress) root folder in all of those directories you will find additional .htaccess files.

In all three of these directories AND in the root directory, at the top of ALL of the .htaccess files you simply need to add one line:

Options +FollowSymlinks

There may or may not already be a line in each like

Options None

Edit and save each .htaccess file and you're done. Now everyhting works perfectly, including MS Frontpage, AND the permalinks of your choosing.

A Final Note

On a personal note, I prefer to use Frontpage to manage/maintain sites, I've been using it since around '96, and by now, since I do most work on UNIX servers anyway I have it configured to use external editors for just about everything, including Zend Studio for php files, Bradbury TopStyle for stylesheets, Adobe ImageReady/Photoshop for images, etc. I'm more or less just using Frontpage as a convenient way to manage the site and access everything, etc. Then when I hit the "save" button in any of the other applications, they have Frontpage save my changes directly to the server, with no need to be FTP'ing files around, etc. It does help to get lots accomplished very quickly, and I was pretty bummed for the past year or so with the permalink frustration, since I was either needing to not use permalinks or not use Frontpage, or keep re-installing the FP extensions. At one point I found a way to make a .htaccess for my "running" site, but then change it to a FP .htaccess when I was doing any work (permalinks of course didn't work), either way it was a real pain.

This should work with most versions of FP and most of the unix versions of the extensions in use today.

--Chradil 17:24, 17 May 2006 (GMT)

When using extra long permalinks in email and posting in comments and chats, some long permalinks are "chopped off" or only the first section is actually recognized as a link and the end seen as text. Here is an example.

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

Can result in:

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

To click on the lower link, the user would get a 404 Page Not Found Error. If you have a tendency to use very long permalink post titles, take these steps to prevent this problem.

1. Check that you are indeed using Permalinks.

2. Edit your .htaccess file and add the following:

 RewriteRule ^post/([0-9]+)?/?([0-9]+)?/?$ /index.php?p=$1&page=$2 [QSA]

3. Test it. Find a post's ID number and type the following (with your information) in your browser and you should be redirected to your post:

http://yourdomain.example.com/post/(the ID #)

It is also worth noting that most email software will not cut off URLs that have been delineated with angle-brackets (< and >), so when pasting URLs into emails, you should write them as so:

Read my blog post at <http://yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog>

Additionally, some decent email clients offer a "preformat" option when composing plain-text emails. Using the "preformat" option when pasting links will force the email client not to insert linebreaks inside the links.

その他の問題点

If your .htaccess file is being generated correctly, but Permalinks still do not function, the following might be a problem. If problems persist, post a note in the WordPress Forum's How To section.

AllowOverride が無効 (AllowOverride Not Enabled) 
Your server may not have the AllowOverride directive enabled. If the AllowOverride directive is set to None in your Apache httpd.config file, then .htaccess files are completely ignored. In this case, the server will not even attempt to read .htaccess files in the filesystem. When this directive is set to All, then any directive which has the .htaccess Context is allowed in .htaccess files. Example of enabled AllowOverride directive in httpd.config:
 <Directory />
    Options FollowSymLinks
    AllowOverride All
 </Directory>

You may also have to enable the AllowOverride directive in your DocumentRoot:

 <Directory /var/www/html>
    # ... other directives...
    AllowOverride All
 </Directory>
You may also have to change the AllowOverride settings for the site. This is surely the case when using Mac OS X Server, but might be likewise with other systems. Usually you can find the site configuration files in /etc/httpd/sites/
If you don't want to set AllowOverride to all (as it is above) then your AllowOverride list must include the FileInfo directive. You must restart your Apache server for any httpd.config file changes to take effect. For more information on which overrides are allowed, read about Apache Core Features.
ページナビゲーションが動かない (Paged Navigation Doesn't Work) 
Sometimes navigation to second (and subsequent) pages of posts does not work as expected. Your page may generate a link to a page with one of these URIs:
 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/
The result of clicking one of those links is that the page loads with all the surroundings (header, footer, sidebar), but instead of a page of posts, there is an error message: "Sorry, no posts match that criteria."
This is due to a glitch in the .htaccess file that WordPress generates. To fix it, delete the contents of your .htaccess file and re-create it.
  1. In the Control Panel, go to Manage > Files (More Info on Editing Files)
  2. Click the link to your .htaccess file to edit its contents
  3. Copy the contents of the file and paste it to a text file in a text editor. This is a precaution in case your .htaccess file has manual entries for redirects, denials or other handy htaccess tricks
  4. Delete all contents from your .htaccess file and click the Update File button.
  5. In the Control Panel, go to Options > Permalinks.
  6. Click the Update Permalink Structure button to freshly generate new rewrite rules for your permalinks.
  7. Test the results using a link that had previously broken.
  8. Add any manual htaccess entries back in your file (Place manual htaccess entries before the # BEGIN WordPress or after # END WordPress lines.)
You may also perform similar steps by deleting the .htaccess files from the server, creating a fresh empty .htaccess file, changing its permissions to 666, and then in Options > Permalinks generate a new set of htaccess rules by clicking the Update Permalinks Structure button.
If that still doesn't work, take a look at the wordpress support forums, specifically, this support post.
「ページ」へのパーマリンクが効かない (Permalinks to pages don't work) 
If you've tried to navigate to a newly created Page and encounter an error, you likely need to update your Permalink structure. Remember, each time you add a new static Page to WordPress, new rules must be generated and updated to .htaccess (WordPress 1.X) or to the internal rewrites array (WordPress 2.X).
Ultimate Tag Warrior のタグページへのパーマリンクが効かない (Permalinks to Ultimate Tag Warrior tag pages don't work) 
If you get 404 errors on local tag URLs when using the UltimateTagWarrior plugin on WordPress 2.X, it's because the internal rewrites generated by WordPress are being overly greedy and getting invoked before UTW's rewrite rules have a chance. This usually occurs only when using a custom permalink structure (like /%postname%/). To fix it, either switch your Permalink structure to "Date and name based" or hack the UTW plugin to place the UTW rewrites at the top of the internal rewrites array. More Info on this.
パーマリンクは動作・ページが存在しないと返される (Permalinks work but no pages are returned) 
Some versions of PHP 4.4.x and 5.x have a bug that causes mod_rewrite to fail when used with some versions of Apache 2.x. More details at http://bugs.php.net/bug.php?id=35096 and http://bugs.php.net/bug.php?id=35059.

その他のヘルプ

If these steps do not work, search for your problem in the Codex, トラブルシューティング, or in the Support Forum. As a last resort, file a bug report.

ヒントと小技

投稿記事の末尾に .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最新版との差分