WordPress all pages not found except home page

WordPress all pages not found except the home page. It’s one of our more common drivers of support related to WordPress hosting. This post covers what you’ll see when your WordPress website has this problem, how to fix the all pages not found except home page problem, and an explanation about how the fix works, and how the problem came about in the first place.

If your website is affected by this problem, what you’ll see is your website’s home page working OK, and your wp-admin working OK, but all other pages will show a not found or 404 error. The 404 error code means, page not found, so 404 and “not found” are pretty much the same thing.

You’ll need access to your hosting to fix this problem, as you’re going to have to manually modify one of your websites files. You’d typically access this by clicking on an icon labelled “File Manager” (or equivalent if you’re not using cPanel):

You then need to navigate to your domain’s document root. This is the directory (or folder) that your website’s domain is mapped to. If you’re using single site hosting, and are using cPanel this directory (or folder) will be called public_html:

If you have a multi domain account, domains can have their own uniquely named folder (in cPanel the “domains” section shows which domains are mapped to which folders). If you’re using a hosting platform other than cPanel, the document root of your domain might be called htdocs or httpdocs.

What you’ll see in the domains’ document root is your WordPress installation at file level. You’ll usually see a lot of files and directories that start with wp (as in WordPress):

In amongst these files is one called .htaccess. This is the file we need to modify to fix the WordPress all pages not found except home page problem. If you don’t see the .htaccess file it may be because hidden files aren’t being displayed. TO display hidden files click on Settings (toward the top right):

Then click “Show Hidden Files (dotfiles)” (1) then click save (2):

You should now be able to see the .htaccess file.

Right click on the .htaccess file and click “edit”:

You’ll then need to add these rules to the .htaccess file:

# 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

Then save the changes.

If you see any lines that start with:

php — BEGIN cPanel-generated handler, do not edit

You should add the rules above directly above this line, and below any other text, should there be any:

You should then find that the pages of your WordPress website then load as expected, and you’ve solved the WordPress all pages not found except home page problem.

It would be STRONGLY ADVISABLE to log in to your WordPress and save caching plugin options, and security plugin options after carrying out the above. You are using a security plugin, right?

Both caching plugins and security plugins can also write to .htaccess.

If caching plugin rules are missing from your site’s .htaccess file, this can negatively affect the performance of your website. Resaving the caching plugin options usually causes the caching plugin rules to be re-added to the .htaccess file, and eliminate potential performance issues.

If security plugin rules are missing from .htaccess your site is potentially lacking the protection that a security plugin provides. Resaving security plugin options usually causes the security plugin rules to be re-added to the .htaccess file, and re-implement security directives.

If you’re happy with that, you can stop reading now if you like, although the explanation that follows will help you gain an understanding of how WordPress, and web hosting functions.

The .htaccess file is a bit like a link between the web server and the web application. These files can be used to instruct the web server with regard to how pages should be loaded (if compression should be used, for example), if they should load, or if they should redirect.

The .htaccess file can be used to do quite a lot, such as:

• IP blocking / whitelisting
• Basic Password protection
• Directory browsing control
• Prevent access to specific files
• URL Rewriting and Redirection
• Force HTTPS
• Redirect old URLs to new ones
• Canonical redirect (non-www to www or vice versa)
• Enable GZIP compression
• Set cache expiration headers

In the context of this article and the WordPress rewrite rules, the one we’re interested in is “URL Rewriting and Redirection”. This is what the WordPress rules above do.

The WordPress rules mentioned above are rewrite rules. When any page on your WordPress site is requested, these rules rewrite the request to the index.php file in the root directory of your website (usually public_html).

This happens because WordPress is an application (or program), and it’s this application as a whole that generates your website’s pages.

Let’s say you have a page on your website called Contact, with the URL:
https://www.mydomain.com/contact

This Contact page does not exist as a physical file on your hosting account. Instead, its content is stored in your website’s database, and WordPress dynamically generates the page when it is requested.

Even though the browser requests https://www.mydomain.com/contact, the WordPress rewrite rules internally rewrite this request to:
https://www.mydomain.com/index.php

The index.php file then loads wp-blog-header.php. That file in turn loads wp-load.php and then template-loader.php. These files trigger the rest of the WordPress core files needed to generate the page. The WordPress code executes, pulls the content from the database, and together they generate the HTML output for the page — which is then sent to the visitor’s browser.

When WordPress rewrite rules are missing, only requests to the homepage (https://www.mydomain.com/) go to index.php. Any other URL (such as https://www.mydomain.com/contact) is treated as a non-existent file/folder, so the web server does not internally rewrite it to index.php.

However, some hosting setups (especially with DirectoryIndex index.php and fallback behaviour) still end up passing non-homepage requests through to index.php anyway — which means WordPress loads but returns its own 404 page. Ultimately index.php is executed, WordPress runs, but it can’t find a matching post/page for /contact, so it shows its own 404 or not found message.

As I’ve mentioned above, the .htaccess file is used to do a lot of things, not just handle WordPress’ rewriting mechanism.

Plugins within WordPress will also write to .htaccess.

Caching plugins have to write to .htaccess to do things like define a caching policy or bring compression in to effect.

Security plugins also write to .htaccess to do things like prevent PHP files in directories such as uploads or wp-includes being called directly from an external source (although these directories do contain PHP files, they should be invoked internally as outlined above). Security plugins can also use .htaccess to block specific IP addresses, or user agents.

Media conversion plugins that are used to do things like convert all jpg images to webp format can also write to .htaccess to rewrite a request to a .jpg file to the equivalent .webp file.

Really, what I’m saying here, is that a lot in your WordPress can write to .htaccess to achieve different objectives. This writing takes place automatically, in a transparent manner.

A developer or site owner edits .htaccess manually (e.g., to add IP blocking, redirects, or security rules) and accidentally deletes or overwrites the WordPress section.

FTP clients or file managers can be used incorrectly and overwrite the file.

Some WordPress security or optimisation plugins (like Wordfence, iThemes Security, or WP Fastest Cache) modify .htaccess and may accidentally remove the WordPress rewrite block during updates or when toggling features.

A buggy plugin might attempt to modify .htaccess and do it incorrectly.

In rare cases, installing/removing plugins that manage permalinks or caching can wipe or alter .htaccess.

If .htaccess is not writable by the web server (chmod 444 or owned by root), WordPress can’t update it when permalinks are changed.

When a user updates the permalink structure in Settings > Permalinks, WordPress tries to write the rewrite rules. If it can’t, they’re simply not added.

Add the WordPress rewrite rules to the site’s .htaccess file.

The WordPress rewrite rules are:

# 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

You’d put them in the site’s .htaccess file, which is located in the document root of your site’s domain.

Without the WordPress rewrite rules, the WordPress application isn’t correctly invoked, this prevents WordPress from being able to locate the page you’re requesting, so a 404 or not found message is displayed.

There are various causes to the WordPress rewrite rules going missing. These can range from configuration or permissions problems, user error or plugins trying to write to .htaccess at the same time.

It’s unlikely that the WordPress rewrite rules will go missing if you’ve been hacked. This problem is more along the lines of things not working properly than hacking. Most hackers don’t want you to notice you’ve been hacked, and this is quite an obvious problem. If you see lines IN ADDITION to the rewrite rules that look like this, you may have been hacked:

<FilesMatch "\.(php|php5|phtml)$">
  SetHandler application/x-httpd-php
</FilesMatch>

These lines allow direct access to php files from an external source, which hackers may use to access PHP files directly. If you think you may have been hacked:

• Carry out a virus scan in your hosting
• As your hosting provider to malware scan your account
• Use an in WordPress malware scanner such as the Sucuri Security plugin, or WordFence
• Use a vulnerability scanner such as the one built in to Solid Security to check to see if you’re operating any vulnerable themes or plugins (update or remove any that are found).