How to Fix the WordPress 404 Error: Permalinks, .htaccess, and Server Checks

Overview

The fastest way to fix a WordPress 404 error is to identify what kind of 404 you are seeing. Not every “page not found” issue is the same, and the correct repair depends on where the break happened.

Start with this simple classification:

• Only one page is 404: the URL may be wrong, the content may be in draft or trash, the slug may have changed, or a redirect may be missing.
• All posts and pages are 404, but the homepage loads: permalink rules or rewrite rules are the most common cause.
• 404 appeared after migration or domain change: site URL settings, rewrite rules, hard-coded links, DNS, SSL, or server config may be involved.
• Custom post types or taxonomy archives are 404: the post type rewrite rules may need to be flushed, or the registration settings may be incomplete.
• Only some users see the 404: CDN, cache, browser cache, or DNS propagation may be masking the current state.

Before changing anything, capture a quick baseline:

1. Test the homepage, one post, one page, one category archive, and one media attachment URL.
2. Note whether the WordPress admin area still works.
3. Check whether the issue started after a plugin update, theme change, migration, permalink edit, SSL setup, or server move.
4. Make a backup of your site files and database before editing configuration files.

Once you know the pattern, move through the repair steps in order. In most cases, the first three checks solve the problem.

Step 1: Re-save permalinks

This is the safest and most common first fix for WordPress permalinks not working.

1. Log in to WordPress admin.
2. Go to Settings > Permalinks.
3. Do not change anything yet. Click Save Changes.
4. Test one affected URL in a new private browser window.

Why this works: saving the permalink settings tells WordPress to regenerate rewrite rules. If those rules were out of sync, this may immediately clear the 404.

Step 2: Check the .htaccess file

If saving permalinks does not help, the next likely cause is a missing or incorrect .htaccess file on Apache or LiteSpeed hosting.

For a standard WordPress installation, the default rewrite block usually 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 WordPress

Key checks:

• The file exists in the WordPress root directory.
• The rules are not duplicated or malformed.
• A migration or security plugin did not overwrite the WordPress block incorrectly.
• There are no old redirect rules sending valid URLs to missing paths.

If the file is missing, you can create it and then re-save permalinks. If it exists, review it carefully before replacing anything custom, especially on sites with manual redirects or security rules.

Step 3: Confirm rewrite support on the server

If the .htaccess file is correct and the problem remains, the server may not be applying rewrite rules.

Typical checks include:

• Apache: confirm mod_rewrite is enabled and the virtual host allows overrides where needed.
• Nginx: WordPress does not use .htaccess; the server block must include correct rewrite handling for try_files.
• Managed hosting: review the host control panel or support docs for rewrite behavior and caching layers.

If you are on Nginx, saving permalinks alone will not fix a missing server rule. The application and the server both need to agree on how friendly URLs are handled.

If you also suspect JavaScript or network errors on the front end, it can help to compare symptoms with this related guide: How to Use Browser DevTools to Troubleshoot CSS, JavaScript, and Network Errors.

Maintenance cycle

The most reliable way to prevent recurring 404 issues is to treat URL health as a maintenance task, not a one-time fix. WordPress sites change often: plugins update, themes change route behavior, hosts migrate accounts, SSL settings are adjusted, and administrators rename or remove content. A lightweight review cycle catches problems before users do.

Use this practical maintenance cycle:

Weekly or after any release

• Open a few key URLs manually: homepage, blog index, one post, one page, one category, and one form or landing page.
• Check that recent content uses the expected permalink structure.
• Review whether any plugin related to redirects, SEO, caching, or security was updated.

Monthly

• Review 404 entries in your analytics, SEO tool, or server logs if available.
• Check whether deleted or renamed pages need redirects.
• Verify that custom post types and taxonomy archives still resolve correctly.
• Retest after major plugin or theme updates.

Quarterly

• Audit the .htaccess file or Nginx config for old rules left by migrations, staging pushes, or retired plugins.
• Confirm WordPress Address and Site Address values are still correct.
• Review canonical redirects between HTTP/HTTPS and www/non-www.
• Validate that your SSL setup and redirect chain still behave as expected. If needed, use this companion guide: How to Set Up SSL Certificates: HTTPS Installation and Common Fixes.

This recurring process is especially useful on sites with multiple admins, frequent content updates, or staging-to-production deployments. The more moving parts a site has, the more likely rewrite and URL rules are to drift over time.

A simple 404 maintenance checklist

• Backup completed before config changes
• Permalinks re-saved after structure changes
• .htaccess or Nginx rules reviewed after migration
• Redirect plugin rules tested after content cleanup
• 404 logs reviewed and high-value URLs redirected
• Canonical domain and HTTPS rules verified
• Cache cleared at plugin, server, and CDN layers

For launch or relaunch work, it is also worth pairing this with a broader validation pass: Website Launch Checklist: Everything to Test Before You Go Live.

Signals that require updates

You do not need to wait for a full outage before revisiting your 404 troubleshooting process. Certain changes are strong signals that your site should be checked immediately.

After a migration

A 404 after migration in WordPress is common because several layers can change at once: file paths, database URLs, web server rules, DNS, SSL, and caching. If the problem started after moving hosts or domains, review these in order:

1. Confirm the site files and database both came from the same backup set.
2. Check Settings > General for the correct WordPress Address and Site Address.
3. Re-save permalinks.
4. Inspect .htaccess or Nginx config on the new server.
5. Clear plugin cache, server cache, and CDN cache.
6. Check hard-coded internal links or serialized URL replacements if the domain changed.
7. Confirm DNS now points to the new host.

For migration planning and reduced downtime, this internal guide is useful: Step-by-Step Guide to Migrating a WordPress Site to a New Host with Zero Downtime.

After changing permalink structure

If you switch from plain URLs to post name, or change category bases, old links may break unless redirects are added. Re-saving permalinks helps WordPress understand the new structure, but it does not automatically preserve every old URL pattern. High-value pages should get explicit redirects.

After installing redirect, SEO, security, or cache plugins

These plugin categories often touch URLs directly or indirectly. Look for:

• Unexpected trailing slash behavior
• Forced redirects that loop or point to removed pages
• Blocked requests caused by security rules
• Cached 404 responses that persist after the actual fix

After enabling SSL or changing domain preference

A mixed setup—such as WordPress expecting HTTPS while the server still serves some routes over HTTP—can create confusing behavior. Users may report a 404 when the root issue is actually redirect logic. If the site was recently moved to HTTPS, confirm your protocol and host redirects are consistent.

If you recently changed DNS or domain records, it is worth checking propagation timing and record consistency with these guides: DNS Propagation Checker Guide: How Long DNS Changes Take and What to Do While Waiting and How to Point a Domain to Your Website: DNS Records Explained for Beginners.

After registering custom post types or taxonomies

Developers often see 404 errors on custom routes after adding or changing post type code. In many cases, the route exists in code but rewrite rules have not been refreshed. Re-saving permalinks is the standard first step. Also confirm:

• public is set as intended
• rewrite is enabled or configured correctly
• Slugs do not conflict with existing pages or reserved paths
• Archive settings match your expected URLs

Common issues

This section gives you a cause-based repair list for the most frequent WordPress page not found scenarios.

1. Homepage works, internal pages 404

This pattern usually points to permalink or rewrite problems.

Try:

• Re-save permalink settings
• Review .htaccess contents
• Confirm Apache mod_rewrite or Nginx rewrite handling
• Clear all caches

2. Only one specific page or post returns 404

This is more often a content or slug issue than a server issue.

Check:

• Whether the content is published
• Whether the slug changed
• Whether the page is in trash
• Whether a parent page slug changed in a nested URL
• Whether a redirect should exist from the old URL

3. 404 on category, tag, author, or custom archive pages

Archive routes can break after plugin changes, theme changes, or permalink adjustments.

Check:

• Permalink settings
• Category base or tag base changes
• SEO or redirect plugin archive settings
• Theme code disabling archives unintentionally

4. 404 on media files or uploads

If uploaded files return 404, the issue may sit outside WordPress routing.

Check:

• Whether the file exists in the uploads directory
• File permissions
• Hotlink protection rules
• CDN origin settings
• Incorrect upload path configuration

5. 404 only after cache purge or only for some users

This often points to multiple cache layers or DNS inconsistency.

Check:

• Browser cache
• WordPress cache plugin
• Server cache
• CDN cache
• DNS propagation after a host move

If the domain or records were recently changed, also review: Troubleshooting Common DNS and Domain Issues: A Practical Checklist for IT Admins.

6. 404 after theme or plugin activation

Deactivate the most recent change first. Then test again.

A practical isolation method:

1. Deactivate the newest plugin involved with URLs, redirects, caching, or custom content.
2. Re-save permalinks.
3. Retest affected URLs.
4. If still broken, switch temporarily to a default theme on a staging copy if possible.
5. Review plugin or theme code that registers post types, endpoints, or rewrites.

If the admin becomes inaccessible or the site fails more broadly, you may also need a recovery path like this: WordPress White Screen of Death Fix Guide: Causes, Recovery Steps, and Prevention.

7. 404 caused by incorrect site URLs

If WordPress Address or Site Address is wrong, WordPress may build links to the wrong location.

Review:

• Settings > General values
• Any WP_HOME or WP_SITEURL constants in wp-config.php
• Search-and-replace changes performed during migration

Be careful not to mix protocols or subdomains unintentionally.

8. 404 from deleted content with no redirect plan

Not every 404 is a technical failure. Sometimes the page really is gone. In that case, the correct fix is not rewriting rules but redirect management.

Use a redirect when:

• The old URL has backlinks
• The page still gets meaningful traffic
• A close replacement exists

Leave as 404 or 410 when:

• The content is intentionally retired
• No suitable replacement exists
• You do not want to route users to a loosely related page

The goal is not to eliminate every 404 response. The goal is to fix the accidental ones and manage the intentional ones cleanly.

When to revisit

Use this section as your action plan. WordPress 404 troubleshooting should be revisited on a schedule and whenever the site changes in ways that affect URLs.

Revisit immediately when:

• You change hosts, domains, DNS, or SSL settings
• You edit permalink structure
• You launch a redesign or new theme
• You activate plugins that manage redirects, SEO, security, caching, or custom post types
• You restore from backup or push from staging to production

Revisit on a routine cycle when:

• Your team publishes often and renames pages
• Your site has many landing pages or custom content types
• You rely on search traffic and want to catch broken URLs early
• You maintain multiple environments and regular deployments

A repeatable 10-minute WordPress 404 review

1. Open five representative URLs and confirm they load.
2. Check permalink settings and save only if you recently changed routes or content structures.
3. Review recent plugin, theme, and server changes.
4. Inspect 404 logs or analytics for repeated missing URLs.
5. Add redirects for high-value retired pages.
6. Clear relevant caches and retest in a private browser window.
7. Document what changed so the next fix is faster.

This last step matters more than it seems. Many recurring 404 incidents happen because the previous cause was fixed but never documented. A short internal note covering the date, trigger, affected URLs, and resolution can save real time during the next outage. Teams that maintain several WordPress properties may even want a reusable troubleshooting runbook alongside broader platform documentation.

If you want one practical rule to remember, use this: when the homepage works and inner pages do not, test permalinks and rewrite rules first. Then move outward to server config, migrations, caching, DNS, and redirects. That order solves the largest share of WordPress 404 cases without unnecessary changes.

Keep this guide bookmarked and return to it after every migration, structural URL change, or major plugin update. The problem is common, but the fix is usually methodical rather than complicated.