2026年9月23日

2026年9月23日

IISのWordPressでweb.configのURL書き換えが効かないときの直し方|500.19・404

Windows の IIS(Internet Information Services)でWordPressを動かすと、「設定」→「パーマリンク」で投稿名などのURLを選んだときに、.htaccess ではなく web.config にURLの書き換えルールが書かれます。この web.config の中身や、書き換えに必要なモジュールに問題があると、サイト全体が「HTTP Error 500.19」になったり、トップページ以外が404になったりします。

この記事では、WordPress 7.1 のソースコードとMicrosoftの公式ドキュメントで確認した内容(2026年11月時点)をもとに、原因の見分け方と直し方を説明します。

WordPressがIISでパーマリンクを使う条件

WordPressは、次の3つがそろっているときだけ、IISで /sample-post/ のような形のパーマリンクを使えると判断します(iis7_supports_permalinks() 関数)。

  1. IIS 7 以降で動いている
  2. IIS の URL Rewrite モジュールが入っていて、サイトで有効になっている(有効だとPHPに IIS_UrlRewriteModule というサーバー変数が渡される)
  3. PHPが FastCGI で動いている(PHPの PHP_SAPI が cgi-fcgi)

加えて、web.config を書き換えるためにPHPの DOM 拡張(DOMDocument クラス)が必要です。

どれかが欠けると、パーマリンク設定の選択肢が /index.php/%postname%/ のように index.php 付きになります。この表示になっていたら、まず下の手順1でURL Rewrite モジュールを確かめます。

症状から原因を見分ける

症状 主な原因
サイト全体が HTTP Error 500.19、エラーコード 0x8007000d web.config の書式の誤り(閉じていないタグなど)、またはURL Rewrite モジュールが入っていないのに <rewrite> が書かれている
トップページは表示されるが、投稿や固定ページが404 書き換えルールが無い、web.config の場所が違う、ルールが無効になっている
パーマリンクの選択肢が index.php 付きになる URL Rewrite モジュールが無い、PHPがFastCGIで動いていない、DOM拡張が無い
パーマリンクを保存すると、ルールを手で貼るよう求められる web.config かサイトのルートフォルダーに、PHPから書き込む権限が無い

Microsoftのドキュメントでは、500.19 の 0x8007000d は「設定ファイルの中に、壊れたXMLか、認識できない要素がある」場合のエラーとされ、例として URL Rewrite モジュールが入っていないのに書き換えの設定がある場合が挙げられています。

手順1:URL Rewrite モジュールを入れる

IIS マネージャーでサイトを選び、機能の一覧に「URL 書き換え」(英語版では「URL Rewrite」)があるかを確かめます。無ければモジュールが入っていません。

URL Rewrite モジュールは、Microsoft のURL Rewrite の配布ページから入手します。2026年11月時点の版は 2.1 で、IIS 7 から IIS 10 に対応し、x64 用・x86 用のインストーラー(日本語版もあり)が配布されています。入れたあと、IIS マネージャーを開き直して「URL 書き換え」が表示されることを確かめます。

手順2:WordPressが書くルールの形を知る

WordPressがパーマリンク設定の保存時に web.config に追加するルールは、次の形です(WordPress: のあとにはサイトのURLが入ります)。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="WordPress: https://example.com" patternSyntax="Wildcard">
          <match url="*" />
          <conditions>
            <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>
  </system.webServer>
</configuration>

意味は「実在するファイルやフォルダーへのアクセスはそのまま返し、それ以外はすべて index.php に渡す」です。画像やCSSは実在するファイルなので、書き換えの対象になりません。

このルールは、WordPressの index.php があるフォルダー(サイトのホームのフォルダー)の web.config に入れます。

既存の web.config に足すときの注意

  • <configuration> の中の <system.webServer> の中の <rewrite> の中の <rules> の中に入れます。<system.webServer> がすでにある場合は、2つ目を作らず既存のものの中に入れます。
  • WordPressは、name が wordpress か WordPress で始まるルールがすでにあると、ルールを追加も更新もしません。古い誤ったルール(例: 名前が wordpress のまま内容が違うもの)が残っていると、パーマリンクを保存し直しても直らないので、そのルールを消すか正しい内容に直します。
  • XMLは大文字・小文字を区別し、タグの閉じ忘れが1か所あるだけで500.19になります。保存前にXMLとして正しいかを確かめます(下の手順4)。

手順3:web.config に書き込めないときは手で追加する

PHPを動かしているユーザー(アプリケーションプールのID)に書き込み権限が無いと、パーマリンクを保存したときに、WordPressは web.config を書き換えられず、画面に貼り付けるためのルールを表示します。

  • web.config がすでにある場合は、表示された <rule> を /<configuration>/<system.webServer>/<rewrite>/<rules> の中に入れるよう案内されます。
  • web.config が無い場合は、<configuration> から始まるファイル全体が表示されるので、サイトのルートに web.config という名前で保存します。

ファイルはUTF-8で保存します。メモ帳などで編集した場合は、拡張子が web.config.txt になっていないかも確かめます。

一時的に書き込み権限を与えてWordPressに書かせる方法もあります。その場合WordPressは、ルールを保存したあとに書き込み権限を元に戻すよう案内します。

手順4:設定を確かめる

XMLとして正しいか

PowerShell で、web.config をXMLとして読み込めるかを確かめられます(パスはサイトの場所に置き換えます)。

[xml](Get-Content -Raw -Path 'C:\inetpub\wwwroot\web.config') | Out-Null

何も表示されなければXMLとしては正しく、誤りがあれば何行目かを含むエラーが表示されます。

IISが設定を読めるか

Microsoftのドキュメントで案内されている appcmd で、サイトの system.webServer の設定を読み込めるかを確かめます(管理者として実行。Default Web Site はサイト名に置き換えます)。

& "$env:windir\system32\inetsrv\appcmd.exe" list config "Default Web Site" /section:system.webServer/rewrite/rules

ここでエラーになる場合は、URL Rewrite モジュールが入っていないか、設定の書式に誤りがあります。500.19 のエラーの詳細は、イベントビューアーの「Windows ログ」→「Application」にも、行番号つきで記録されることがあります。

ブラウザーで確かめる

  1. 「設定」→「パーマリンク」で「投稿名」を選んで保存します。
  2. 投稿・固定ページ・カテゴリーのページを開き、404にならないことを確かめます。
  3. 画像やCSSが表示されていること(実在するファイルが書き換えられていないこと)を確かめます。

手順5:.htaccess のルールを変換した場合の注意

Apache から移ってきたサイトで、.htaccess の内容を URL Rewrite モジュールのインポート機能(Import Rules)などで変換したルールが残っていることがあります。WordPressに必要なのは手順2のルール1つだけなので、変換された古いWordPress用のルールは消して、手順2のルールに置き換えます。キャッシュ系プラグインなどが .htaccess に書いていた設定は IIS では使われないので、そのプラグインのIIS向けの説明に従って設定し直します。

まとめ

  • IISでパーマリンクを使うには、URL Rewrite モジュール、FastCGIで動くPHP、PHPのDOM拡張が必要です。欠けるとパーマリンクが index.php 付きになります。
  • 500.19(0x8007000d)は、web.config の書式の誤りか、URL Rewrite モジュールが無いときに出ます。
  • 正しいルールは「実在しないファイル・フォルダーへのアクセスを index.php に渡す」1つだけです。名前が wordpress で始まる古いルールがあると、WordPressは更新しません。
  • 書き込めない場合は、パーマリンク設定の画面に表示されるルールを手で web.config に貼り付けます。

お気軽にご相談ください

お見積りへ お問い合わせへ
▲