How to Fix WordPress 404 Errors

Quick fix: if the homepage works but every post/page with a readable URL returns 404, open Settings → Permalinks and click Save Changes without changing the structure. If one URL alone fails, check that page’s status, slug, parent and exact published URL instead.

The correct fix depends on the pattern. Do not install a redirect plugin before identifying whether the content exists.

Identify the 404 pattern

Test these URLs:

• homepage;
• /wp-login.php;
• one Page;
• one Post;
• one category archive;
• a plain URL such as /?p=123 for a known post ID.

Interpret the result:

Refresh WordPress rewrite rules

Go to Settings → Permalinks and click Save Changes. Keep the existing permalink option selected unless you intentionally want a URL migration.

With WP-CLI:

wp rewrite flush

Reload a failed page. If this fixes it temporarily but the problem returns, a plugin, deployment or permission problem may be replacing the rules.

Repair .htaccess on Apache or LiteSpeed

WordPress uses .htaccess for pretty permalinks on compatible Apache/LiteSpeed setups. Back up the existing file, then compare its WordPress block with the official rules generated by the Permalinks screen.

If WordPress cannot write the file, correct ownership and permissions according to the host’s documentation, save permalinks again, and restore any necessary security or cache directives carefully.

Do not copy random .htaccess files from another site. Multisite, subdirectory installs and server plugins can require different rules.

Check Nginx configuration

Nginx ignores .htaccess. A standard site configuration normally routes missing files to index.php, but the exact configuration belongs at the server level.

If a migration moved the site to Nginx and pretty URLs began returning 404, ask the administrator or host to inspect the WordPress try_files rule and reload Nginx after validation. Do not paste Apache rewrite directives into Nginx configuration.

Fix one missing page or post

Find it in Pages or Posts, including Trash and Drafts. Confirm:

• it is published;
• the slug matches the requested URL;
• its parent page has not changed;
• password/private status is intentional;
• no other page or taxonomy uses a conflicting path;
• the browser is not following an old bookmark.

Open the editor and copy the actual permalink rather than reconstructing it from the title.

If the content moved, create one direct 301 from the old URL to its closest equivalent. Do not redirect unrelated missing URLs to the homepage.

Fix custom post type 404s

When products, portfolios or another custom post type fail while posts work:

1. resave permalinks once;
2. confirm the responsible plugin is active;
3. check whether its post-type slug conflicts with a Page or taxonomy;
4. review recent changes to register_post_type();
5. flush rules only on activation/deactivation—not on every request.

If code was changed, test the rewrite slug on staging. Renaming it changes every public URL in that content type and requires redirects.

Handle 404s after a migration

Compare the old and new permalink structures. Build a URL mapping from old sitemap, analytics, Search Console, backlinks and server logs.

Redirect at the most reliable layer available and avoid chains:

old URL → final relevant URL

Do not use:

old URL → intermediate URL → newest URL

Preserve query parameters only when the destination uses them. Monitor 404 logs after launch because crawlers and users will reveal URLs missing from the migration list.

Rule out caching and security layers

A CDN or security service can generate its own 404 before WordPress. Compare response headers, bypass the CDN if authorized, and test the origin. Purge a cached 404 after the origin is fixed.

Security plugins may block unusual paths, but do not disable protection globally without evidence. Check their event logs for the exact request.

Verify the repair

Test the canonical URL, trailing-slash behavior, mobile navigation and internal links. Confirm the repaired page returns 200, not a soft-404 page with a success status.

For permanently removed content with no replacement, a helpful real 404 is correct. For content that changed location, use a direct 301 and update internal links to point at the final URL.