Website launch checklist for Wix

Wix can get a new site online quickly, but a visitor may still meet an old menu target, an unclear form confirmation, a narrow-screen layout problem, or a checkout path that was never safely exercised. Use this checklist for a deliberate public-site pass before a launch, redesign, campaign, or client handoff.

Keep the work bounded. Start in a clean signed-out browser, record the URLs and viewports actually observed, and only test visitor actions the owner has authorized. Do not publish content, change site settings, submit real personal data, create an account, or place an order just to learn what happens.

Before opening the public site

• Confirm the intended public or staging URL, canonical domain, launch pages, and visitor journeys in scope.
• Use a clean signed-out browser. Editor access, stored consent, cached assets, and saved cart state can hide a first-visitor problem.
• Agree which public form, newsletter, booking, member-area or commerce views may be inspected. Every review journey stops before submit or payment.
• Check at least one desktop width and one simulated phone width. Add a tablet width if it matters to the intended audience.
• Record browser, viewport, date, and exclusions. The handoff should say what was observed, not imply every device, payment method, browser, or connected app was covered.

1. Follow the first-visitor path

Begin where a visitor is most likely to arrive: a search result, campaign link, social profile, direct URL, or home page.

1. Does the browser title identify the page clearly?
2. Does the visible headline match the promise that brought the visitor there?
3. Is the main next step understandable without hunting through unrelated sections?
4. Do the logo, header navigation, footer links, and primary buttons lead to the intended public destinations?
5. Can a keyboard user reach controls and see a visible focus indicator?
6. Do important former URLs land on a relevant current page or an understandable redirect?
7. Does a missing route offer a helpful path back to active content?

For every finding, capture the URL, action, expected result, observed result, browser, and viewport. Screenshots are useful context, but they should not replace steps another person can repeat.

2. Review pages, CMS collections, and navigation

Wix sites can mix ordinary pages with blog posts, services, stores, events, portfolios, and member content. A working homepage does not prove every collection item or menu path is launch-ready.

• Open the homepage, main conversion page, contact page, and representative items from each in-scope collection.
• Confirm headings, page titles, descriptions, images, prices or dates, and calls to action are present and understandable.
• Follow menu links, cards, category or tag links, pagination, search, and related-content links where they are in scope.
• Check empty, filtered, retired, or out-of-stock states for a clear next step.
• Look for prominent links to a deleted page, draft, preview URL, editor route, or unexpected third-party domain.
• Confirm that contact, privacy, policy, and consent links are reachable where a visitor would reasonably expect them.

Do not call all collection items or redirects correct from a sample. Name the exact pages reviewed in the release handoff.

3. Check layout at agreed widths

Review the homepage and the core conversion path at the agreed desktop and simulated phone widths. An editor preview can miss a public layout that makes the primary action difficult to use.

• Navigation opens and closes without hiding essential content or trapping the visitor.
• Headlines, body copy, prices, dates, buttons, and legal links do not overlap, clip, or force horizontal scrolling.
• Hero images, galleries, background media, and banners have sensible crops and do not conceal important copy.
• Fixed headers, pop-ups, announcement bars, and consent controls can be dismissed or do not prevent a visitor from continuing.
• Buttons and form controls are large enough to use without accidental taps.
• Motion, lazy-loaded media, and embedded blocks do not leave key copy blank or make the next action unclear.

These observations do not certify a site across every device and browser. State the configurations that were actually inspected.

4. Treat forms, bookings, and commerce as journeys

A live-looking form or checkout button is not proof that its downstream email, payment, booking, or automation completed.

1. Open each in-scope form from the route a visitor would use.
2. Check required-field and invalid-format messages without entering real personal data.
3. Confirm field labels explain what is required, where information goes, and what happens after submission.
4. Review privacy language and any marketing-consent choice close to the control. A contact request or purchase is not automatically permission for marketing.
5. Stop before submitting any form or making any payment. Record confirmations, recipient delivery and downstream actions as untested.
6. For newsletter, calendar, map, chat, video, or other embedded services, check that a slow or unavailable state remains understandable.
7. Every review journey stops before submit or payment, including account creation and paid booking.

An on-page success message is not evidence that a CRM, email list, payment processor, tax rule, analytics event, or fulfillment integration worked. List those downstream systems as untested in this public-page pass.

5. Finish the release and handoff pass

• Confirm the intended HTTPS domain loads and does not unexpectedly send visitors to an editor, staging site, preview address, or noncanonical domain.
• Review public titles and descriptions for the main conversion pages.
• Note third-party assets, embeds, delivery flows, and visitor steps that were excluded or not safely testable.
• Save a concise handoff: public pages and journeys checked, browser and viewports, reproducible findings, and known exclusions.
• Route fixes through the owner’s Wix workflow. Do not make unapproved live changes during a visitor-perspective pass.

What this checklist does not prove

A bounded launch pass is not a security audit, performance guarantee, accessibility conformance review, cross-browser certification, tax review, migration audit, or proof that payment, email, analytics, and third-party integrations work. Those services are outside ReleaseCheck Desk’s scope.

Keep the release record

Record the exact pages, actions, expected and observed results, browser, viewport, date and exclusions. Share reproducible findings with the site owner and recheck affected paths after others make corrections.

Read the general website launch checklist · See Launch QA scope and terms