Support

FAQ

What is the difference between draft, preview, and published?

Draft is work in progress, preview is what you review before launch, and published is what visitors see on the live website.

In-depth answer+

Publishing converts reviewed draft content into the public version and may trigger deployment, cache, sitemap, and domain checks. A publish should be treated as a release step, not a normal save.

Technical checks

  • Confirm the preview is correct before publishing. Check homepage, key navigation, Mass times, giving links, contact pages, and any page changed in the current draft.
  • Verify the user has publish permission. Editors may be able to draft content without being allowed to make it live.
  • Check domain readiness before launch: DNS records, SSL status, canonical host, redirect behavior, and whether an old host should remain active during transition.
  • After publish, open the live URL in a fresh browser session if possible and check that the expected version appears.

Escalation details to include

  • Send the site ID, publish time, user email, visible error, and whether the issue happened before, during, or after publish.
  • For stale live content, include the preview URL, live URL, and which section differs.
  • For deployment errors, include whether the domain was recently changed or DNS records were edited.

Reference notes

  • Publish permission: required for making a draft public.
  • Deployment: the build or hosting update that serves the published files.
  • Rollback: use version history when a known previous state needs to be restored.
  • Cache behavior: DNS, CDN, or browser cache can delay visible changes after successful publish.

What happens if publishing fails?

The existing live site should stay intact, the failure is logged, and support can review the diagnostic details. Send a support request if the dashboard does not already explain the next step.

In-depth answer+

Publishing converts reviewed draft content into the public version and may trigger deployment, cache, sitemap, and domain checks. A publish should be treated as a release step, not a normal save.

Technical checks

  • Confirm the preview is correct before publishing. Check homepage, key navigation, Mass times, giving links, contact pages, and any page changed in the current draft.
  • Verify the user has publish permission. Editors may be able to draft content without being allowed to make it live.
  • Check domain readiness before launch: DNS records, SSL status, canonical host, redirect behavior, and whether an old host should remain active during transition.
  • After publish, open the live URL in a fresh browser session if possible and check that the expected version appears.

Escalation details to include

  • Send the site ID, publish time, user email, visible error, and whether the issue happened before, during, or after publish.
  • For stale live content, include the preview URL, live URL, and which section differs.
  • For deployment errors, include whether the domain was recently changed or DNS records were edited.

Reference notes

  • Publish permission: required for making a draft public.
  • Deployment: the build or hosting update that serves the published files.
  • Rollback: use version history when a known previous state needs to be restored.
  • Cache behavior: DNS, CDN, or browser cache can delay visible changes after successful publish.

Contact us

Include the domain, current site or dashboard URL, what changed, what you expected, and a screenshot when the issue is visual.

Need urgent help?

We will get back to you as soon as possible.