Campaigns have lifecycles; hosting should respect the ending

An evergreen product landing page may live for years. A campaign landing page exists for a flight of ads, an event registration window, or a seasonal SKU—and then it should go away or park cleanly. This article is about that lifecycle. For general landing-page craft, see static landing page hosting; here the emphasis is spin-up, isolation, measurement hygiene, and teardown.

StaticHost fits because each campaign can be its own site (plan site counts matter), deploys are reversible, and you are not maintaining a WordPress install per promo. Zip or GitHub of prebuilt HTML, HTTPS preview immediately, custom domain cert after DNS verifies, history/rollback. No remote npm, no SPA fallback, no email/cPanel/CDN product/forever-free (trial ~1 day).

Isolate per campaign

Prefer a dedicated StaticHost site (and often a dedicated hostname) per campaign:

  • go.example.com / spring2026.example.com
  • Separate deploy history from the evergreen homepage
  • Separate teardown without touching core brand pages

Site quotas:

PlanSitesStoragePrice
Starter12 GB$9/mo
Pro310 GB$30/mo (+ staging)
Scale1030 GB$65/mo
Business30100 GB$130/mo (+ teams)

Agencies running parallel flights lean Scale/Business—agencies.

Spin-up runbook

  1. Freeze creative + copy.
  2. Build static page (hand HTML, export, or Vite single page).
  3. Zip contents correctly—zip.
  4. Deploy; QA on HTTPS preview (UTM links, pixels, forms).
  5. Add campaign hostname; DNS verify; wait for certificate—custom domain.
  6. Grep mixed content—SSL.
  7. Enable ads only after step 6.
  8. Record the site ID and hostname in the campaign ticket for teardown.

If the page is a history-mode SPA, fix routing before spend—SPA.

During the flight

  • Small copy deploys; roll back losing variants via deploy history.
  • Staging on Pro for legal review of claims without touching the live ad URL.
  • Do not “temporarily” host unrelated content on the campaign hostname.

Teardown runbook

When the campaign ends:

  1. Pause ads and email drives to the URL.
  2. Replace the page with a polite sunset (This offer has ended + link to evergreen site) or remove the site if the hostname will be retired.
  3. Lower DNS TTLs ahead of hostname retirement; remove DNS when done.
  4. Delete or archive the StaticHost site so you stop paying for ghost campaigns.
  5. Export final analytics; keep the last zip in object storage for legal/records if required.

Teardown is part of hosting cost control. Forgotten microsites are how teams accidentally need Business when Starter should have sufficed.

Measurement hygiene

Use unique UTM defaults baked into on-page links. Keep pixels campaign-scoped when vendors allow. Because StaticHost has no built-in edge A/B product, run experiments with external tools or sequential deploys—not mythology.

Worked example: two-week summit registration microsite

Product marketing wants summit.example.com live for fourteen days. Legal must approve claims. Paid social starts Friday noon.

Monday: build a single index.html with schedule anchors (/#speakers). Form posts to a registration SaaS over HTTPS. Zip and deploy to a new StaticHost site on Pro so staging exists.

Tuesday: legal reviews staging HTTPS URL; they reject one superlative. You fix copy, redeploy staging, get Slack approval. Production still shows the safe earlier build.

Wednesday: promote approved build to production; add summit.example.com; create DNS; wait for verification; wait for certificate. Grep for http:// pixels.

Thursday: QA on the custom domain—form, UTM links, mobile. Confirm try_files reality: you did not invent /register as a client route without a file.

Friday noon: ads on. Saturday: headline underperforms; you deploy a variant; Sunday you roll back via deploy history when CTR falls.

Day 15: pause ads; deploy sunset page linking to https://example.com/events; export metrics; delete the StaticHost site next billing cycle if the hostname retires. StaticHost never ran npm, never sent email, and never needed a CDN product for a two-week page with a 120 KB hero.

Failure table: campaign hosting

SymptomLikely causeFix
Ads live, cert not readySkipped DNS waitStop spend; finish verify → cert
Legal angry at live claimsEdited production firstUse Pro staging; promote after approval
Budget burns on old micrositesNo teardownSunset + delete sites; right-size plan
/agenda 404 from QR codeSPA path without fileReal agenda/index.html or hash
Form leads missingHost assumed to mailboxForm SaaS; test before ads
Wrong UTM on all creativesLinks not baked/testedPreview click-through checklist
Nested zip, blank ad landingsite/index.html nestingFlatten; re-QA on preview

Extra procedure: campaign ticket template

Use these fields in every campaign hosting ticket:

  • Site name / StaticHost site ID
  • Hostname(s)
  • Plan (and whether staging is required)
  • Build source (zip owner or Git artifact branch)
  • Form endpoint + analytics property IDs
  • Ad start datetime + earliest teardown datetime
  • Last known good deploy description
  • Sunset destination URL
  • Owner for DNS removal

When the flight ends, the ticket already knows what to delete. That is how you stay on Scale ($65) instead of sleepwalking into Business ($130) because twelve dead promos still exist. Evergreen craft remains in the landing page guide; this procedure is the lifecycle wrapper. No forever-free, no cPanel, no email—set those expectations in the same ticket so nobody opens a surprise request mid-flight.

Creative versioning without losing the audit trail

Regulators and brand teams sometimes ask which exact headline ran during a flight. Because StaticHost keeps deploy history, label deploys with ticket IDs (SUMMIT-142-headline-B) in your own notes when you upload. Keep the corresponding zip in object storage for the retention window legal quoted—even after you delete the live site in teardown.

Do not overwrite staging randomly during an active flight without recording what production currently serves. Pro staging is for the next candidate, not a scratchpad that drifts from the ad URL. If you must hot-fix a broken pixel, change only that snippet, redeploy, and note it in the campaign ticket. The host will not run npm mid-flight; your prebuilt artifact discipline is the compliance-friendly path.

FAQ

How is this different from the landing page article?

That guide covers structure and performance of landers generally. This one covers campaign isolation, ad-flight timing, and teardown.

Can one site host many campaigns under paths?

Yes (/promo/spring), but isolation and teardown get messier. Prefer separate sites when quotas allow.

Should campaign pages use the apex domain?

Usually a subdomain keeps risk and cookies cleaner relative to the main app/site.

What about post-campaign SEO URLs?

If the URL earned links, leave a sunset page with a clear next hop instead of hard 404 immediately.

Do I need Git for two-week campaigns?

Zip is enough. Use Git when multiple people ship changes under deadline.