How to Find 404 URLs Before a Website Relaunch

To find 404 URLs before website relaunch, crawl the current site and compare its URLs with your sitemap, analytics, CMS exports, and backlink records. Then test important URLs, map useful old pages to relevant destinations, and verify the redirects on the new site before launch.

Finding broken URLs early helps visitors reach the content they expect and reduces the chance of losing search visibility or valuable referral traffic. Use the steps below to create a practical URL inventory and resolve problems before the new site goes live.

How to find 404 URLs before website relaunch

A site crawl is a good starting point, but it only finds URLs that the crawler can discover. Pages that are unlinked, removed from navigation, or missing from the current sitemap may be absent from the crawl. Combine several sources so your review covers more than the pages currently connected to the site.

1. Crawl the current website

Use a website crawler to follow internal links and record each page’s response code, canonical URL, title, and destination. Crawl the production site before changing it, and save the results so you can compare them with the relaunch version later.

Review both the URLs that return errors and the links that point to them. A 404 on an internal link is usually a fixable site issue: update the link, restore the missing page, or redirect it if a suitable replacement exists. Check crawl settings too. A crawler may need permission to access parts of a site, and crawl limits can affect how much it discovers.

2. Gather URLs from more than one source

Build a master list from the current crawl, XML sitemaps, CMS exports, and any available server logs. Add URLs from analytics reports to find pages that people have visited, even if they are no longer linked from the site. If the business has a record of old campaigns, product pages, or downloads, include those as well.

Check external references, too. Backlink data can identify old pages that other websites still link to. A URL with valuable referral traffic or links deserves attention even if it is absent from the current navigation. Remove duplicates and keep the source of each URL where possible; that makes it easier to judge what should happen to it.

3. Check response codes and investigate errors

HTTP status codes help you distinguish a missing page from other problems. A 404 means the server did not find a page at that address. A 410 indicates that a resource has been intentionally removed. A 5xx response points to a server-side issue, while a 3xx response means the URL redirects somewhere else.

Test priority URLs with the HTTP Status Checker to quickly inspect their response codes. Start with URLs from your crawl, sitemap, analytics, and backlink list that matter most to visitors or the business. If a URL returns an unexpected result, check it again and investigate the page or server configuration before deciding it needs a redirect.

Do not treat every 200 response as proof that a page is healthy. A page can return 200 while displaying an error message or empty content; this is often called a soft 404. Review the actual page, not just its status code. Likewise, a redirect may be technically successful but still send visitors to an irrelevant destination.

4. Make a URL decision and redirect map

For each old URL, decide whether to keep it, restore it, redirect it, or let it remain removed. Redirect a page only when there is a genuinely relevant replacement. For example, an old product page might point to its current version or a closely related category. Sending every retired URL to the homepage can confuse visitors and may be treated as a soft 404.

Create a redirect map with the old URL, the intended destination, the reason for the change, and the check result. This gives developers and content editors a clear implementation plan and reduces guesswork during launch.

5. Test the new site before launch

If you have a staging environment, crawl it before launch and compare its important pages with the URL inventory. Confirm that planned redirects point to the right destinations and that those destinations load successfully. Look for redirect chains, loops, incorrect domain or protocol versions, and links that still point to the old site.

Keep staging protected from public access and search indexing according to your team’s normal process. Also remember that a staging site may differ from production: hosting rules, CDN settings, and domain configuration can affect responses. A successful staging check is useful, but it does not replace a production check after launch.

What to prioritize when time is limited

It may not be practical to review every historic URL by hand. Prioritize pages that have recent visits, external links, important conversions, strong internal links, or a clear role in the customer journey. Also prioritize URLs in menus, product listings, and key landing pages because visitors are likely to encounter them.

Use a simple tracking sheet with columns for URL, source, current response, new destination, owner, and test status. Agree on who will approve redirects and who will verify them. A clear record helps prevent the same URL from being fixed in one place and overlooked in another.

Recheck URLs after the relaunch

Once the new site is live, crawl it again and test the most important old URLs against the production domain. Confirm that redirects resolve to the intended pages, internal links work, and important pages return the expected response. Watch analytics and server logs for visits to old URLs that still return 404s, then add fixes when there is a meaningful destination.

Keep the old-to-new URL map after launch. It can help with later migrations, content updates, and troubleshooting. A short follow-up review is worthwhile because issues can come from deployment settings or links that were missed during pre-launch testing.

Frequently asked questions

Can a site crawl find every 404 URL?

No. A crawl finds URLs it can discover through links and its configured sources. Combine it with sitemaps, CMS exports, analytics, logs, and backlink records to find more unlinked or historical URLs.

Should every 404 redirect to the homepage?

No. Redirect an old URL to a relevant replacement when one exists. If there is no suitable destination, it is usually clearer to leave the page removed and make sure internal links no longer point to it.

What is the difference between a 404 and a soft 404?

A 404 response tells browsers and crawlers that the requested page was not found. A soft 404 appears missing or unhelpful but returns a success response, often 200. Check both the response code and the page content.

Is checking the staging site enough?

No. Staging checks can catch problems before launch, but production settings may differ. Recheck important URLs and redirects on the live site after deployment.

When should I start checking URLs?

Start during relaunch planning, before URL structures or content are finalized. That leaves time to decide which pages to keep, restore, redirect, or retire and to test the changes before launch.