The dangerous version of a launch checklist is a long sheet where every row says 'done' but nobody can show what was tested. This version is built around evidence. A passing form check includes the production URL, a timestamp, the received lead, and the owner who confirmed it. A passing redirect check includes the old URL, the returned status, and the correct destination. That makes the checklist a go/no-go control, not launch-day decoration.

Four gates to productionEach gate protects a different part of the business; the final decision needs all four.
01ExperienceContent, responsive behavior, accessibility, and browser QA
02Business pathForms, calls, bookings, purchases, email, and operations
03Discovery and dataRedirects, canonicals, indexing controls, schema, analytics
04Release controlDNS, HTTPS, backups, permissions, monitoring, rollback

Set the launch rules before the final review

Name one launch decision owner, one technical lead, and the owners of content, marketing measurement, customer inquiries, and infrastructure. Define severity in plain language. A blocker prevents a critical customer task, risks data or access, creates a broad discovery failure, or makes recovery unsafe. A deferrable issue has limited impact, a workaround, an accountable owner, and an agreed fix date. This prevents schedule pressure from turning every failed check into 'we will fix it later.'

Example decision rules

FindingDefault decisionEvidence needed to change it
Primary contact form does not create a usable leadBlockSuccessful end-to-end production test and receiving-team confirmation
Public pages return certificate warningsBlockValid HTTPS on all required hostnames
High-value old URLs have no mapped destinationBlock or narrow launch scopeApproved redirect map with tested responses
Minor spacing issue on one older deviceAssessDocumented affected audience, usable workaround, owner, and fix date
Analytics event name differs from the measurement planBlock measurement sign-offVerified corrected event or a documented reporting bridge
Optional editorial image is not finalDefer if layout and accessibility are safeApproved placeholder, replacement owner, and date

Freeze content and test the actual production build

  • Confirm every navigation, footer, logo, breadcrumb, button, phone number, email address, legal link, and external link in the production build.
  • Compare services, locations, staff, pricing language, policies, and calls to action against the approved source—not an old mockup.
  • Check page titles, headings, dates, authors, image alternatives, captions, and downloadable files for accuracy and ownership.
  • Remove staging banners, sample records, test testimonials, placeholder people, development URLs, and `noindex` controls that are not part of the launch plan.
  • Verify the correct social-sharing title, description, and image on representative pages using rendered metadata, not only CMS fields.
  • Confirm that error pages, empty search results, validation messages, and unavailable-content states give a useful next action.

Test the deployable production artifact or a release candidate that will not be rebuilt between approval and launch. A staging environment can pass while production fails because environment variables, redirects, storage, form endpoints, or security headers differ. Record the build or release identifier in the checklist so sign-off is tied to something specific.

Walk every revenue and service path end to end

Test as a customer and as the receiving team

01

Begin from a realistic landing page

Enter from a service, location, campaign, or search landing page instead of always starting on the homepage.

02

Complete the task on real devices

Submit the form, make the test call where approved, book a test appointment, or complete a safe transaction. Include keyboard-only and mobile checks where they apply.

03

Inspect validation and recovery

Try missing and invalid input, a declined or unavailable state when safe, duplicate submission behavior, and the back button. Error text should identify the problem without erasing valid work.

04

Follow the data downstream

Confirm the inbox, CRM, calendar, ecommerce system, or help desk receives the correct fields, source information, permissions, and assignment.

05

Confirm the human response

The department receiving the test should recognize it, know the response expectation, and confirm that notifications do not expose information to the wrong people.

Review responsive behavior and accessibility together

Do not limit responsive QA to shrinking a desktop browser. Use current real phones and tablets available to the team, then use browser tools to widen coverage. Rotate the device, increase text size, zoom, open the on-screen keyboard, and test a slower network profile for important paths. W3C guidance applies accessibility requirements to mobile web content too; 'mobile friendly' and 'accessible' are not separate sign-offs. Automated scanning can find certain code patterns, but it does not replace keyboard, screen-reader, focus-order, content, and task testing.

Visual spot-checkTask-based QA
NavigationMenu opensMenu opens by keyboard and touch, focus is visible, labels are clear, and it closes predictably
FormFields fit the screenLabels, errors, autofill, keyboard, focus, and submission all work without lost input
ContentNo obvious overlapText reflows when enlarged; headings and reading order remain meaningful
MediaImage loadsAlternative text or treatment matches purpose; controls and captions work where needed
CTAButton is visibleTarget is operable, accurately named, not covered by a sticky element, and leads to the promised result
VISUAL CHECKPOINT · RedesignFour gates to production

Each gate protects a different part of the business; the final decision needs all four.

Protect search visibility during the release

Search release checks

ControlPass conditionCommon failure
Redirect mapEach moved, merged, or retired valuable URL has an intentional outcomeEverything redirects to the homepage or returns 404 without review
Status codesPublic pages return the intended success, redirect, not-found, or gone responseA styled error page returns success; redirect chains hide mistakes
Canonical linksIndexable pages point to their intended canonical URLProduction pages name staging, HTTP, or a different page
Robots controlsRobots.txt and page-level directives match the approved index planA staging `noindex` rule reaches production
Internal linksNavigation, breadcrumbs, body links, and XML sitemap use final URLsInternal links depend on redirects
Structured dataMarkup describes visible page content and passes syntax checksOld business details or unsupported claims remain in copied schema
Search ConsoleCorrect properties and verified owners are availableNo current team member can inspect the site after launch

Google recommends permanent server-side redirects such as 301 or 308 when a page has permanently moved. The destination should be the closest relevant replacement, not automatically the homepage. If the domain itself changes, follow Google's site-move process and use Change of Address where it applies. A redesign on the same domain with stable URLs is not the same project as a domain move.

Verify measurement, privacy, and ownership

  • Run the approved analytics debug or real-time test and confirm production events use the planned names and parameters.
  • Verify consent controls and disclosures against the business's requirements and configured vendors; do not copy another site's banner settings.
  • Confirm campaign parameters, cross-domain journeys, payment referrals, call tracking, and booking embeds do not create false attribution.
  • Check that business-controlled accounts retain administrator access for domain, DNS, hosting, CMS, analytics, Search Console, tag management, forms, and critical integrations.
  • Remove unnecessary launch credentials and document the process for granting, reviewing, and revoking access.
  • Save the pre-launch analytics benchmark, event dictionary, and annotation time so post-launch comparisons have a reliable boundary.

Prepare DNS, rollback, and the first 24 hours

Export the current DNS zone and identify web, mail, verification, and subdomain records before changing anything. Confirm the exact new-host values and HTTPS sequence. Keep the old environment available for the agreed rollback window, with a clear rule for data created after launch. A rollback that restores an old site but loses new orders is not complete. Assign monitors for uptime, errors, forms, email, analytics, redirects, and customer reports, and decide how the team will communicate status.

The final go/no-go meeting

01

Read blockers first

Review unresolved severity-one findings, the evidence, affected task, and owner. Do not bury them under dozens of passing cosmetic checks.

02

Confirm the release candidate

Make sure the approved build, configuration, content snapshot, redirect map, and DNS plan are the items scheduled for production.

03

Confirm recovery

Have current backups or prior deploys, previous DNS values, restore instructions, credentials, and an authorized rollback decision-maker available.

04

Confirm observation coverage

List who will watch which signals, for how long, and where findings are logged. Include the team that receives leads and customer calls.

05

Record the decision

Write who approved launch, known deferred issues, owners, deadlines, and the exact release time. If the decision is no-go, schedule the next evidence review rather than a vague delay.

A capable website design partner should be able to show this evidence in language your business owners understand. Use the full redesign and migration collection to assign the work before the final week.

For any changed URLs, build and test the website redesign redirect map early. A redirect map is not a task to improvise while DNS is switching and the team is already handling launch-day issues.

Who should have final authority to launch a redesigned website?

Name one business decision owner who understands the technical, customer, and operational evidence. The agency or technical lead can recommend go or no-go, but ownership of material business risk should be explicit rather than assumed.

How many devices and browsers must we test?

There is no universal count. Use your supported-browser policy, analytics baseline, customer context, and critical tasks to choose coverage. Combine real-device tests for priority journeys with browser tools for broader responsive checks, then record what was and was not covered.

Should every 404 error block launch?

No. A deliberate not-found response can be correct for a page with no replacement. Unmapped valuable URLs, broken internal links, or widespread errors are different. Judge the affected page, traffic or customer value, intended outcome, and scale.

Can we remove the old hosting account immediately after launch?

Usually wait through the agreed observation and rollback period. The proper duration depends on the site's data, update frequency, hosting terms, and recovery plan. Confirm how new leads, orders, or content would be reconciled before relying on rollback.

Is passing an automated accessibility scan enough?

No. Automated tools cover only some detectable issues. Include keyboard operation, focus, reading and heading order, labels, error recovery, zoom or reflow, contrast review, and assistive-technology testing appropriate to the site's risk and audience.