A site redesign carries major SEO and conversion risk if technical fundamentals, content preservation, and redirect mapping are mishandled. This checklist walks through the critical pre-launch, migration, and post-launch tasks that prevent traffic loss and protect years of ranking equity.
Before anyone touches a line of code or opens Figma, establish what you currently have. Export a full XML sitemap and crawl your live site with Screaming Frog or Sitebulb to generate a complete URL inventory. Pull Google Search Console performance data for the trailing twelve months and isolate your top 500 landing pages by sessions and conversions—these are non-negotiable to preserve. Download HTML snapshots of key templates and high-value pages so you have a reference when content mysteriously vanishes during migration. In Canada, bilingual sites need separate inventories for English and French paths, especially if you are restructuring how language selectors and hreflang tags work. Document current Core Web Vitals in PageSpeed Insights and CrUX for each template type. Note which pages have featured snippets, rich results, or Local Pack inclusion. This baseline becomes your success criteria: a successful redesign maintains or improves these positions, and any regression triggers immediate investigation. If your site has ten years of blog archives or resource sections, catalog them now. Agencies and in-house teams routinely lose entire content branches because no one verified staging matched production.
Decide early whether URL paths will change. The lowest-risk redesign keeps every URL identical and updates only visual design, code architecture, and page speed mechanics. If you must change paths—merging sections, flattening hierarchy, moving from dated archives to evergreen slugs—build a redirect map before development begins. Export your URL inventory and create a spreadsheet with old URL, new URL, and redirect type. Every single page that changes location needs a direct 301, not a redirect to the homepage or a category index. Pattern-based redirects handle bulk moves but always leave exceptions: pagination, query parameters, regional subfolders for Canadian provinces, case variations. Manual QA is non-negotiable. In WordPress migrations, plugins like Redirection or Yoast handle simple cases, but complex portfolios need server-level rules in Apache or Nginx for performance. Avoid redirect chains—if page A redirected to B and now B redirects to C, rewrite the rule so A goes straight to C. Test redirects in staging by hitting old URLs and confirming they return 301 status and land on the intended destination, not a 302 or soft 404.
Redesigns kill SEO when content changes underneath the new layout. Marketers assume designers and developers will port everything verbatim, but compression happens—paragraphs get trimmed for mobile aesthetics, secondary CTAs disappear, FAQ schema gets dropped. Compare staging against production at the HTML level. Check title tags, meta descriptions, H1 hierarchy, image alt attributes, and structured data. If the old page had an FAQ block with schema markup that earned a rich result, the new page needs identical markup even if the design differs. Internal linking often breaks when navigation structures change. A sidebar widget that linked to ten cornerstone guides might vanish in a minimalist redesign, orphaning those pages. Rebuild those links in footer menus, in-content contextual links, or resource hubs. Canadian bilingual sites must ensure both language versions migrate in parallel with matching hreflang annotations. If the old site had English at /en/ and French at /fr/, and the redesign consolidates to subdomain or root-level language selectors, update hreflang sitemaps accordingly. Pagination, filters, and search result pages need robots meta and canonical tags preserved exactly as before to avoid indexation chaos.
A visually perfect redesign can still fail in Google's renderer. Crawl staging with user-agent spoofing set to Googlebot and compare rendered HTML to the initial server response. JavaScript frameworks that rely on client-side rendering often serve empty shells to bots if server-side rendering or dynamic rendering is misconfigured. Check that critical content, internal links, and schema appear in the raw HTML, not injected seconds later by React or Vue. Core Web Vitals almost always regress during redesigns because new CSS frameworks, hero videos, and animation libraries bloat page weight. Run Lighthouse audits on mobile and desktop for each major template. Identify render-blocking resources, oversized images, and layout shifts caused by ads or lazy-loaded embeds. If migrating hosting—common when moving from shared hosting to managed WordPress or headless CMS—validate DNS propagation, SSL certificates, CDN rules, and firewall settings in staging. Canadian agencies often deal with clients who have legacy .ca domains pointed to outdated nameservers; a redesign is the moment to consolidate under Cloudflare or a modern DNS provider. Test forms, search functionality, and any dynamic elements like calculators or booking widgets in staging across browsers.
Staging must mirror production configuration: same CMS version, same plugins, same server environment. A redesign that works in staging on PHP 8.1 but launches to production still running 7.4 will break. Crawl staging completely and compare the URL count to your production inventory—if production had 1,200 indexed pages and staging only shows 980, find the missing 220 before launch. Check robots.txt and meta robots to ensure staging blocks indexing but production allows it. Verify all third-party integrations: analytics tags, Google Tag Manager containers, CRM tracking pixels, chat widgets, and any API dependencies. Confirm GA4 events fire correctly for conversions, scroll depth, and file downloads. If you are switching from Universal Analytics historical data, document the new event schema so reporting remains comparable. Security headers, HTTPS enforcement, and redirect rules need testing in staging. Hit old URLs, mistyped paths, and http:// versions to confirm they resolve correctly. Canadian e-commerce sites must test provincial tax calculation and bilingual checkout flows if those touch redesigned templates. Create a launch-day runsheet: DNS cutover steps, cache purging sequence, CDN invalidation, Search Console property verification, and rollback plan if traffic drops unexpectedly.
The two weeks after launch are critical. Monitor Google Search Console daily for crawl errors, coverage issues, and manual actions. A spike in 404s or server errors indicates broken redirects or missing pages. Check that your XML sitemap submitted successfully and that Google is discovering new URLs at the expected rate. In Google Analytics, compare sessions, bounce rate, and conversion rate week-over-week against the pre-launch baseline. A sudden drop in organic traffic to a specific section signals a redirect failure or noindex tag left in production. Use server log analysis to see exactly which pages Googlebot is hitting and whether any return unexpected status codes. Soft 404s—pages that return 200 but contain thin or missing content—are common post-redesign when template logic fails. Canadian sites with regional targeting should verify that geolocation and language detection still work: a Toronto user hitting the homepage should see English by default, a Montreal user should have the option for French. Re-crawl the live site with the same tool used in staging and diff the results. Any discrepancy in URL count, internal link structure, or meta tags needs immediate investigation. If rankings drop for high-value keywords, check whether the target page changed URLs without a redirect, lost key content, or now has a noindex tag. Speed and usability issues surface under real traffic—monitor Core Web Vitals in CrUX and address any regressions within the first month.
Indefinitely. Once a 301 redirect is in place, Google and users rely on it. Removing redirects after six months or a year can cause previously recovered pages to 404 again, losing all the ranking equity you worked to preserve. Redirects are lightweight server-side rules with negligible performance cost, so there is no benefit to removing them.
Phased rollouts reduce risk if you have a large site with distinct sections. Launch the homepage and core landing pages first, monitor for issues, then migrate blog archives or resource libraries. However, phasing complicates redirect logic and can create UX inconsistencies where navigation points to both old and new templates. For smaller sites, a single coordinated launch is simpler and faster to troubleshoot.
Failing to map redirects at the individual URL level. Teams assume developers will handle it or rely on automated pattern matching, but edge cases always exist—pagination, query parameters, archived content, regional variants. Every URL that changes location needs a verified 301 redirect, tested in staging before launch. Missing even a handful of high-traffic pages can cost thousands in lost organic sessions.
Yes, and verify that the sitemap reflects the new URL structure. If URLs changed, the old sitemap will list paths that now 301 redirect, which is inefficient. Generate a fresh XML sitemap from the live redesigned site, submit it in Search Console, and monitor the coverage report to ensure Google discovers and indexes the new pages at the expected rate.
Ensure both language versions migrate simultaneously with matching URL structures and updated hreflang annotations. If English lives at /en/ and French at /fr/, maintain that pattern or update hreflang sitemaps if consolidating to a different structure. Test language detection, navigation switchers, and geo-targeting in staging. Each language version needs its own redirect map and content preservation checklist.
Screaming Frog or Sitebulb for full-site crawls and URL inventory comparison. Google Search Console for baseline indexation and performance data. PageSpeed Insights and Lighthouse for Core Web Vitals audits. A diff tool like Beyond Compare or WinMerge to compare HTML snapshots and redirect maps. Server log analyzers like GoAccess or Logflare to verify Googlebot behavior post-launch.