11 min read
Fix The Requested URL Was Not Found on This Server
“The requested URL was not found on this server” is Apache’s default 404 page. It means the web server received the request but could not match the path to a file, directory or rewrite rule. On a WordPress site the fix is almost always one of four things: a typo in the URL, a missing or broken .htaccess file, the mod_rewrite module being switched off, or permalinks that need re-saving after a migration.
Visitors see it after clicking a dead link. Site owners usually see it on every page except the homepage, right after moving hosts or changing permalink settings. The sections below explain what the server is telling you, list every common cause, and walk through the fixes in the order we apply them on client sites.
What Does This Error Indicate?
Whenever someone enters a URL or clicks a link, the browser sends a request to the server hosting the website. The server checks its file system or routing logic to locate and deliver the resource. If it cannot find a match, it returns a 404 HTTP status code with a message like:
Not Found
The requested URL was not found on this server.This is often followed by a server signature such as:
Apache/2.4.58 (Ubuntu) Server at example.com Port 80That signature is the useful part. It tells you the request reached Apache (not NGINX, not Cloudflare, not WordPress), so the problem sits between Apache and your files. WordPress never generated this page; if WordPress had handled the request, you would see your theme’s 404 template instead.
The message does not always mean something is permanently broken. It means the server could not match this URL to a file or route at this moment. A missing rewrite rule produces exactly the same page as a deleted file.
NGINX users see a different wording for the same problem: a plain “404 Not Found” page with “nginx” underneath. The causes and most of the fixes below apply there too, except that NGINX ignores .htaccess entirely and needs a try_files directive in the server block instead.
What Can Cause This Error?
The root causes vary widely. Here are the ones we see most often, roughly in order of frequency:
Incorrect URL Entry
The most straightforward reason is that the user entered an incorrect URL. It may contain spelling errors, wrong letter case, or an invalid path. Linux servers are case-sensitive, so /About and /about are different paths.
Missing or Deleted Files
If the file being requested has been deleted or moved without updating internal links or routing rules, the server responds with this error. Uploads that never finished copying during a migration are a common version of this.
Broken or Outdated Links
If your site or another website links to a resource that no longer exists or has been renamed, users land on a 404 page. You cannot fix the other site’s link, but you can redirect the old path.
Misconfigured .htaccess File (Apache Servers)
In Apache environments, the .htaccess file controls routing. If the rewrite rules are misconfigured or the file is missing, every pretty permalink fails while the homepage (which is a real file, index.php) keeps working. That pattern is the single biggest clue on a WordPress site.
Improper File Permissions
Even if the file exists, wrong permissions on files or directories can stop Apache reading them. Some configurations return 403 Forbidden in this case, others return 404, depending on the server’s settings.
Disabled mod_rewrite Module (Apache)
The mod_rewrite module handles clean URLs. If it is disabled, the rules in .htaccess are ignored, pretty URLs stop working, and the server cannot find the resource.
Issues in CMS Configuration
For sites on WordPress, Joomla, or similar platforms, permalink settings and routing configuration decide how URLs map to content. A site URL that still points at the old domain, or a permalink structure that was never saved on the new host, is enough to break every page.
DNS Propagation or Hosting Changes
If you recently changed hosting providers or updated DNS records, some requests may still reach the old server, or reach a new server that does not have your files yet. Both produce this error until propagation finishes.
| Symptom | Most likely cause | First thing to try |
|---|---|---|
| One page 404s, rest of site fine | Typo, deleted file, or old link | Check the URL, then add a 301 redirect |
| Homepage works, every other page 404s | Missing .htaccess or mod_rewrite off | Re-save permalinks; check mod_rewrite |
| Whole site 404s right after a migration | Files not in the document root, or DNS not propagated | Confirm the document root path and run dig |
| Images and CSS 404 but pages load | Uploads folder not copied, or wrong site URL | Check wp-content/uploads exists; check Settings > General |
| 404 only on /wp-admin or /wp-login.php | Security plugin renamed the login URL | Check the plugin’s settings or disable it via FTP |
Step-by-Step Fixes
Double-Check the URL in the Address Bar
Start by verifying that the URL is entered correctly. Case sensitivity matters on Linux servers, and missing file extensions (.php.html) can trigger this error on sites without rewrite rules. Try the homepage and one other page so you know whether the problem is one URL or the whole site.
Examine the File Directory Structure
Log into your hosting panel or connect over SFTP and inspect the directory structure. Make sure the file or directory actually exists and has not been deleted or renamed. On a WordPress site, confirm that index.php, wp-content and wp-includes sit in the document root your virtual host points at, not one level deeper in a folder left over from unzipping a backup.
Inspect the .htaccess File on Apache Servers
If your server uses Apache, the .htaccess file in the root directory may be missing or broken. A standard WordPress single-site file, per the WordPress Advanced Administration handbook, looks like 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 WordPressMake sure the file exists, is named exactly .htaccess (hidden files are easy to miss in FTP clients), and contains these lines. If you are not sure what else is in it, rename the existing file to .htaccess-old and create a fresh one with only the block above. Then enable mod_rewrite if it is not already active:
sudo a2enmod rewrite
sudo systemctl restart apache2Set Proper File and Directory Permissions
The web server needs to read the files requested. These commands set the usual WordPress permissions and assign ownership to the web server user:
sudo find /var/www/html -type d -exec chmod 755 {} \;
sudo find /var/www/html -type f -exec chmod 644 {} \;
sudo chown -R www-data:www-data /var/www/htmlDirectories get 755 and files get 644. Avoid the older habit of running chmod -R 755 on everything, which makes every file executable for no reason, and never use 777.
Update Apache Configuration to Allow Overrides
Apache ignores .htaccess unless AllowOverride is enabled for the directory. This is the default on many fresh Ubuntu installs, and it catches people who set up their own VPS. Edit the virtual host file (usually in /etc/apache2/sites-available/):
<Directory /var/www/html>
AllowOverride All
Require all granted
</Directory>Then test the config and restart Apache:
sudo apachectl configtest
sudo systemctl restart apache2If you want to move away from .htaccess altogether (Apache’s own documentation recommends it for performance), paste the WordPress rewrite block inside that Directory section instead and set AllowOverride to None.
NGINX: Add a try_files Rule
On NGINX there is no .htaccess. The equivalent of the WordPress rewrite block is one line in the location / block of your server configuration:
location / {
try_files $uri $uri/ /index.php?$args;
}Run sudo nginx -t to check the syntax, then sudo systemctl reload nginx. Managed hosts that run NGINX (Kinsta, WP Engine, Cloudways on the NGINX stack) already include this, so if you are on one of those, the problem is elsewhere.
WordPress and CMS-Specific Fixes
If your site runs on WordPress, reset permalinks:
- Go to the admin dashboard
- Open Settings > Permalinks
- Click “Save Changes” without changing anything
This regenerates the rewrite rules in .htaccess (if the file is writable) and flushes WordPress’s internal rewrite cache. If you cannot reach wp-admin, run wp rewrite flush --hard over SSH with WP-CLI; it does the same job.
Also confirm that WordPress Address and Site Address under Settings > General match the domain you are visiting. After a migration these often still hold the old domain or a staging URL, and the resulting redirects end in a 404.
Analyze Server Logs
Server logs often record the real reason a request failed. On Apache:
sudo tail -f /var/log/apache2/error.logOn NGINX the file is /var/log/nginx/error.log. Look for entries matching the time of the failed request. “File does not exist: /var/www/html/about” tells you Apache looked for a literal file called about, which means the rewrite rules never ran. “Permission denied” points at ownership or permissions.
Clear Caches
If you use a CDN, a caching plugin, a server-side cache like Varnish or LiteSpeed Cache, or even your browser cache, clear it. A cached 404 can outlive the fix by hours. On Cloudflare, use Purge Everything or enable Development Mode for a few minutes while you test.
Recheck DNS and Hosting Setup
If your site recently moved to a new host or you changed DNS, allow time for propagation, usually under an hour with modern TTLs but up to 48 hours in the worst case. Use dig example.com +short or nslookup example.com to confirm the domain resolves to the new server’s IP. If it still shows the old IP, you are looking at the old server’s error page, not the new one.
Reducing Future Occurrences
To keep these errors rare:
- Keep internal and external links updated, and run a link check after any content reorganisation.
- Use 301 redirects when you delete or move pages. The free Redirection plugin logs every 404 your visitors hit, so you can redirect the ones that matter.
- Watch the Pages report in Google Search Console for “Not found (404)” URLs; a crawler like Screaming Frog finds the same issues before Google does.
- Customise your theme’s 404 page with a search box and links to your main sections.
- Back up the site and database on a schedule so a bad migration or a wiped .htaccess is a five-minute restore.
- Keep a copy of your working .htaccess and virtual host configuration in version control or a notes file.
WordPress-Specific Example
On WordPress, this error shows up most often after migrating a site, changing permalinks, or moving to a new server. Here is the sequence we follow, in order, on a typical Apache host:
- Confirm the homepage loads. If it does and inner pages do not, skip straight to step 3.
- Check that WordPress files are in the document root and that Settings > General shows the correct domain.
- Check that the .htaccess file exists in the root directory and contains the standard WordPress rewrite block shown earlier.
- Make sure mod_rewrite is enabled and AllowOverride is set to All for the document root:
sudo a2enmod rewrite
sudo systemctl restart apache2- Go to Settings > Permalinks and click Save Changes.
- Clear every cache layer and test in a private browser window.
Still stuck? Temporarily rename the plugins folder to plugins-off and reload. If the site comes back, a security or redirect plugin is rewriting URLs; rename the folder back and disable plugins one at a time to find it. Membership and community sites are the usual suspects because plugins that gate content or rename the login URL touch the rewrite rules.
Fixing “The requested URL was not found on this server” comes down to one question: did the request reach WordPress at all? If Apache answered with its own page, WordPress never ran, and the fix is in .htaccess, mod_rewrite or the document root, not in your theme or content.
Frequently asked questions
Is “The requested URL was not found on this server” the same as a 404?
Yes. It is the text of Apache’s default 404 response. The status code is 404 either way; the wording tells you Apache, rather than WordPress or NGINX, produced the page.
Why does my homepage work but every other page shows this error?
Because the homepage is a real file (index.php) and the other pages are pretty permalinks that need rewrite rules. Either .htaccess is missing, mod_rewrite is disabled, or AllowOverride is off. Re-save permalinks first, then check the server side.
Can a plugin cause this error?
Yes. Security plugins that hide the login URL, redirect managers, and multilingual plugins all add rewrite rules. Rename the plugins folder over SFTP to test; if the error disappears, re-enable plugins one by one.
Does this error hurt SEO?
A handful of 404s on genuinely removed pages is normal and harmless. Site-wide 404s caused by a broken server configuration are not: if Google recrawls while the site is down, rankings can drop within days. Fix it quickly and check Search Console afterwards.
I am on shared hosting and cannot run these commands. What now?
You can still do most of it. Re-save permalinks, check and recreate .htaccess through the File Manager, and confirm the site URL. If the error persists, ask your host to confirm mod_rewrite and AllowOverride are enabled; it takes them a minute.
Where to Start
Re-save permalinks, then check .htaccess, then check mod_rewrite and AllowOverride. That order fixes the error on roughly nine out of ten WordPress sites we are asked to look at, and all three steps take under ten minutes.
If the error appeared after a host move and the steps above do not clear it, the migration itself is usually incomplete. Our WordPress migration service handles the server configuration, DNS and testing, and a WordPress care plan keeps someone watching the logs so you hear about 404s before your visitors do.
Interesting Reads:
The Ultimate Guide to Setting Up Your WordPress Blog Development Environment
Related reading