2026年9月8日

WordPressでアーカイブページだけが500エラーになる原因と解決方法

エラー・白い画面

トップページや個別記事は表示できるのに、カテゴリー・タグ・投稿タイプ・日付などのアーカイブページだけが500エラーになる場合、原因はアーカイブ用のテンプレートか、一覧の取得条件を変えるコード（pre_get_posts など）に絞り込めることが多いです。この記事では、アーカイブ特有の原因の見分け方と、エラーログから原因の行を特定して直すまでの手順を解説します。

500エラーが「アーカイブだけ」で起きる意味

500 Internal Server Error は、サーバー側の処理が途中で失敗したことを示すだけで、原因の中身は教えてくれません。そのため、まず「どのページで起きるか」を整理することが切り分けの近道です。

WordPressは表示するページの種類に応じて、テーマ内のテンプレートファイルを選びます（テンプレート階層）。たとえばカテゴリーのアーカイブでは category-{スラッグ}.php、category.php、archive.php、index.php の順に探し、最初に見つかったファイルを使います。カスタム投稿タイプなら archive-{投稿タイプ}.php、タクソノミーなら taxonomy-{タクソノミー}.php が候補に入ります。ブロックテーマの場合は templates/archive.html や templates/category.html などが同じ役割を持ちます。

個別記事は single.php など別のテンプレートを使うため、「記事は表示できるがアーカイブはだめ」という状況は、アーカイブ用のテンプレートか、一覧の取得だけに影響するコードが原因であることを示しています。次のように症状を整理しておくと、後の調査が楽になります。

すべてのアーカイブで起きるのか、特定のカテゴリーや投稿タイプだけなのか
1ページ目から起きるのか、2ページ目以降だけなのか
投稿数の多いカテゴリーだけで起きるのか
テーマやプラグインの更新、PHPのバージョン変更の直後から起きたのか

作業前の準備

調査ではテーマやプラグインの有効・無効を切り替えたり、wp-config.php を編集したりします。始める前にファイルとデータベースのバックアップを取ってください。可能であれば、本番と同じ構成のステージング環境で再現させてから調べると、訪問者への影響を避けられます。

原因を特定する手順

1. エラーログで原因の行を確認する

最初にエラーの中身を確認します。wp-config.php の「編集が必要なのはここまでです」より上に次の設定を追記します。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

この状態で問題のアーカイブページを開くと、wp-content/debug.log にエラーが記録されます。PHP Fatal error で始まる行に、エラーの種類とファイルパス、行番号が書かれています。パスが wp-content/themes/ で始まればテーマ、wp-content/plugins/ で始まればプラグインが原因です。

debug.log に何も書かれない場合は、PHPが処理を始める前の段階、またはPHPの実行時間切れなどでサーバー側が処理を打ち切っている可能性があります。レンタルサーバーの管理画面やサーバー上のエラーログ（Apacheの error_log、Nginxの error.log、PHP-FPMのログなど）も確認してください。

なお、WordPress 5.2以降ではPHPの致命的なエラーが起きると、真っ白な画面ではなく「重大なエラー」を知らせるメッセージが表示され、管理者のメールアドレスに通知が届くことがあります。このメールにも原因のファイルが書かれているので、あわせて確認すると手がかりが増えます。

2. テーマが原因かを切り分ける

ログでテーマのファイルが示されていれば、そのテンプレートを直します。はっきりしない場合は、プラグイン「Health Check & Troubleshooting」のトラブルシューティングモードを使うと、自分のログインセッションだけでテーマをデフォルトテーマに切り替え、プラグインを無効にした状態を再現できます。訪問者の表示は変わらないため、本番環境でも比較的安全に切り分けられます。

トラブルシューティングモードに入った直後は、プラグインがすべて無効でデフォルトテーマが使われる状態です。ここでアーカイブが表示できたら、モードの画面からプラグインを1つずつ有効に戻し、最後に元のテーマへ切り替えます。エラーが再発した時点で有効にしたものが原因の候補です。この状態でもエラーになる場合は、テーマやプラグイン以外（mu-plugins 内のコードやサーバー設定）を疑います。

管理画面に入れない場合は、WP-CLIでも同じ切り分けができます。

# 現在のテーマとプラグインの状態を確認
wp theme list
wp plugin list --status=active

# デフォルトテーマへ一時的に切り替える(テーマ名は環境に合わせる)
wp theme activate twentytwentyfive

3. 遅いクエリやメモリ不足を確認する

投稿数の多いアーカイブだけでエラーになる場合は、一覧の取得が重すぎてメモリ不足や実行時間切れになっている可能性があります。ログに Allowed memory size of ... bytes exhausted と出ていればメモリ不足です。エラーにならない程度に再現できるなら、プラグイン「Query Monitor」を入れると、そのページで実行されたデータベースクエリと所要時間、メモリ使用量を確認できます。

よくある原因と直し方

pre_get_posts の書き方の誤り

アーカイブの表示件数や並び順を変えるために pre_get_posts を使うコードは、書き方を誤るとアーカイブ全体を壊します。よくあるのは次の3つです。

メインクエリかどうかを確認せず、ウィジェットや管理画面のクエリまで変更してしまう
フックの中で get_posts() や new WP_Query() を呼び、そのクエリでも同じフックが動いて処理が繰り返され、メモリ不足になる
posts_per_page を -1（全件）にして、数千件の投稿を一度に読み込む

安全な書き方は次のとおりです。

add_action( 'pre_get_posts', function ( $query ) {
    // 管理画面とメインクエリ以外には手を出さない
    if ( is_admin() || ! $query->is_main_query() ) {
        return;
    }

    if ( $query->is_category() ) {
        $query->set( 'posts_per_page', 20 );
    }
} );

is_admin() と $query->is_main_query() の確認を入れることで、変更がアーカイブのメインの一覧だけに限定されます。全件表示が必要な場面でも、ページ送りを使って件数を区切るほうが安定します。

PHPバージョン変更による非互換

PHP 8系に上げた後からアーカイブだけが壊れた場合、古いテンプレートのコードが新しいPHPで致命的なエラーになっている可能性があります。代表的なのは、配列でない値を count() に渡して TypeError になるケースや、削除された関数を呼んでいるケースです。ログに出た行を開き、値が配列かどうかを確認してから処理するように直します。テーマの配布元が更新版を出しているなら、まずテーマを最新版にしてください。

無効化したプラグインの関数をテンプレートが呼んでいる

アーカイブのテンプレートで、特定のプラグインが提供する関数（関連記事、パンくず、カスタムフィールドの表示など）を呼んでいると、そのプラグインを無効化した途端に Call to undefined function で止まります。テンプレート側では、関数が存在するかを確認してから呼ぶようにします。

<?php if ( function_exists( 'your_plugin_breadcrumb' ) ) : ?>
    <?php your_plugin_breadcrumb(); ?>
<?php endif; ?>

your_plugin_breadcrumb の部分は、実際に使っている関数名に置き換えてください。

重いクエリによる実行時間切れ

カスタムフィールドでの絞り込み（meta_query）や複数のタクソノミーを組み合わせた条件は、投稿数が増えると急に遅くなります。Query Monitorで遅いクエリが見つかったら、条件を減らす、表示件数を下げる、結果をキャッシュするなどで負荷を軽くします。メモリ上限を WP_MEMORY_LIMIT で上げると一時的に回避できることはありますが、根本の原因であるクエリの重さが残る点に注意してください。

修正後の確認

直した後は、エラーが出ていたアーカイブの1ページ目と2ページ目以降、別のカテゴリー、カスタム投稿タイプのアーカイブを順に開いて確認します。キャッシュプラグインやCDNを使っている場合は、古いエラーページが配信されないようにキャッシュを削除してください。確認が終わったら WP_DEBUG を false に戻し、debug.log は削除するか外部から読めない場所に移します。この記事の手順は、WordPressの安定版を前提にしています（2026年10月現在）。

まとめ

アーカイブだけが500エラーになる場合は、アーカイブ用テンプレートか、一覧の取得条件を変えるコードが原因であることが多いです。
まず WP_DEBUG_LOG で debug.log を確認し、エラーのファイルと行番号からテーマかプラグインかを判断します。
切り分けにはHealth Check & Troubleshootingのトラブルシューティングモードが便利で、訪問者の表示に影響しません。
pre_get_posts では is_admin() と is_main_query() の確認を入れ、全件取得を避けます。
PHPの更新後に起きた場合は、テンプレートの古いコードやプラグイン関数の呼び出しを見直します。