Author: Mahmudur Rahman

Pre-launch guide

A website redesign should improve the experience without making valuable pages disappear, breaking lead journeys or leaving your measurement blind. The safest projects treat search visibility, conversion paths and tracking as launch requirements—not tasks to revisit after the new design is live.

This website redesign SEO checklist is for business owners, marketers and project leads planning a substantial visual or structural change. It covers what to record before development, what to preserve during the build, how to test the release, and what to monitor after launch.

If you are still defining objectives, content and required functionality, start with our website design brief checklist. Then use this guide to turn those requirements into a controlled migration and acceptance plan.

A redesign needs a measurable starting point. Export or record the pages that currently attract qualified organic visits, generate enquiries, support paid campaigns, earn external links, or help prospects make a decision. Include service pages, location pages, guides, tools, contact routes and confirmation pages.

Do not judge value from traffic alone. A low-traffic page may support a valuable search query, assist a sale, answer an objection or serve as the destination for an advertisement. Combine search data, analytics, form or CRM evidence, and stakeholder knowledge. Note the reporting window and any known measurement gaps so the team does not compare unlike periods later.

Capture representative screenshots and key template behaviour on desktop and mobile. This is not only a visual archive; it records calls to action, form fields, disclaimers, trust elements and content that can be accidentally omitted when attention shifts to the new layout.

Build one inventory that connects the current site to the proposed site. Give each existing indexable URL one clear decision:

• Keep: the address and purpose remain substantially the same.
• Improve: the address remains, while content or design becomes more useful.
• Merge: overlapping pages become one stronger destination.
• Move: the content needs a new address and a permanent redirect.
• Retire: the page no longer serves users and has no relevant replacement.

Preserving a useful URL is usually simpler than changing it for visual neatness. When an address must change, map the old URL directly to the closest relevant new page. Avoid sending every removed page to the homepage; that fails to preserve the visitor’s intent and makes the migration harder to diagnose.

Google’s site-move guidance recommends preparing a mapping from old URLs to new URLs and setting up server-side permanent redirects. The mapping should include images, downloadable files and campaign landing pages when those assets are moving too.

A redesigned page can look better while becoming less clear. For each priority URL, state the visitor’s question, the service or topic, and the next useful action. Keep important answers in crawlable text rather than hiding everything behind sliders, images or interaction states.

Review the document title, meta description, one visible H1, descriptive H2 and H3 structure, image alternatives, link text and calls to action. Headings should describe the content that follows. Internal links should help both visitors and search engines move from supporting guides to service pages, related evidence and contact routes.

Update links in the page body, navigation, footer, breadcrumbs, related-content blocks and structured data so they point directly to final destinations. Relying on redirects for internal navigation wastes a useful opportunity to make the new architecture explicit.

A permanent move needs consistent signals. Google documents 301 and 308 server-side redirects as permanent redirects, and it treats redirects as a strong canonical signal. Test each redirect from the old address to the intended final URL, including uppercase variants, trailing-slash patterns and commonly linked parameters where they matter.

Each live page should have a canonical that matches the preferred public URL unless there is a deliberate reason to point elsewhere. Google’s canonical guidance explains that redirects, rel="canonical" and sitemap inclusion are signals used to identify the preferred version. Do not make them disagree.

• Remove staging passwords or blocks only when production is ready.
• Check that copied noindex directives are not left on public pages.
• Keep admin, cart, account or internal search areas controlled as intended.
• Generate a sitemap containing preferred, indexable, successful URLs—not redirects or error pages.
• Update robots.txt carefully; it is not a substitute for a page-level indexing decision.
• Use Google Search Console’s Change of Address process only when the site is moving from one domain or subdomain to another, not for an ordinary redesign on the same host.

If the redesign also changes domain, protocol, hosting and content, separate the work where practical. Fewer simultaneous variables make problems easier to identify and reverse.

Tags can disappear when templates, consent tools, forms or thank-you behaviour change. Start with a measurement plan that names each action, where it occurs, what success looks like and which platform should receive it.

Use browser and platform diagnostics rather than trusting that a container published successfully. Google Analytics provides DebugView for monitoring events from a debug-enabled device. Validate parameters, consent behaviour and event duplication as well as the event name. Then confirm important advertising and analytics actions in the relevant receiving platforms.

If your current measurement is incomplete, RDA’s Google Tag Manager setup service can help translate lead journeys into a maintainable implementation. Our guide to GA4 and GTM conversion tracking explains the wider setup context.

Performance is easier to protect when it is a design constraint. Large hero media, multiple font files, animation libraries, third-party widgets and oversized JavaScript can turn a polished prototype into a slow public page.

The current Core Web Vitals guidance defines “good” thresholds as Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint within 200 milliseconds, and Cumulative Layout Shift no greater than 0.1, assessed at the 75th percentile of page loads. These field-oriented targets are useful acceptance criteria, but a launch review should also include repeatable laboratory checks and real mobile interaction.

• Optimise the main image for its displayed size and format.
• Reserve image and embedded-media dimensions to reduce layout movement.
• Load non-critical media and scripts only when needed.
• Keep primary navigation and calls to action usable before optional widgets finish.
• Test a representative service page, article, form and commerce template rather than only the homepage.

Record the device, connection profile, page, test tool and result. A single perfect desktop score does not describe how a prospect experiences the site on a mid-range phone.

Accessibility supports people who use keyboards, screen readers, zoom, voice input or different visual settings. It also exposes weak interaction design that can affect any visitor.

Use the W3C’s Web Content Accessibility Guidelines (WCAG) 2.2 as the technical reference appropriate to your project. Automated scans can find some problems, but they cannot confirm whether content is understandable or whether a complete journey works with assistive technology.

• Every interactive control can be reached and operated with a keyboard.
• Focus is visible and does not disappear behind sticky headers or floating controls.
• Form fields have programmatic labels, instructions and useful error messages.
• Text and controls retain sufficient contrast in default, hover, focus and disabled states.
• Heading order and landmarks make the page understandable out of visual context.
• Meaningful images have useful alternatives; decorative images are handled appropriately.
• The page remains usable when text is enlarged and at a narrow mobile width.

A form can pass a visual test and still fail the business. Test from the public landing page through submission, notification, CRM or inbox delivery, confirmation, analytics and follow-up ownership. Use safe test details and clearly identify test records so they are not mistaken for real prospects.

Check required fields, invalid formats, long entries, duplicate clicks, slow responses, file uploads where used, spam controls and privacy or consent text. Confirm the visitor sees a useful success or error state and knows what happens next.

On mobile, inspect floating contact buttons, cookie controls and sticky navigation at the top, middle and bottom of the page. A widget that covers a submit button or key paragraph can damage a journey even when automated accessibility or link checks pass.

Launch-day sequence

1. Freeze unplanned content and configuration changes.
2. Take restorable backups of the website, database and critical configuration.
3. Confirm DNS, certificates, hosting, cache, CDN and email dependencies.
4. Deploy the approved build and apply the final redirect map.
5. Remove staging-only restrictions and confirm intended production indexability.
6. Test priority URLs, redirects, canonicals, sitemap, structured data and navigation.
7. Complete logged-out desktop and mobile lead journeys.
8. Validate analytics and advertising events without polluting business reports with uncontrolled tests.
9. Check server logs, browser errors, broken resources and unexpected status codes.
10. Record the release time, version, owners, known issues and rollback decision point.

For larger sites, release during a period when the responsible technical, marketing and business owners are available. A quiet traffic window is not useful if nobody can approve a rollback or diagnose a failed integration.

What to monitor after launch

Review the site more frequently in the first days, then continue at agreed weekly and monthly intervals. Compare against the documented baseline while accounting for normal demand, campaigns and reporting delays.

• Old URLs returning 404 or redirecting to irrelevant destinations.
• Priority pages becoming excluded, duplicated or unexpectedly canonicalised elsewhere.
• Sitemap processing and important-page discovery in Search Console.
• Organic landing-page changes by page and query group, not only sitewide totals.
• Form, call, WhatsApp and other lead actions from source to destination.
• Mobile performance and layout shifts on real templates.
• Browser, application and server errors.
• Sales-team reports of missing context, poor lead routing or broken follow-up.

Not every movement is caused by the redesign, and reporting systems do not update at the same speed. Investigate page-level evidence before rewriting content or reversing a technical decision. When a defect is clear, fix the narrowest responsible layer and retest the full journey.

Worked example: a service-business redesign

Imagine a consultancy replacing an old five-page site with a new service-led structure. The current homepage receives branded visits, two service pages attract non-branded searches, and the contact form records a thank-you page as a lead.

A weak migration publishes the new design, renames every URL, links all old pages to the homepage, and installs the analytics tag without testing the form. The site appears modern, but search visitors reach less relevant destinations and the team cannot tell whether enquiries stopped or measurement broke.

A controlled migration keeps the two proven service URLs where practical, maps each changed address to a relevant replacement, retains the useful questions and proof from the old pages, and updates internal links. The team tests the contact form from page load to inbox and analytics, checks mobile performance and keyboard use, submits the clean sitemap, and reviews errors daily after release. The redesign is then a managed business change rather than a visual gamble.

Questions to ask a redesign partner