Your homepage loads fine, but click through to any post, page, or category and you get a flat "404 Not Found" instead of your content. Nothing in the WordPress admin looks wrong — the page exists, it's published, the URL looks correct. This is one of the more confusing WordPress errors because the site mostly works, which throws people off the scent. Here's what's actually going on and how to fix it on cPanel hosting.

Symptom: Homepage Works, Everything Else 404s

The pattern is usually consistent: yourdomain.com loads the homepage without issue, but yourdomain.com/about/, yourdomain.com/blog/my-post/, or any URL with "pretty" permalinks returns a 404 page — sometimes WordPress's own 404 template, sometimes a bare server-generated one with no styling at all. If you switch Settings > Permalinks to "Plain" (the ugly ?p=123 style), the pages suddenly load again. That one detail is the biggest clue: it points straight at URL rewriting, not a database or plugin problem.

It usually shows up right after one of these events:

  • Migrating the site to a new host (including a move to SkyServer)
  • Restoring from a backup
  • Switching PHP handlers or upgrading PHP version in cPanel's MultiPHP Manager
  • Installing WordPress in a subdirectory, then moving it to the root domain
  • A security plugin or manual edit that touched .htaccess

Cause: Apache Isn't Rewriting the URLs

WordPress's "pretty" permalinks aren't real file paths. There's no physical folder called /about/ sitting on the server. Instead, Apache's mod_rewrite module reads rules in your site's .htaccess file and silently redirects every request that isn't a real file back to index.php, which then asks WordPress's routing system what to actually show. When that chain breaks, Apache does exactly what a plain web server should do when it can't find a matching file: it returns a 404.

The break happens in one of three places:

  1. The .htaccess file is missing or empty. Very common after a migration or backup restore — a lot of backup tools skip dotfiles by default because they're hidden.
  2. The rewrite rules are wrong or stale. Leftover rules from a subdirectory install, or a caching/security plugin that wrote rules for a different setup, will conflict with WordPress's own block.
  3. mod_rewrite isn't enabled, or AllowOverride is set to None in the server or virtual host config, so Apache ignores .htaccess entirely. This is rarer on shared cPanel hosting since it's enabled by default, but it does turn up on self-managed VPS setups running raw Apache.

Fix: Regenerate and Verify the Rewrite Rules

Work through these in order — most cases are solved by step 1 or 2.

1. Re-save your permalink structure

Log into wp-admin, go to Settings > Permalinks, and click Save Changes without touching anything else. You don't need to change the structure — just re-saving forces WordPress to rewrite .htaccess with a fresh, correct rewrite block. If wp-admin itself is 404ing, skip to step 2 first.

2. Check that .htaccess exists and has the right content

In cPanel's File Manager, navigate to your site's root (usually public_html or public_html/yourdomain.com for addon domains). Make sure "Show Hidden Files" is turned on in Settings — dotfiles don't show by default. If .htaccess is missing, create it and paste in the standard WordPress block:

# 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

If the file already exists but looks off — duplicated blocks, rules pointing at a subdirectory like RewriteBase /blog/ when the site now lives at the root, or content clearly written for a different CMS — back it up (rename it to .htaccess.bak) and let step 1 regenerate a clean one.

3. Confirm file permissions

.htaccess should be 644. Right-click the file in File Manager, choose Permissions, and set it there if it's anything more restrictive (like 600, which some servers block Apache from reading, causing a silent fallback to default routing).

4. Rule out a subdirectory mismatch

If you migrated from a staging URL like yourdomain.com/staging or from a subdirectory install, check Settings > General in wp-admin — the WordPress Address and Site Address fields need to match where the files actually live now, with no trailing subdirectory left over from the old setup.

5. On a VPS: confirm mod_rewrite is actually loaded

If you're on a self-managed VPS rather than shared cPanel hosting, SSH in and check:

apache2ctl -M | grep rewrite

If nothing comes back, enable it and restart Apache:

sudo a2enmod rewrite
sudo systemctl restart apache2

Then check your virtual host config has AllowOverride All for the site's document root, not AllowOverride None — without that, Apache loads but ignores every rule inside .htaccess.

6. Running LiteSpeed instead of Apache?

Most SkyServer cPanel accounts run LiteSpeed, which reads the same .htaccess syntax, so the fix above still applies. If pages still 404 after confirming the file is correct, clear the LiteSpeed cache from LSCache in wp-admin (if the plugin is installed) — a stale cached 404 response can persist even after the underlying rule is fixed.

Prevention: Don't Let This Repeat Next Migration

  • When you back up manually via File Manager or FTP, explicitly confirm dotfiles are included — check the "show hidden files" box before zipping.
  • After any migration, restore, or PHP version change, re-save permalinks as a routine last step, even if the site looks fine.
  • Keep a copy of your working .htaccess somewhere outside the site (a password manager note or a local text file works fine) so you can restore it instantly instead of troubleshooting from scratch.
  • If you use a security or caching plugin that writes its own rewrite rules, check its documentation for how it expects to coexist with the WordPress block — conflicting rule order is a common repeat offender.

Frequently Asked Questions

Why does only the homepage work while every other page 404s?

The homepage is often served directly without needing a rewrite rule, while every other URL depends on mod_rewrite correctly redirecting the request to index.php. When that chain is broken, the homepage survives and everything else doesn't — it's the clearest sign the issue is rewriting, not WordPress itself.

I re-saved permalinks and it still 404s. What next?

Check the actual contents of .htaccess right after saving — if WordPress can't write to the file (wrong ownership or permissions), it'll report success in the admin but the file on disk won't change. Set the file to 644 and confirm the folder itself isn't locked down, then re-save again.

Can I just switch to "Plain" permalinks and stop worrying about it?

You can, and it'll stop the 404s immediately, but you lose clean URLs, which matters for SEO and for any inbound links you've already built. It's a fine temporary workaround while you fix the underlying rewrite issue, not a permanent solution.

Does this happen with Nginx too?

Nginx doesn't read .htaccess at all — rewrite rules live directly in the server block config. If you're on an Nginx-based VPS setup and hitting this, the fix is adding a try_files $uri $uri/ /index.php?$args; directive to your site's config rather than editing any file in public_html.

Could a plugin be causing this instead of .htaccess?

It's possible but less common — usually only if a plugin is filtering the_posts query or overriding WP_Query in a way that breaks routing. Test by renaming your active theme's folder via File Manager to force the default theme, and disable plugins via wp-config.php's WP_PLUGINS_DIR trick or by renaming the plugins folder temporarily. If pages start resolving, it's a plugin or theme conflict, not the server — re-enable one at a time to find it.