Start before the design files are final
A redesign changes more than colors and components. It can change URLs, navigation, headings, copy, templates, internal links, structured data, performance, and the pages search engines already understand. Google recommends mapping old URLs to new destinations, testing the move, and changing one major system at a time when possible.[1]
The safest first move is an inventory. Export the current crawlable URLs, the sitemap, important landing pages, title tags, meta descriptions, canonical tags, headings, internal links, structured data, and any downloadable assets people still use. Record the intended action for every URL: keep, improve, merge, redirect, or retire. “We will figure it out after launch” is not a migration plan.
Baseline to save
- Every indexable URL and its current HTTP status.
- Page title, description, H1, canonical, robots directive, and schema.
- Navigation and contextual links pointing to high-value pages.
- Current sitemap and robots rules.
- Representative mobile and desktop screenshots.
- Analytics and Search Console annotations for the launch window, when access is available.
Plan URL and content continuity
1. Keep useful URLs when you can
If a page still serves the same purpose, keeping its URL removes unnecessary migration risk. A cleaner-looking slug is not automatically more valuable than continuity. When a URL must change, select one relevant final destination and use a permanent server-side redirect. Avoid redirect chains, blanket redirects to the homepage, and mappings based only on similar words.
2. Align redirects, canonicals, links, and the sitemap
Google treats redirects, rel="canonical", and sitemap inclusion as canonicalization signals. These signals work best when they agree.[2] Update navigation and contextual links to point directly to final URLs rather than relying on redirects. Put fully qualified canonical URLs in the sitemap and remove URLs that should no longer be indexed.[3]
3. Preserve the reason each page deserves to exist
Do not let a new template flatten distinct pages into interchangeable marketing copy. Carry forward the useful answers, proof, service detail, and topic relationships that match the visitor’s intent. Improve weak material deliberately, but do not delete a working information architecture simply because the redesign starts from a blank canvas.
4. Rebuild crawl paths
Every important page needs a discoverable internal link from a relevant hub, service page, or supporting article. Breadcrumbs, related resources, descriptive anchor text, and a coherent navigation hierarchy help visitors and crawlers understand how pages relate. A URL listed only in a sitemap is technically discoverable but poorly integrated.
5. Make accessibility part of the component system
Test semantic headings, keyboard access, visible focus, labels, status messages, contrast, zoom, reduced motion, and navigation behavior before the component library spreads across the site. WCAG 2.2 provides testable criteria for perceivable, operable, understandable, and robust experiences.[5]
Test the staged site like a release candidate
A visual review is not enough. Crawl the staging build and compare it with the inventory. Verify that intended pages return 200, redirected URLs resolve in one hop, missing URLs return a real 404, canonical tags are self-consistent, and indexable pages do not carry accidental noindex directives.
Pre-launch release gate
- Exactly one descriptive H1 on every primary page.
- Unique title and meta description for each indexable URL.
- Valid canonical, Open Graph, and appropriate JSON-LD.
- No broken internal links, missing images, or mixed-content requests.
- Forms, confirmations, analytics, consent tools, and error paths tested without using real customer data.
- Mobile navigation, keyboard flow, skip link, focus visibility, and 200% zoom checked.
- No horizontal overflow at narrow and wide viewports.
- Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift reviewed with field data when available and lab tests used diagnostically.[4]
Keep production-only secrets out of staging. If a protected form or chatbot already works, define it as a boundary: copy the known configuration exactly, test the visible interface without submitting, and compare file hashes so the redesign does not quietly alter lead routing.
Launch in a controlled sequence
Take a complete backup before replacing files. Deploy the smallest coherent set, then request representative old and new URLs as a normal visitor and as major search crawlers. Re-crawl the site, parse the sitemap, inspect rendered pages, and verify the conversion path. If a critical check fails, restore the known-good files rather than debugging on the public site.
After launch, monitor server errors, redirect behavior, indexing reports, organic landing pages, and real-user performance. Expect search systems to recrawl and reprocess changes; technical correctness makes that possible but does not guarantee rankings or traffic. Keep the redirect map and migration log so later issues can be traced to an explicit decision.
Keep planning
Sources
These primary and first-party references informed this guide. They are provided so you can verify the underlying guidance.
Planning a redesign?
Send your current URL and the changes you are considering. I’ll help identify the SEO continuity work that belongs in the scope.
Start the conversation