Website Launch Checklist: Rehearse the Go-Live on Staging

A website launch checklist for a staging rehearsal is the most underrated document in a CMS project. Most teams treat go-live as a single event and discover its problems in public: a form that emails nobody, a redirect loop, a menu that breaks on tablets. This audit-style checklist shows how to rehearse the launch on a staging copy first, so that the real switch-over is boring in the best possible way.

Why rehearse a launch on staging

Staging gives you a place to be wrong without consequences. A rehearsal there means performing the entire go-live sequence, not just looking at the pages. You move content, flip the settings, test the forms and practise the rollback. Anything that fails does so privately, and the fix becomes a note rather than an incident.

The principle is simple: the first real run is a bad time to discover the missing step. The checklist below is organised so that each section can be ticked off, assigned and revisited.

Section 1: Make staging a faithful copy

Clone the production database and files, not a stale export from weeks ago.
Match the PHP version, server software and caching layer to the live environment.
Confirm that the same plugins, modules or extensions are active at the same versions.
Block search engines from indexing staging and note how that block will be lifted.
Disable outbound email or route it to a test inbox so rehearsals never reach real customers.

A rehearsal on an unfaithful copy teaches false lessons. If staging differs in a way that matters, the exercise gives comfort without evidence.

Section 2: Rehearse the content and structure

Walk every key template: home, service pages, article, contact, search and error pages.
Check that menus, breadcrumbs and internal links resolve properly.
Review headings, titles and meta descriptions for each important page.
Confirm that images load, scale and carry useful alternative text.
Test the site at phone, tablet and desktop widths.

If you are still deciding which pages the site needs, a sound reference such as this structural overview of the pages a company site should carry can anchor the audit. Rehearsal is the moment to find the gap, not launch week.

Section 3: Rehearse the functions that carry business value

Submit every form with realistic data and confirm the message arrives where it should.
Run a test purchase or booking through to the confirmation stage, using a sandbox for payments.
Check login, password reset and any member areas with a fresh test account.
Verify analytics and tag-manager events fire once and only once.
Confirm cookie notices and consent settings behave as designed.

These items matter more than visual polish because they translate directly into leads and revenue. A form that fails silently is a launch defect that may stay hidden for weeks.

Section 4: Rehearse the switch itself

Write the cut-over steps in order, with a named person for each one.
Time the process on staging so you know how long the freeze on edits will last.
List the redirects from old addresses and test a sample of them.
Practise lowering DNS time-to-live ahead of the change, and note when it was done.
Rehearse the rollback: how would you return to the previous site, and how long would it take?

Teams often rehearse the build and skip the switch, but the switch is where unfamiliar commands, permissions and waiting times show up. Reading the steps aloud while performing them on staging is usually enough to expose a missing credential or an ambiguous instruction.

Performance deserves a place here too. Load a heavy page on staging with the real image set and measure how it feels on a mid-range phone over an ordinary mobile connection. Caching, compression and image sizes often differ between environments, so treat any speed result as a rough guide and repeat the check immediately after launch. The purpose is to catch an obvious regression, such as an unoptimised hero image or a plugin that adds a long delay, while there is still time to remove it calmly.

Section 5: Rehearse the first day after launch

Decide who watches errors, uptime and form deliveries during the first hours.
Prepare a short list of checks to run immediately after the switch: home page, forms, checkout, search, key redirects.
Agree where problems are reported and who can approve a rollback.
Clear caches in a defined order and record it.

Planning the project from the outset also helps. A piece like this stepwise approach to preparing a business site before any development begins sets expectations that the rehearsal later confirms.

A note on content that is not about software

CMS work often reaches beyond corporate sites. Community and heritage projects use the same platforms to publish recipes, oral histories and photographs, and they face the same launch risks. Blendz, a global archive devoted to traditional recipes, rare ingredients and food stories, with a way for visitors to contribute, is a useful example of a content-heavy site where structure, submissions and long-term preservation all depend on getting the build right before visitors arrive.

Scoring the rehearsal

After the run, review it as you would an audit. For each section, record what passed, what failed and what was untested. Assign each failure an owner and a date. Do not accept a vague “mostly fine”. If a step was skipped, treat it as untested rather than passed.

Green: performed, verified and written down.
Amber: performed but not independently verified, or fixed without a retest.
Red: failed or not attempted.

Only when everything is green, or the amber items have an explicit owner and plan, should the go-live date stay on the calendar. If it fails, schedule a second rehearsal. That is not delay; that is the process doing its job.

Who should attend the rehearsal

Invite the people who will actually perform or approve the launch: the developer, the content owner, whoever manages the domain and a representative from the business side. Each of them holds a piece of the sequence that the others may not see. A rehearsal with only developers tends to pass cleanly and still fail on the day, because nobody checked that the content owner could publish or that the domain contact could be reached.

Keeping the checklist alive

The best output of a staging rehearsal is an improved checklist. Edit it straight away while the memory is fresh, remove steps that proved pointless and add the ones you learned about. Store it with the project so the next release, whether a redesign or a plugin update, starts from a proven script instead of a blank page.