Website go live checklist: before and after launch
A website go live checklist should tell your team more than what to test. It should show who owns each check, what proves it passed, and what happens if it fails. This guide gives founders, marketing leaders, and project owners a practical way to control a launch. It covers the work before release, during cutover, and after the site is public.
Do not mark a task complete without evidence. “The form works” is an opinion until someone submits it, receives the expected response, and records the result. That record turns a loose list into a launch plan your team can use to make a clear go or no-go decision.
The website go live checklist starts with ownership
Every critical task needs an owner, a reviewer when appropriate, evidence, and a response if the check fails. One person may cover several roles on a small project. However, each row should still name a person, not just a department or agency.
Start with this control matrix and adapt it to your website:
| Phase | Task | Suggested owner | Evidence of acceptance | Response if it fails |
|---|---|---|---|---|
| Before launch | Approve final page content and media | Content owner | Dated approval or signed QA sheet | Keep the affected page out of release or postpone |
| Before launch | Test navigation, search, forms, and conversion paths | QA or project owner | Test record with URLs, devices, and results | Fix the critical path and retest |
| Before launch | Review accessibility against agreed criteria | Designer, developer, and reviewer | Completed accessibility review with unresolved issues logged | Resolve blockers or document the release decision |
| Before launch | Confirm indexability, canonical URLs, sitemap, and redirect map | SEO owner or developer | Crawl report and approved URL mapping | Correct the configuration before release |
| Before launch | Confirm backup and rollback readiness | Technical owner | Restorable backup confirmed and rollback steps recorded | Do not begin cutover |
| Launch day | Check DNS, TLS, and production availability | Technical owner | Successful production checks from agreed locations and devices | Follow the rollback or incident plan |
| Launch day | Verify priority URLs and redirects | SEO owner or QA | Logged status and destination checks | Repair incorrect routes before promotion |
| Launch day | Complete the stop/go review | Launch owner | Decision log with open risks and approvers | Pause when a defined blocker remains |
| After launch | Submit forms and test conversion paths in production | Marketing or QA owner | Test submissions and receipt evidence | Escalate and fix the broken path |
| After launch | Validate analytics and consent behavior | Analytics owner | Recorded test visits or events in the chosen platform | Diagnose configuration before relying on reports |
| After launch | Monitor errors, indexing signals, and business-critical journeys | Assigned operational owners | Dated monitoring log and issue tickets | Triage by impact and assign a resolution owner |
The labels are less important than accountability. For example, a founder may be the content owner and final approver, while a development partner owns deployment. In both cases, the launch owner keeps the matrix current and records the final decision.
New websites and migrations need different controls
A new site and a redesign migration share content, functional, accessibility, and measurement checks. A migration also has history to protect. Existing URLs may have links, bookmarks, search signals, or campaign traffic, so changing them creates extra dependencies.
| Decision area | New website | Redesign or CMS migration |
|---|---|---|
| Legacy URLs | Usually no existing production URL set | Export and compare the current URL inventory |
| Redirects | Needed only for changed temporary or campaign paths | Map each changed legacy URL to the most relevant live destination |
| Baseline | Record initial performance and measurement settings | Save pre-launch traffic, conversion, crawl, and priority-page baselines |
| Rollback | Restore the previous deployment or holding state | Account for the old site, database, DNS, and redirect configuration |
| Search checks | Confirm indexability and sitemap availability | Also compare old and new URLs, redirects, canonicals, and indexing controls |
For a migration with URL changes, use an explicit map rather than redirecting every old page to the home page. Google Search Central’s site-move guidance explains URL mapping, server-side redirects, and monitoring during a move. Your team should review that guidance against the actual platform and migration scope.
A redesign that keeps the same domain can still be a migration. If page paths, content ownership, templates, analytics, or the CMS change, compare the old and new states. Conversely, a new domain without legacy pages does not need an invented redirect project. It still needs an indexability, sitemap, analytics, and production QA plan.
Pre-launch checks need acceptance evidence
Before launch, test the release candidate in an environment that is as close as practical to production. The goal is to find unresolved dependencies while the team can still pause without disrupting the public site.
Approve content and page structure
Review every page included in the release. Confirm headings, body copy, calls to action, contact details, images, downloads, metadata, and legal text supplied for the project. Also check empty states, error messages, and thank-you pages because they are easy to miss during a visual review.
Then record approval. A dated checklist, annotated page list, or issue tracker can serve as evidence. If a stakeholder has not approved a business-critical claim or conversion page, the launch owner should treat that as an open risk rather than assuming silence means consent.
Test complete user journeys
Test journeys, not isolated buttons. A contact journey may include the landing page, navigation, form validation, successful submission, notification, thank-you page, and follow-up destination. An ecommerce or account journey will have more steps, but the same principle applies.
Use the devices and browsers agreed in the project scope. Record the URL, input, expected result, actual result, and tester. When a test fails, create a traceable issue and run the full journey again after the fix.
Use accessibility criteria your team can verify
Accessibility acceptance should refer to a defined standard instead of a vague instruction to “check accessibility.” The W3C Web Content Accessibility Guidelines 2.2 provide testable success criteria that teams can use as a reference.
Automated tools can support the review, but the acceptance record should also cover interactions that require human judgment. Examples include keyboard use, visible focus, meaningful link text, form instructions, error recovery, content order, and text alternatives. Document unresolved findings and who approved any decision to release with them.
Confirm search and URL controls
Check the elements that determine how search systems discover and interpret the production site. These include robots directives, page-level indexing directives, canonical URLs, HTTP status behavior, internal links, and the XML sitemap.
For a migration, compare the redirect map with the final production URL list. Test representative paths as well as priority pages. In addition, confirm that staging restrictions or staging canonical URLs have not carried into production.
Prepare measurement, backup, and rollback
Write down what a successful analytics test looks like before launch. For example, the owner may need to see a test visit, form submission, or other agreed event in the correct property. Avoid accepting a tag merely because its code appears on the page.
The technical owner should also confirm the backup or recovery state appropriate to the hosting setup. A rollback plan must identify the decision maker, trigger, steps, access requirements, and communication route. It is not useful if the credentials or previous release cannot be reached during cutover.
If your project still needs development governance before this stage, review how professional website development is planned before setting the launch date.
Launch day needs a recorded stop or go decision
Launch day should follow a short runbook with a named coordinator. The coordinator confirms that the release version is correct, the required people are available, backups and rollback steps are ready, and no critical pre-launch issue remains open.
A practical sequence is:
- Freeze unplanned content and configuration changes.
- Confirm the release package, owners, communication channel, backup, and rollback route.
- Begin the approved deployment or DNS change.
- Check production availability, TLS, priority pages, and critical assets.
- Test navigation, forms, logins, search, checkout, or other business-critical journeys that apply.
- For a migration, verify sampled redirects and compare priority legacy URLs with their destinations.
- Validate analytics behavior and record the result.
- Log defects, owners, severity, and the next review time.
- Record the go, hold, or rollback decision.
A failed check does not always require rollback. A typo on a low-traffic page and a broken lead form carry different business risk. Therefore, define blockers before launch. Typical blocker categories may include unavailable priority pages, failed transactions or forms, unsafe access, widespread redirect errors, or the inability to measure a launch tied to an active campaign. Your project’s decision makers should approve the actual criteria.
Do not let a calendar commitment overrule an unresolved blocker without a recorded decision. The launch owner should state what failed, the likely impact, the workaround if any, and who accepts the remaining risk.
Post-launch checks catch production-only problems
Production validation begins as soon as the public release is reachable. Start with the paths that matter most to customers and the business, then expand the review. The purpose is to detect regressions that staging could not reveal, such as production configuration, integrations, caching, redirects, or measurement behavior.
During the initial observation period, recheck:
- homepage and priority landing pages;
- navigation, internal search, forms, and conversion paths;
- TLS and mixed-content warnings;
- page status codes, canonicals, indexing directives, and sitemap availability;
- redirect destinations for migrated URLs;
- analytics visits and agreed conversion events;
- server or application errors available to the technical team;
- accessibility issues introduced during deployment;
- campaign links and third-party integrations included in scope.
Use two practical monitoring views: immediate checks after cutover and a first-week review. These are planning windows, not universal guarantees. A high-traffic transactional site may need closer observation, while a small brochure site may use fewer checks. Set the frequency according to risk, traffic, launch timing, and team availability.
Close each issue with retest evidence. In addition, compare actual production behavior with the baseline captured before a migration. Keep ownership active until priority defects are resolved and stakeholders have accepted any remaining items.
After the launch stabilizes, ongoing updates, backups, security reviews, and compatibility work move into operations. This guide to WordPress website maintenance after launch explains how that work differs from the launch checklist.
A complete checklist makes the launch decision visible
A useful launch document answers five questions for every critical check: what are we testing, who owns it, what proves it passed, what happens if it fails, and who decides whether to continue? That record helps a small internal team as much as it helps a larger group of specialists.
Before approving release, confirm that:
- every critical row has a named owner;
- acceptance evidence is attached or linked;
- migration-only controls have been applied when legacy URLs or systems change;
- blockers and rollback triggers are understood;
- production checks and monitoring times are assigned;
- open risks have an owner and an explicit decision.
ID7 Studio is a design and website development studio serving international businesses. Our team brings more than 15 years of experience and has worked with more than 800 clients. If you want a website project with launch planning built into the scope, request a tailored proposal.
