A redesign can look finished while important launch decisions remain unresolved. Before replacing the live website, your team needs evidence that customers can still find the right pages, use essential features and reach the business.
Use this website redesign launch checklist to review one agreed version. It helps you record what passed, what needs attention and who can decide whether to proceed.
What makes a redesign ready to launch?
A redesign is ready for a launch decision when the agreed version has been reviewed, important journeys have test evidence, URL changes have an approved plan and unresolved issues have named owners. The team also needs an authorised launch contact and a recovery approach that accounts for information created after the switch.
Start with the version and the people
Identify the exact website version under review. Record the staging address or release reference, the pages included and any changes made after testing. A screenshot from an earlier design does not confirm the current build.
Name a business approver and a technical launch lead. Agree who can report a problem, who decides whether it blocks launch and who can authorise recovery. For a Cyprus team working with suppliers elsewhere, write down the launch window and time zone.
If the broader project scope is still unclear, resolve that with your website development team before treating the launch review as complete.
Check the pages and URLs that matter
Start with existing pages people use to enquire, buy, book or find important information. Include relevant downloads and other linked resources. Use available CMS records, sitemaps and search or traffic data to build the list; one source may not cover everything.
For each existing URL, record whether it stays, moves, merges or is intentionally removed. Identify the intended destination and the person approving that decision. Keeping a URL can be appropriate when the page still serves the same purpose.
When URLs change, ask the technical team to check the agreed mapping, destination relevance and redirect behaviour. Sending every removed page to the homepage can leave visitors without the information they expected.
Google’s site-move guidance explains URL mapping and redirect planning. A careful migration can reduce avoidable problems, but significant changes can still cause search fluctuations. Do not use “rankings will stay unchanged” as an acceptance promise.
Review staging and public access separately
A staging site is a review environment, not proof that the final public site will behave identically. Record how access is restricted during development and who will verify the intended public settings after launch.
Ask the technical reviewer to check that development restrictions are handled appropriately on the public website, while private environments remain protected. Review relevant crawl/index settings, canonical URLs and sitemap references against the agreed plan.
Do not remove all restrictions simply to make a test pass. Some pages should remain private or excluded. The check is whether each environment and page has the intended behaviour.
Test the customer journey, not just the page
Choose representative tasks that matter to the business: reading a service and enquiring, finding contact details, downloading a document or completing a booking. Include an agreed checkout test if the site sells online.
For each task, record the steps, expected result, test conditions and actual result. A button changing colour or a form showing a success message is only part of the evidence.
For enquiries, confirm that the intended team receives the test message. Where payments or bookings are involved, agree a safe test method with the relevant providers; do not create unintended charges or customer notifications.
Check error handling as well as the successful route. Missing fields, unavailable services and failed submissions should give people a useful next step.
Review content and representative layouts
Check the final business details, service descriptions, contact destinations and important document links. Confirm that draft wording, placeholders and private review notes have been removed from the public version.
Review important journeys at representative phone, tablet and desktop sizes. Look for obscured buttons, clipped content, unusable menus and form problems. Include keyboard and other accessibility checks within the agreed review scope.
Record performance evidence separately by URL, device and test date. A single speed score does not certify the whole website. If a required check has not been performed, mark it not tested and assign an owner.
For a wider discussion of layout and customer journeys, see our website design services.
Agree what happens to new information
Before the switch, identify information that may change while the team is deploying: orders, bookings, enquiries, user accounts or content edits. Agree how it will be protected and reconciled.
A backup is useful only within a workable recovery process. Ask what can be restored, who can access it and how the team avoids overwriting valid information created afterwards.
A rollback may involve more than restoring files. It can affect the database, external integrations and configuration. The technical team should confirm the recovery approach for this particular release rather than promise a universal one-click reversal.
Use this go/no-go evidence record
Copy the following fields into your release document. Keep credentials and unnecessary customer information out of it.
Release identity
Website and version:
Pages or changes included:
Proposed launch date, time and time zone:
Business approver:
Technical launch lead:
Check record — repeat for each important check
Check or customer task:
Affected URL or feature:
Expected result:
Environment, device and test date:
Actual result and evidence reference:
Reviewer:
Status: passed / failed / not tested:
Issue owner and next action:
Required retest:
Open-issue decision — repeat where needed
Issue and affected journey:
Business impact:
Fix before launch, defer, or investigate:
Person authorising that decision:
Reason and agreed follow-up:
Recovery and escalation
Recoverable version and evidence of availability:
Person responsible for recovery:
Conditions that trigger a recovery discussion:
Information created after launch that must be protected:
How recovery will be checked:
First contact and escalation route:
Final launch decision
Decision: go / no-go:
Approved release reference:
Outstanding issues and accepted limitations:
Authorised by:
Decision date and time:
Post-launch checks, owners and review time:
A “go” decision should be explicit. An unanswered message or a meeting date is not evidence that someone authorised replacing the live website.
A hypothetical launch-blocking issue
Imagine that a redesigned service page looks correct, but its test enquiry never reaches the agreed inbox. This is a fictional example.
The reviewer records the affected URL, test time and missing outcome. The launch lead investigates with the relevant provider, while the business approver decides whether the unresolved enquiry journey blocks release.
Once corrected, the team repeats the test and records receipt. A screenshot of the form alone would not close this issue. If the team defers another, less significant issue, the decision should still name an owner and a follow-up.
Verify again after the switch
Repeat important checks on the public website. Confirm the expected pages and destinations, enquiry delivery and other agreed journeys; staging results do not replace this step.
Ask the technical reviewer to check the public URL mapping, intended indexing settings, canonical references and sitemap. Record the actual release time so later observations can be interpreted in context.
Keep the previous environment and recovery arrangements available for the period agreed with your technical team. Continue reviewing relevant errors and customer reports. Later search data can inform monitoring, but immediate traffic movement alone does not diagnose a migration problem.
Once the release is stable, transfer any remaining work into the agreed website maintenance process. Launch acceptance and ongoing care have different responsibilities and review periods.
FAQs
Do we need redirects for every redesign?
Not necessarily. A visual or content redesign can keep existing URLs. Where URLs change or pages merge, the technical team should plan suitable destinations and verify the resulting behaviour. Intentional removals also need an appropriate decision; do not assume every old address should redirect to the homepage.
Can we launch with minor issues?
That depends on the agreed requirements and the effect on customers. Record the issue, who accepts the limitation and when it will be resolved. Failures affecting essential enquiries, purchases or access deserve particular attention. A reviewer should not silently convert a failed check into approval.
Does a backup guarantee an easy rollback?
No. Recovery depends on the available copy, access, system dependencies and information created after that copy. Agree and assess the recovery process before launch. The technical lead should explain any limits and how valid new orders, enquiries or other changes would be protected.
Make the launch decision reviewable
Choose the version, gather evidence for the important journeys and give unresolved issues a decision owner. Then record the launch decision and carry out the agreed public checks.
To discuss a website redesign with Absolute Websites, share what is changing and the launch questions your team needs help resolving.
