Going live

Everything here assumes a site built OUTSIDE Grofomo: your own code, Webflow, WordPress, a site builder, or an AI assistant. The platform does not care which. What it cares about is the order, because most launch-day failures are steps done in the wrong one.

The one rule

Allow an address before anything loads pages from it. Browsers are blocked from reading your data on any address that is not on the event's allowed-domains list, and the block looks like a broken site, not like a helpful error. This applies to the STAGING address as much as the live one: allow it before the first browser test, or the first browser test fails.

Everything an organiser hands over lives in one place: the organiser page covers the slug, the publishable key and the allowed domains.

While the site is being built

• Test on the deployed address, not just locally. The origin checks, the CORS behaviour and the form endpoints behave differently for a real deployed page than for a build on a laptop. A signup that works on localhost proves nothing about launch day; one that works on the staging address proves nearly everything.
• Null means the organiser has not filled it in. Drop the field. Never render a blank. The organiser's console shows them what a website will find empty, so gaps are their job to fill, not yours to pad.
• The event detail ships a ready-made schemaOrg block: use it instead of hand-building structured data, and the search-facing half of the launch is done.

Before the switch

• Both forms of the live domain on the allowed list: https://example.com AND https://www.example.com. Only one of them being present is a launch-day failure that looks like a platform outage.
• Smoke test the signup and any forms ON the deployed address, and confirm the entries arrive in the organiser's console.
• If the new site replaces an old one, map the old URLs to their new homes with redirects, and spot-check them.

Launch day

• DNS last. Point the domain only after everything above is green. Nothing needs changing in Grofomo on the day: the live domain was allowed in advance, and there is nothing to remove afterwards.
• Keep the old site reachable for about a week as a safety net before switching anything off.
• Submit the sitemap in Google Search Console.

Three common paths

A custom build on a static host (Cloudflare Pages, Netlify, Vercel). Three rules, and the first is the one that bites:

• Re-fetch on every build. The committed snapshot is the fallback, not the source. A build that reads only the committed copy turns every rebuild into a replay of old content, and the failure is silent: the deploy succeeds, the log is green, the page never changes. Commit the snapshot so a Grofomo hiccup ships the last good data instead of failing a deploy, and read it only when the fetch fails.
• Point site.content_changed at the host's deploy hook, so publishing a lineup, an article or an FAQ rebuilds the site instead of waiting for someone to push. Changes are batched into one rebuild per editing session, so expect a notification a couple of minutes after a change rather than instantly.
• Key any local image cache on the image URL, not on the artist or event id. Grofomo mints a fresh URL whenever an image changes, so URL equality is a reliable cache key and an id is not: an id-keyed cache serves whichever photo it fetched first, forever, and no number of rebuilds will dislodge it.

Gate the staging address behind a password that skips the live hostname: then the gate needs no removing on launch day, which is the one day nobody remembers to remove anything.

Staying on Webflow, WordPress or a site builder. Nothing needs a build step: fetch the feeds from the visitor's browser with the publishable key, and POST signups straight to the mailing-list endpoint. The key is designed to be visible in page source; see Authentication.

Building with an AI assistant. Hand it llms.txt and it can read this entire reference itself: see For AI agents. One human rule still applies: make it test on the deployed address, not just its local build.

After launch

The feeds keep the site current with no redeploys for content: a published lineup change, a new FAQ, a reordered photo gallery and fresh ticket availability all flow through on the next fetch. On a static build "the next fetch" is the next BUILD, so that only holds if the build re-fetches and something triggers it. How often each feed updates is covered in Caching.