Most people think of 404 errors as SEO housekeeping. From the server side they are also a load question. On WordPress, a request for a missing URL is not a cheap static response: it runs through PHP and WordPress before the “not found” page is produced. A handful is nothing. A steady stream of them, or one missing file referenced on every page, can slow a site down and in the worst case knock it over. This article explains which 404s matter on a hosted WordPress site, which ones you can fix yourself and when to bring us in.
How WordPress handles a missing URL
When a visitor asks for a page that exists, the page cache can usually serve a stored copy without WordPress running at all. A URL that does not exist generally has no cached copy, so the request falls through to PHP. WordPress loads, works out that nothing matches, and builds the 404 template. Each of those requests costs the server roughly what an uncached page view costs.
That is why it is possible to flood a WordPress site with requests for missing URLs and overwhelm it, and why a missing file in the theme is far worse than a missing page.
The worst kind: a missing file in the template
If the theme, header or footer references an image, stylesheet or JavaScript file that has been deleted or mistyped, every single page view generates a 404 for it. The browser also has to deal with the error while it is rendering the page, and if the site has a custom 404 page the browser may fetch that as well. The result is a page that feels like it stalls part way through loading.
The hosting risk is volume. A common pattern: something in the footer calls a file that no longer exists, a newsletter goes out, and five or ten thousand people click through in a short window. Each visit now carries an extra uncached PHP request on top of the page itself, which can be enough to take the site down.
To find these, run a speed test that shows a waterfall view and look for requests marked in red or with a 404 status. Typical finds are a missing favicon.ico, a cookie or consent script pointing to a file that has gone, and live chat code embedded twice. Fix the reference in the theme or plugin settings, or upload the missing file.
Small files worth creating
- favicon.ico: browsers request it automatically. Upload one to the root of the site so the request stops failing.
- ads.txt: Google requests it regularly. If you do not sell advertising, an empty ads.txt in the site root stops the 404 and also states that nobody is authorised to sell ad space on your site.
- .well-known requests: paths under
/.well-known/used for mobile app links can safely return 404 if you do not have an app.
Make sure the site returns a real 404 status
The page a visitor sees and the status code the server sends are separate things. A correct setup returns HTTP 404 along with the not found page. Some setups return 200 OK with an error page, and some plugins redirect every missing URL to the homepage. Both hide the problem and leave the site open to junk URLs being treated as real pages, which can be exploited in negative SEO attacks.
WordPress returns a proper 404 by default, so if yours does not, a plugin or a custom rule is usually responsible. To check, open your browser’s developer tools, go to the Network tab, load a made-up URL on your domain and look at the status column for the first request.
Old subdomains and DNS records
Sites that have been around for many years often have subdomains for an old CRM, shop or staging copy that no longer exist but still have DNS records. Google keeps crawling them, and those errors show up in the Crawl stats report under Settings in Google Search Console, broken down by host. If a subdomain is no longer in use, delete its DNS record wherever your DNS is managed. If you are unsure whether a record is still needed, ask us before removing it.
What you can change yourself
- Add 301 redirects for retired pages and products that still have links or traffic, using your SEO plugin’s redirect feature (Rank Math has one) or a redirect plugin. Point each one at the replacement product, the closest category or the current version of the page.
- Leave obvious junk and spam URLs returning 404.
- Stop Google crawling areas it does not need, such as old review list URLs, with a Disallow line in robots.txt rather than redirects.
When to open a ticket
Open a ticket from the client area when:
- The site slows down or errors during traffic spikes and you suspect missing files or a flood of requests for URLs that do not exist.
- The same missing URL is being requested thousands of times and you want to know whether it can be stopped before it reaches WordPress.
- Made-up URLs return 200 instead of 404 and you cannot find the cause.
Include the URL or file returning 404, roughly when the problem started, whether it is one URL or many, and any recent theme, plugin or email campaign changes. A screenshot of the Crawl stats response breakdown or the “Not found (404)” list from Google Search Console helps us see the pattern quickly.
Do not aim for zero
A site with no 404s at all is usually a site redirecting things it should not. Missing pages should return 404, and Google expects that. The ones worth your time are files that load on every page, URLs requested in large volumes, and retired pages that still have links pointing at them.