Fix 404 Errors on WordPress Posts and Pages

Overview

A 404 error on WordPress posts and pages is one of the most common issues on fresh installs and after server migrations. Your homepage works, but clicking any post, category, or custom page returns “404 Not Found.” The site isn’t broken — WordPress just can’t tell the server how to route those URLs.

The root cause is almost always a corrupted or missing .htaccess file, or a web server that isn’t processing WordPress rewrite rules correctly. This happens after cPanel migrations, server software upgrades, a PHP version change, or when someone accidentally deletes .htaccess while cleaning up files.

This article covers every fix I’ve seen work in practice — from the 30-second permalink flush to manual Apache/Nginx config corrections on a VPS. Start from the top and work down.

Prerequisites

• WordPress admin access (username and password for /wp-admin)
• FTP, SFTP, or File Manager access in cPanel or Plesk — needed if the admin fix doesn’t work
• SSH access if you’re on a VPS or dedicated server and the rewrite module needs enabling
• Know your document root — typically /public_html/ on shared hosting or /var/www/html/ on a VPS
• WordPress 5.x or later (steps are the same; UI labels match current versions as of 2026)

Step-by-Step Instructions

Step 1: Flush WordPress Permalinks

Do this first — it fixes the problem 70% of the time and takes 30 seconds.

1. Log in to your WordPress admin panel at https://yourdomain.com/wp-admin.
2. Go to Settings → Permalinks.
3. Don’t change anything. Just click Save Changes at the bottom.

This forces WordPress to rewrite the .htaccess file with fresh rewrite rules. Load a post — if it works, you’re done.

📝 Note: If the Save Changes button completes but posts still 404, WordPress couldn’t write to .htaccess. That means a permissions problem or a read-only file. Move to Step 2.

Step 2: Check and Fix .htaccess

Navigate to your WordPress root directory using cPanel File Manager, Plesk File Manager, or an SFTP client like FileZilla.

1. Open File Manager in cPanel and navigate to public_html/ (or your WordPress install directory).
2. Make sure hidden files are visible. In cPanel File Manager, click Settings in the top-right and check Show Hidden Files (dotfiles).
3. Look for a file named .htaccess. If it’s missing, you need to create it.
4. Right-click .htaccess and click Edit. Confirm the content matches the standard WordPress block below. If it’s empty, has extra content from a plugin conflict, or is missing entirely, replace it with 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

⚠ Warning: If WordPress is installed in a subdirectory (e.g. yourdomain.com/blog/), the RewriteBase line must reflect that path: RewriteBase /blog/. Using / in a subdirectory install will break things further.

5. Save the file, then check that its permissions are set to 644. Right-click → Change Permissions → enter 644.

📝 Note: Permissions of 444 (read-only) are sometimes set by security plugins like Wordfence or iThemes Security. That’s why Step 1 didn’t write the file. Change it to 644, flush permalinks again, then you can set it back to 444 if your security setup requires it.

Step 3: Verify Apache mod_rewrite Is Enabled (VPS / Dedicated Server)

On shared hosting at Host & Tech, mod_rewrite is enabled by default. If you’re on a VPS or dedicated server managing your own Apache config, it may not be.

1. SSH into your server.
2. Check if the module is active and enable it if not, then restart Apache:

apache2ctl -M | grep rewrite
sudo a2enmod rewrite
sudo systemctl restart apache2

On CentOS/AlmaLinux with Apache (common on cPanel VPS), check /etc/httpd/conf/httpd.conf or the relevant virtual host file and confirm this line is present and not commented out:

LoadModule rewrite_module modules/mod_rewrite.so

Step 4: Check the AllowOverride Directive

This one trips up a lot of people. Even if mod_rewrite is enabled, Apache won’t obey .htaccess files unless AllowOverride is set correctly. This is the non-obvious gotcha that the WordPress codex glosses over.

1. On your server, open the Apache virtual host config for your site, or the main config:

sudo nano /etc/apache2/sites-available/yourdomain.com.conf

Or on cPanel-based servers, check /usr/local/apache/conf/httpd.conf.

2. Find the <Directory> block for your document root. It should look like this — if AllowOverride is set to None, that’s your problem:

<Directory /var/www/html/>
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

3. Change AllowOverride None to AllowOverride All, save, and restart Apache:

sudo systemctl restart apache2

Step 5: Nginx-Specific Fix

If your server uses Nginx (standalone, not as a reverse proxy in front of Apache), .htaccess files are completely ignored. Nginx needs the rewrite rules in its own config block.

1. Open your site’s Nginx server block config, typically at /etc/nginx/sites-available/yourdomain.com.
2. Inside the server {} block, make sure this location block exists:

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

3. Save and reload Nginx:

sudo nginx -t
sudo systemctl reload nginx

📝 Note: If you’re on Host & Tech Managed WordPress Hosting, the Nginx config is managed for you and this won’t be the cause. Open a support ticket instead — something else is going on.

Common Issues and Troubleshooting

Permalinks Save but Posts Still 404

Cause: WordPress saved the settings but couldn’t update .htaccess — either due to file permissions or because the file is owned by a different system user after a server migration.

Fix: Manually replace .htaccess with the standard WordPress block from Step 2. Then verify the file owner via SSH with ls -la /public_html/.htaccess. The owner should match your cPanel username. If it shows root, run sudo chown yourusername:yourusername /public_html/.htaccess.

Only the Homepage Works, All Other Pages Are 404

Cause: This is the classic symptom of mod_rewrite not being active, or AllowOverride None blocking .htaccess entirely. The homepage loads because it hits index.php directly.

Fix: Follow Steps 3 and 4. If you’re on shared hosting and don’t have SSH access, contact support — this is a server configuration issue you can’t fix from cPanel alone.

404 Errors After Moving WordPress to a Subdirectory

Cause: The RewriteBase in .htaccess is still set to / but WordPress is now at /blog/ or another subdirectory.

Fix: Update RewriteBase to match the subdirectory path. Also confirm that the WordPress Address (URL) and Site Address (URL) in Settings → General reflect the correct paths.

404 After Updating Permalink Structure

Cause: Changing from one permalink structure (e.g. ?p=123) to another (e.g. /post-name/) requires the .htaccess file to be rewritten. If the file isn’t writable at that moment, old rules stay in place.

Fix: After changing permalink structure, immediately go back to Settings → Permalinks and click Save Changes a second time. If the file still doesn’t update, replace it manually using the block in Step 2.

Custom Post Types Returning 404

Cause: When a plugin registers a custom post type, WordPress needs to flush rewrite rules to register the new URL patterns. This often gets missed on first activation.

Fix: Go to Settings → Permalinks and click Save Changes — no other changes needed. This is a known quirk: any time you activate a plugin that adds custom post types or taxonomies, you should flush permalinks immediately after.

FAQ