Website redesign SEO checklist: protect rankings during migration

A website redesign can improve clarity, conversion and performance while quietly removing the URLs, content and signals that earned existing search visibility. The risk is not the new colour palette. It is launching without an inventory, page-level redirect map, content parity check, measurement plan and post-launch monitoring owner.

This checklist is for South African teams redesigning a marketing site, moving to a new CMS, changing URL structure, consolidating services or migrating domains. It turns “remember the SEO” into testable release criteria.

First decide what is actually changing

Different changes carry different risks:

Google maintains separate guidance for hosting changes without visible URL changes and moves that change URLs. Classify the project before estimating or scheduling it.

Build the URL inventory before changing navigation

Crawl the current site and combine that export with analytics, Search Console, sitemap URLs, backlinks, paid-landing-page lists and important links from email or sales materials. No single source contains every valuable URL.

For each page, record:

• current URL and status code;
• indexability and canonical URL;
• page title, primary heading and meta description;
• organic clicks, impressions and conversions;
• inbound links or referral traffic;
• content purpose and target customer intent;
• proposed action: keep, improve, merge or retire; and
• exact destination if the URL will change.

Do not delete a page simply because it received little traffic last month. It may support a high-value journey, rank seasonally, hold external links or answer a sales objection.

Map every old URL to the most relevant destination

A redirect map is a product decision, not a developer afterthought. Each retiring URL needs the closest useful replacement.

Google says permanent redirects such as 301 do not cause a loss in PageRank. Its migration guidance also warns against sending many unrelated old URLs to one destination because that can confuse users and may be treated as a soft 404.

Preserve the content that explains why a page ranks

A redesign often makes pages visually cleaner by removing the detail customers and search engines relied on. Before shortening a page, identify its job:

• Which questions does it answer?
• Which service or problem does it describe precisely?
• What proof supports the claim?
• Which pages does it connect through internal links?
• Which conversion path fits that intent?

Preserve meaning, not necessarily every sentence. Rewrite dated or weak content, but maintain topical coverage and useful evidence. If several thin pages compete for the same intent, combine them deliberately and redirect the originals.

Keep unique titles, meta descriptions, headings, image alternatives and structured data aligned with the new page. Metadata should describe the visible content rather than promise something removed during design.

Control staging so it cannot become the public site

Staging needs two protections: users and search engines should not treat it as production, and the blocking mechanism must be removable at launch.

Use authentication or network access controls where possible. If noindex is used, include its removal in the launch checklist. Do not rely only on robots.txt to hide sensitive staging content; crawling restrictions are not access control.

Before launch, crawl staging as a rendered site and test:

• status codes and redirect chains;
• indexability, canonicals and robots directives;
• page titles, descriptions and headings;
• internal links and orphan pages;
• structured data where used;
• responsive layouts and keyboard navigation;
• image sizes, alternatives and lazy loading;
• forms, calls, bookings and thank-you states;
• analytics, consent and advertising tags; and
• performance on representative mobile devices.

Protect analytics and conversion evidence

Document the existing measurement before replacing it. Record analytics property IDs, tag-manager containers, conversion names, consent behaviour, call tracking, CRM fields and cross-domain configuration.

Create a test matrix for the events that drive decisions:

Compare analytics immediately before and after launch. A sudden “conversion improvement” may be duplicate events; a sudden collapse may be a tag or form failure rather than lower demand.

Build performance into the redesign

Do not wait until launch to discover that the hero image, font stack and scripts make the new site slower. Test key templates throughout development using field and lab evidence. Optimise image dimensions and formats, reserve layout space, reduce unused JavaScript and control third-party tags.

Performance work should support the person using the site. Prioritise pages that receive organic and paid traffic, revenue-critical forms and templates repeated across hundreds of URLs. The goal is a fast, stable journey, not a perfect score achieved by removing useful functionality.

Use Google's explanation of Core Web Vitals to keep the discussion tied to loading, responsiveness and visual stability, then validate the real templates and devices your customers use.

Use a release gate, not a hopeful launch date

The person approving launch should receive evidence for each gate:

Search gate

• URL mapping is complete and reviewed.
• Permanent redirects work directly, without chains.
• Production canonicals reference final URLs.
• No accidental noindex or global crawl block remains.
• Important content and internal links are present.

Experience gate

• Mobile layouts, navigation and accessibility basics pass.
• Forms and calls reach the correct team.
• Error pages return correct HTTP status codes.
• Images and downloads load from production hosts.

Measurement gate

• Analytics and consent behaviour are validated.
• Primary conversions fire once and carry useful context.
• Baseline dashboards and alert owners are ready.

If a critical gate fails, move the launch. Recovering lost leads and signals usually costs more than a short, controlled delay.

Launch in a sequence the team can observe

For a small or medium site, launch during a staffed period with development, content and lead owners available. Activate and verify redirects, then crawl production from the public internet.

Update internal links to point directly to final URLs. Update canonicals, structured data, campaign destinations and prominent external profiles. Generate a sitemap from the actual published database or routing source, not a forgotten hard-coded list.

Google recommends including canonical, fully qualified URLs in sitemaps and says website software should generate them automatically for larger or changing sites. Review its current sitemap guidance. Submit the new sitemap in Search Console; remember that submission is a discovery hint, not an indexing guarantee.

Monitor by page group, not only site totals

Overall traffic can look stable while a profitable service cluster disappears. Compare old and new performance by mapped page group:

• indexed URLs and crawl errors;
• organic clicks and impressions;
• rankings for priority intent groups;
• landing-page engagement and conversion;
• 404s, redirect hits and redirect chains;
• form, booking and call success;
• mobile performance and server errors; and
• paid campaigns still pointing to old URLs.

Google advises retaining redirects for as long as possible, generally at least a year, so signals and old links have time to transfer. From a user perspective, keeping useful permanent redirects longer is often sensible.

Monitoring cadence

• Launch day: crawl production, test priority journeys and inspect server errors.
• First week: review daily for unexpected 404s, indexing blocks, conversion anomalies and traffic shifts.
• Weeks 2–6: compare mapped page groups and resolve content or linking gaps.
• Months 2–3: assess settled visibility, performance and conversion quality; improve rather than reverse changes impulsively.

Some ranking fluctuation is normal while Google recrawls and reindexes a changed site. The migration map helps distinguish expected processing from a broken implementation.

Assign ownership before launch

A rollback plan should explain what can be reversed safely and what data must be preserved. Avoid a panicked full rollback when a targeted redirect or rendering fix will solve the issue.

Redesign without discarding demand

A successful redesign carries forward what already works, improves what does not, and leaves a clear audit trail between the two. Inventory first, map every URL, test the full customer journey and monitor the release by page group.

Luminum can combine product design, development, content, measurement and technical SEO into one migration plan—so the new site is better for customers without becoming invisible to search.