Key takeaways
- Click Save Changes under Settings → Permalinks without changing anything. That rebuilds WordPress’s rewrite rules, and after a migration or restore it is usually the whole fix.
- A 404 page in your theme’s design means WordPress got the request. A bare white server error page means the server never handed the request over, so look at the server, not the dashboard.
- Nginx never reads .htaccess. The fix there is a try_files rule in the server block, and on managed hosts like Kinsta that change goes through support.
- Do not switch to a new permalink structure or WooCommerce product base to make 404s go away. Every existing URL changes, and old links break unless you add 301 redirects.
- Redirect plugins cannot repair broken rewriting. Redirection’s own docs say it needs working permalinks before it can run.
The homepage loads. wp-admin works. The editor still shows the post you published. But the link you just sent a customer returns “404 Not Found”, and so does every other post, page and product you try.
That pattern means a routing problem, not missing content. Pretty URLs like /blue-shirt/ only work if two layers agree. WordPress needs a current set of rewrite rules, and the web server has to send each request for a path that is not a real file to WordPress’s index.php. The homepage needs no rewriting, which is why it still works. Your job is to find out which layer broke before you change anything. If the 404 is about one URL that moved, our guide to how WordPress slugs work is the better starting point.
Which 404 are you looking at?
Look at the error page before you touch a setting. If it shows your theme’s header, footer and styling, WordPress received the request and could not match it to content. That points at rewrite rules, the content itself or a plugin. If it is a plain white page that says “404 Not Found” with a server name like nginx at the bottom, the request never reached WordPress. That points at server configuration. WP Engine’s support docs make the same split between a WordPress-themed 404 and a default Nginx 404.
Then check the scope:
- Everything except the homepage fails. Rewrite rules or server routing. Keep reading.
- One URL or a few fail. Open the item in the editor. Check that it is published, not in the trash, and that the slug matches the link. A renamed or deleted page needs a redirect, not a routing repair.
- Only products, a custom post type or account pages fail. Probably a slug collision or a plugin. See the sections below.
One more quick test. Find the post’s ID in the editor’s address bar (post.php?post=123) and visit yoursite.com/?p=123. If that loads while /my-post/ does not, rewriting is broken. If ?p=123 fails as well, the problem is deeper than permalinks, usually theme or plugin code changing the query.
Re-save your permalinks first, without changing anything
Go to Settings → Permalinks and click Save Changes. Do not pick a different option. The WordPress documentation for that screen explains that WordPress regenerates its rewrite rules there. On Apache, if WordPress can write to .htaccess, saving also updates the file.
Test the URL that failed in a private window. If it loads, you are done. This is the standard fix after a migration, a backup restore, a change of host, or installing a plugin that adds its own URL types. Migration plugin vendors put this step at the end of their own checklists for exactly that reason.
For custom post types, WordPress documents a longer variant: switch to the default structure, save, switch back to your real structure, and save again. It is optional. Just make sure you finish on the structure you started with.
Developers with WP-CLI can run wp rewrite list to see whether a rule for the failing URL exists, and wp rewrite flush to rebuild the rules from the command line. Do not put flush_rewrite_rules() on every page load. WordPress’s function reference warns that flushing is expensive, and it does nothing for a server that ignores the rules.
Why saving did not fix it
Saving only rebuilds WordPress’s half of the routing. If the 404s are still there, check these in order. They start with the cheapest to rule out, not with whatever happens to be most common, because nobody has measured how often each cause turns up.
A cache is still serving the old 404
Your fix may have worked while a cache keeps handing out the old error page. Clear your caching plugin, any server cache your host runs (LiteSpeed, Varnish), and your CDN, then test logged out in a private window. WooCommerce’s product 404 documentation warns that cached 404s and testing while logged in can make a working fix look broken.
Apache is not reading the rules
On Apache and LiteSpeed, pretty permalinks depend on three things. WordPress’s Common Errors handbook names an inactive mod_rewrite module as a cause. Apache also ignores .htaccess completely when the directory is set to AllowOverride None. Your host controls both settings, so ask them to confirm both are on.
The third is the file itself. It lives in the WordPress root, next to wp-admin and wp-content. Your file manager may hide it because the name starts with a dot. For a site installed at the domain root, the WordPress block looks like this:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressDownload a copy of the file before you edit it. Many sites keep redirects and security rules in there, and pasting a fresh block over the whole file deletes them. Add or fix the WordPress block only, and keep custom rules above # BEGIN WordPress, as our guide to htaccess 301 redirects explains. Subdirectory installs need a different RewriteBase, so copy the rules WordPress shows you rather than the example above.
If WordPress cannot write the file, the Permalinks screen tells you to update .htaccess yourself and shows the rules to paste. That usually means the file’s ownership is wrong. Setting the file to world-writable (666) is not a fix. Ask your host to correct the ownership.
The server is Nginx, and .htaccess does nothing
Nginx has no per-directory config files. WordPress’s Nginx handbook says WordPress cannot generate Nginx rewrite rules, so no amount of saving in the dashboard will help. Editing .htaccess on an Nginx server is the most common wasted afternoon in this whole topic. A missing .htaccess on Nginx is normal, not a fault.
The handbook’s rule for a single site goes in the server block:
location / {
try_files $uri $uri/ /index.php?$args;
}If a location / block already exists, edit it rather than adding a second one. Run nginx -t before reloading. On managed hosting you probably cannot touch this file. Kinsta’s docs, for example, say its WordPress sites have no .htaccess and that server configuration changes go through support. Send your host the failing URL, what you have already tried, and the exact 404 page you see.
Two things are claiming the same URL
The Common Errors handbook notes that a custom post type and a page with the same name cause 404s. WooCommerce’s permalinks documentation warns against using the same value for the product base and the product category base. Re-saving cannot fix a collision. Rename one of the two, save permalinks again, and add a redirect for whichever URL changed.
A plugin or theme is intercepting the request
Plugins that register their own content types, custom fields or URL rules can break WooCommerce account endpoints, product pages or whole sections of a site. Themes can do it too, which is when even ?p=123 URLs fail. Start with whatever was installed or updated last. Use the Health Check & Troubleshooting plugin’s Troubleshooting Mode, which turns plugins off only for your own session, or use a staging copy. Change one thing at a time, and re-save permalinks after each change. Our guide to troubleshooting plugins that are not working covers the full isolation method.
A migration damaged the data
If someone moved the site by running a raw SQL find-and-replace on the old domain, they may have corrupted serialized data. PHP stores the length of each string inside serialized values, and a replacement that changes the length breaks them. Practitioners report 404s, missing images and plugin errors after this kind of move. Restore from backup and redo the replacement with wp search-replace, starting with --dry-run, or use a migration plugin that handles serialized data.
Why the 404s come back after you re-save
If saving fixes the site for a day or a week and then the 404s return, saving is hiding the problem, not fixing it. Something keeps overwriting the rewrite rules or caching a broken state. In community threads the usual suspects are security plugins that rewrite .htaccess, host-level caching, and plugin interactions nobody pinned down. None of those threads confirmed a single root cause.
To narrow it down, keep a copy of .htaccess from when the site works and compare it with the file the next time the site breaks. If the WordPress block has changed or disappeared, check which plugin writes to that file and look at its settings. If the file has not changed, look at caching. Do not settle for re-saving every few days on a store, where a broken return URL after payment costs you orders.
Do not fix a 404 by changing your URLs
Switching to “Post name” or renaming the WooCommerce product base can make the 404s go away, because WordPress rebuilds the rules along the way. It also changes every established URL. Links already shared, bookmarked and in Google’s index now point at nothing. WooCommerce’s documentation warns that old product links will return 404 unless you redirect them. Re-save the structure you have. Change it only on purpose, with a redirect map ready.
If URLs did change, Google’s site-move guidance asks for permanent server-side redirects from each old URL to its closest new equivalent. Sending everything to the homepage instead can be treated as a soft 404. Our explainer on permanent redirects and SEO walks through the mapping. Remember that a redirect plugin cannot rescue broken rewriting: the Redirection plugin’s installation docs say it needs WordPress permalinks working first.
When to stop and get help
Stop clicking Save and hand the problem over when the host has to change server configuration you cannot reach, when the 404s keep coming back, when a plugin or theme conflict points into custom code, or when a migration may have corrupted the database. Several public support threads in each of these groups never reached a fix, even after the owner had tried a dozen things. Give your host or developer the failing URL, which kind of 404 page appears, whether ?p= URLs work, and what changed just before the problem started.
If you would rather someone else does the diagnosis, SiteSelf can find and fix WordPress errors like this through chat. It needs hosting (SSH) access for server and .htaccess work, and it reports what it changed and what it checked.