PHPの404エラーの対処法について

2026年7月4日

PHPで「404エラー」が表示される場合、多くのケースではPHPそのもののエラーではなく、Webサーバーやアプリケーションが「指定されたURLに対応するページやファイルが見つからない」と判断している状態です。

404はHTTPステータスコードの一種で、正式には「404 Not Found」を意味します。

つまり、PHPの文法ミスや処理エラーというよりも、以下のような原因で発生することが多いです。

URLが間違っている
ファイルの配置場所が間違っている
ドキュメントルートが正しくない
.htaccess の設定が間違っている
Nginxの try_files 設定が不足している
LaravelやWordPressなどのルーティング設定に問題がある
アプリケーション側が意図的に404を返している

ただし、PHPアプリケーションの中で http_response_code(404) などを使い、意図的に404を返している場合もあります。

そのため、PHPで404エラーが発生したときは、まず「Webサーバーが返している404なのか」「PHPアプリケーションが返している404なのか」を切り分けることが重要です。

PHPで404エラーが発生する主な原因

URLやファイル名が間違っている

最も基本的な原因は、アクセスしているURLやファイル名の間違いです。

たとえば、実際のファイル名が Contact.php なのに、ブラウザで contact.php にアクセスしている場合、Linux系サーバーでは404になることがあります。

Windows環境ではファイル名の大文字・小文字をあまり厳密に扱わないことがありますが、Linuxサーバーでは大文字と小文字が区別されます。

たとえば、以下はすべて別のファイルとして扱われる可能性があります。

/contact.php
/Contact.php
/CONTACT.php

ローカル環境では問題なく表示されていたのに、本番環境にアップロードしたら404になる場合は、ファイル名の大文字・小文字を確認してください。

確認すべきポイントは以下です。

ファイル名が正しいか
拡張子が .php になっているか
URLとファイル名の大文字・小文字が一致しているか
ディレクトリ名が正しいか
URLに余計な文字やスペースが入っていないか

PHPファイルの配置場所が間違っている

PHPファイルをアップロードした場所が間違っている場合も、404エラーの原因になります。

Webサイトで公開されるファイルは、サーバー内の「公開ディレクトリ」に配置する必要があります。

よく使われる公開ディレクトリ名には、以下のようなものがあります。

public_html
www
htdocs
html
public
/var/www/html

たとえば、サーバーの公開ディレクトリが以下の場合、

/home/user/public_html/

index.php は次のように配置する必要があります。

/home/user/public_html/index.php

ところが、誤って次のような場所に置いてしまうと、ブラウザからアクセスできず404になります。

/home/user/index.php

特に、独自ドメインやサブドメインを利用している場合は、ドメインごとに公開先ディレクトリが異なることがあります。

例：

example.com      → /public_html/
blog.example.com → /public_html/blog/
test.example.com → /public_html/test/

PHPファイルが正しい場所にあるかどうかは、FTPソフトやサーバー管理画面、VirtualHost設定、Nginxの root 設定などで確認しましょう。

ドキュメントルートが間違っている

ドキュメントルートとは、Webサーバーが外部に公開する基準となるディレクトリのことです。

たとえば、ドキュメントルートが以下の場合、

/var/www/html

ブラウザで次のURLにアクセスすると、

https://example.com/about.php

サーバーは基本的に次のファイルを探します。

/var/www/html/about.php

しかし、実際のファイルが別の場所にあると、404になります。

Laravelなどのフレームワークでは、プロジェクト直下ではなく public ディレクトリをドキュメントルートにする必要があります。

正しい例：

/var/www/example-app/public

誤った例：

/var/www/example-app

Laravelのプロジェクト直下を公開してしまうと、404の原因になるだけでなく、設定ファイルや内部ファイルが外部から見えてしまうリスクもあります。

`index.php` が認識されていない

URLでディレクトリだけを指定した場合、Webサーバーは通常 index.html や index.php を探します。

たとえば、以下のURLにアクセスした場合、

https://example.com/

サーバーは次のようなファイルを探します。

index.html
index.php

Apacheでは、DirectoryIndex の設定によって、どのファイルを優先的に表示するかを指定できます。

DirectoryIndex index.php index.html

ただし、index.php が存在しない場合や DirectoryIndex の設定が正しくない場合、必ず404になるとは限りません。

ディレクトリ自体が存在しない場合は404になりやすく、ディレクトリは存在するものの index.php がなく、ディレクトリ一覧表示も禁止されている場合は403になることが多いです。

つまり、以下のように考えると分かりやすいです。

ディレクトリが存在しない → 404になりやすい
ディレクトリは存在するがindexファイルがない → 403になりやすい

`.htaccess`が原因で404になるケース

リライト設定が間違っている

Apache環境で、.php を付けないURLを使っている場合は、.htaccess のリライト設定が原因で404になることがあります。

たとえば、以下のようなURLを使っているケースです。

https://example.com/about
https://example.com/contact
https://example.com/products/item-001

このようなURLは、実際に /about や /contact というファイルが存在しているわけではなく、index.php などにリクエストを渡して処理していることが多いです。

一般的な .htaccess の例は以下です。

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [L]

この設定は、実在するファイルやディレクトリがない場合に、リクエストを index.php に渡すという意味です。

ただし、この設定はすべてのPHPサイトに必要なわけではありません。

以下のように実ファイルへ直接アクセスするサイトであれば、必須ではありません。

/about.php
/contact.php
/company.php

一方で、Laravelや独自MVCのように、すべてのリクエストを index.php に集約する構成では、このようなリライト設定が重要になります。

`.htaccess` が効いていない

.htaccess に正しい設定を書いていても、Apache側で .htaccess の使用が許可されていなければ、設定は反映されません。

Apacheでは、以下のような設定が必要です。

<Directory /var/www/html>
    AllowOverride All
</Directory>

また、リライト機能を使うには mod_rewrite が有効になっている必要があります。

Ubuntu系のサーバーであれば、以下のコマンドで有効化できます。

sudo a2enmod rewrite
sudo systemctl restart apache2

ただし、AllowOverride All は便利ですが、本番環境では必要な範囲だけ許可する設定が使われることもあります。

例：

AllowOverride FileInfo

初心者向けのトラブルシュートでは AllowOverride All で確認することが多いですが、実際の運用ではサーバー方針に合わせて調整しましょう。

サブディレクトリ運用でRewriteBaseが必要な場合がある

サイトをサブディレクトリで運用している場合、RewriteBase の設定が必要になることがあります。

たとえば、次のようなURLでサイトを公開している場合です。

https://example.com/myapp/

この場合、.htaccess は以下のように設定することがあります。

RewriteEngine On
RewriteBase /myapp/

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [L]

サブディレクトリ配下で404になる場合は、URLの基準パスとリライト設定が合っているか確認してください。

Nginx環境で404になるケース

`.htaccess` はNginxでは使えない

Nginx環境では、Apacheの .htaccess は使えません。

そのため、Nginxで動いているサーバーに .htaccess を設置しても、リライト設定は反映されません。

NginxでPHPアプリケーションを動かす場合は、Nginxの設定ファイルに try_files を正しく書く必要があります。

一般的な設定例は以下です。

server {
    listen 80;
    server_name example.com;
    root /var/www/html/public;

    index index.php index.html;

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

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }
}

重要なのは以下の部分です。

try_files $uri $uri/ /index.php?$query_string;

これは、まず実在するファイルを探し、次にディレクトリを探し、それでも見つからなければ index.php にリクエストを渡すという意味です。

LaravelやCodeIgniter、独自MVCなどでは、この設定が必要になることがあります。

PHP-FPMの設定は環境によって異なる

NginxでPHPを動かす場合、PHP-FPMとの連携設定も重要です。

設定例として、以下のような指定があります。

fastcgi_pass unix:/run/php/php8.2-fpm.sock;

ただし、このパスは環境によって異なります。

たとえば、以下のような設定になることもあります。

fastcgi_pass unix:/run/php/php8.1-fpm.sock;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
fastcgi_pass 127.0.0.1:9000;
fastcgi_pass php-fpm:9000;

Docker環境では、コンテナ名を指定することもあります。

fastcgi_pass php:9000;

Nginxの設定を変更した場合は、構文チェックを行います。

sudo nginx -t

問題がなければ、Nginxを再読み込みします。

sudo systemctl reload nginx

Laravelで404になる原因と対処法

ルート定義が存在しない

Laravelで404が表示される場合、まず確認すべきなのはルート定義です。

Laravelでは、通常 routes/web.php にURLと処理の対応を定義します。

例：

Route::get('/contact', function () {
    return view('contact');
});

この定義があれば、以下のURLでアクセスできます。

https://example.com/contact

現在登録されているルートは、以下のコマンドで確認できます。

php artisan route:list

アクセスしたいURLが一覧にない場合、Laravelはそのページを見つけられず404を返します。

ドキュメントルートがpublicになっていない

Laravelでは、公開ディレクトリをプロジェクト直下ではなく public に設定する必要があります。

正しい例：

/var/www/example-app/public

誤った例：

/var/www/example-app

public ではなくLaravelプロジェクト直下をドキュメントルートにしていると、ルーティングが正しく動かないだけでなく、セキュリティ上も問題があります。

ApacheやNginx、レンタルサーバーのドメイン設定で、公開先が public になっているか確認してください。

ルートキャッシュが古い

Laravelでは、本番環境でルートキャッシュを利用していることがあります。

ルートを変更したのに404が出る場合、古いキャッシュが原因かもしれません。

以下のコマンドでキャッシュを削除できます。

php artisan optimize:clear

個別に実行する場合は、以下のコマンドも使えます。

php artisan route:clear
php artisan config:clear
php artisan cache:clear
php artisan view:clear

その後、必要に応じてルートキャッシュを再作成します。

php artisan route:cache

APP_URLは404の直接原因になりにくい

Laravelの .env にある APP_URL は、URL生成やメール内リンク、署名付きURL、アセットURLなどに影響します。

ただし、通常のページアクセスで404が発生する直接原因としては、優先度は高くありません。

Laravelの404調査では、まず以下を確認するのが基本です。

routes/web.php にルートがあるか
php artisan route:list で確認できるか
ドキュメントルートが public になっているか
ApacheやNginxのリライト設定が正しいか
ルートキャッシュが古くないか

WordPressで404になる原因と対処法

パーマリンク設定が崩れている

WordPressでトップページは表示されるのに、投稿ページや固定ページだけ404になる場合、パーマリンク設定が原因のことがよくあります。

この場合は、管理画面から以下を実行します。

設定 → パーマリンク → 変更を保存

実際に設定内容を変更しなくても、「変更を保存」を押すことでリライトルールが再生成され、404が解消されることがあります。

`.htaccess` が書き込めない

Apache環境のWordPressでは、パーマリンク設定を保存したときに .htaccess が更新されることがあります。

しかし、.htaccess に書き込み権限がない場合、設定が反映されず404が続くことがあります。

WordPressの標準的な .htaccess は、以下のような内容です。

# 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

ただし、サブディレクトリ運用や環境によって内容は変わる場合があります。

カスタム投稿タイプのリライトルールが更新されていない

カスタム投稿タイプやカスタムタクソノミーを使っている場合、リライトルールが更新されていないことで404になることがあります。

この場合も、まずはパーマリンク設定を保存し直すのが有効です。

テーマやプラグイン開発では、必要なタイミングで flush_rewrite_rules() を実行することもあります。

ただし、flush_rewrite_rules() は負荷が高いため、毎回実行するのではなく、プラグイン有効化時など必要なタイミングに限定するべきです。

独自PHPルーティングで404になるケース

ルート定義にURLが登録されていない

独自PHPでルーティングを実装している場合、PHP側のルート定義にアクセス先URLが登録されていないと404になります。

例：

$routes = [
    '/' => 'home.php',
    '/about' => 'about.php',
    '/contact' => 'contact.php',
];

$path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);

if (array_key_exists($path, $routes)) {
    require $routes[$path];
} else {
    http_response_code(404);
    require '404.php';
}

この場合、$routes に存在しないURLへアクセスすると、PHPアプリケーションが404を返します。

末尾スラッシュの違いで404になる

独自ルーティングでは、以下のURLを別物として扱ってしまうことがあります。

/contact
/contact/

この違いを吸収するには、URLの末尾スラッシュを正規化します。

$path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
$path = rtrim($path, '/');

if ($path === '') {
    $path = '/';
}

これにより、/contact と /contact/ の扱いを統一できます。

CSS・JavaScript・画像だけ404になる場合

相対パスの指定が間違っている

PHPページ自体は表示されるのに、CSS・JavaScript・画像だけ404になる場合は、パス指定の問題であることが多いです。

たとえば、以下のように指定しているとします。

<link rel="stylesheet" href="css/style.css">

現在のURLが以下の場合、

https://example.com/news/detail/123

ブラウザは次のような場所を探しに行く可能性があります。

https://example.com/news/detail/css/style.css

本来のCSSが次の場所にある場合、

https://example.com/css/style.css

404になります。

このような場合は、ルート相対パスを使うと安定します。

<link rel="stylesheet" href="/css/style.css">
<script src="/js/app.js"></script>
<img src="/images/logo.png" alt="">

サブディレクトリ運用ではルート相対パスに注意する

サイトをサブディレクトリで運用している場合、/ から始まるパスにも注意が必要です。

たとえば、サイトが以下で公開されている場合、

https://example.com/myapp/

次の指定は、

<link rel="stylesheet" href="/css/style.css">

以下を参照します。

https://example.com/css/style.css

本来参照したい場所が以下であれば、

https://example.com/myapp/css/style.css

次のように指定する必要があります。

<link rel="stylesheet" href="/myapp/css/style.css">

PHP側でベースパスを定義しておくと、管理しやすくなります。

define('BASE_URL', '/myapp');

echo '<link rel="stylesheet" href="' . BASE_URL . '/css/style.css">';

フォーム送信後に404になる場合

action属性の指定が間違っている

フォーム送信時に404になる場合は、form タグの action 属性が間違っている可能性があります。

例：

<form action="send.php" method="post">

現在のページが以下の場合、

https://example.com/contact/

送信先は次のように解釈されることがあります。

https://example.com/contact/send.php

しかし、実際の送信先ファイルが以下にある場合、

https://example.com/send.php

404になります。

この場合は、次のように絶対パスで指定します。

<form action="/send.php" method="post">

Laravelを使っている場合は、route() を使うと安全です。

<form action="{{ route('contact.send') }}" method="post">

include・requireのパスミスに注意する

通常は404ではなくPHPエラーや500になりやすい

include や require のパスが間違っている場合、通常は404ではなくPHPエラーや500エラーになることが多いです。

例：

require 'parts/header.php';

ファイルが見つからない場合、以下のようなエラーが発生することがあります。

Warning: require(...): Failed to open stream
Fatal error: Uncaught Error: Failed opening required ...

本番環境ではエラー表示が無効になっているため、白画面や500エラーとして見えることもあります。

ただし、アプリケーションのエラーハンドリングによっては、404ページのように表示されることもあります。

そのため、404調査の直接原因として優先度は高くないものの、関連する問題として確認しておく価値があります。

`DIR` を使うとパス指定が安定する

include や require では、相対パスだけに頼ると、実行ファイルの場所によって読み込みに失敗することがあります。

そのため、__DIR__ を使うと安全です。

require __DIR__ . '/parts/header.php';

親ディレクトリのファイルを読み込む場合は、以下のように書けます。

require __DIR__ . '/../config.php';

パーミッションが原因になるケース

多くの場合は403や500になりやすい

ファイルやディレクトリの権限が不適切な場合、404ではなく403や500になることが多いです。

たとえば、以下のようなケースです。

ファイルは存在するが読み取り権限がない → 403になりやすい
PHPが必要なファイルに書き込めない → 500になりやすい
アプリ側がファイルを見つけられず404を返す → 404に見える場合がある

そのため、パーミッション不備は404の直接原因としては優先度が低いものの、関連する確認項目として重要です。

一般的な目安は以下です。

ディレクトリ：755
ファイル：644

設定例：

find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

ただし、機械的にすべての権限を変更すると、必要な実行権限や書き込み権限まで変わってしまうことがあります。

Laravelでは、以下のディレクトリに書き込み権限が必要です。

storage
bootstrap/cache

例：

chmod -R 775 storage bootstrap/cache

ただし、安易に 777 を設定するのは避けましょう。所有者やグループ設定も含めて確認することが重要です。

サーバーログを確認する

ログを見ると原因を特定しやすい

404の原因が分からない場合は、サーバーログを確認するのが効果的です。

Apacheの場合：

sudo tail -f /var/log/apache2/error.log
sudo tail -f /var/log/apache2/access.log

Nginxの場合：

sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/nginx/access.log

CentOSやRHEL系では、Apacheのログパスが以下になることもあります。

/var/log/httpd/error_log
/var/log/httpd/access_log

PHP-FPMのログも環境によって異なります。

/var/log/php8.2-fpm.log
/var/log/php-fpm/error.log
/var/log/php-fpm/www-error.log

Docker環境であれば、以下のようにコンテナログを確認することもあります。

docker logs コンテナ名

レンタルサーバーでは、管理画面からエラーログやアクセスログを確認できる場合があります。

アクセスログで実際のURLを確認する

404調査では、エラーログだけでなくアクセスログも重要です。

アクセスログを見ると、実際にどのURLへアクセスして404になっているかが分かります。

たとえば、思っていたURLとは違うパスにアクセスしている場合、リンクやフォームの指定ミスが原因だと分かります。

404エラーの切り分け方

Webサーバーが返す404

Webサーバーが404を返している場合、PHPまでリクエストが届いていないことがあります。

主な原因は以下です。

ファイルが存在しない
ドキュメントルートが違う
ApacheのVirtualHost設定が違う
Nginxのroot設定が違う
URLのパスが間違っている

確認すべき項目は以下です。

ファイル配置
ドキュメントルート
VirtualHost設定
Nginxのserver block
アクセスログ
エラーログ

リライト不備による404

リライト不備による404は、実ファイルが存在しないURLを使っているサイトで起こりやすいです。

例：

/about
/contact
/products/item-001

このようなURLを index.php に渡す設定ができていない場合、404になります。

確認すべき項目は以下です。

.htaccess
mod_rewrite
AllowOverride
Nginxのtry_files
RewriteBase

PHPアプリケーションが返す404

WebサーバーからPHPまではリクエストが届いているものの、アプリケーション側が「そのページは存在しない」と判断して404を返している場合もあります。

主な原因は以下です。

Laravelのroutes/web.phpにルートがない
WordPressのパーマリンク設定が崩れている
独自ルーターにURLが登録されていない
CMS上で記事が非公開・削除済み
スラッグが変更されている

確認すべき項目は以下です。

ルート定義
CMSの投稿状態
スラッグ
コントローラー
ルートキャッシュ
アプリケーションログ

404エラーを調査する手順

まずtest.phpを作成して確認する

原因を切り分けるには、まず公開ディレクトリに test.php を置いて、直接アクセスできるか確認します。

<?php
echo 'PHP OK';

次のURLでアクセスします。

https://example.com/test.php

これが表示されない場合、問題はPHPのルーティングではなく、以下の可能性が高いです。

ファイルの配置場所が違う
ドキュメントルートが違う
ドメイン設定が違う
Webサーバー設定が違う
パーミッションに問題がある

index.phpに直接アクセスする

次に、以下のURLで index.php に直接アクセスします。

https://example.com/index.php

これが表示されるのに、以下が404になる場合、

https://example.com/

DirectoryIndex の設定やトップページの扱いに問題がある可能性があります。

静的ファイルにアクセスする

sample.txt などの静的ファイルを公開ディレクトリに置き、アクセスできるか確認します。

https://example.com/sample.txt

これも404になる場合、PHP以前にドキュメントルートやファイル配置が間違っている可能性があります。

`.htaccess` を一時的に無効化する

Apache環境で .htaccess が原因か確認したい場合は、一時的にファイル名を変更します。

.htaccess
↓
.htaccess_backup

この状態で直接PHPファイルにアクセスできる場合は、.htaccess のリライト設定が原因の可能性があります。

ただし、WordPressやLaravelでは .htaccess を無効化すると下層ページが表示できなくなるため、検証後は必ず元に戻してください。

ルーティングを確認する

Laravelであれば、以下を実行します。

php artisan route:list

WordPressであれば、管理画面からパーマリンク設定を保存し直します。

設定 → パーマリンク → 変更を保存

独自PHPであれば、ルート定義や $_SERVER['REQUEST_URI'] の値を確認します。

SEO観点での404エラー対応

URL変更後は301リダイレクトを設定する

SEOの観点では、URL変更後に旧URLが404のままになっていると、検索流入や外部リンクの評価を失う可能性があります。

旧URLに対応する新URLがある場合は、301リダイレクトを設定します。

Apacheの場合：

Redirect 301 /old-page /new-page

Nginxの場合：

rewrite ^/old-page$ /new-page permanent;

PHPで設定する場合：

header("Location: /new-page", true, 301);
exit;

ただし、WordPressやLaravelなどでリライト設定を使っている場合は、リダイレクトルールを書く順番に注意が必要です。

通常は、個別のリダイレクトルールをフロントコントローラーへの転送ルールより前に書きます。

すべての404をトップページへ転送しない

存在しないURLをすべてトップページへ301リダイレクトするのはおすすめできません。

たとえば、以下のようなURLをすべてトップページに転送するケースです。

/old-product-a
/deleted-column
/random-missing-url

これはユーザーにとって不親切であり、検索エンジンからも不自然に見られる可能性があります。

基本的には、以下のように対応します。

対応する新ページがある → 301リダイレクト
完全に削除したページ → 404または410
一時的に存在しないページ → 404
明確に廃止したページ → 410

カスタム404ページを用意する

404ページを用意する場合は、単に「ページが見つかりません」と表示するだけでなく、HTTPステータスコードも正しく404にする必要があります。

PHPで404ページを返す例：

<?php
http_response_code(404);
?>
<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>ページが見つかりません</title>
</head>
<body>
    <h1>404 Not Found</h1>
    <p>お探しのページは見つかりませんでした。</p>
</body>
</html>

SEO上も、存在しないページは正しく404を返すことが重要です。

404・403・500の違い

404はページが見つからない状態

404は「指定されたURLに対応するページやファイルが見つからない」という意味です。

主な原因は以下です。

URLミス
ファイルなし
ルート未定義
ドキュメントルート違い
リライト不備

403はアクセス権限がない状態

403は「アクセス権限がない」という意味です。

主な原因は以下です。

ファイルやディレクトリの権限不足
DirectoryIndexがない
ディレクトリ一覧表示が禁止されている
アクセス制限がかかっている

500はサーバー内部エラー

500は「サーバー内部でエラーが発生した」という意味です。

主な原因は以下です。

PHPの構文エラー
requireやincludeの失敗
アプリケーションの例外
サーバー設定ミス
パーミッション不備

502や503にも注意する

NginxとPHP-FPMを使っている環境では、PHP-FPMが停止している場合や接続できない場合、404ではなく502になることがあります。

503は、メンテナンス中や一時的な過負荷、アプリケーション停止時などに発生することがあります。

ステータスコードごとに原因が異なるため、ブラウザの開発者ツールやサーバーログで正確なステータスを確認しましょう。

症状別の確認ポイント

test.phpも404になる場合

test.php を置いても404になる場合は、PHPアプリケーション以前の問題である可能性が高いです。

確認ポイントは以下です。

公開ディレクトリが正しいか
ドキュメントルートが正しいか
ドメイン設定が正しいか
ファイル名が正しいか
サーバー設定が正しいか

トップページは表示されるが下層ページが404になる場合

この場合は、リライト設定やルーティングの問題が疑われます。

確認ポイントは以下です。

.htaccess が正しいか
mod_rewrite が有効か
AllowOverride が適切か
Nginxのtry_filesが正しいか
フレームワークのルート定義があるか

Laravelで全ページが404になる場合

Laravelで全ページが404になる場合は、以下を確認します。

ドキュメントルートがpublicになっているか
routes/web.phpにルートがあるか
ApacheやNginxの設定が正しいか
ルートキャッシュが古くないか

確認コマンド：

php artisan route:list
php artisan optimize:clear

WordPressで投稿ページだけ404になる場合

WordPressで投稿ページや固定ページだけ404になる場合は、パーマリンク設定を確認します。

設定 → パーマリンク → 変更を保存

それでも直らない場合は、以下を確認します。

.htaccessが正しいか
mod_rewriteが有効か
カスタム投稿タイプのリライト設定が正しいか
スラッグが重複していないか

CSS・画像だけ404になる場合

CSSや画像だけ404になる場合は、パス指定を確認します。

確認ポイントは以下です。

相対パスが正しいか
ルート相対パスになっているか
サブディレクトリ運用のベースパスが合っているか
ファイル名の大文字・小文字が一致しているか

PHPの404エラー対処法まとめ

PHPで404エラーが発生した場合は、PHPコードだけを見るのではなく、URL・ファイル配置・ドキュメントルート・Webサーバー設定・アプリケーションのルーティングを順番に確認することが重要です。

特に多い原因は以下です。

URLやファイル名の間違い
PHPファイルの配置場所の間違い
ドキュメントルートの設定ミス
.htaccess のリライト設定ミス
Nginxの try_files 設定不足
Laravelのルート未定義
WordPressのパーマリンク設定崩れ
CSSや画像のパス指定ミス

調査するときは、まず公開ディレクトリに test.php を置き、直接アクセスできるか確認するのが効果的です。

<?php
echo 'PHP OK';

これが表示されない場合は、ファイル配置やドキュメントルート、サーバー設定を確認します。

一方で、test.php は表示されるのに下層ページだけ404になる場合は、.htaccess、Nginxの try_files、LaravelやWordPressのルーティング設定を確認しましょう。

404エラーは原因の範囲が広いため、やみくもに設定を変更するのではなく、以下の順番で切り分けるのが効率的です。

1. URLとファイル名を確認する
2. ファイルの配置場所を確認する
3. test.phpで直接アクセスを確認する
4. ドキュメントルートを確認する
5. .htaccessやNginx設定を確認する
6. フレームワークやCMSのルーティングを確認する
7. サーバーログを確認する

この順番で確認すれば、PHPの404エラーの原因を効率よく特定できます。

以上、PHPの404エラーの対処法についてでした。

最後までお読みいただき、ありがとうございました。

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

PHPの404エラーの対処法について

採用はこちら

PHPで404エラーが発生する主な原因

URLやファイル名が間違っている

PHPファイルの配置場所が間違っている

ドキュメントルートが間違っている

index.php が認識されていない

.htaccessが原因で404になるケース

リライト設定が間違っている

.htaccess が効いていない

サブディレクトリ運用でRewriteBaseが必要な場合がある

Nginx環境で404になるケース

.htaccess はNginxでは使えない

PHP-FPMの設定は環境によって異なる

Laravelで404になる原因と対処法

ルート定義が存在しない

ドキュメントルートがpublicになっていない

ルートキャッシュが古い

APP_URLは404の直接原因になりにくい

WordPressで404になる原因と対処法

パーマリンク設定が崩れている

.htaccess が書き込めない

カスタム投稿タイプのリライトルールが更新されていない

独自PHPルーティングで404になるケース

ルート定義にURLが登録されていない

末尾スラッシュの違いで404になる

CSS・JavaScript・画像だけ404になる場合

相対パスの指定が間違っている

サブディレクトリ運用ではルート相対パスに注意する

フォーム送信後に404になる場合

action属性の指定が間違っている

include・requireのパスミスに注意する

通常は404ではなくPHPエラーや500になりやすい

__DIR__ を使うとパス指定が安定する

パーミッションが原因になるケース

多くの場合は403や500になりやすい

サーバーログを確認する

ログを見ると原因を特定しやすい

アクセスログで実際のURLを確認する

404エラーの切り分け方

Webサーバーが返す404

リライト不備による404

PHPアプリケーションが返す404

404エラーを調査する手順

まずtest.phpを作成して確認する

index.phpに直接アクセスする

静的ファイルにアクセスする

.htaccess を一時的に無効化する

ルーティングを確認する

SEO観点での404エラー対応

URL変更後は301リダイレクトを設定する

すべての404をトップページへ転送しない

カスタム404ページを用意する

404・403・500の違い

404はページが見つからない状態

403はアクセス権限がない状態

500はサーバー内部エラー

502や503にも注意する

症状別の確認ポイント

test.phpも404になる場合

トップページは表示されるが下層ページが404になる場合

Laravelで全ページが404になる場合

WordPressで投稿ページだけ404になる場合

CSS・画像だけ404になる場合

PHPの404エラー対処法まとめ

関連記事

`index.php` が認識されていない

`.htaccess`が原因で404になるケース

`.htaccess` が効いていない

`.htaccess` はNginxでは使えない

`.htaccess` が書き込めない

`DIR` を使うとパス指定が安定する

`.htaccess` を一時的に無効化する