Website launch checklist for Squarespace

Squarespace makes publishing a polished page straightforward, but a new visitor can still encounter a missing navigation target, a clipped mobile button, a form with unclear confirmation, or a checkout step that has not been safely tested. Use this checklist for a deliberate public-site pass before a new launch, redesign, campaign, or client handoff.

Keep the pass bounded. Work from a clean signed-out browser, record the URLs and viewports actually checked, and test only the visitor actions the site owner authorizes. Do not change site settings, publish content, submit real personal data, create an account, or place an order merely to see what happens.

Before opening the public site

• Confirm the intended public or staging URL, canonical domain, and the pages and visitor journeys in scope.
• Use a clean signed-out browser so editor access, saved cart state, consent choices, and cached previews do not hide a 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 when it is part of the agreed scope.
• Record browser, viewport, date, and exclusions. A useful handoff states what was observed; it does not imply every device, browser, payment method, or integration was covered.

1. Follow the first-visitor path

Start where a person is likely to arrive: a search result, campaign link, social post, direct URL, or the home page.

1. Does the browser title describe the page clearly?
2. Does the visible heading match the message that brought the visitor there?
3. Is the primary next action clear without a confusing detour?
4. Do the logo, header links, footer links, and primary buttons reach the expected public destinations?
5. Can a keyboard user reach interactive controls and see where focus is?
6. Do direct visits to important former URLs reach an intended page or an understandable redirect?
7. Does a missing route show a useful 404 page with a path back to active content?

For each observation, record the URL, action, expected result, observed result, browser, and viewport. A screenshot can help explain a visual issue, but it should accompany reproducible steps.

2. Review pages, collections, and navigation

Squarespace sites often combine standard pages with blog posts, products, events, portfolios, and collection pages. Check representative public routes rather than assuming that a working homepage proves every item is ready.

• Open the homepage, a core conversion page, contact page, and representative collection items that visitors will use.
• Confirm headings, page titles, descriptions, hero media, prices or dates, and calls to action are present and understandable.
• Follow navigation, cards, pagination, category links, tags, related content, and search results where they are in scope.
• Check empty, retired, or filtered collection states for an understandable next step.
• Look for prominent internal links to a deleted page, draft, preview address, or unexpected third-party domain.
• Confirm contact, privacy, policy, and consent links can be reached where visitors reasonably expect them.

A sample does not prove that every collection item, redirect, or indexed URL is correct. Name the exact routes reviewed in the handoff.

3. Check layout at agreed widths

Inspect the homepage and main conversion path at the agreed desktop and simulated phone widths. Squarespace styles can look correct in an editor while a public layout still crowds important copy.

• Navigation opens and closes without covering required content or trapping the visitor.
• Headlines, body copy, buttons, prices, dates, and legal links do not overlap, clip, or require horizontal scrolling.
• Images, galleries, background video, and banners have sensible crops and do not hide the next action.
• Fixed headers, pop-ups, announcement bars, and cookie controls have a clear dismissal or do not prevent a visitor from continuing.
• Button labels and form controls remain usable without accidental taps.
• Motion, lazy-loaded media, and embedded blocks do not make key copy unreadable or leave a confusing blank state.

Do not call a site responsive across all devices and browsers from these checks alone. State the configurations actually observed.

4. Treat forms, scheduling, and commerce as journeys

A visible form or checkout button is not proof that a downstream email, payment, booking, or automation completed successfully.

1. Open each in-scope form from the same path a visitor would use.
2. Check required-field and invalid-format messages without entering real personal data.
3. Confirm labels explain what is required, where the information goes, and what happens after submission.
4. Review privacy language and any marketing-consent choice near its control. A contact request or purchase must not be treated as marketing permission.
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 external blocks, verify that an unavailable or slow-loading state remains understandable.
7. Every review journey stops before submit or payment, including account creation and paid booking.

Do not interpret an on-page success message as proof that an email platform, CRM, analytics event, payment processor, tax setting, or fulfillment integration worked.

5. Finish the release and handoff pass

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

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