2026年6月16日

WordPressのカテゴリー・タグページが404になる原因と直し方｜ページ送り・カスタムタクソノミーも解説

カスタマイズ

WordPressでカテゴリーやタグの一覧ページが404になる原因は、大きく「リライトルールが古い」「サーバーがWordPressにURLを渡していない」「URLの衝突」「2ページ目以降の件数計算のずれ」の4つに分かれます。この記事では、どこで止まっているかを切り分ける方法から、原因ごとの直し方、カスタムタクソノミーを登録したときの注意点までを順に解説します。読み終えるころには、404の原因を推測ではなく確認で特定できるようになります（2026年10月現在のWordPress 6.x系を前提にしています）。

まず「どこで404になっているか」を切り分ける

最初に、問題がWordPressの外（Webサーバー）にあるのか、中（リライトルールやクエリ）にあるのかを分けます。次の3つを試してください。

パーマリンクを使わないURLで開く：カテゴリーなら https://example.com/?cat=カテゴリーID、タグなら https://example.com/?tag=タグのスラッグ で開きます。これで表示されるなら、カテゴリー自体と投稿は正常で、URLの解釈に問題があります。
投稿の個別ページが開くか確認する：投稿や固定ページも含めてパーマリンク形式のURLがすべて404なら、Webサーバー側の設定（.htaccessやNginxの設定）が原因の可能性が高くなります。
1ページ目と2ページ目を比べる：1ページ目は開くのに /page/2/ 以降だけが404なら、後述する表示件数のずれが原因です。

404の画面がテーマのデザインで表示されていれば、リクエストはWordPressまで届いています。サーバー標準のそっけない「Not Found」画面なら、WordPressに届く前にWebサーバーが返しています。この見た目の違いも切り分けの手がかりになります。

リライトルールを再生成する

WordPressは「このURLはこのクエリに対応する」という対応表（リライトルール）をデータベースに保存しています。プラグインの有効化・無効化、カテゴリーベースの変更、カスタム投稿タイプやタクソノミーの追加をしたあとに、この対応表が更新されていないと、新しいURLが404になります。

再生成は、管理画面の「設定」→「パーマリンク」を開き、何も変えずに「変更を保存」を押すだけです。保存するとリライトルールが作り直され、Apacheで .htaccess が書き込み可能な場合はその内容も更新されます。WP-CLIが使える場合は次のコマンドでも同じ処理ができます。

wp rewrite flush

再生成したあとは、ページキャッシュ（キャッシュプラグインやサーバーのキャッシュ機能、CDN）も消去してください。404の応答がキャッシュに残っていると、直っているのに404が見え続けます。

Webサーバーの設定を確認する

Apacheの場合

Apacheでは、ドキュメントルートの .htaccess に次のブロックが必要です。WordPressがルート直下にインストールされている場合の標準形です。

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

/blog/ のようなサブディレクトリにWordPressを置いている場合は、RewriteBase /blog/ と RewriteRule . /blog/index.php [L] に変えます。編集前には、元の .htaccess を別名で保存しておいてください。記述が正しいのに効かない場合は、Apache側で mod_rewrite が有効になっていないか、.htaccess による上書きが AllowOverride で禁止されている可能性があります。VPSなら仮想ホストの設定で AllowOverride All（少なくとも FileInfo）になっているかを確認します。

見落としやすいのが、URLと同じ名前の実ディレクトリです。!-d の条件は「実在するディレクトリならWordPressに渡さない」という意味なので、ドキュメントルートに category や tag という名前のフォルダーがあると、そのURLはWordPressに届かず404や403になります。

Nginxの場合

Nginxは .htaccess を読みません。パーマリンク設定の保存でサーバー側が変わることはないため、サーバー設定に次の記述が必要です。

location / {
    try_files $uri $uri/ /index.php?$args;
}

この記述がない、またはサブディレクトリ用の location が抜けていると、トップページ以外がすべて404になります。設定を変えたら nginx -t で文法を確認してから再読み込みします。

カテゴリーベース・タグベースの衝突を解消する

「設定」→「パーマリンク」の「カテゴリーベース」「タグベース」は、URLの /category/ や /tag/ の部分を変える設定です。ここを変えたことで、ほかのURLとぶつかって404になることがあります。

固定ページのスラッグとの衝突：カテゴリーベースを news にし、同じ news というスラッグの固定ページがあると、どちらかのURLが期待どおりに解釈されません。固定ページとカテゴリーベースには別の名前を使います。
カテゴリーベースとタグベースが同じ：両方に同じ文字列を入れると、どちらかのURLが正しく解釈されなくなります。
カテゴリーベースを消すプラグインや小技：カテゴリーベースに . を入れたり、プラグインで /category/ を取り除いたりすると、投稿や固定ページのスラッグとカテゴリーのスラッグが同じ階層で競合します。子カテゴリーや2ページ目だけが404になる症状も、この構成で起きやすい問題です。

カテゴリーのスラッグを変えた場合、古いURLは自動ではリダイレクトされません。投稿のスラッグ変更には古いURLからの転送機能がありますが、カテゴリーやタグには働かないためです。外部からのリンクや検索結果に古いURLが残っているなら、リダイレクト用プラグインやサーバー設定で新しいURLへ301リダイレクトを設定します。

2ページ目以降だけ404になる場合

カテゴリーの1ページ目は表示されるのに /category/news/page/3/ が404になる場合、多くはテンプレート側で表示件数を変えていることが原因です。

WordPressは、URLを受け取った時点で「メインクエリ」を実行し、管理画面の「設定」→「表示設定」にある「1ページに表示する最大投稿数」をもとに総ページ数を決めます。テーマの category.php などで new WP_Query() や query_posts() を使って別の件数で一覧を作り直していると、画面上のページ送りは作り直したクエリの件数で計算されます。たとえば最大投稿数が10件、テンプレートで5件表示にしている場合、投稿が30件あればページ送りは6ページ分出ますが、メインクエリでは3ページしかないため、4ページ目以降をWordPressが「存在しない」と判断して404を返します。

対処は、テンプレートでクエリを作り直すのをやめ、pre_get_posts フックでメインクエリそのものの件数を変えることです。子テーマの functions.php などに書きます。

add_action( 'pre_get_posts', function ( $query ) {
	// 管理画面とサブクエリには影響させない
	if ( is_admin() || ! $query->is_main_query() ) {
		return;
	}
	// カテゴリーとタグの一覧だけ12件表示にする
	if ( $query->is_category() || $query->is_tag() ) {
		$query->set( 'posts_per_page', 12 );
	}
} );

is_main_query() の判定を省くと、サイドバーのウィジェットなど、ほかのクエリまで件数が変わってしまいます。テンプレート側は通常のループ（have_posts() と the_post()）に戻し、ページ送りには the_posts_pagination() などコアの関数を使うと、メインクエリと計算が一致します。

なお、投稿数を超えるページ番号（3ページしかないのに /page/5/ を開くなど）が404になるのは正常な動作です。

カスタムタクソノミーのアーカイブが404になる場合

register_taxonomy() で独自の分類（ジャンル、地域など）を作った場合は、登録時の引数も確認します。

add_action( 'init', function () {
	register_taxonomy( 'genre', array( 'post' ), array(
		'label'        => 'ジャンル',
		'public'       => true,
		'hierarchical' => true,
		'show_in_rest' => true,
		'rewrite'      => array( 'slug' => 'genre' ),
	) );
} );

確認するポイントは次のとおりです。

public が false だと、publicly_queryable も既定で false になり、アーカイブはフロント側で表示されません。
rewrite の slug を変えたら、リライトルールの再生成が必要です。
タクソノミー名や rewrite のスラッグに、name、year、author、page など、WordPressが内部のクエリ変数として予約している語を使うと、クエリが誤って解釈されて404になります。
rewrite のスラッグが、カスタム投稿タイプのスラッグや固定ページのスラッグと同じになっていないかも確認します。

プラグインで登録する場合、flush_rewrite_rules() を init のたびに呼ぶのは避けてください。処理が重く、毎回データベースを書き換えることになります。有効化時に1回だけ実行するのが一般的で、その際は先にタクソノミーを登録してから再生成しないと、新しいルールが含まれません。

WP-CLIでどのルールに一致しているかを調べる

ここまでで解決しない場合は、問題のURLがどのリライトルールに一致しているかを直接確認します。

wp rewrite list --match=/category/news/page/2/

一致したルールと、それが変換されるクエリ（category_name=news&paged=2 など）が表示されます。期待と違うルール（固定ページ用のルールなど）に一致していれば、URLの衝突が原因と分かります。何も一致しない場合は、ルールが登録されていないので、登録コードや再生成を見直します。管理画面で確認したい場合は、Query Monitorプラグインでも、表示中のページが一致したリライトルールとクエリ変数を確認できます。

まとめ

?cat=ID で開けるかを試し、サーバー側とWordPress側のどちらの問題かを切り分ける
設定変更やプラグイン追加のあとは、パーマリンク設定の保存か wp rewrite flush でルールを再生成し、キャッシュも消す
Apacheは .htaccess と AllowOverride、Nginxは try_files を確認する
カテゴリーベースと固定ページ・タグベースの衝突、スラッグ変更後のリダイレクト漏れに注意する
2ページ目以降の404は、pre_get_posts でメインクエリの件数を変えて解消する