How to Fix WordPress 404 Errors After Changing Permalinks

Fixing Broken WordPress Permalinks Without Losing Search Traffic

Changing a WordPress permalink structure can make URLs cleaner, but it also changes how requests reach your content. A post that previously loaded at /2026/11/example-post/ might now live at /example-post/. If your server does not route the new address correctly, visitors see a 404. If an old bookmark or Google result has no redirect, that old address may also return a 404 even though the post still exists.

The solution is not to install more plugins or repeatedly change URL settings. Identify which URLs fail, refresh the WordPress rewrite rules, check the correct server configuration, and preserve your existing search traffic with accurate redirects. Follow the steps below in order, especially on a live site with indexed pages.

First, Identify Which URLs Are Returning 404

Test your homepage, a recently published post, an older post, a category archive, and one URL from before the change. Open each in a private browser window. Do not assume every 404 has the same cause.

Important: A real HTTP 404 status is different from a page that displays “not found” while returning 200. Use a status-code checker or inspect the browser’s Network tab when the result is unclear.

Step 1: Refresh Permalink Rewrite Rules

1. Sign in to the WordPress administration dashboard.
2. Open Settings > Permalinks.
3. Confirm the permalink structure is the one you intend to use. Do not switch structures merely to troubleshoot.
4. Click Save Changes. WordPress also refreshes its rewrite rules when the Permalinks screen is visited, but saving provides a familiar confirmation step.
5. Open a failing post in a new tab and test its newly generated permalink.

WordPress stores rewrite rules that translate readable URLs into internal requests. Refreshing these rules can resolve a mismatch after changing settings, activating a plugin, or registering a custom post type. If posts still fail, investigate the server rather than repeatedly saving the same settings.

Step 2: Repair Apache .htaccess Rules Safely

On an Apache installation that uses per-directory rewrite rules, WordPress typically stores its permalink instructions in a hidden file named .htaccess. An outdated or unwritable file can prevent the new URL structure from working.

1. Create a backup of the current .htaccess file and confirm you can restore it.
2. Open the site root through your hosting file manager or SFTP. Enable the display of hidden files.
3. Look for the WordPress-managed rule block. Check whether WordPress reported that the file was not writable after saving permalinks.
4. Compare the rules with the code WordPress provides on the Permalinks screen or in its official server documentation.
5. If correction is required, preserve unrelated security, redirect, and application rules. Test the site immediately after changing the file.

For a standard single-site WordPress installation in the domain root on Apache, the core rewrite block commonly looks like this:

# 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

Do not paste this block blindly. Subdirectory installations, Multisite networks, proxy configurations, and custom server setups can need different rules. Do not replace the entire file or remove existing redirects. If you are unsure, ask your host to review the rewrite configuration.

If the file looks correct but every readable URL still fails, your host should confirm that Apache’s mod_rewrite module is enabled and the applicable virtual-host configuration permits the necessary overrides. Changing file permissions to 777 is not a safe fix.

Step 3: Use the Correct Fix for Nginx

Nginx does not read Apache .htaccess files. If your WordPress site uses Nginx, editing that file will not repair permalink routing. The relevant rules belong in the Nginx server configuration.

A common WordPress routing pattern is:

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

This directs requests for paths that are not actual files or directories to WordPress. It is an example, not a complete production configuration. Existing location blocks, subdirectory installations, reverse proxies, and security rules can change where it belongs.

If you manage the server, review the active virtual host, test configuration syntax using nginx -t, and reload Nginx only after the test passes. On managed hosting, ask support to verify WordPress permalink routing instead of editing configuration files you do not control.

Step 4: Redirect the Old Permalinks to the New Ones

Refreshing rewrite rules makes the new addresses work. It does not automatically guarantee that every old address reaches the replacement. If you changed the URL structure on an established website, redirects are part of the migration.

For example, a post might move from:

Old: https://example.com/2026/11/wordpress-guide/
New: https://example.com/wordpress-guide/

Visitors and search engines requesting the old address should receive a 301 permanent redirect to the exact new address. A 308 permanent redirect can also be appropriate, but 301 is widely used for normal webpage migrations.

1. Export or collect the old URLs from a previous sitemap, crawl, analytics records, or your redirect log.
2. Match each old URL with its corresponding live new URL.
3. Create the redirects through your server configuration or a suitable WordPress redirect manager.
4. Test the response of both the old address and its destination. The destination must load successfully.
5. Check for redirect loops, long chains, and pages sent to unrelated destinations.

Do not redirect every missing article to the homepage. Google may interpret irrelevant redirects as soft 404s. For content that has genuinely been removed and has no appropriate replacement, a true 404 or 410 can be correct.

Step 5: Check Posts, Custom Post Types, and Plugin Conflicts

When only individual URLs fail, check the content rather than treating it as a site-wide routing failure. Open the editor and confirm that the post is published, the slug is correct, and the current permalink matches what you are testing.

For a custom post type such as products, listings, or documentation, review the plugin that registers it. Conflicts can arise when a page, taxonomy, and post type claim the same URL base. A plugin may also change rewrite rules when activated or updated. After correcting the registration or naming conflict, refresh the rewrite rules once.

If the issue started after a plugin or theme change, test in a staging environment or use an isolated troubleshooting mode. Avoid switching off critical plugins on a busy live store merely to experiment.

Step 6: Rule Out Cache and CDN Problems

After fixing the underlying cause, an old 404 response can remain in a page cache, reverse proxy, or CDN. Purge the affected URLs and retest in a private window. If your site has multiple web servers, make sure every node uses the same routing configuration.

Cache clearing is a verification step, not a substitute for fixing broken WordPress or server rules. If a request continues to return 404 at the origin, deleting cached copies will not solve the underlying problem.

Advanced Option: Refresh Rules with WP-CLI

If you have authorized command-line access and the WordPress dashboard is unavailable, WP-CLI provides a way to regenerate rewrite rules:

wp rewrite flush

Run the command from the correct WordPress installation. The --hard option can update Apache .htaccess rules on supported single-site installations, so use it only after backing up any custom rules. On Multisite, identify the intended site and review the command’s supported options. Do not call rewrite-flush functions on every page load; regeneration is relatively expensive.

How to Verify the Fix and Protect SEO

A post loading in your browser is necessary, but it is not the only test. Check the HTTP response and the signals you send to search engines:

• New live URL: It should return 200 and display the intended content.
• Old replaced URL: It should redirect permanently to the correct new page, preferably in one hop.
• Internal links: Update menus, articles, related posts, and important navigation links to point directly to current URLs.
• Canonical tags: Make the intended indexable page reference its current canonical URL.
• XML sitemap: Submit a sitemap containing the final live URLs, not outdated redirects.
• Google Search Console: Review indexing and 404 reports, inspect representative URLs, and monitor the transition.

Google recommends preserving permanent redirects for at least a year during URL migrations; keeping useful old-to-new redirects indefinitely is often better for visitors and external links. Rankings can fluctuate while search engines recrawl and process the new addresses. Redirects, accurate canonicals, and updated internal links reduce avoidable problems but do not guarantee unchanged rankings.

Frequently Asked Questions

Why does the homepage work while every WordPress post shows 404?

The homepage can load directly while readable post URLs depend on rewrite rules. Refresh the permalink settings, then check the appropriate Apache or Nginx routing configuration if the problem remains.

Will saving permalinks change the addresses again?

Not if you leave the selected permalink structure unchanged. Saving can regenerate routing rules without choosing a different URL format.

Can changing WordPress permalinks hurt SEO?

It can if indexed URLs begin returning 404 or redirect to irrelevant pages. Preserve old-to-new mappings, update internal links and sitemaps, and monitor Search Console after the change.

Is .htaccess always the cause of WordPress permalink 404s?

No. .htaccess matters for applicable Apache configurations. Nginx uses its own server rules, and isolated errors can be caused by slugs, custom post type conflicts, or missing redirects.

Should every 404 be redirected to the homepage?

No. Redirect only when there is a genuinely relevant replacement. If a page was permanently removed without one, an accurate 404 or 410 response is appropriate.

Final Troubleshooting Checklist

1. Confirm whether the old URL, new URL, or both fail.
2. Refresh rewrite rules in Settings > Permalinks.
3. Inspect Apache .htaccess or Nginx routing, whichever actually applies.
4. Resolve isolated slug and custom post type conflicts.
5. Map changed URLs and put permanent redirects in place.
6. Clear stale caches, test HTTP responses, and review indexing signals.

So the first restore access to the new WordPress URLs. Then preserve access from the old ones. Treating those as separate tasks makes permalink 404 problems easier to diagnose and prevents a small configuration change from becoming a larger SEO migration issue.