WordPress Posts Return 404 Not Found After Changing Permalinks

The home page loads. Every post, page and category returns "Not Found - The requested URL was not found on this server" (Apache) or a bare nginx "404 Not Found." The wp-admin screens may still work. This usually follows a permalink change, a migration, a server change or a plugin that rewrote .htaccess.

WordPress "pretty permalinks" such as /blog/my-post/ do not map to real files. The web server has to hand unknown paths to index.php, and WordPress then looks up the post. If that hand-off is missing, the web server handles the 404 itself and WordPress never runs. The fix is to restore the hand-off.

Tell where the 404 comes from

A WordPress-generated 404 shows your theme's 404 template. A server-generated 404 shows a plain Apache or nginx page. Check with the HTTP स्टेटस चेकर or:

curl -i https://example.com/sample-post/ | head -n 20

Then try the plain-permalink form, which needs no rewriting:

curl -I "https://example.com/?p=123"

If ?p=123 works while /sample-post/ fails, it is a rewrite problem, and the steps below apply. If both give your theme's 404, the content is missing or the permalink structure and post type settings are off.

Fix 1: flush rewrite rules

In the dashboard, go to Settings, Permalinks and click Save Changes. Do not change anything. This regenerates the rewrite rules and, on Apache, tries to rewrite .htaccess. With WP-CLI:

wp rewrite flush --hard
wp rewrite structure '/%postname%/'

If WordPress shows a message that it cannot update .htaccess, it is not writable, or the server ignores it. Continue below.

Fix 2: restore the Apache rules

The default WordPress block in .htaccess is:

<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>

If the file is missing, create it in the WordPress root with that block. Make it writable by the owner so WordPress can maintain it (644 is normal).

Then check that Apache will actually read it:

1. mod_rewrite enabled: sudo a2enmod rewrite on Debian and Ubuntu, then reload Apache.
2. AllowOverride set for the site directory:

<Directory /var/www/html>
    AllowOverride All
</Directory>

With AllowOverride None, .htaccess is ignored, which is the most frequent cause on a new server. Reload with sudo apachectl configtest && sudo systemctl reload apache2. If you see a 403 rather than a 404, read Apache client denied by server configuration.

Fix 3: add the nginx rule

nginx does not read .htaccess. The server block needs a try_files fallback to index.php:

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

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}

Paths and the socket name depend on your distribution and PHP version. Test and reload with sudo nginx -t && sudo systemctl reload nginx. If PHP files themselves fail, see PHP-FPM Primary script unknown. If a location block for static files or a /blog subfolder takes priority, move the try_files line there too.

Fix 4: check for conflicting causes

• Site URL changed. If Settings, General holds an old domain or path, links point to the wrong place. Fix URLs, and see WordPress SSL and HTTPS migration after an HTTPS move.
• A custom post type or taxonomy was added by a plugin or theme that is now inactive. Resave permalinks after activating it.
• Slug conflicts. A page and a category or post type with the same slug can shadow each other.
• Subdirectory install. RewriteBase and the try_files fallback must include the subfolder.
• A plugin rewrites .htaccess (security, caching, redirects). Inspect the file for duplicated or broken blocks, and test by temporarily disabling plugins. See plugin conflict troubleshooting.
• Redirects. If requests bounce first, trace them with the रीडायरेक्ट चेकर.

Emergency workaround

Select "Plain" in Settings, Permalinks. URLs become ?p=123, which needs no rewriting. Use this to regain access, not as a long-term answer, since changing structure alters URLs and affects search engines. If you must change structure, add redirects from old URLs; see HTTP redirects 301 vs 302.

How to verify

Open several posts, a page, a category and a feed URL (/feed/). Each should return 200 in the HTTP स्टेटस चेकर. Add an अपटाइम मॉनिटर for a deep URL, not just the home page, so this class of failure is caught.

अगले कदम

• Read the HTTP 404 reference.
• Check headers with the HTTP Header Checker.
• Run the वेबसाइट हेल्थ चेक.
• Review Updating failed: not a valid JSON response, since broken rewrites also break the REST API.

सामान्य प्रश्न

Why does saving permalinks fix it?

It rewrites the rules WordPress keeps in the database and, on Apache, the .htaccess block. A stale rule set is a common cause after migrations.

Why do wp-admin pages work but posts do not?

Admin files are real files on disk, so they load without rewriting. Posts depend on the rewrite hand-off.

Does this happen on nginx?

Yes, when try_files is missing. Editing .htaccess does nothing on nginx.

Will changing the structure hurt SEO?

It can. Changing the URLs of indexed content without redirects causes 404s and lost rankings.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.