Skip to content
Rescue 404
Rescue

WordPress Errors

WordPress Permalinks Not Working (WordPress Repair)

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

WordPress permalinks not working usually means pretty URLs never reach index.php—resave Settings → Permalinks, restore default Apache rewrite rules or the host’s nginx try_files block, then purge caches before rewriting the whole site.

This is WordPress Repair for the classic “homepage works, every other link 404s” failure. Pretty permalinks depend on server rewrite rules and writable configuration; when those break after a migration, host change, or `.htaccess` overwrite, posts and pages look missing even though content still exists in the admin. This guide separates rewrite failures from deleted content and CDN-cached 404s.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • WordPress ships with Plain permalinks by default, which look like example.com/?p=N and work on every server environment. (Using Permalinks)
  • Pretty and Almost Pretty permalinks require the host's web server to be configured for rewrite handling; WordPress tells you to contact the host when that config is missing. (Using Permalinks)
  • Permalink structure is chosen on Settings → Permalinks, including custom structures built from official structure tags like %postname%. (Settings Permalinks Screen)
  • WordPress publishes nginx rewrite guidance separately because nginx does not use Apache .htaccess rules for pretty permalinks. (Nginx (WordPress documentation))

What the error means

WordPress pretty permalinks turn paths like `/about/` into front-controller requests that load `index.php`, which then resolves the slug inside the database. On Apache that typically means `mod_rewrite` plus a WordPress block in `.htaccess`; on nginx it means `try_files` (or equivalent) rules in the server config WordPress cannot always edit from the dashboard. When rewrites are missing, only paths that map to real files—often just the homepage—load, while posts, pages, categories, and `/wp-json/` return 404. That is different from a true missing page (content deleted) and from a full site outage (5xx or DNS failure). Resaving permalinks rewrites rules when the web server allows it; otherwise you must repair `.htaccess` or ask the host to fix nginx.

Common symptoms

  • Homepage loads but posts, pages, or category archives return 404
  • Settings → Permalinks shows a structure other than Plain, yet public pretty URLs fail
  • `?p=123` or Plain permalinks work while `/post-name/` does not
  • Problem started after migration, SSL cutover, security hardening, or editing `.htaccess`
  • wp-admin may work while front-end pretty links 404 (or pretty admin URLs 404 too)
  • REST API routes under `/wp-json/` 404 alongside public posts
  • Custom 404 template appears, proving WordPress is running but the slug was never routed

Most likely causes

  1. 01 Missing, empty, or corrupted WordPress rewrite block in `.htaccess`
  2. 02 Apache `mod_rewrite` disabled, or AllowOverride preventing `.htaccess` rewrites
  3. 03 Nginx host without `try_files $uri $uri/ /index.php?$args` (or host equivalent) for the site
  4. 04 Document root pointing at the wrong directory after a move or addon-domain change
  5. 05 Security, redirection, or “404 to homepage” plugins interfering with rewrite flow
  6. 06 CDN or page cache still serving stored 404 responses after origin rewrites were fixed
  7. 07 Filesystem permissions preventing WordPress from updating `.htaccess` when you click Save

What changed before the problem started

  • Host migration, server rebuild, or change from Apache to nginx
  • Manual `.htaccess` edit, security hardening snippet, or malware cleanup
  • Permalink structure changed in Settings → Permalinks
  • SSL, www, or domain cutover without regenerating rewrites
  • Caching/CDN enabled that stored 404s for pretty URLs
  • File permission change that made `.htaccess` non-writable

Troubleshooting steps

  1. 01

    Confirm pretty URLs 404 while content still exists

    Open a failing post URL and note a real 404 (not 500). In wp-admin, verify the post/page is published with the expected slug. If `?p=ID` works but `/slug/` does not, you have a rewrite problem—not missing content.

  2. 02

    Resave permalinks without changing the structure

    Go to Settings → Permalinks and click Save Changes even if you change nothing. That regenerates rewrite rules when the server allows it. Retest a failing URL in a private window immediately after.

  3. 03

    Restore a default WordPress `.htaccess` on Apache

    Via FTP or File Manager, back up the root `.htaccess`, then restore the standard WordPress rewrite block (or delete a broken file and resave permalinks so WordPress recreates it). Retest pretty URLs before re-adding custom rules one block at a time.

  4. 04

    Check document root and install location

    Confirm the domain’s document root is the folder that contains `wp-config.php` and `wp-content`. After migrations, hosts often leave the vhost aimed at an empty `public_html` or an old subdirectory copy, which looks exactly like broken permalinks.

  5. 05

    Purge page cache and CDN 404s

    Clear WordPress page-cache plugins and purge Cloudflare (or other CDN) for the failing URLs. Edge networks can keep serving a cached 404 after origin rewrites are already fixed.

  6. 06

    Verify `.htaccess` is writable, then resave again

    If Permalinks Save shows a notice that you must update `.htaccess` manually, fix file permissions on the file and parent directory, paste the rules WordPress displays, or ask the host to allow overrides—then save permalinks once more.

When to stop troubleshooting

Escalate when the host uses nginx or locked Apache config you cannot edit, document root ownership is unclear after a migration, ecommerce category URLs stay 404 through revenue hours, or resaving permalinks and restoring `.htaccess` changes nothing. Bring a sample failing URL, proof the post exists in admin, whether `?p=` works, and whether the stack is Apache or nginx.

Information to collect before requesting help

  • 01 Example failing pretty URL and whether the homepage loads
  • 02 Whether Plain or `?p=ID` URLs still work
  • 03 Whether Settings → Permalinks → Save changed anything
  • 04 Apache vs nginx (or unknown) and hosting provider name
  • 05 Recent migration, `.htaccess`, SSL, or CDN changes
  • 06 Screenshot of the 404 page and the Permalinks screen
  • 07 Whether `/wp-json/` also 404s

How a professional repairs the problem

We confirm content exists and isolate rewrite failure from missing posts, regenerate permalinks, restore clean Apache rules or coordinate nginx front-controller config with the host, correct document root mistakes after migrations, and purge caches that stored 404s. The goal is real pretty URLs resolving again—not a permanent switch to Plain permalinks or a blanket redirect of every 404 to the homepage.

Frequently asked questions

Why does the homepage work if permalinks are broken? +
The front page is often served as a physical index file or a simple route that does not need the same rewrite depth. Pretty paths for posts and pages still need the front controller; when rewrites fail, only the homepage survives.
Is this the same as a deleted page? +
No. Deleted or drafted content 404s for that slug only. Broken permalinks typically 404 many published URLs at once while those posts still appear in wp-admin.
Will switching to Plain permalinks fix SEO? +
Plain may restore access for troubleshooting, but it is a poor long-term substitute. Repair rewrites and keep a stable pretty structure; use redirects if you must change URL patterns.
Can Cloudflare cause permalink 404s? +
Cloudflare does not remove WordPress rewrite rules, but it can cache 404 responses. Fix origin rewrites first, then purge the CDN so visitors stop seeing stale misses.
Do I need to change the permalink structure itself? +
Usually no. Saving the existing structure is enough to regenerate rules. Change structures only when you intentionally want new URL patterns—and plan redirects from old paths.
How is this different from a WordPress critical error? +
A critical error means PHP crashed while rendering. Broken permalinks usually return a clean 404 with your theme’s missing-page template. Different layer, different fix.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.