Website Content

Website content turns workspace configuration into a usable public presence. The console owns the editing surfaces; sites renders the customer experience.

Website

Use Website to manage:

• Homepage.
• Custom pages.
• Page builder blocks.
• Navigation.
• Footer sections.
• Legal links.
• Brand media.
• Public preview.

Every page should answer a customer question or drive a customer action. Avoid publishing placeholder pages.

Use the Website area as the customer-facing composition layer, not as a duplicate database. If a page needs live products, services, forms, reviews, or help articles, use blocks that read those records instead of copying the same text into static content. That keeps customer pages current when operators update the source record.

Content Model

When a customer-facing section mixes several record types, name the owner before editing. For example, a service landing page may be owned by Website, but the service price and availability should still be owned by Scheduling.

Page Builder Blocks

Common public-site blocks include:

• Hero and section headers.
• Rich text.
• Feature grids.
• FAQ accordions.
• Calls to action.
• Product grids.
• Service grids.
• Forms.
• Articles or stories lists.
• Background media.

Use product and service blocks when you want the public site to pull live catalog or booking data rather than duplicating content.

Before publishing a page with dynamic blocks, verify the empty state, loading state, mobile layout, and the behavior when the underlying product, service, form, or article is unpublished.

Forms

Forms collect structured customer input. Use them for:

• Contact requests.
• Intake.
• Consent.
• Quotes.
• Support.
• Feedback.
• Pre-booking or post-purchase details.

Submitted forms should land in the console where the team already triages work. Test every required field, file upload, confirmation state, and notification before launch.

Stories

Stories are editorial content for resource pages, news, guides, local SEO, or campaigns. They can support categories, tags, authors, search, sharing, and article-specific metadata.

Use Stories when the content should behave like a publication. Use Pages when the content is durable site structure.

Story content should have a clear distribution path: navigation, related content, campaign link, search route, or email campaign. A story that cannot be discovered by customers should remain draft until the team knows where it belongs.

Help And Knowledge Content

Help surfaces let customers self-serve:

• Help landing page.
• Decision trees.
• Knowledge articles.
• Category pages.
• Search.
• Article voting.
• Ticket escalation when an answer does not solve the issue.

Good help content reduces inbox volume and gives the team a consistent answer to reuse.

Discovery

Discovery covers how the site is found and shared:

• SEO titles and descriptions.
• Redirects and short links.
• GEO and answer-engine content.
• Search verification.
• Sitemap and robots.
• Open Graph previews.
• IndexNow when configured.

Use redirects and short links for campaign paths that operators need to copy, print, or change later.

Reviews

Reviews can be managed through the console and connected to Google Business Profile when available. Public review surfaces should make the real customer source clear and should not promise review sync unless the integration is connected.

Review display should be intentional: choose where reviews support trust, how stale reviews are handled, who can respond, and what happens when the Google Business Profile connection disconnects.

Publishing Preview

Before publishing, compare console and site state:

Content Publishing Rules

1. Prefer one source of truth. A product description should live on the product when product blocks render it.
2. Verify mobile layout before launch.
3. Keep legal and policy links visible.
4. Re-test public pages after changing branding, navigation, footer, domains, or site status.
5. Use Discovery to check how a page appears outside the site.