Most website redesigns lose traffic in the first 30 days for one reason: nobody mapped the old URLs to the new ones before launch. Rankings built over years get flattened because a template change silently dropped canonical tags, redirect rules, or the H1 structure Google had indexed. This checklist exists because a redesign is not a design project with a technical afterthought - it is a technical migration that happens to include new design.
Why redesigns fail more often than new builds
A brand-new website has no history to protect. A redesign does. Every page has backlinks pointing at a specific URL, analytics history tied to specific event names, and rankings tied to specific title tags, internal linking patterns and content depth. Change any of those without a plan and you are not improving the site - you are starting its SEO and conversion history over from zero. The checklist below is organized around the four things that actually break during redesigns: URLs and redirects, content and on-page SEO, analytics and tracking, and conversion paths.
Pre-project: scoping and discovery
Inventory the existing site before anyone touches design
- Full URL crawl (via Screaming Frog or Sitebulb) exported with status codes, indexation status, title tags, meta descriptions, H1s and word count
- Google Search Console export of top-performing pages by clicks and impressions over the last 12-16 months
- Backlink report (Ahrefs or Semrush) identifying which URLs hold external link equity - these must not disappear or change without a 301
- List of pages generating organic conversions or assisted conversions in Google Analytics 4, not just top-traffic pages
- Audit of existing structured data (schema markup) currently live on the site
Define what "redesign" actually means for this project
Is this a visual refresh on the same CMS and URL structure, a full platform migration (WordPress to a headless stack, for example), or a content and IA overhaul that will change navigation and URL paths? Each answer changes the risk profile. A visual-only refresh on stable URLs carries low SEO risk. A platform migration with new URL slugs carries the highest risk and needs the most rigorous redirect planning.
URL structure and redirect mapping
Build a one-to-one redirect map before development starts
Every old URL that has traffic, backlinks, or indexation needs a documented destination on the new site - not a blanket redirect to the homepage. A spreadsheet with columns for old URL, new URL, redirect type (301, not 302), and a status column marking "tested" is the minimum deliverable. This map should exist before a single template is coded, because it also informs the new site's information architecture.
Common mistakes to check for
- Redirect chains (A to B to C) instead of a single direct 301 - these dilute link equity and slow crawling
- Case-sensitivity mismatches and trailing slash inconsistencies creating duplicate URLs
- Parameter-based URLs (from filters or tracking) accidentally left crawlable and indexable on the new site
- Redirecting to a page with thin or unrelated content just to "get a redirect in place"
Content and on-page SEO continuity
Preserve or improve, never silently downgrade
Copy new title tags, meta descriptions, H1s and body content into a working document before the new templates go live, comparing word count and keyword coverage against the old version. Design teams routinely shorten copy to fit a cleaner layout - this is where rankings quietly erode. If content is being consolidated (three thin pages merged into one), each consolidated URL needs its own entry in the redirect map, and the merged page needs to actually cover what the old pages covered.
Internal linking
New navigation and footer structures often break internal link paths that were feeding authority to deep pages. Map which pages previously received internal links from high-authority pages and confirm the new IA still links to them, even if the visual navigation is simplified.
Analytics, tracking and tag continuity
Tracking breaks silently, not loudly
GA4 property configuration, conversion events, Google Tag Manager containers, and any custom event tracking (form submissions, phone click tracking, e-commerce events) need to be rebuilt and tested on a staging URL before launch, not patched after. A common failure: the new dev team installs a fresh GTM container without importing existing tags, so the site launches with zero conversion tracking for days or weeks until someone notices the dashboards are empty.
- Confirm GA4 measurement ID matches production before DNS cutover
- Test all conversion events (contact form, quote request, add-to-cart, phone click) on staging with GA4 DebugView
- Re-verify Google Search Console property and submit the new XML sitemap immediately at launch
- Check that heatmap or session-recording tools (Hotjar, Clarity) are reinstalled and firing
- Preserve UTM-tagged campaign URLs still driving paid or email traffic, or redirect them correctly
Conversion path and UX checks before launch
Test the paths, not just the pages
A redesign can look better and convert worse. Forms with new validation logic, checkout flows with a changed number of steps, or click-to-call buttons that got restyled into non-clickable text on mobile are common regressions. Walk every primary conversion path - contact form, quote request, checkout, booking - on real devices, not just in a desktop browser at 100% zoom.
Site speed and Core Web Vitals
New design frameworks and heavier front-end libraries frequently regress Largest Contentful Paint and Cumulative Layout Shift scores compared to the old site. Run PageSpeed Insights or Lighthouse on staging for the top 10 pages by traffic before launch, and compare against the current live scores - not against an arbitrary "green" target that ignores where the site started.
Launch day sequence
- Freeze content changes on the old site 24-48 hours before cutover so the redirect map stays accurate
- Deploy redirects and confirm a sample of high-traffic and high-backlink URLs return 301s, not 200s on old paths or 404s
- Update DNS and confirm SSL certificate is valid on the new hosting immediately
- Submit new sitemap.xml in Search Console and request indexing for key pages
- Verify GA4 and GTM are firing correctly within the first hour of traffic
- Check robots.txt has not accidentally blocked crawling on the new environment
Post-launch monitoring (first 30-90 days)
What to watch, and when to worry
Some ranking fluctuation in the first two to four weeks is normal as Google re-crawls and re-evaluates the site. What is not normal: a sustained drop in organic clicks in Search Console beyond four weeks, a spike in 404 errors in the crawl stats report, or a conversion rate drop that persists after UX issues are fixed. Set a recurring weekly check on Search Console's Pages report, GA4 conversion trends, and server log 404s for at least the first two months.
Comparing proposals using this checklist
When evaluating redesign proposals, ask directly whether the vendor's scope includes redirect mapping, GA4/GTM migration, and pre-launch Core Web Vitals testing as line items - not as assumed "included" work with no deliverable attached. Urgent IT Solution treats these as explicit, documented steps in every redesign engagement precisely because they are the parts that get skipped under deadline pressure and cause the most damage after launch.
