Website Launch Checklist for Marketing Teams
Before signing off a website, ask your team to complete the tasks it was built for. Find a service, submit an enquiry, publish a resource and correct an editing mistake.
User acceptance testing, or UAT, checks the delivered site against the brief. It sits alongside the project's technical, accessibility and security testing.
Write down what should happen
Replace “check the form” with a specific test:
“A visitor selects the Brisbane team and submits an enquiry. They receive confirmation, and the matching record reaches the team responsible for responding.”
Agree the expected result with the people who own the process. Record the page, starting conditions, action and result. Include a screenshot or submission reference where it helps someone reproduce a failure.
Open the acceptance worksheet to keep the tests and decisions together.
Test the important visitor tasks
| Task | Check |
|---|---|
| Find a service | Audience, location, eligibility and next step are clear |
| Find a resource | Search and filters return the current item; the download works |
| Send an enquiry | Validation, confirmation and delivery work |
| Register for an event | Date, location and booking details match the source system |
| Request a quote | The chosen product and options reach the receiving team |
| Use an account | Each role sees the right records and permitted actions |
Include difficult cases: no search results, missing required fields, an expired session or an unavailable connected service. Agree which failure tests are suitable for staging.
Use ordinary user accounts. An administrator account can hide permission problems.
For a multi-step enquiry, test the points where the outcome can change. Our ROH Wheels build notifies a dealer after the customer completes PIN verification. For that type of flow, add cases such as:
| Test case | Expected result to agree |
|---|---|
| Customer stops before verification | No dealer notification is sent |
| Customer verifies, then refreshes or retries | One enquiry and the intended notification |
| Customer changes their selected vehicle | The enquiry contains the updated vehicle and wheel details |
| Message delivery fails | Staff can identify and recover the failed delivery |
These checks cover behaviour a successful first submission will miss.
Review the content in context
Ask the relevant content owners to approve service details, eligibility, contact information and downloads.
Check page titles, headings and navigation labels. Remove placeholders. Follow links from the page where visitors will use them.
For shared information, change the source record and check everywhere it appears. Confirm that retired pages and documents have the agreed replacements or removal behaviour.
Let editors try their own work
Ask staff to create a draft, replace an image, preview a page, publish an authorised change and restore a previous version.
Note where they need help. Compare those tasks with what the brief promised they could manage.
The WorkUP Queensland project included styled WordPress blocks and a recorded CMS training session. Include equivalent handover materials in your acceptance list if your team needs them.
Record outstanding issues
Agree simple severity categories:
- Blocker: a critical task fails or a launch requirement is unmet.
- Major: an important task is impaired and needs a fix or an accepted workaround.
- Minor: a limited issue that can be assigned a follow-up date.
Give each issue an owner. If something will remain at launch, record who accepted it and when it will be fixed.
Attach the relevant browser, accessibility, performance and security reports. For accessibility, W3C's evaluation guidance helps define the scope of the assessment.
Ask the technical tester to check restricted actions by direct request as well as through the interface. Hiding a button does not enforce permissions. OWASP recommends validating permissions on every request.
Retest fixes and identify the version that passed. Substantial changes after sign-off need another check.
Check the live site
Name who authorises release and who checks production. Confirm access to domains, hosting, backups and support contacts.
After deployment, repeat the critical tasks. Check production email, integrations, caching and analytics. Verify a completed enquiry in the receiving system, including its assignment to the right team.
Record any differences between staging and production, such as test email delivery, payment modes or API credentials. GOV.UK recommends staging that closely matches production, but those deliberate differences still need live checks.
Before agreeing to a database rollback, decide how to retain enquiries or orders received since launch. Restoring yesterday's backup can restore the website while removing today's records.
Our website development service covers the build, launch checks and handover.