Website Relaunch SEO

Think of a website relaunch like moving to a new house. You would not throw your furniture in a truck without labelling the boxes. Same here: you need a map of where everything currently lives (URLs), decide where it is going (new URLs), and leave forwarding instructions ([301 redirects](/301-redirect/)). If you skip that, Google shows up at the old address, finds nothing, and drops your pages. The most common mistake is to assume a redirect map alone is sufficient. I once worked on a relaunch where 15% of URLs were missed in the map—those pages vanished from the index for three weeks. A proper migration requires crawling the live site, exporting every indexable URL, prioritising high-value pages by traffic and backlinks, and building a redirect map that covers 100% of old URLs. Even then, you have to update internal links so they point directly to new URLs, not through redirect chains. The post-launch monitoring phase is just as critical: check Search Console for crawl errors, submit a fresh [sitemap](/sitemap/), and track indexing coverage. Without that, you can bleed traffic for months.

A full migration workflow matters most in five scenarios. First, you are redesigning the site and changing URL structure. If the look changes but URLs stay identical, you may not need redirects—but still audit internal links and metadata. Second, you are migrating to a new CMS, for example from WordPress to Shopify. Platform migrations often alter URL patterns, so a redirect map is essential. Third, you are changing domains, like oldbrand.com to newbrand.com. That requires the address change tool in Google Search Console, something I forgot on my first domain move and lost domain authority for three months. Fourth, you are merging or splitting sites, such as combining two blogs into one. You need to consolidate duplicate content and set up [canonical tags](/canonical-tag/) to tell Google which version to index. Fifth, you are moving from HTTP to HTTPS, which should now be standard but can still trip up crawlers if mixed content breaks [technical SEO](/technical-seo/). In every case, the decision rule is: if any URL changes, build a redirect map and test it with a crawl before launch. If no URLs change, skip the redirects but still check [website structure](/website-structure/) and speed.

The first time I did a relaunch, I thought a redirect map was enough. I forgot to update internal links. So every page on the new site was pointing to old URLs, which then redirected to new ones. That created redirect chains that slowed load times and confused crawlers. Took me two weeks to clean up. Another mistake I made was not testing the redirect map with a full crawl before going live. I assumed the one-to-one mapping was correct, but 50 URLs were mapped to the wrong destinations. On launch day, visitors hit 404s and Google started dropping pages from the index. I now always run a crawl of the staging environment against the live redirect map to catch mismatches. I also used to believe that submitting a sitemap alone would fix indexing. It does not. You must manually request indexing for high-priority pages in Search Console after verifying the redirects. One more error: I neglected to update canonical tags on pages that existed on both old and new structures. That created [duplicate content](/duplicate-content/) signals that took another month to resolve. The lesson: every element of the migration—URLs, redirects, internal links, canonicals, metadata, structured data—needs a deliberate check. Assume nothing works until you have verified it with a crawl and a live test.