Why is my website showing 404 errors? A checklist for site owners

What a 404 is, and when it is fine

A 404 Not Found is the server's way of saying it has nothing at that address. It does not say whether something used to be there or might be later. A 410 Gone is the deliberate version: the page existed and has been removed on purpose.

A 404 is not a penalty. Google states plainly that 404s on URLs that should not exist do not harm how the rest of your site ranks. Every site collects them from typos, scrapers, old campaigns and bots probing for files such as /wp-login.php on sites that do not run WordPress. Those can be left alone.

A 404 becomes a problem in three situations:

• The page moved. The content still exists at a new address, but the old address has links, bookmarks or search traffic and no redirect.
• Your own site links to it. A broken internal link wastes visitors' time and sends crawlers to a dead end on every crawl.
• Pages that should work are failing. A whole section, or every post, suddenly returns 404 because of a configuration change, not because anything was deleted.

Where 404s come from

After a move to a new platform the same table applies on a larger scale, and the migration redirects guide covers building the full map.

How to find the 404s that matter

Use three sources, because each shows a different slice:

• Search Console. The Page indexing report lists URLs under Not found (404). These are addresses Google knows about, from links, sitemaps or its own history. Click a URL and use URL Inspection to see where Google found it.
• A site crawler. A crawl starts from your home page and follows your own links, so every 404 it finds is one you created. Those are the first to fix.
• Server access logs. Logs show what real visitors and bots actually requested and how often. A 404 hit 300 times a week from a referrer matters far more than one hit once by a scanner.

To pull the most requested 404s from a standard nginx or Apache access log, run this on the server:

sudo awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -n 30

Field 9 is the status code and field 7 the path in the common combined log format. On Plesk, the domain's log is /var/www/vhosts/system/example.com/logs/access_ssl_log. To see where visitors to one missing URL came from, filter on that path and print the referrer:

sudo grep ' /old-services/ ' /var/log/nginx/access.log | awk '$9 == 404 {print $11}' | sort | uniq -c | sort -rn

Then confirm the response for any URL with curl -sI https://www.example.com/old-services/. The first line should read HTTP/2 404 for a page that is truly gone and HTTP/2 301 for one you have redirected. Our 404 errors guide for audits explains how to read the same findings in a crawl report.

Deciding what each missing URL should do

Work through the list and give every URL one of four outcomes:

Do not redirect every missing page to the home page. Visitors who wanted a specific product land somewhere unrelated, and Google often treats a redirect to an irrelevant page as a soft 404 anyway, so you gain nothing. A redirect should land on a page that satisfies the same need. For more on choosing between redirect types, see fixing redirect chains, which also explains why each old URL should point straight at its final address.

Platform notes: WordPress, Shopify, Apache and nginx

WordPress

If the home page loads but every post and page returns 404, the rewrite rules are missing or stale. Open Settings, then Permalinks, and click Save Changes without changing anything. WordPress rebuilds its rules and, on Apache, rewrites the WordPress block in .htaccess if it can. On nginx there is no .htaccess, so the server block must pass unknown paths to WordPress:

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

For individual moved pages, a redirect plugin such as Redirection lets you add old and new paths without touching server files, and logs 404s so you can see new ones as they appear. WordPress also tries to guess the right post when a URL is close to a real one, which is why some mistyped addresses redirect on their own. Redirects in WordPress covers the plugin options.

Shopify

Shopify keeps redirects in its URL redirects list, reached from Online Store, then Navigation, or from Content, then Menus in newer admin layouts. When you edit a product or collection handle, the search engine listing section offers a tick box to create a redirect from the old URL; leave it ticked. You can also import redirects in bulk from a CSV file with two columns, the old path and the new address.

Apache and nginx

For a single page, use a plain permanent redirect:

# Apache, in .htaccess or the virtual host
Redirect 301 /old-services/ https://www.example.com/services/

# nginx, inside the server block
location = /old-services/ { return 301 https://www.example.com/services/; }

For a page that is gone on purpose, Apache's Redirect gone /old-offer/ returns 410, and in nginx location = /old-offer/ { return 410; } does the same.

A worked example: one rule for thousands of URLs

A blog changes its WordPress permalink setting from day and name, giving addresses such as /2026/10/17/post-name/, to post name only, giving /post-name/. WordPress itself often redirects old date-based links, but this site sits behind a static cache that serves its own 404 first, and thousands of old links from social media and other sites now fail. Search Console's Not found (404) count climbs every day.

Adding one redirect per post would take days. Every old URL follows the same pattern, so one rule handles all of them. In nginx:

rewrite ^/[0-9]{4}/[0-9]{2}/[0-9]{2}/([^/]+)/?$ /$1/ permanent;

Or in Apache:

RedirectMatch 301 ^/[0-9]{4}/[0-9]{2}/[0-9]{2}/([^/]+)/?$ /$1/

The pattern requires a slug after the date, so date archive pages such as /2026/10/ are not caught. A quick check with curl -sI on three old links shows each returning 301 with a location header pointing at the new address, which then returns 200. Over the following weeks the 404 count in Search Console falls as Google recrawls the old URLs.

The fix, step by step

Edge cases worth knowing

• Soft 404s. A friendly error page that returns 200 OK is reported by Google as a soft 404. The page must return status 404 or 410. In Apache, ErrorDocument 404 /404.html works, but giving a full address such as https://www.example.com/404.html makes Apache redirect instead, and the status is lost. In nginx, use error_page 404 /404.html; without the =200 option.
• Thin or empty pages. Empty category pages and out-of-stock product pages with no content can also be classed as soft 404s even though they return 200.
• 404 versus 410. Both remove a page from the index over time. A 410 is a slightly stronger signal and may be acted on a little sooner, but a 404 is fine for most cases.
• Images and files. Missing images, PDFs and scripts are 404s too. A missing stylesheet can break a page's layout for visitors and for Google's rendering.
• Sitemaps listing dead URLs. A sitemap should only list live pages. See fixing sitemap 404s if Search Console shows URLs from your sitemap returning 404.

Keeping it fixed

Make the 404 page useful. Include your main navigation, a search box and links to your most popular pages, so visitors who reach it can carry on. Keep the status code at 404 and test it with curl -sI https://www.example.com/this-does-not-exist/ after any theme change.

Build redirects into your routine. Whenever you rename a page, change a slug or remove a product, add the redirect at the same time. Keep a simple spreadsheet of old and new addresses during any redesign. After launch, crawl the site, check the 404 report in your redirect plugin or logs weekly for a month, and look at Search Console's Page indexing report. The HTTP error audit guide explains how to schedule regular checks.