Checklist
Website launch checklist
A website launch checklist covering the checks that actually block a go-live: functionality, cross-browser, forms, analytics, redirects, and rollback.
The website redesign checklist, as a regression checklist
A website redesign checklist is a regression checklist. It covers the baseline captured while the old site is still up, a url inventory with its redirect map, content parity recorded page by page, the forms and tracking attached to those pages, regression across everything that was not redesigned, accessibility and performance compared against the old measurements, the cutover, and a watch window with a named owner.
- Checklist
- 11 groups
- 51 checks
- Updated
A redesign is not a launch. A launch puts something new in front of people, so the worst case is that it does not work yet and somebody says so. A redesign replaces a surface that already worked, was already indexed, was already linked from pages nobody on the team controls and already sat in somebody's bookmarks. The worst case there is quieter: something that worked last week stops, and it stops on a page that looks better than it did before, which is why it can run for a month without being reported.
In the checklist
- Before the old site comes down 6
- Url inventory and redirects 6
- Content parity 5
- Navigation and the paths people already knew 4
- Forms, tracking and integrations 6
- Regression on what was not redesigned 5
- Accessibility 4
- Performance 3
- Cutover 4
- After the switch 5
- Rollback 3
Website redesign checklist, ready to copy
Copy it as it is. There is no email step, and nothing on this page is behind one.
Before the old site comes down
Url inventory and redirects
Content parity
Navigation and the paths people already knew
Forms, tracking and integrations
Regression on what was not redesigned
Accessibility
Performance
Cutover
After the switch
Rollback
Every group below is a comparison, and that sets the one limit worth planning around: the reference is the old site, and it stops being observable the moment it is replaced. A crawl, a list of forms and their destinations, the tag identifiers, the numbers per template. Whatever was not captured while the old site was up cannot be captured afterwards, and the question of whether a page used to bring in traffic turns into a disagreement between two people's recollections.
What each group is for
Scroll the table sideways for the examples.
| Group | Why it earns its place | Example |
|---|---|---|
| Before the old site comes down | A crawl with status codes and metadata, the top pages by traffic and by entry, every form with the destination it delivered to, the tracking identifiers, and performance measured per template. This is the only group on the list with a deadline that is not the launch date, because the evidence is deleted by the change itself. | Crawl exported the week before the switch: 412 urls, their titles, canonicals and status codes, kept alongside the traffic export. |
| Url inventory and redirects | Every old url resolves to a new url, a deliberate 404 or a 410, as a 301 with no chain longer than one hop, and query strings and anchors survive the hop. A redesign usually changes the url scheme wholesale, so this is not a handful of exceptions but a table with a row for every page that existed. | /services/web-design maps 301 to /work/web-design. /2019-conference returns 410, because it is gone and should stop being requested. |
| Content parity | Each page of the old site is marked kept, merged or retired, with a name against the decision. What disappears in a redesign is never the home page; it is the pricing note sales relied on, the support article carrying search traffic, the legal page linked from a signed contract. | Old FAQ merged into the new pricing page: the two answers about billing cycles were carried over verbatim. |
| Navigation and the paths people already knew | Every task reachable from the old header still reachable, renamed sections keeping their old label as a search synonym, internal search answering the terms the old site was found by, and the deep links held in bookmarks, documentation and help articles still landing. A redesign reorganises the navigation for people who have never used the site, and in doing so breaks it for everyone who had already learned it. | The old Support link is gone and its three tasks now sit under Help, so searching for support still returns them. |
| Forms, tracking and integrations | Forms verified at their destination, hidden fields the CRM depends on still present in the new markup, and analytics goals remapped to the selectors and urls that changed. New markup breaks the tracking attached to the old markup silently, and the failure looks like a quiet week rather than an error. | Demo form submitted end to end: the lead reached the CRM with its source field intact, not blank. |
| Regression on what was not redesigned | Sign in, checkout, transactional emails, admin screens, and every page sharing a template or component with the redesign. The brief scopes the redesign to some pages; the deployment ships a change to a shared layer, and anything on that layer is inside the blast radius whether or not it was in scope. | Checkout was out of scope and still inherited the new button styles, which pushed the pay button below the fold on small viewports. |
| Accessibility | Keyboard reach and a visible focus indicator on every interactive element, contrast checked against the new palette rather than inherited from the old one, and the heading order still forming one outline after the new layout reordered it. The item worth looking hardest at is whatever the old site happened to get right and the new design may have quietly dropped. | The old site's skip link survived the rebuild, but its target had moved, so it skipped to nothing. |
| Performance | New numbers compared against the baseline per template rather than against a generic target, images sized for the slots the new layout gives them, and the fonts, scripts and embeds the redesign added accounted for one by one. A redesign that is faster than the industry and slower than the site it replaced is still a regression. | New article template loads heavier than the old one on a mid-range Android, traced to two fonts and an unused carousel script. |
| Cutover | TTL lowered ahead of the switch, CDN and page caches purged and the purge confirmed from outside the network, certificates valid for every hostname including the ones that only redirect, and the production robots.txt read after the switch rather than before. | Cache purged, then the old markup was still served to a colleague on another network for eleven minutes. |
| After the switch | A named owner reading the 404 log, the form arrival rate against the baseline, the old top pages in search reporting, and whatever support and sales are hearing, for a fixed number of days with an end date. Redesign defects surface as complaints from regular users, and they surface early or never. | Two weeks of daily review, owned by one engineer; the 404 log found nine linked urls the map had missed on day two. |
| Rollback | The previous site can be restored, somebody has done it once, the redirect map reverts with it, and a named person can make the call out of hours. Reverting a redesign without reverting its redirects puts the old pages back while every inbound link still points at urls that no longer answer. | Restore rehearsed on staging, with the redirect map versioned alongside the deploy so the two go back together. |
A redirect plan that looks finished, and one that is
Not this
[ ] Redirects set up for the old pages
This instead
[ ] Every url in the pre-launch crawl resolves to a new url, a deliberate 404 or a 410 [ ] Each one is a 301, with no chain longer than a single hop [ ] Query strings and anchors survive the hop [ ] The list was checked against the crawl rather than against memory
A redesign usually changes the url scheme wholesale, so redirects are not a handful of exceptions; they are a table with a row for every page that existed. The first version gets ticked by whoever set up the eleven they remembered. The second cannot be ticked without the crawl, which is also the one artefact on the list that stops existing the moment the old site comes down.
The baseline only exists while the old site does
A crawl of the old site, an export of its top pages, a list of every form and the destination it delivered to, the tag identifiers, and the numbers each template posted. All of it is cheap to collect while the site is up and impossible to collect once it is gone. The failure this prevents is specific and recurring: somebody says a page used to be found, or a form used to arrive, and there is nothing to check the claim against. Capture the reference before the redesign deletes it, because after the switch every argument about a regression is an argument about memory.
Parity is a page by page comparison, not an impression
A redesign feels finished long before it is complete, because the pages everybody looks at are the ones that got the most attention. Content parity means each url of the old site is accounted for by name: present in the new site, merged into another page on purpose, or retired on purpose. Three states, one row each, nothing left implicit. The pages that fall through are the ones with no owner in the room during the redesign, which tend to be the pages a small number of people relied on heavily and nobody thought to defend.
The regression surface is everything that was not redesigned
The brief covers a set of pages. The deployment changes a shared codebase, a shared theme or a shared component library, and that layer reaches further than the brief does. Checkout inherits the new base styles. The login screen picks up the new header and loses a link that used to sit in it. A form nobody touched now renders through a template that no longer carries the hidden field the CRM reads. Anything sitting on the same layer as the redesign is in scope for testing even when it was explicitly out of scope for design.
The first real reports come from people who already knew the site
Regular users are the strongest detector a redesign has, because they are the only ones who can tell that something changed rather than that something is confusing. They report it as a complaint rather than as a defect: the thing that used to be in the menu, the page bookmarked for two years that now leads nowhere, the export button that moved. Those arrive through support, sales and social, and they arrive in the first days or not at all. Deciding in advance where such a report lands, and who reads that queue each morning of the watch window, is what turns the volume into a list of fixes.
Common questions
What should be on a website redesign checklist?
A baseline captured while the old site is still up, a url inventory with its redirect map, content parity marked page by page, forms and tracking verified at their destinations, regression across everything sharing a layer with the redesign, accessibility and performance compared against the old numbers, the cutover with its cache purge, a watch window with a named owner, and a rehearsed rollback.
How is a redesign checklist different from a launch checklist?
A launch checklist asks whether something new works. A redesign checklist asks whether anything that already worked stopped working. Almost every item is therefore a comparison against a previous state: the same urls, the same content, the same leads arriving in the same place, the same numbers per template. That previous state has to be captured before the switch, which a launch never has to think about.
How do you avoid losing search traffic after a redesign?
Crawl the old site before it comes down, map every url to a new url or a deliberate error status, use 301 rather than 302, keep chains to one hop, and carry titles, descriptions and structured data across rather than regenerating them. Then watch the old top pages in search reporting for several weeks, because the drop from a missed redirect shows up later than the launch it came from.
What breaks most often after a website redesign?
Tracking and form integrations, because new markup silently breaks the selectors and hidden fields attached to the old markup. After that, urls that were linked from places nobody controls, and features that were out of scope for design but shared a template with the redesign. All three fail quietly, which is why the watch window exists and why the baseline is what makes them provable.
How long should the old site stay recoverable?
Until the watch window closes with nothing outstanding, which in practice is a few weeks rather than a few hours. A rollback is worth having while the redirect map is still being corrected and the search reporting is still settling, and it has to be able to revert the redirects together with the pages. A restore that has never been performed once is a hypothesis.
Terms used on this page
More templates
-
Checklist
QA checklist
A QA checklist for a release: what to verify before a build leaves the pipeline, who signs each item, and which failures block the release outright.
Checklist
UAT checklist and sign-off
A copyable UAT checklist and sign-off template: what to confirm before the window opens, how to record each scenario and finding, and what sign-off states.
Or skip the template and capture the fields automatically.
Environment, console and network attach themselves, on the free plan.