Help

Publishing takes a copy of your last saved draft and makes it the live portal on your domain. Until you do, nothing you have built is reachable by anyone — you can design, preview and iterate for as long as you like. This guide covers the publish step, what changes for visitors and search engines the moment you go live, how to ship updates, and how to take a portal offline again.

Before you publish

A verified domain, mapped to this portal

Pick it in the Branding panel under Panel domain. Without one, publishing is refused — see below.

Your latest edits saved

Publish ships the last saved draft. Edits save on their own, so this is usually a matter of seconds.

A walk through the Preview step

Every page reachable, every list populated, the sign-in screen branded. See Previewing and Testing Your Portal.

Publishing

In the portal editor, click step Publish.
Read the summary card. It names the address the portal will answer on — Will publish to before the first publish, Live at afterwards — and counts what goes live: Pages: N, Public: N, and a note such as “2 hidden pages stay off the live site”.
Click Publish. The chip in the corner flips from Draft to Live, and the domain starts serving.

The Publish step of a live portal. Before the first publish the chip reads Draft, the address is labelled “Will publish to”, and the button reads Publish.

If publishing is refused

A portal has to have a domain that your organization has actually registered and that is mapped to this portal. If it does not, the publish is rejected and the portal stays in Draft, with the message: “Map an active custom domain to this portal before publishing — otherwise it won’t be reachable. Set one up under My Domains.” The Set up a domain button on the same card takes you there.

If you click Publish with unsaved edits pending, you are told “Saving your latest changes — click Publish again in a moment.” On a portal that is already live, a small warning appears while edits are pending: “You have unsaved changes. They go live the next time you publish.”

What goes live, and for whom

Publishing copies your draft to the live site in one step; there is no partial state. From that moment:

Page	Anonymous visitor	Signed-in participant
Public and Public, richer when signed in	Served from the server, indexable, listed in the sitemap.	Served, with the extra content a signed-in reader gets.
Private	Does not exist. Requesting the address returns a plain not-found — never a “you need to sign in” hint.	Served normally.
Hidden (eye toggle off)	Does not exist, and links to it are removed.	Does not exist.

Menu links pointing at pages a visitor cannot open are stripped from the anonymous version of the menu, so the title of a private page never prints on a crawlable page. Your Sign In link survives — it is the one app route a public menu may point at.

Search engines

Going live is what turns a portal into an indexable site. It brings three things with it:

A robots file at /robots.txt that allows exactly your public pages and disallows everything else, and points at your sitemap.
A sitemap at /sitemap.xml listing every public page, with blog listings expanded to one entry per published post, addressed by slug.
Page metadata — title, description, canonical URL, social share image and, on a post page, structured article data. On a post page the post’s own search title and description win over the page’s.

Paginated listing pages beyond the first (?page=2 and up) are deliberately crawlable but not indexed, so the posts on them are discovered without the listing pages competing with each other in search results.

Claiming the site in Google Search Console. If you control the domain’s DNS, add it as a Domain property and paste Google’s TXT record at your registrar — nothing to enter in the portal, and Google verification file stays empty. If you cannot touch DNS, add it as a URL prefix property (https://your-domain/), choose the HTML-file method and put the filename it shows into Google verification file in the Branding panel; publish first — the file is served from the live portal. For Bing Webmaster Tools, paste the token from its XML-file option into Bing verification token, or import the site from Search Console and skip the token. Indexing itself does not depend on verification; submitting /sitemap.xml in Search Console is what gets the site discovered.

The portal URL is simply your domain, and the Publish card gives you Copy link and Open in New Tab next to it. Share it in survey invitations, welcome emails, your own website or intranet, printed QR codes, or an automation that emails new participants when they are added.

How people get an account depends on two settings, and both take effect immediately without a republish:

Allow self-registration (Branding panel) decides whether the sign-in screen offers a Register link at all. Off means “only participants you onboard can sign in on this portal”.
Auto-approve sign-ups (Settings popover) decides what happens next. On, a new sign-up is active straight away. Off, they land on a “Registration Under Review” screen and wait for an administrator — signed in, that screen redirects them automatically once you approve.

Self-registration works on your own custom domain only. The shared preview host does not accept sign-ups.

Updating a live portal

Editing a published portal never takes it offline. The live site keeps serving the last published version while your changes pile up in the draft; nothing you type is visible to a participant until you publish again.

Make your edits in the Design step as usual.
Check them in Preview.
Return to Publish and click Publish changes.

The switch is atomic — participants mid-session are not disturbed. Give it a minute for pages to refresh across the cache, and up to an hour for the robots file and sitemap to catch up.

Publishing and unpublishing move one thing: the live copy. The draft, its history and the domain mapping are untouched either way.

Version history and rollback

The toolbar’s Version History drawer lists every saved state of the draft, newest first, the top one marked Current. Compare shows what changed against the current draft; Restore brings an older state back as the new draft. Restoring does not change the live site — preview it, then publish to push it out.

Version history is draft-side. Publishing does not create a version entry of its own, so rolling the live site back means restoring the draft you want and publishing it.

Taking a portal offline

Open the Publish step.
Click Unpublish and confirm — “Take this portal offline? Participants will no longer be able to open it.”

The live site is removed. Your design, its version history and the domain mapping are all kept, so republishing brings it straight back. Two side effects to expect while it is down: search engines are told to crawl nothing, and the search-engine verification file stops being served, so a verification you had not yet completed will need redoing.

Running several portals

Account → Portal Designs lists every portal with its status, domain, version and last-updated time. A domain belongs to exactly one portal and a portal serves exactly one domain, so a customer site, a staff hub and a partner portal are three portals on three domains — designed, branded and published independently.

Troubleshooting

Symptom	What to check
Publish is refused with a domain message	The portal has no domain, or its domain is not one your organization has registered and verified. Fix it under Account → My Domains, then select it in the Branding panel.
The domain shows a certificate warning or does not resolve	DNS is not finished. Check the domain card under My Domains — it re-checks on its own and shows Valid Configuration when routing is correct.
A page 404s for visitors but works for you	It is Private, or it is hidden. Change it under Who can see this page, or switch its eye icon back on, and publish.
A menu entry is missing on the live site	It points at a private or hidden page, so the public menu drops it. The Design canvas shows such links dimmed with a lock; re-point it at a public page or at Sign In.
Signing in lands people on the wrong page	No page — or the wrong page — is marked Default page after sign-in. It is a per-page checkbox, and it is separate from Default public page.
Changes are not showing after publishing	Confirm the draft was saved before you published, then give the cache a minute. A hard refresh in the browser rules out a local cache.
Search Console verification fails	The portal must be published — the verification file is served from the live site — and the filename must match Search Console exactly.
A metric or list shows an error	Its entity type, columns or filter are misconfigured. Select the component in Design and check its settings.