Fixing 404 errors after a website migration

Not every 404 needs fixing. Google’s Page indexing documentation says 404 responses “are not necessarily a problem, if the page has been removed without any replacement.” An expired campaign nobody links to can return 404 forever without costing anything.

The 404s that cost something after a migration are different: old urls of pages that still exist on the new site under another address. Google removes a url that answers with a 4xx from its index once it recrawls it (http status codes), and the new page does not inherit its rankings or the links pointing at it unless a redirect connects the two. Visitors from bookmarks, newsletters and other sites land on an error page.

• fix — old urls with an equivalent or related page on the new site, urls with clicks or impressions, urls with backlinks, urls still linked from your own site or listed in your sitemap.
• leave or 410 — pages removed deliberately with no replacement and nothing pointing at them.
• ignore — urls that never existed: typos in other sites’ links, scanner probes for /wp-admin on a site that never ran WordPress.

Each source sees a different part of the problem. Use at least the first three together.

Search Console — open Indexing → Pages and look for Not found (404). The list is a sample — the report’s example table is limited to 1 000 urls — and it fills up over weeks as Google recrawls old urls. Use it to confirm the problem and spot patterns, not as the complete list.

server logs — filter the access log for status 404 since the launch, drop asset requests and obvious scanner traffic, and count by path. Paths that are requested repeatedly are the ones people and crawlers still use.

the old url list — the most complete source, if you have one: the old sitemap, an old crawler export, or the cms’s url export. Request every url on the live site and keep the ones that answer 404. If the list is missing, rebuild it from the sources in finding orphan urls.

One rule decides almost every row: if you can name a page that answers the same question, redirect to it.

What not to do: send every unmatched url to the homepage. Google’s site move documentation says redirecting many old urls to one irrelevant destination such as the homepage “might be treated as a soft 404” — the redirect exists, but it passes nothing on, and the visitor lands somewhere they did not ask for.

On 410 versus 404: Google says all 4xx errors except 429 are treated the same and lead to the url being removed from the index. A 410 is still the more honest answer for a deliberate removal, because it tells the next person looking at the logs that it was a decision, not an oversight. Google’s move guide asks for exactly that: removed pages should return a 404 or 410 on the new site.

A list of 600 404s looks like a week of work. It rarely is, because the value is not spread evenly. Sort before you start:

• clicks before the migration. Export the Search Console performance report for the months before launch; the download includes a pages file with clicks and impressions per url (export format). Join it onto the 404 list.
• backlinks. An old url with links from other sites matters even if it had little search traffic. The Links report in Search Console lists top linked pages.
• internal references. A 404 linked from your own new navigation or listed in your new sitemap is a bug in the new site — fix the link as well as adding the redirect.

Then work top-down. The first rows are checked by hand, one by one. Further down, where urls have no clicks and no links, whole sections can be settled with a directory rule, and the rest can be accepted in bulk once the matches look right.

Matching hundreds of 404s to new pages by hand is the slow part. Silentfrog does it from a url list: switch on old site already offline?, hand it the 404 list (one url per line, or a csv with the url in the first column), and enter the new site. The new site is crawled, and every old url is scored against every new page (when the old site is gone). If the old site still answers on another host, crawl it as the old site instead — titles and headlines then take part in the matching, and fewer rows need review.

Import the pre-migration Search Console export as traffic data and the table gains a clicks column to sort by; urls with traffic that are missing from your list are shown separately and can be added (traffic data). Rows below the review threshold stay unmatched and are left out of the export — those are your 410 candidates.

The redirects file comes in the spelling of your platform’s importer — Webflow, Shopify, the WordPress plugins, Squarespace, .htaccess, nginx or plain pairs. The first 50 old urls are free. If the platform’s importer replaces existing redirects instead of adding to them, merge the new rows with the current list first (see importing into webflow for one such case).

• request every url from the 404 list again. Each should answer 301 and then 200, in one hop.
• in Search Console, open the Not found (404) reason and click validate fix. Google recrawls the listed urls and reports which still fail.
• spot-check important urls with URL Inspection — the live test shows what Google gets now.
• keep watching the logs for a few weeks: new 404 paths that keep appearing point at a source you had not included.

Watch for soft 404s as well. A redirect to an unrelated page, or a new page that answers 200 but looks empty, shows up under Soft 404 in the same report. Those are 404s in disguise and need a better target.

• Only 404s on urls with a replacement, traffic, backlinks or internal links need fixing.
• Search Console shows a sample; the old url list checked live shows them all. Use both, plus the logs.
• 301 to the equivalent page, 301 to the closest category, 404 or 410 for deliberate removals — never everything to the homepage.
• Sort by pre-migration clicks and backlinks, map the top rows by hand, settle whole folders with one rule.
• Validate in Search Console and watch for soft 404s afterwards.