How to Publish a Squarespace Website

Updated September 2026 · Written and maintained by the Progression Agency strategy team

Upgrading to a paid plan does not publish a Squarespace site. A trial site starts private and stays private after payment until you change the site availability setting explicitly, which is why “I paid and it is still not live” is nearly always the same problem. This page covers the publishing steps in order, the five reasons a site stays invisible, the domain decisions that cost traffic if you get them wrong, and the redirect work that decides whether a rebuild keeps its search visibility.

How do you publish a website on Squarespace?

Upgrade the trial to a paid plan, then set the site’s visibility from private to public in the site availability settings. Those are two separate actions and doing only the first leaves the site invisible.

This catches almost everyone once. Paying for a plan does not publish the site. A trial site starts in a private state, and it stays private after payment until you change the visibility setting explicitly.

So the answer to “I paid and my site is still not live” is nearly always the same: the visibility setting. Everything else on this page is about the things worth doing before you flip it, because several of them are far harder to fix afterwards.

1. Upgrade to a paid plan. The trial cannot serve a public site.
2. Connect or transfer your domain, and give DNS time to propagate before announcing anything.
3. Set site availability to public. This is the step people miss.
4. Confirm the site is reachable on the real domain in a private browser window, not just in the editor preview.
5. Check the built-in domain still resolves if anything links to it, and that the redirect to your custom domain works.
6. Verify the site in Google Search Console and submit the sitemap.
7. Check every page’s SEO title and description, because the defaults are almost never what you want.
8. Confirm forms send to a monitored address and that the confirmation message is not the default one.

Why is my Squarespace site still not visible after publishing?

Five common causes: visibility still private, the domain not connected or not propagated, password protection left on, individual pages still unlinked or disabled, or browser cache showing you the old state.

Work through them in order. The first two account for most cases, and the fourth is the one that produces the confusing situation where the homepage works and half the site does not.

Site availability is still private

The single most common cause. Payment and publication are separate actions.

Password protection is still enabled

A site-wide password set during the build hides everything from everyone, including search engines.

The domain is not connected, or DNS has not propagated

Propagation can take hours. Check the built-in Squarespace URL to see whether the site itself is live.

Individual pages are disabled or unlinked

Squarespace distinguishes between pages in the navigation, pages that are not linked, and pages that are disabled. Only the last is genuinely off, but unlinked pages are invisible to visitors.

Browser cache

Check in a private window before troubleshooting anything else. This wastes more time than any other item on the list.

The site is live but not indexed

Being visible and being in Google are different things, and the second takes days to weeks.

Connecting a domain, and the mistakes that cost you traffic

Decide between transferring the domain and pointing it, get the redirect from the non-preferred version right, and never launch a rebuild without a redirect map.

For a brand new site this is straightforward. For a rebuild replacing an existing site, this is the step where sites lose their search visibility, and the loss is usually not noticed for weeks.

The pre-launch checklist that actually matters

Titles and descriptions, forms, mobile layout, 404 page, analytics, and a redirect map if anything preceded this site. Everything else can be fixed later.

Squarespace makes it easy to launch a site that looks finished and behaves badly. The items below are the ones that either cost money immediately or become expensive to fix once the site is indexed.

1. Page titles and meta descriptions written per page. The defaults repeat the site name and tell search engines nothing.
2. Form submissions confirmed to arrive at an address someone actually reads, tested from outside your own network.
3. The form confirmation message and any autoresponder, which default to generic text.
4. Mobile layout checked on a real phone. Section spacing and image cropping behave differently from the desktop preview.
5. A custom 404 page pointing somewhere useful rather than a dead end.
6. Analytics installed and firing, verified with a real visit rather than by looking at the settings.
7. Search Console verified and the sitemap submitted, which happens automatically at /sitemap.xml but still needs submitting.
8. Image alt text on anything meaningful, both for accessibility and because it is a launch-time job that never gets done later.
9. Page load checked with real images rather than placeholders, since uncompressed uploads are the commonest speed problem.
10. A redirect map if this site replaces another. This is the single highest-consequence item on the list.

What Squarespace does automatically, and what it does not

It handles hosting, SSL, sitemaps and basic mobile responsiveness. It does not write your titles, compress your images sensibly, or set up redirects.

Knowing the split saves a lot of time. People frequently either duplicate work the platform already does, or assume it handles something it does not.

Launching a rebuild without losing search visibility

Map every old URL that had traffic to a new one, set the redirects before the switch, and check them the day it goes live.

This is the most expensive avoidable mistake in web projects, and it is entirely preventable with an afternoon of work. A redesign that changes URL structure without redirects discards whatever search visibility the old site had earned, and recovery takes months.

1. Export a list of the old site’s URLs, from analytics, Search Console or a crawl.
2. Identify every URL that received traffic or holds a link. Those are the ones that matter; the rest can go.
3. Decide the new URL for each, and write the pairs down.
4. Set up the redirects in Squarespace’s URL mappings before making the site public.
5. Keep the redirect for a page that no longer exists pointing somewhere genuinely relevant, not to the homepage. Homepage redirects for everything are treated as soft 404s.
6. Launch, then test a sample of the redirects immediately.
7. Recheck Search Console for crawl errors over the following fortnight.
8. Expect a temporary dip regardless. A clean migration recovers; a careless one does not.

After launch: what to do in the first month

Watch Search Console for crawl errors, check that forms are still arriving, and fix the things real visitor behavior reveals.

A launched site is not a finished site, and the first month of real traffic tells you more than any amount of pre-launch review. The useful discipline is to look at what people actually do rather than at what the site looks like.

Why does the published site look different from the editor?

The editor renders your page at one width, logged in, with drafts visible and caching bypassed. The published site does none of those things. Almost every “it looked right before I published” report resolves to one of four causes.

The first is width. Squarespace previews at the browser width you happen to be using, and the breakpoints where a layout reflows are easy to miss if you only ever edit on one screen. Check the published page at a narrow width before assuming something broke — most reported breakage is a layout doing exactly what it was configured to do at a size you had not looked at.

The second is caching, on their end and yours. A hard refresh, or the same page in a private window, distinguishes a stale copy from a real problem in about ten seconds. If the private window is correct, nothing is broken and you are looking at your own cache.

The third is unpublished or scheduled content. Draft pages and scheduled posts are visible to you while logged in and invisible to everyone else, which produces empty sections and navigation links leading nowhere. The fourth is fonts and images that were still uploading when you published — a large image that had not finished processing shows in the editor from your local copy and as a placeholder to visitors. Always check the live URL logged out, from a device that has never seen the site.

What should you do about email deliverability before launch?

Publishing the site does not make its forms deliverable. Form notifications and any newsletter you send from your own domain need authentication records in DNS, and setting them up after the first message goes missing means the failures already happened silently.

The failure mode is quiet by design. Nothing bounces visibly, nothing errors in the editor, and the contact form reports success — the message simply lands in spam or is discarded before delivery. The first evidence is usually a customer asking why nobody replied to an inquiry you never saw.

Three DNS records govern this. SPF names which servers may send on behalf of your domain; DKIM signs each message so a receiver can verify it was not altered and genuinely came from you; DMARC tells receiving servers what to do when the first two do not line up, and can report back on who is sending as your domain. Missing any of them, and messages that clear one check while failing another get treated as suspicious.

Do this before you announce the site, not after. Send a test inquiry through the live form to an address on a different provider from your own, and confirm it arrives in the inbox rather than the spam folder. A form nobody can reach is the most expensive thing on a new site, because it looks exactly like a site with no inquiries.

Redirect mapping

Every old URL with traffic mapped before the switch, not after. This is the step that decides whether a rebuild keeps its rankings.

Technical setup at launch

Search Console, analytics, sitemap, titles and descriptions written per page rather than left as defaults.

Squarespace specifics

Plan, domain, availability and the platform’s own quirks. See what Squarespace costs and the customization guide.

Backups you control

The platform has no conventional backup. See how to back up and export a Squarespace site.

Post-launch monitoring

Crawl errors, form delivery and real visitor behavior in the first month, which reveals more than any pre-launch review.

Publishing a Squarespace site: what actually happens at the moment you go live

Squarespace publish is a single action with several consequences, and the confusion around it comes from the fact that a site can be visible in three different senses. The trial site is reachable by anyone with the URL. A site behind a password is built and hidden. A published Squarespace website is on your own domain and open to search engines. These are separate settings and people frequently change one expecting the others to follow.

People search this a dozen ways — squarespace publish website, publish website squarespace, publish squarespace website, publish squarespace site, publishing squarespace website — and they all describe the same four steps. The sequence for publishing a Squarespace website is: end the trial by subscribing, connect or transfer the domain, remove any site-wide password, and set the site to public. Only the last of those actually publishes; the earlier steps make publishing possible. A common outcome of publishing Squarespace site content without checking the password setting is a live domain that shows a lock screen to every visitor.

Worth knowing before you publish: Squarespace has no separate staging environment in the sense developers expect. A Squarespace staging site is normally either a second unpublished trial site or a duplicate of the live one, and changes made in the editor apply to the live site as soon as you save. There is no draft-and-deploy step, which is the single biggest adjustment for anyone arriving from another platform.

Frequently asked questions