What belongs on a website redesign launch checklist?

A website redesign launch checklist exists to protect one thing above all: the rankings the client already has. A redesign is the moment those rankings are most at risk, because URLs, metadata, and tracking can all change at once. So the checklist organizes around three jobs, protecting URLs, protecting on-page SEO, and protecting measurement, plus a parity check to catch what slipped. WPBuildAI crawls the old site, builds the redirect and metadata map, and verifies parity, so a redesign launches without losing the client’s traffic.

The checklist, grouped by what it protects

URLs. Crawl the old site, map every URL, and 301 each one to its new page before launch. Google’s site move guidance makes this map the core of a safe launch, its redirects guidance confirms the 301 is what carries the ranking signals across, and the spreadsheet form is the URL mapping template.

On-page SEO. Carry over titles, meta descriptions, canonicals, and schema, and preserve headings and image alt text. Backlinko’s analysis of 11.8 million search results found these on-page signals correlate with ranking, so losing them thins pages overnight.

Measurement. Confirm analytics and Search Console still fire on every template, the break covered in why analytics stops after a redesign.

Grouping the checklist this way, rather than as a flat list, keeps the team focused on outcomes (rankings held, data flowing) instead of ticking tasks.

Why URLs top the list

Unredirected URLs are the single biggest cause of a redesign losing traffic, which is why they head the checklist. A redesign almost always changes some URLs, and any old URL without a 301 returns a 404 and forfeits the rankings and backlinks it held. Ahrefs found in its search traffic study that a small share of pages carries most organic traffic, so missing the redirect on the wrong handful, the pages that actually drove visits, is enough for a visible, sometimes dramatic drop, the failure traced in why traffic falls after a redesign. The defence is completeness: a crawl that finds every old URL, reconciled against analytics and Search Console so orphaned-but-ranking pages are included, then a redirect for each. Because URLs carry the highest risk and the cheapest fix, the crawl and the redirect map come first, before any design work is reviewed.

Building the URL inventory

The redirect map is only as good as the URL list it covers, so the inventory step deserves care. No single source has every URL: a crawl following internal links finds what is reachable, the XML sitemap adds pages the crawl missed, analytics and Search Console reveal orphaned pages that still get traffic, and a backlink export catches externally-linked pages. Merge all of these and de-duplicate, and you have a list far more complete than any one source. The pages an agency most often forgets, old campaign landing pages, paginated archives, PDFs, are exactly the ones a single-source list misses and a multi-source inventory catches. This completeness is the whole game, because a redirect map covering 95% of URLs still breaks the 5% that were probably the oldest, most-linked pages. Build the inventory thoroughly and the rest of the checklist has a solid base.

Protecting on-page SEO

Beyond URLs, the redesign must carry the on-page signals that make each page rank, and these are easy to lose because they are invisible. For every page, confirm the new version keeps its title tag, meta description, canonical, heading structure (one clear H1), and any schema the old page had, plus image alt text. A redesign that rebuilds templates often drops these silently: the content looks right while the title reverts to a generic auto-title and the schema vanishes, which thins the page to a search engine overnight. The crawl-based parity check below is how you catch this at scale. The principle is that the redesign should change how pages look, not what they tell search engines they are, so the metadata layer must survive intact even as the visual design changes completely.

A worked example: a 200-page client redesign

Picture an agency relaunching a 200-page client site on a new design. The crawl-and-reconcile step finds 260 URLs, the 200 known pages plus 60 forgotten ones: old service pages, paginated blog archives, and a few linked PDFs. Each is mapped to a 301. The metadata is carried across so every page keeps its title, description, and schema. Analytics is confirmed on every template, not just the homepage. On staging, a parity crawl compares old to new: it flags three pages whose titles reverted to generic and two old URLs with no redirect, which the team fixes before launch. The site goes live and rankings hold. Had the agency mapped only the 200 known pages and spot-checked the homepage, the 60 forgotten URLs would have 404’d and the reverted titles would have shipped, producing exactly the post-launch drop the checklist exists to prevent.

Verify on staging, then watch

The parity check is what turns a checklist from hopeful to proven. Before going live, crawl staging and compare it to the old site: every old URL should resolve or redirect in a single hop, titles and metadata should match the intended values, and no page should be an empty template or a soft 404. This catches the gaps, missing redirects, reverted titles, dropped schema, while they are still cheap to fix, rather than after the client’s traffic falls. After launch, watch Search Console for a few weeks for new 404s, indexing changes, and structured-data errors, and resubmit the sitemap so the new URLs are discovered. The before-and-after pairing, verify on staging, then monitor live, is what gives an agency confidence the launch was clean rather than hoping it was.

Making it repeatable across clients

For an agency, the real value is turning the checklist into a repeatable, crawl-driven process so quality does not depend on which person ran the launch. The same steps every time, inventory, map, migrate, verify, mean no client launch relies on someone remembering the redirects or the metadata. Automating the crawl and the redirect-map generation removes the manual gaps that cause client traffic drops, and a standard parity check on staging gives every launch the same verification. This is the same discipline as the WordPress migration SEO checklist, applied as a process rather than a one-off. A repeatable process also protects the agency’s reputation: a client whose traffic drops after a relaunch blames the agency, so a verified, identical launch procedure is both better for the client and safer for the agency.

Common mistakes on a redesign launch

The recurring errors all undermine the rankings the checklist is meant to protect. Mapping only the known pages, and skipping the crawl-and-reconcile, leaves forgotten URLs to 404. Spot-checking the homepage instead of running a parity crawl misses template-level breaks like reverted titles and dropped schema. Treating the redesign as done at “it looks great,” before verifying redirects and metadata, ships the breaks live. Forgetting to confirm analytics on every template loses measurement silently. And launching without a post-launch Search Console watch lets a missed redirect go unnoticed until the traffic report does. Each is avoided by the grouped, crawl-driven checklist: protect URLs with a complete inventory and map, protect on-page SEO and measurement by carrying them over and verifying, and prove it with a parity check before and after launch.

Key points to remember

A website redesign launch checklist protects the client’s existing rankings by guarding three things: URLs (crawl and reconcile a complete inventory, then 301 every one), on-page SEO (carry over titles, descriptions, canonicals, schema, and alt text), and measurement (verify analytics and Search Console on every template). Unredirected URLs are the top risk, so the crawl and redirect map come first and must be complete, since a small set of pages carries most of the traffic. Verify with a parity crawl on staging before launch and watch Search Console after, and turn the whole thing into a repeatable crawl-driven process so no launch depends on memory. WPBuildAI crawls the old site, builds the redirect and metadata map, and verifies parity before launch, so each client redesign goes live without losing rankings; send the site URL for a fixed quote.

Not affiliated with WordPress or Lovable.