WordPress Website Redesign Checklist: How to Improve UX, SEO, and Conversions

A WordPress redesign checklist for search, usability, and enquiries

A new WordPress theme can change more than colours and layout. Because a theme controls how stored content is presented, including templates, CSS, and front-end structure, a redesign can quietly break navigation, forms, and page headings that were working. If URLs change, Google may need to recrawl and reindex the site, and search visibility can fluctuate for a time.

A redesign, then, is a change to how the site looks, works, performs in search, and produces enquiries or sales. Success on all four is the goal, though none is guaranteed.

This guide follows the order of the work: baseline audit, theme and development approach, mobile and accessibility, search protection, performance, plugins and security, then launch and monitoring. A concise pre-launch checklist appears before the final section.

Record what the current site does before you change it

A baseline is a saved snapshot of how the site performs today, so you can compare it with the redesigned site after launch. A conversion is any action you want visitors to take, such as submitting a form or calling.

Capture these before touching the theme:

• Top organic landing pages from the Search Console Performance report, with the date range, filters, search type, and export date noted. Exports are limited to 1,000 rows.
• Conversion paths and forms, plus the GA4 key events that track them.
• Core Web Vitals status from Search Console, which groups similar URLs.
• Templates, active plugins, custom code, and PHP version, found in Site Health.

Recording templates, plugins, and settings now gives you something concrete to check after launch.

Here is an illustrative example with no real figures. A service page earns steady impressions, but its contact form sits below three screens of text, it has only two internal links, and it loads slowly on phones. The audit points the redesign toward a visible form, more internal links, and lighter mobile media, while the URL stays unchanged.

Saved together, these records let you judge the launch against evidence instead of memory.

Pick a theme approach, then set up staging and a template plan

Start with an inventory of the current themes, page builders, plugins, content dependencies, and template needs. The template hierarchy works as a checklist: pages, posts, archives, search results, and 404 pages each need a design.

A block theme lets editors design headers, footers, and content with blocks. A child theme changes a parent without editing its files, but WordPress allows only two levels, and heavy customization gets hard to manage. At that point, forking the parent into a full theme is often better. For a simple design preset, a style variation may be enough.

In a block theme, the Site Editor puts every page type’s template in one list you can plan around.

Teams without in-house developers can bring in website design and development services for a custom or child-theme build.

Build on a staging copy and block search engines from indexing it. Keep the theme in version control, and back up the site before any update. Then write the template plan: each page type, its template, and the content that fills it.

Check usability on phones, keyboards, and the full enquiry path

Test the redesign on real phones and tablets, then walk the whole path from landing page to submitted form. Easier enquiries and fewer abandoned forms come from removing friction at each step, and no check below guarantees a particular gain.

• Use a responsive layout so each page keeps one URL.
• Keep mobile headings, internal links, and structured data equivalent to desktop.
• Meet WCAG 2.2 contrast: 4.5:1 for normal text, 3:1 for large text.
• Check tap targets against WCAG 2.5.8 (Target Size, Level AA).
• Tab through everything without a mouse. Focus must stay visible and not be hidden behind sticky headers, and a skip link should jump past the menu.
• Give every form field a visible label.
• In classic themes, confirm menu locations are assigned, because WordPress can fall back to an unintended menu.

The enquiry button should look and work the same on a phone and a laptop, including when you reach it with the Tab key.

An “Accessibility Ready” theme label means minimum review standards, not full WCAG compliance. Tools such as aXe and WAVE help, but manual testing is still required.

Map every URL before the new theme goes live

Crawl the live site and map each current URL to its destination before launch. A new WordPress theme does not require new permalinks, so where a URL stays, leave it alone. Redirects are for URLs that change or content that is removed or merged, and each unnecessary one adds a hop.

Use permanent server-side redirects such as 301 or 308, and point each old URL straight at its final destination, since redirect chains add latency.

Canonical tags, internal links, redirects, and XML sitemaps should all name the same preferred URL. Google treats a declared canonical as a preference, not a rule, so conflicting signals can lead it to pick a different URL. Keep titles, headings, and structured data on retained pages.

Before launch, check for three staging leftovers: a “discourage search engines” setting or noindex tag, a robots.txt that still blocks crawling, and redirect chains from stacked old and new rules.

After launch, submit the sitemap instead of requesting indexing URL by URL, and spot-check key pages with URL Inspection. Temporary ranking fluctuations can follow a launch, and no step here guarantees they will not.

Set Core Web Vitals targets and test them in two ways

Set targets before design sign-off: LCP (how quickly the main content appears) at 2.5 seconds or less, INP (how fast the page responds to taps and clicks) at 200 milliseconds or less, and CLS (how much the layout jumps) at 0.1 or less. A page passes when 75% of visits meet all three, measured separately for mobile and desktop. INP replaced FID in March 2024.

Use lab tests on staging to find causes. Use field data, which PageSpeed Insights reports over a rolling 28 days, to judge real visitors after launch.

Tie findings to redesign choices: sliders, page-builder output, web fonts, embeds. WordPress skips lazy-loading for the first content image, but check that hero images in custom templates are not lazy-loaded.

Prune plugins, lock down access, and confirm backups

Remove plugins that duplicate theme or builder features, and test the rest on staging. WordPress names keeping the platform and extensions current as its most important general security practice. Review pending updates under Dashboard, then Updates. Give each user only the role their work needs, and remove unused accounts. Confirm you can roll back before enabling automatic plugin and theme updates.

Pre-launch checklist:

• Baseline data saved
• Redirect map tested
• noindex removed
• Canonicals and sitemap checked
• Forms and tracking tested
• Accessibility pass done
• Core Web Vitals checked
• Full backup (files and database) restored once as a test
• Plugins, themes, and core updated
• Staging blocked or removed

Check the launch day by day and compare with your baseline

Inspect representative pages with URL Inspection, submit the new sitemap, and walk through old URLs to confirm redirects. Run each form and GA4 event in DebugView.

• First day: indexing status, redirects, forms, events.
• First week: crawl errors, sitemap status, field Core Web Vitals.
• First month: compare date ranges against your baseline, filtered to redesigned pages.

Keep redirects for at least one year. Results vary, and no outcome is guaranteed. Adjust based on what the data shows.