How to Fix 404 Errors in Nginx

A 404 Not Found error means Nginx looked for the requested resource and could not find it. The cause is almost always one of three things: the file genuinely does not exist, Nginx is looking in the wrong place, or a rewrite rule is not configured correctly. For WordPress sites specifically, the most common cause is a permalink configuration issue.

How Nginx serves files

When a request comes in, Nginx evaluates it against the server block and location blocks in its configuration. For a standard WordPress site, the critical directive is try_files:

nginx

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

This tells Nginx to try the following in order:

1. Look for an exact file match at the requested URI
2. Look for a directory match at the requested URI
3. If neither exists, pass the request to index.php with the original query string

Step 3 is what makes WordPress pretty permalinks work. A URL like /blog/my-post/ does not correspond to an actual file or directory on disk. Nginx tries the file, tries the directory, finds neither, and hands the request to WordPress via index.php. WordPress then parses the URL and serves the correct content.

If try_files is missing or misconfigured, every request for a WordPress post or page returns a 404 because the file does not exist on disk and Nginx does not know to fall back to index.php.

WordPress permalink 404s

This is the most common 404 scenario on WordPress hosting. You set up a site, visit a post, and get a 404. The WordPress dashboard is accessible but all front-end URLs return 404.

The cause is almost always that the Nginx try_files directive is not passing requests to index.php correctly. On managed hosting this is handled automatically, but if you are configuring Nginx yourself, this is the first thing to check.

The fix on the WordPress side: go to Settings > Permalinks in the WordPress admin and click Save Changes without changing anything. This flushes WordPress’s rewrite rules. If the issue is in WordPress’s internal routing rather than Nginx configuration, this often resolves it.

If that does not fix it, the issue is in the Nginx configuration itself. The try_files directive needs to be present in the location block serving your WordPress site.

404 after moving or renaming content

If a URL that previously worked now returns a 404, the content was moved, renamed, or deleted. Common causes:

• A post or page was deleted or moved to draft
• The post slug was changed
• The site URL was changed in WordPress settings
• A category or tag structure was modified
• A plugin that generated URLs was deactivated

For moved or renamed content, set up a 301 redirect from the old URL to the new one. This preserves any SEO value the old URL had and sends visitors to the correct location. On Hostney, redirects are managed under Hosting > Redirects (301/302) in the control panel.

404 for static files

If images, CSS, JavaScript, or other static files are returning 404, the file either does not exist at the path Nginx is looking for, or the document root is configured incorrectly.

Check the following:

File path: Confirm the file exists on disk at the path being requested. A request for /wp-content/uploads/2026/03/image.jpg should correspond to a file at that path relative to your document root.

Document root: If the document root in the Nginx configuration points to the wrong directory, all file lookups will fail. On shared hosting this is managed by the platform, but on self-managed servers this is worth verifying.

Upload permissions: If files uploaded through WordPress are returning 404, check that the upload directory exists and that PHP has write permissions to it. A missing wp-content/uploads directory will cause all media uploads to fail silently and return 404 when accessed.

WordPress file URL settings: Check Settings > Media in the WordPress admin to confirm the upload path is correct. If it has been manually set to a non-standard path, files may be stored in a location Nginx is not serving.

404 after migrating a site

Migrations commonly produce 404 errors because the WordPress site URL settings do not match the new domain or directory structure. WordPress stores the site URL in the database and uses it to construct all internal links.

After migrating, if the site URL in the database still points to the old domain or path, all links will be wrong and most requests will 404.

Fix by updating the site URL in wp-config.php:

php

define( 'WP_HOME', 'https://yournewdomain.com' );
define( 'WP_SITEURL', 'https://yournewdomain.com' );

Or update it directly in the database:

sql

UPDATE wp_options SET option_value = 'https://yournewdomain.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://yournewdomain.com' WHERE option_name = 'home';

Or use WP-CLI, which is the cleanest approach:

bash

wp option update siteurl 'https://yournewdomain.com'
wp option update home 'https://yournewdomain.com'

After updating the site URL, run a search and replace on the database to update any hardcoded URLs in post content:

bash

wp search-replace 'https://olddomain.com' 'https://yournewdomain.com' --skip-columns=guid

404 for WordPress admin pages

If wp-admin or wp-login.php is returning 404, the WordPress core files may be missing or the document root is pointing to the wrong location. Verify that the WordPress core files exist in the directory Nginx is serving from.

If the files exist but wp-admin still 404s, check whether a security plugin or server-level rule is blocking access to wp-admin from your IP. Some security configurations restrict wp-admin access to whitelisted IPs.

404 for plugin or theme assets

Plugins and themes load assets from their own directories within wp-content. If these are returning 404, the plugin or theme files may not have been uploaded correctly, or the wp-content directory path may be non-standard.

A complete WordPress installation should have wp-content/plugins, wp-content/themes, and wp-content/uploads all present and accessible. If any of these directories are missing or empty after a migration, the corresponding assets will 404.

Reading the Nginx error log

When diagnosing 404s, the Nginx error log is more useful than the access log. The error log shows the full file path Nginx attempted to find, which tells you exactly where it is looking and whether the document root is correct.

A 404 entry in the error log looks like:

2026/03/14 10:23:41 [error] 12345#0: *1 open() "/var/www/example.com/public_html/blog/my-post" failed (2: No such file or directory)

The path shown is where Nginx looked for the file. If this path is wrong, the document root configuration needs to be corrected.

On Hostney, error logs are available under Logs & statistics > Error Log in the control panel.

404 vs other errors

A 404 means the resource was not found. It is worth distinguishing from related errors:

• 403 Forbidden – the file exists but Nginx does not have permission to read it, or access is blocked by a security rule
• 500 Internal Server Error – a PHP error occurred while processing the request
• 301/302 – the resource has been permanently or temporarily moved, and the redirect destination is what should be checked if the final URL is 404ing

If you expect a URL to work but are getting 404, confirm it is actually a 404 and not one of the above by checking the HTTP status code in your browser’s developer tools under the Network tab.

Summary

404 errors in Nginx on WordPress sites are most commonly caused by a missing or incorrect try_files directive that prevents requests from being passed to index.php, moved or deleted content without a redirect in place, or a site URL mismatch after migration. Check the Nginx error log to see the exact file path Nginx attempted to resolve, which points directly at the configuration or file system issue causing the 404.