Website Rebuilds: Map URLs and Verify the Launch

A website rebuild needs a plan for the pages people already visit and link to. Start by deciding which URLs can stay the same, which need a replacement and which are being retired. Keep that decision record alongside the launch checklist.

Build an inventory before changing URLs

Combine a site crawl with sitemaps, CMS records, analytics, search reports and available server logs. A crawl alone can miss URLs that are no longer linked. Include important images, downloads and other resources.

For each URL, record its purpose, planned action, destination where applicable and verification result. Give business-critical pages particular attention while keeping the full inventory available for review.

Choose the correct response

Keep a working URL when there is no reason to change it. For a permanent move, Google's redirect guidance recognizes both 301 and 308 responses. Temporary redirects serve a different purpose; choose according to the actual change.

Send a moved page to its relevant replacement. Do not funnel every old article or service page to the homepage simply to eliminate errors. If content is permanently removed and has no suitable replacement, a genuine 404 or 410 response can be appropriate.

Prepare the release and a recovery option

Follow Google's site-move guidance for the type of change involved. Update internal links, canonical references and sitemaps to the intended destinations. Confirm that development-only indexing restrictions will not remain on public production pages.

Keep a recoverable copy of the prior release and document who can address a failed launch. Check forms, contact links and analytics as well as page appearance. A successful page load does not prove that inquiries are still recorded correctly.

Test actual responses after launch

• Request old URLs and check their HTTP status and final destination.
• Look for redirect loops, unnecessary chains and unrelated destinations.
• Confirm that replacement pages load their intended content.
• Check important links, files, canonical references and indexing controls.
• Record failures and verify each correction after it is released.

Repeat verification on production even when the preview passed. Differences in domains, server rules or environment settings can change the outcome.

Monitor without assuming a deadline

Review Search Console indexing information and performance for old and new URLs, alongside analytics and relevant logs. Investigate the reason given for an indexing problem. A page can be crawled without being indexed.

Record the launch date and other material changes when comparing traffic. Search visibility can fluctuate during a move; there is no universal loss percentage or recovery schedule. If you discover an omitted redirect later, implement the relevant mapping and verify it rather than declaring the page's history permanently lost.