WordPress Permalinks Not Working 404: 7 Real Fixes (2026)

Your homepage loads fine. Every other page throws a 404. If your WordPress permalinks not working 404 problem showed up out of nowhere — after a plugin update, a host move, or a random Tuesday afternoon — take a breath first. Your content isn't gone. The posts still sit in your database exactly where they were. What broke is the small set of rewrite rules that tell your server how to turn a clean URL like /about-us/ into the right WordPress page.

That one detail is why the fix is usually quick. This is a routing problem, not a data-loss problem, and most cases clear in under two minutes.

Our team resolves 20–30 client issues every single day, and this exact error is one of the fastest to close — so this guide is written the way we'd walk a customer through it live: fastest fix first, theory after. On a well-run stack like Hostaccent's, a broken permalink is almost always one setting knocked out of place, not a disaster.

Here's the plan. A 30-second reset that fixes most sites, then six deeper fixes for the stubborn cases, including the Nginx and post-migration scenarios that the quick tutorials skip entirely.

Quick answer: WordPress permalinks return a 404 on every page except the homepage when the server's URL rewrite rules are missing or broken. Fix it fast: go to Settings → Permalinks in wp-admin and click Save Changes (no edits needed) to regenerate the rules. If that fails, repair your .htaccess file on Apache, or add a try_files rule on Nginx. Most sites recover in under two minutes.

What's Actually Happening When Every Page But the Homepage 404s

Your homepage works because it maps straight to index.php — no rewrite required. Every other URL depends on rewrite rules that quietly translate a pretty permalink into a query WordPress understands. Break those rules and the server has no idea where /my-post/ lives, so it returns a 404 Not Found.

A WordPress permalink 404 almost always means the web server can't turn a clean URL into a WordPress query. As of July 2026, the single most common trigger we see is a missing or overwritten .htaccess rewrite block on Apache, or an absent try_files directive on Nginx. The homepage keeps loading because it needs no rewrite; everything else fails at the routing step.

There's a fast way to confirm this is your situation. Call it The Homepage Test: if your homepage loads but posts and pages all 404, the problem is rewrite rules roughly nine times out of ten — not corrupted WordPress core, not a hacked site, not a database issue. That single observation saves you from chasing the wrong fix. If even the homepage is down, that's a different animal (often a 500 server error or a PHP fault), and this guide isn't your first stop.

Pro Tip: Before you touch anything, note whether the 404 hits all inner pages or just one. All pages = rewrite rules. One page = a slug clash, a deleted page, or a stale cache. The scope tells you which fix to reach for.

The Real Causes, Ranked by How Often We See Them

The fix you need depends on the cause, so it helps to know which ones are actually common versus rare. In the tickets we handle, these show up roughly in this order.

Most frequent first: stale rewrite rules after a plugin, theme, or WordPress update flushed them. Next, a missing or corrupted .htaccess file on Apache. Then Apache's rewrite engine being switched off — a classic case of mod_rewrite not enabled on the server. Fourth, an Nginx site with no rewrite rule at all, which is extremely common straight after a migration. Fifth, an .htaccess file that exists but isn't writable, so WordPress can't regenerate it. Last, a plugin or caching layer serving a stale 404.

From the Ticket Queue: According to Hostaccent's support-queue data (July 2026), WordPress issues make up about 30% of the tickets we handle each month, and permalink 404s are among the most frequent inside that bucket. In the cases that reach us, a missing or unwritable .htaccess file is the top culprit by a wide margin — well ahead of anything actually wrong inside WordPress.

Notice what's not on that list: your posts vanishing. They don't. This is why the panic rarely matches the reality. Fix the routing and every page reappears, untouched.

The 7 Real Fixes for WordPress Permalinks Not Working 404

Work these in order. Fix 1 resolves the majority of cases in under a minute, and each fix after it handles a progressively deeper cause. Back up your .htaccess file before editing it — one copy on your desktop is enough insurance to undo any mistake.

Fix 1: Resave your permalinks (the 30-second reset)

Log into wp-admin, go to Settings → Permalinks, and click Save Changes. Change nothing. That click alone flushes and rebuilds WordPress's rewrite rules, and on Apache it rewrites the managed block in your .htaccess. This is the single highest-hit fix for this error — try it first, every time.

If clicking Save shows a warning that .htaccess isn't writable, skip ahead to Fix 6, then come back.

Fix 2: Rebuild the WordPress .htaccess rewrite block (Apache)

If the reset didn't hold, your .htaccess is probably missing or corrupted. It lives in your site's root directory (usually public_html or the folder holding wp-config.php). Open it via your control panel's File Manager or SFTP, and make sure these .htaccess rewrite rules are present between the # BEGIN WordPress and # END WordPress markers (replace the whole block if it looks mangled):

apacheCopy
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Save, then reload a post URL. If the file didn't exist at all, creating it with this block is often the entire fix.

Fix 3: Enable mod_rewrite (Apache)

Apache can't run those rewrite rules if its rewrite module is off. On a self-managed server, turn it on and restart:

bashCopy
## enable Apache's rewrite module, then restart the service
sudo a2enmod rewrite
sudo systemctl restart apache2

If you're on shared hosting, you can't run this — but the module is enabled by default on any competent host, so mod_rewrite not enabled there usually points to a control-panel toggle instead. Check the docs for Apache's mod_rewrite module if you're configuring it by hand.

Fix 4: Set AllowOverride All so .htaccess is even read

Here's the gotcha the beginner tutorials leave out. If your Apache virtual host sets AllowOverride None, Apache flat-out ignores your .htaccess file — your rewrite rules are perfect and still do nothing. In your vhost or directory config:

apacheCopy
<Directory /var/www/html>
    AllowOverride All
    Require all granted
</Directory>

Reload Apache afterward. This one bites people who migrated onto a fresh server with locked-down defaults.

Fix 5: Add the Nginx rewrite rule (Nginx ignores .htaccess entirely)

Nginx doesn't read .htaccess files — full stop. So every .htaccess fix above is irrelevant on an Nginx stack, which is exactly why sites break the moment they move from Apache to Nginx. You add the routing rule directly to the server block:

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

Then test and reload:

bashCopy
## validate config, then apply it with zero downtime
sudo nginx -t && sudo systemctl reload nginx

That try_files line tells Nginx: try the file, try the directory, and if neither exists, hand the request to index.php — which is precisely what makes pretty permalinks work. The Nginx documentation covers the directive in depth if you're tuning a custom setup.

Live site and no time to experiment with server configs? Our engineers fix this exact 404 for a small one-time fee, and you'll see the precise quote before anyone touches a config file — no work starts without your yes. Hosted with Hostaccent already? Then a broken permalink is simply support's job, covered at no charge. Have an engineer fix it

Fix 6: Make .htaccess writable so WordPress can heal itself

If Fix 1 threw a "not writable" warning, WordPress can't rebuild the block on its own. Set sane permissions from your site root:

bashCopy
## 644 lets the server read it and the owner write it — never use 777
chmod 644 .htaccess

Also confirm the file is owned by your web user (often www-data or your cPanel account), not root. After that, run Fix 1 again — the reset should stick this time.

Fix 7: Rule out a plugin, theme, or cache conflict

Still 404ing? Deactivate all plugins, then resave permalinks. If pages return, reactivate one at a time to find the culprit (SEO, redirect, and security plugins are the usual suspects). Switch to a default theme to rule the theme out. Finally, purge every cache — page cache, object cache, and any CDN — because a stale 404 can outlive the actual fix. Custom post types sometimes need a permalink resave to register their own rules too.

Which fix should you try first?

Always start with Fix 1 — it's free, instant, and clears most cases. Apache users who need more go 2 → 3 → 4. Nginx users can skip straight to Fix 5. And if this started right after moving hosts, read the next section before anything else, because migrations have their own signature causes.

Fixing Permalinks 404 After a Migration

Seeing permalinks 404 after migration is the most predictable version of this problem, and it has a short list of specific causes. The biggest one: you moved from Apache to Nginx and your rewrite logic didn't come with you (see Fix 5). But there are quieter culprits too.

Across the 4,000+ sites Hostaccent has migrated, the step people most often get wrong is the hidden files. Many FTP clients skip dotfiles by default, so .htaccess never makes the trip — and the destination server has no rewrite rules to load. Turn on "show hidden files" and verify it copied. Second, file ownership and permissions frequently reset during a transfer, which is why WordPress pages return 404 even when the file is present (loop back to Fix 6). Third, if you changed domains, a hardcoded old URL in the database can misroute everything; a proper serialized search-and-replace, not a raw SQL find-replace, sorts that out.

Insider Insight: After a migration, resave permalinks before you troubleshoot anything else. On a fresh server, WordPress often just needs that one nudge to write correct rules for the new environment — we've watched it turn a "totally broken" site green in a single click more times than we can count. The WordPress documentation is the reference to keep open while you verify the new setup.

If your new host is slow and throwing routing errors, the move itself may have landed you on weaker hardware — worth reading our take on why a WordPress site feels slow and whether shared hosting resource limits are part of the picture.

How to Confirm the Fix and Keep It From Coming Back

Once a post URL loads, confirm the fix properly rather than trusting a single refresh. Open a post in an incognito window (to dodge your browser cache), test two or three different pages, and if you're command-line comfortable, run curl -I https://yourdomain.com/a-post/ and check for a 200 instead of a 404. In Google Search Console, the Pages report will clear the 404 flags over the following crawls.

Prevention comes down to a few habits. Keep .htaccess writable and keep a backup copy so WordPress can self-heal after updates. Don't hand-edit the managed rewrite block unless you have to — let the Settings → Permalinks screen manage it. Test plugin and core updates on a staging copy before pushing them live, since an update flushing your rules is the number-one repeat cause. And keep real backups you've actually restored from, not backups you hope work.

The quick recap:

• Homepage loads but inner pages 404 = rewrite rules, roughly 9 times out of 10.
• Resave permalinks first — it fixes most sites in about 30 seconds.
• Apache: repair .htaccess, enable mod_rewrite, set AllowOverride All.
• Nginx: add the try_files rule; .htaccess does nothing there.
• After a migration, check hidden files, permissions, and the Apache-vs-Nginx switch.

A recurring 404 is often a symptom of a stressed or misconfigured server, so it's worth confirming your hosting isn't the weak link — our guides on high TTFB in WordPress and Core Web Vitals and hosting dig into that.

Your Next Step: The Host Where This Is Support's Job

Now that your WordPress permalinks not working 404 headache is behind you, the honest question is whether you should ever have to touch a rewrite rule again. If you fixed it yourself: nice work — bank the prevention habits above and move on. On a well-managed host, this whole class of problem lands in support's queue, not yours. That's the real pitch: our own engineers answer the line and treat a broken permalink as our job, on a stack (NVMe SSD, tuned Nginx → Apache, 99.9% uptime, 30-day money-back) built so it rarely happens. Start on the Economy shared plan — $1.99/mo, or if you want WordPress-tuned from day one, the WordPress Basic plan — $22.99/yr. Consolidating a move? Grabbing your domain — .com $13.99/yr in the same dashboard means one renewal date instead of three. One honest caveat: Economy is built for single sites — running several client projects? Standard fits better. Still stuck? Open a ticket and we'll quote before we touch a thing. The flat renewal price is the whole point at Hostaccent — what you sign up at is what you pay in year five.

Frequently Asked Questions About Permalink 404 Errors

Why are my WordPress permalinks not working 404 on every page but the homepage?

Because the homepage maps directly to index.php and needs no rewrite, while every other URL depends on rewrite rules to route it. When those rules are missing or broken — a flushed .htaccess, a disabled rewrite engine, or a missing Nginx try_files directive — the server can't locate the requested page and returns a 404. Your content is untouched in the database; only the routing broke. Resaving permalinks in Settings → Permalinks rebuilds the rules and fixes it for most sites in seconds.

How do I fix WordPress pages that return 404 after I change permalinks?

Right after changing your permalink structure, go back to Settings → Permalinks and click Save Changes once more to force WordPress to write fresh rewrite rules. If pages still return 404, your .htaccess may not be writable — check for a warning under the Save button, then set the file to 644 and correct its ownership. On Nginx, the permalink screen can't help; you must add a try_files rule to the server block and reload Nginx for the new structure to work.

Do I need to edit .htaccess to fix permalink 404 errors?

Usually not. The Settings → Permalinks "Save Changes" reset fixes the majority of cases without you opening a single file, because WordPress rewrites the managed block itself. You only edit .htaccess manually when it's missing, corrupted, or not writable — or when you're on a self-managed server and need to enable mod_rewrite or set AllowOverride All. If you're on Nginx, there's no .htaccess to edit at all; the fix lives entirely in the Nginx server block.

Why do permalinks break after migrating to a new host?

Migrations break permalinks for three main reasons. First, moving from Apache to Nginx: your .htaccess rewrite rules simply don't apply on Nginx, which needs its own try_files directive. Second, hidden files — many FTP clients skip .htaccess, so it never reaches the new server. Third, file permissions and ownership often reset during the transfer, leaving the file unwritable. Resave permalinks first on the new server; that alone frequently rebuilds correct rules for the new environment in one click.

How do I fix permalink 404 errors on Nginx?

Nginx ignores .htaccess entirely, so the fix is a server-block rule: location / { try_files $uri $uri/ /index.php?$args; }, followed by nginx -t to validate and a reload to apply it. That directive routes any URL that isn't a real file or folder to index.php, which is what makes pretty permalinks work. We've run this exact pattern on our own Hostaccent stack for years, and on managed hosting it's handled for you automatically — the rule is only your job on a self-managed VPS.

Will resaving permalinks delete my posts or hurt my SEO?

No. Resaving permalinks only regenerates the rewrite rules that route URLs — it never touches your posts, pages, or content, and it doesn't change your URLs unless you deliberately pick a different structure. Your SEO stays intact. The one time SEO is at risk is if you change the permalink structure itself, which alters every URL; in that case you'd add redirects from the old URLs to the new ones. Simply clicking Save on the existing structure is completely safe.

Can a plugin cause WordPress 404 errors?

Yes, fairly often. SEO, redirect, caching, and security plugins can overwrite or interfere with rewrite rules, or serve a cached 404 that outlives the real fix. To test, deactivate all plugins and resave permalinks — if pages return, reactivate them one at a time to find the offender. Also purge every cache layer, including any CDN, after fixing the underlying cause. A single misbehaving plugin editing your .htaccess on activation is a classic source of sudden, site-wide 404s.