Every redesign horror story I have inherited from a new client follows the same shape: a design team ships a beautiful new site, traffic craters within two weeks, and nobody connects the two events until three months later when someone finally checks Search Console. This is the checklist that prevents that, in the order we actually run it.
Crawl the old site before you touch anything
Before a single new page goes live, crawl the existing site with a proper crawler (Screaming Frog or similar) and export every indexable URL, not just the ones in the nav. Cross-reference against Google Search Console's Pages report and your XML sitemap — these three sources rarely agree completely, and the gaps are usually old blog posts, orphaned landing pages, or paginated category pages that still hold rankings nobody remembered existed.
Pull organic traffic and ranking data per URL for at least the past twelve months. This is what tells you which pages are actually earning their keep and cannot simply be dropped in the new structure without a plan.
Build a complete URL inventory and a one-hop redirect map
Every old URL that has ever earned a click, a ranking, or a backlink needs an entry in a 301 redirect map to its most relevant equivalent on the new site. "Most relevant" matters — redirecting everything to the homepage (the single most common redesign mistake we see) tells Google none of the new pages are actually equivalent to what existed before, and rankings do not transfer.
Keep every redirect to one hop. Chains — old URL to intermediate URL to final URL — waste crawl budget, slow the user down, and in long enough chains, Google will simply stop following them. Map old URL directly to final URL, every time, even if that means updating the map twice during a long project.
Content parity for anything already ranking
For every page that currently earns meaningful organic traffic, preserve the content that is actually earning it — not necessarily word-for-word, but the substance: the headings that match search intent, the specific information a searcher came for, and enough of the original copy that the topical relevance carries over. A redesign is a great excuse to improve weak content. It is a terrible excuse to gut content that is already working because the new template "doesn't have room" for it.
Where possible, preserve the exact title tag and meta description for high-performing pages, or change them deliberately rather than as a side effect of a new CMS template. The same goes for H1s — a new design system should not silently rewrite every H1 to match a generic template pattern that drops the specific keyword phrase the old H1 was built around.
The staging noindex problem, in both directions
Two mistakes, mirror images of each other, both common:
- Forgetting to noindex staging. A staging environment left crawlable gets indexed, competes with the production site for the same queries, and occasionally outranks it temporarily with unfinished content. Block staging with both a
noindexmeta tag and authentication, not one or the other. - Forgetting to remove noindex at launch. The inverse mistake is worse and more common than it should be: the new site launches to production with the staging
noindextag still in the template, and the entire site quietly de-indexes over the following two to three weeks while everyone assumes the traffic drop is normal fluctuation. This is the single most expensive checklist item to skip, and the cheapest to verify — check the rendered HTML of the live homepage for anoindexdirective the hour the site goes live, not the week after.
Structured data and technical carryover
Schema markup does not migrate itself just because the visual design does. If the old site had Article, LocalBusiness, FAQ, or Product schema generating rich results in search, confirm the new templates output the equivalent markup before launch, not after someone notices the star ratings disappeared from your search listings. The same goes for hreflang tags on multi-region sites and canonical tags — a new CMS with different default canonical behavior can quietly create duplicate-content signals across parameterized URLs that never existed on the old platform.
Run a full pre-launch QA pass specifically for SEO, separate from the visual and functional QA the design team is already doing: confirm every redirect in the map actually resolves (not just that it exists in a spreadsheet), confirm canonical tags point to the correct self-referencing URL on every template, confirm structured data validates in Google's Rich Results Test, and confirm the robots.txt file being deployed is the production version, not the staging version that blocks everything.
Internal links and the XML sitemap swap
Update internal links to point directly to final URLs rather than relying on redirects to catch outdated internal links — every redirect hop an internal link forces a crawler through is a small, avoidable waste of crawl budget on your own site.
Generate a fresh XML sitemap reflecting the new URL structure and submit it in Search Console the same day the new site goes live. Leave the old sitemap accessible for a few weeks if it is still useful for tracking which old URLs Google has and has not recrawled, but make sure the new sitemap is the one referenced in robots.txt.
Search Console monitoring cadence after launch
- Day one: confirm indexing is live (no stray noindex tags), confirm the sitemap submitted successfully, spot check the redirect map on your ten highest-traffic old URLs.
- Week one: check the Coverage/Pages report daily for a spike in "Not Found (404)" or "Redirect error" — these mean gaps in the redirect map that need patching immediately, not at the next scheduled review.
- Weeks two through six: check weekly. Expect a temporary ranking dip during this window as Google recrawls and reprocesses the new URLs and redirects — this is normal and usually recovers by week six to eight if the redirect map and content parity were done properly.
- Ongoing: monthly review of the Performance report comparing pre- and post-launch trends for your top twenty pages by historical traffic.
When a dip is normal, and when to actually worry
A ranking dip of one to two weeks, recovering by week six to eight, is the expected pattern even for a well-executed migration — Google needs to recrawl and reassess the new URLs, and there is a natural lag. What should trigger real concern:
- Traffic still down more than 20% at the eight-week mark with no recovery trend in Search Console.
- A spike in 404s or redirect errors that was not fully patched within the first week.
- Indexed page count in Search Console dropping sharply and staying down — often the noindex-left-on mistake described above, or a new robots.txt accidentally blocking sections of the site.
- Rankings recovering for the homepage and top-level pages but not for deep content pages, which usually means those specific pages lost content parity or their redirect target is not actually equivalent.
We treat every redesign as a migration project first and a design project second, which is the only way this list gets followed under deadline pressure. If a redesign is on your roadmap and you want a second set of eyes on the plan before anything goes live, that is exactly the kind of project our web design and development team runs end to end, redirect map included.