Website redesign checklist: Core Web Vitals, SEO and accessibility
ElasticMailer team, , 6 min read
A redesign is one of the few projects that can make a website worse in ways nobody notices until traffic and leads fall. The new site looks better in the review meeting, then organic traffic drops 30% because old URLs return 404s, the contact form stops reaching the sales inbox, and the hero video makes the homepage slow on mobile data.
This is the checklist we use for redesigns of business websites, from clinic and real estate sites to B2B SaaS marketing sites. Work through it in order.
Stage 1: before anyone opens a design tool
Record a baseline
You cannot tell whether the redesign worked without numbers from before it.
- Export the last 12 months of organic landing pages, sessions and conversions from Google Analytics 4.
- Export pages, queries, clicks and impressions from Google Search Console.
- Note the current Core Web Vitals report in Search Console for mobile and desktop.
- Record form submissions, calls and WhatsApp clicks per month.
Crawl the current site
Run a crawler (Screaming Frog or similar) and save the full list of URLs, titles, meta descriptions, H1s, canonical tags and status codes. Also list URLs from your XML sitemap and from backlink reports. Some pages that bring links and traffic are not linked from your navigation any more.
Decide what stays, merges or goes
For each URL, mark one of: keep (same URL), move (new URL, 301 redirect), merge (combine into a stronger page, 301 redirect) or remove (410, or redirect only if there is a genuinely relevant replacement). Pages with traffic, conversions or backlinks should never simply disappear.
Stage 2: design and build for performance
Core Web Vitals are Google’s field measures of loading, responsiveness and visual stability, taken from real Chrome users. A page passes when at least 75% of visits are in the “good” range for all three.
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading of the main content | 2.5 s or less | Over 4 s |
| INP (Interaction to Next Paint) | Response to taps, clicks and key presses | 200 ms or less | Over 500 ms |
| CLS (Cumulative Layout Shift) | Unexpected movement of content | 0.1 or less | Over 0.25 |
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. It is stricter, because it looks at responsiveness across the whole visit rather than only the first interaction.
What helps each metric
LCP
- Make the largest above-the-fold element an optimised image or text, not an autoplaying video or carousel.
- Serve images in AVIF or WebP at the size they are displayed. Use
srcsetfor different screens. - Do not lazy-load the hero image. Preload it, or set
fetchpriority="high". - Use a CDN and good hosting. Many Indian business sites still run on shared hosting abroad with slow server response times.
- Limit web fonts to two families and a few weights, and use
font-display: swap.
INP
- Ship less JavaScript. Page builders, chat widgets, multiple analytics tags and heatmap tools all compete for the main thread.
- Load third-party scripts after the page is usable, and remove tags nobody uses.
- Break long tasks up and avoid heavy work in click handlers, such as re-rendering a whole page when a filter changes.
CLS
- Set width and height (or
aspect-ratio) on every image, video and embed. - Reserve space for cookie banners, announcement bars and ads.
- Avoid inserting content above what the user is reading after the page has loaded.
Test on a mid-range Android phone over a 4G connection, not only on a developer’s laptop on office Wi-Fi. That is what most of your Indian visitors use.
Stage 3: accessibility to WCAG 2.2
WCAG 2.2, published by the W3C in October 2023, is the current version of the Web Content Accessibility Guidelines. Level AA is the usual target. Accessibility helps people with disabilities, older visitors and anyone using a phone in bright sunlight, and it overlaps heavily with good SEO and usability.
The basics:
- Text contrast of at least 4.5:1 (3:1 for large text).
- Every image has meaningful alt text, or empty alt text if it is decorative.
- One H1 per page and headings in a logical order.
- Every form field has a visible label, not just placeholder text.
- The whole site can be used with a keyboard, with a visible focus outline.
- Links describe their destination (“View pricing”, not “Click here”).
Criteria added in WCAG 2.2 that redesigns often miss:
- Focus not obscured: sticky headers and chat widgets must not cover the element that has keyboard focus.
- Target size (minimum): tap targets at least 24 by 24 CSS pixels, or with enough spacing around them.
- Dragging movements: anything done by dragging, such as a slider, also needs a simple tap or click alternative.
- Consistent help: contact details or help links appear in the same place across pages.
- Redundant entry: do not make users type the same information twice in one process.
- Accessible authentication: do not rely only on puzzles or memory tests to log in; allow password managers and paste.
Run an automated checker (Lighthouse, axe) and then test key pages by hand with a keyboard and a screen reader. Automated tools catch only part of the problems.
Stage 4: SEO preservation
Redirect map
Build a spreadsheet with every old URL and its new destination, then implement it as server-side 301 redirects.
- Redirect each old URL directly to its final destination. Avoid chains (A to B to C).
- Redirect to the most relevant page, not everything to the homepage.
- Keep old URL patterns for blog posts if you can. It saves hundreds of redirects.
- Include URLs with and without trailing slashes,
wwwand non-www, and oldhttpversions.
On-page elements
- Carry over titles, meta descriptions and H1s for pages that rank well, then improve them carefully.
- Keep the body content of ranking pages. A redesign that turns a 1,200-word service page into three lines and an icon grid often loses its rankings.
- Set self-referencing canonical tags and check that the staging site’s
noindexis not copied to production. - Generate a fresh XML sitemap and reference it in
robots.txt. - Keep structured data (Organization, LocalBusiness, FAQ, Product) working.
Stage 5: forms and analytics
Broken tracking is the most common redesign failure we fix.
- Submit every form on the live site and confirm the lead reaches the inbox, CRM and any auto-responder.
- Add spam protection that does not block real users.
- Recreate GA4 conversion events: form submissions, phone clicks, WhatsApp clicks, bookings.
- Reinstall the Google Ads and Meta conversion tags and test them with each platform’s diagnostic tools.
- If you use a consent banner, check that tags respect it.
- Keep the same GA4 property so you can compare before and after.
Launch-day checklist
- Robots.txt allows crawling and production pages are not
noindex - All 301 redirects live and tested with a crawler using the old URL list
- No important pages returning 404 or 500
- HTTPS everywhere, with no mixed-content warnings
- XML sitemap submitted in Search Console
- Every form tested end to end
- Analytics and ad conversions firing
- Favicon, social sharing images and page titles correct
- Mobile layout checked on real Android and iPhone devices
- Backup of the old site kept for at least three months
After launch
For the first four weeks, check Search Console every few days for crawl errors and 404s, and fix any redirect you missed. Compare organic landing page traffic with your baseline after four and eight weeks. Some movement is normal; a steady drop on specific pages usually points to a missing redirect or removed content. Core Web Vitals field data takes about 28 days to reflect the new site.
If you are planning a redesign and want an outside view of what to protect first, our free audit covers speed, SEO and tracking on your current site.