Website launch QA checklist: 33 checks before handoff

Scope and rollback

Agree what is launching and how the team will recover before checking individual pages.

Record the accepted launch URL setName the homepage and every critical public page included in this release. Do not let the scope grow silently during sign-off.ManualName the launch owner and decision timeOne person should own the go/no-go call, the launch window, and the route for raising a late blocker.ManualConfirm backup and rollback stepsKnow which deploy, theme, or content state can be restored and who can restore it before traffic arrives.ManualRemove the right staging controlsAt the agreed time, remove public-site passwords or launch placeholders without exposing private staging environments.ManualVerify the final HTTPS hostThe accepted URL should resolve to the intended secure hostname rather than an old, temporary, or preview domain.Evidence-ready

Delivery and links

Check what public visitors and crawlers actually receive after redirects finish.

Confirm critical pages return the expected responseRecord the final status and destination for the homepage, primary offer, contact route, and other accepted pages.Evidence-readyVerify HTTP redirects to HTTPSAn insecure request should land on the intended secure page without changing to the wrong host or path.Evidence-readyLook for redirect loops and unnecessary chainsCapture every hop so the team can see loops, unexpected destinations, or avoidable multi-step redirects.Evidence-readyProbe bounded same-site linksCheck a controlled set of public internal links and preserve the final destination rather than trusting anchor text.Evidence-readyConfirm navigation and contact links reach their targetHeader, footer, contact, policy, and primary call-to-action links should resolve to the page the copy promises.Evidence-ready

Search and sharing

Separate crawl and metadata evidence from the slower question of whether a search engine indexes the page.

Review page titles and descriptionsCritical pages should expose specific, non-empty metadata that matches the visible offer and page purpose.Evidence-readyVerify canonical URLsEach accepted page should point to the intended public canonical instead of a preview, duplicate, or unrelated URL.Evidence-readyCheck robots and noindex signalsRecord page-level indexing directives separately from HTTP success. A 200 response does not prove a page is indexable.Evidence-readyPublish and submit the intended sitemapConfirm the sitemap contains the launch URLs, then use the relevant search-console workflow after the public release.ManualPreview social-share metadataOpen Graph and social-card output should use the right title, description, image, and public URL on real sharing surfaces.ManualVerify search ownership and request discoveryUse the site owner's search-console account. Indexing is not instant and should be monitored rather than claimed at launch.Manual

Content and accessibility signals

Record useful structural signals, then reserve interaction and visual judgments for real human testing.

Check headings and the primary page headingRecord heading structure and confirm the visible primary heading describes the page rather than a generic template.Evidence-readyMeasure image-alt coverageFlag images without alt attributes for review; the presence of text does not prove that the text is useful.Evidence-readyRecord page landmarksIdentify the public page's main structural landmarks without treating their presence as a complete accessibility audit.Evidence-readyCheck form-label signalsInputs should expose a programmatic label. The check does not submit the form or validate its business workflow.Evidence-readyTest keyboard flow and visible focusA human should traverse menus, dialogs, forms, and calls to action with a keyboard on the actual release build.ManualReview responsive layout and readable contrastUse representative phones, tablets, and desktop widths. Check clipping, zoom, tap targets, contrast, and text readability.Manual

Conversions and operations

Exercise the workflows that public-page observation cannot safely prove for you.

Run the primary conversion end to endSubmit the real contact, booking, signup, or checkout flow with an approved test method and verify the final state.ManualVerify customer and internal notificationsConfirm the correct recipient, sender identity, subject, content, and timing for every transactional notification.ManualCheck payment, tax, shipping, and refund settingsUse the platform's authenticated controls and approved test mode. A public page cannot prove private configuration.ManualVerify analytics and consent behaviorConfirm the intended events, consent states, privacy disclosures, and data destinations with the account owner.ManualExercise critical third-party integrationsTest CRM, booking, inventory, email, search, or fulfillment handoffs that must work after the launch event.ManualReview contact, policy, and operational contentThe owner should confirm that public contact details, availability, policies, prices, and fulfillment promises are current.Manual

Evidence and post-launch

Keep a timestamped checkpoint, fix known failures, and measure the live result after release.

Capture a rendered screenshot for each accepted pageKeep the image with the corresponding URL and timestamp so later reviewers know which public state was observed.Evidence-readyPreserve pass, fail, and unknown separatelyA timeout, block, skipped check, or inconclusive response must remain unknown rather than becoming a pass.Evidence-readyHash the delivered evidence artifactsCreate a manifest so the team can verify that the report, data, and screenshots have not silently changed.Evidence-readyRerun the same scope after fixesKeep the original checkpoint and compare it with a new run instead of overwriting the first observed state.Evidence-readyMonitor indexing, conversions, and real-user issuesSearch visibility, transactions, support messages, and production behavior emerge after launch and need their own evidence.Manual

Website launch QA checklist: 33 checks before handoff.