This article is a localized edition of the Japanese original. Read the Japanese original
When only a specific page or post returns "Page not found" (404) rather than the whole site, the cause is almost always that page's settings or something else that shares its URL. This article explains how to track down the cause, starting with the easiest checks. It was checked against the WordPress source code and developer.wordpress.org as of November 2026.
If every post and page returns 404, the permalink or .htaccess settings are broken for the whole site. In that case, see Fixing 404 errors after a site migration.
1. Check the page’s status
Look at the page's status in the "Pages" list in the admin ("Posts" for a post).
| Status | What logged-out visitors see |
|---|---|
| Published | The page |
| Draft / Pending Review | 404 |
| Scheduled (publish date in the future) | 404 until the publish date |
| Private | 404 (logged-in editors and administrators can see it) |
| Trash | 404 |
| Password protected | A password form (not a 404) |
If you check while logged in as an administrator, even private pages are displayed. Check for the 404 while logged out or in a private browser window.
If you have WP-CLI, you can look up the status by slug:
wp post list --post_type=page,post --name=your-slug --post_status=any --fields=ID,post_type,post_status,post_name,post_parent2. Check that the URL matches the slug
In the page's editor, check the actual URL (permalink) in the settings panel on the right ("Page"), and compare it character by character with the URL you are trying to open.
Common mismatches:
- The slug was changed: Changing the slug changes the URL. Links and bookmarks to the old URL return 404.
- A parent page was set or changed: When a page has a parent, its URL becomes
/parent-slug/child-slug/. Changing the parent's slug also changes the URLs of all its child pages. - Japanese slugs: A slug generated automatically from a Japanese title becomes a long encoded string in the URL. Make sure the link was not cut off when it was copied.
For posts (entries under "Posts"), changing the slug after publishing records the old slug, and the old URL redirects to the new one automatically. Hierarchical post types such as pages don't have this, so when you change a page's slug you need to set up a redirect from the old URL yourself.
3. Check for a folder or file with the same name
With WordPress's standard .htaccess, if a file or folder with the same name as the URL actually exists on the server, the server returns it without going through 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 WordPressOnly requests that match !-f (no such file) and !-d (no such folder) are passed to WordPress. For example, if you create a page at /campaign/ but an old folder named campaign is still in the WordPress folder on the server, the contents of that folder (or a 403 or 404) are returned instead. Use FTP or the file manager to check for a folder with the same name as the page's slug, and rename or delete it if it is no longer needed.
On Nginx, try_files $uri $uri/ /index.php?$args; in the configuration does the same job. The basics of .htaccess are covered in WordPress .htaccess settings.
4. Rebuild the permalinks (rewrite rules)
If only custom post type pages or pages added by a plugin return 404, the URL map that WordPress keeps (the rewrite rules) may be out of date.
Open "Settings" → "Permalinks" in the admin and click "Save Changes" without changing anything. This rebuilds the rewrite rules.
With WP-CLI, use the following command. Adding --hard also rewrites Apache's .htaccess.
wp rewrite flush --hardTo see which rule the problem URL matches, run:
wp rewrite list --match=/path-of-the-problem-url/If nothing is shown, no rule matches that URL. Check that the plugin or theme that registers the custom post type is active, and that the post type's slug (the slug in rewrite) matches the URL. Working with rewrite rules in WP-CLI is covered in Managing rewrite rules with WP-CLI.
5. Check redirect and security plugins
Plugins like the following can redirect specific URLs or return a 404:
- Redirect management plugins (the redirect target is a page that doesn't exist)
- Security plugins (blocking access to specific paths)
- Multilingual plugins (URL settings per language)
- Membership and access restriction plugins
If you use a redirect plugin, check whether the problem URL is in its list. If you can't tell which plugin is the cause, deactivate them one at a time on a staging site.
6. Clear caches
If someone visited the URL before the page was published, that 404 may still be cached. Clear the caches in this order, then check in a private window:
- Your caching plugin's cache
- The server cache (for example, a feature in your hosting control panel)
- The CDN cache (if you use Cloudflare or similar)
If it still isn’t fixed
Check the server's access log to see what is returned for requests to the problem URL. Where to look next depends on whether the 404 comes from WordPress or directly from the server.
- Your theme's 404 page is shown: WordPress received the URL but could not find a matching page. Check steps 1, 2, 4 and 5.
- A plain server error page is shown: The request is stopped before it reaches WordPress. Check step 3 and the server configuration (other rules in
.htaccess, the Nginx configuration).
Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)