Most people do not think of a redesign as a migration. They think of a migration as moving from WordPress to Webflow, or changing hosts. But from Google’s point of view, any change to your URLs, your page structure or your internal links is a migration, and it treats the new site as something to re-evaluate rather than something to trust because the old one was fine.

That re-evaluation is where rankings get lost. Not through any fault in the new design, but because the pages that were earning traffic now live somewhere else, or nowhere, and the links pointing at them go to a 404. This checklist is the work that prevents that. It is not glamorous and it is the part most often left out of a cheap redesign.

Before anything changes: the inventory

You cannot protect what you have not listed. Before a single page is redesigned, collect:

  1. Every URL on the current site. Crawl it with Screaming Frog, Sitebulb or even the sitemap. Include images and PDFs that rank on their own. You will be surprised what is there.
  2. Search performance per URL. Google Search Console, last twelve months, clicks and impressions by page. This is the list of pages that are earning, and it is often not the pages the business thinks of as important.
  3. Backlinks per URL. Which pages have links from other sites. Those links are equity you already paid for, in time or money. A page with thirty inbound links that gets dropped in a redesign is thirty links wasted.
  4. Conversion paths. Which pages preceded a contact, call or purchase. Analytics will tell you. These pages work, whatever they look like.
  5. Structured data. What schema the current site emits, if any. Organisation, LocalBusiness, Service, FAQ, Article. It must be carried across or improved, never silently dropped.
  6. Rankings for the target terms. A snapshot before launch, so “did we lose anything” is a question with an answer.

During the build: the map

Every old URL needs a decision: keep it, redirect it, or retire it. Write those decisions down as a table — old URL, new URL, action, reason — and treat it as part of the build, not an afterthought at launch. The rules I use:

  • Keep the URL wherever the page survives and there is no strong reason to change the address. A changed URL is a small loss even with a perfect redirect; unchanged is free.
  • Redirect one-to-one when a page moves. Old service page to new service page. Never redirect twenty old pages to the homepage; Google treats that as a soft 404 and the equity does not transfer.
  • Merge deliberately when several thin pages become one good one. Redirect each old page to the section of the new page that replaced it.
  • Retire with a 410 when a page had no traffic, no links and no purpose. Let it go cleanly rather than redirecting it to something unrelated.

Alongside the map:

  • Rebuild internal links to point at the new URLs directly, not through the redirects. Redirect chains slow crawling and leak signal.
  • Carry the title tags and meta descriptions across for pages that were performing, then improve them against the Demand Map. Do not let the CMS overwrite good titles with the page name.
  • Carry the structured data across and validate it before launch.
  • Check the staging site is blocked from indexing, and that the block will be removed at launch. Both mistakes happen constantly.

At launch: the switch

  1. Redirects live before DNS changes, tested with a crawler against the old URL list. Every old URL should return 301 to the right place or 410.
  2. Remove the noindex from the new site. Check the robots.txt is not still the staging one.
  3. Submit the new sitemap in Search Console. Keep the old sitemap available for a few weeks so Google can process the redirects from it.
  4. Verify the new site in Search Console if the domain or protocol changed, and use the Change of Address tool if the domain did.
  5. Crawl the live site once more. Broken internal links, missing images and 404s show up now, not next month.

After launch: the watch

Rankings settle over four to eight weeks. During that window, check Search Console weekly for crawl errors, indexing drops and pages that lost clicks. A dip in the first fortnight is normal. A page that has lost most of its clicks after a month usually has a broken redirect, a missing title or a structural change that removed the content Google was ranking it for. All three are fixable if you are looking.

Then, after three months, compare against the pre-launch snapshot. That comparison is the answer to whether the migration worked. It is also the honest measure of the redesign, which is why the pillar guide asks you to take the snapshot before you start.

Why this is included in every KOODOS build

It is easy to quote a redesign without migration work because most clients do not know to ask for it. The consequence arrives two months after launch, when the phone goes quiet and nobody connects it to the new site. Build includes the inventory, the map, the launch checks and the watch as standard, because a redesign that ranks worse than the site it replaced is not a redesign anyone wanted.