Marketing Website Stack: Webflow vs. Jamstack — Our Rulebook
Introduction
This article is about marketing sites—brand, editorial, launches, docs. Not product dashboards. We run two lanes: Webflow when speed and non-dev ownership win; Jamstack (headless CMS + a modern framework) when the site behaves like a product. We choose by job, not logo—and we design the exit path on day one.
Why marketing sites are a different beast
Marketing sites live on editorial velocity, brand fidelity, SEO, and global reach. The stack that wins is the one your content team can actually use while engineering keeps performance, a11y, and governance tight. That’s the tension: speed & ownership vs control & complexity. Our stack exists to resolve that tension with intention.
Two lanes, one principle: choose by the job
Lane 1 — Webflow (when speed rules)
Use Webflow when most of your work is pages, posts, campaigns, and light integrations.
Why we pick it
- Editors publish in hours, not sprints.
- Designers get pixel accuracy without “please open a ticket.”
- Core Web Vitals are strong with light discipline.
- Ops are boring (in a good way): hosting, CDN, images are built in.
Team demand
- Build: 1 designer + 1 Webflow dev.
- Run: 0–0.5 FTE dev. Marketing owns 80–90% of changes.
When it’s the wrong lane
- Content looks like a database (deep relations, multi-brand trees, programmatic pages).
- You need complex roles/approvals, heavy personalization, or gated areas.
- You want pockets of app-like behavior beyond simple embeds.
Lane 2 — Jamstack (when the site acts like a product)
Jamstack = headless CMS (Sanity/Contentful) + a modern framework, shipped to an edge-first platform.
Why we pick it
- Model complex content cleanly (relations, locales, validations, workflows).
- Scale programmatic pages (thousands), API-fed sections, catalogs, geo variants.
- Deeper integration surface (experiments, search, first-party data).
- You own the knobs: caching, headers, redirects, structured previews.
Framework choice (keep it pragmatic)
- Astro for content-first speed: zero JS by default, island hydration only where needed. Great for docs/editorial/landing systems with a few widgets.
- Next.js for app-like needs: SSR/ISR, server actions, auth, complex routing. Best when personalization and experiments are first-class.
Team demand
- Build: usually 2–3 engineers (FE, content/schema, part-time DevOps).
- Run: 1–2 FTE devs (schemas evolve, CI, experiments, perf budgets).
Five signals that decide the lane
- Content complexity: Flat + human-written → Webflow. Deeply structured/programmatic → Jamstack.
- Team & governance: Small team, simple roles → Webflow. 10–50 editors, approvals, granular permissions → Jamstack.
- Localization: 1–3 locales → Webflow. 4+ locales with market-specific variants → Jamstack.
- Integrations/personalization: CRM/forms → Webflow. APIs, experiments, audience segments → Jamstack.
- Scale & cadence: <5k pages, weekly cadence → Webflow. 5k–100k pages, daily pipelines → Jamstack.
If one signal is extreme (e.g., heavy personalization), it can outweigh the others. We’re opinionated, not dogmatic.
What actually changes for performance, SEO, and experiments
Both lanes can be fast and search-friendly—if you respect budgets.
- Webflow: easy wins—image discipline, a script diet, server redirects, avoid layout shift.
- Astro: speed by default—almost no JS ships; islands hydrate only where useful.
- Next.js: more control—ISR windows, edge redirects, server-side testing (no CLS tax), granular headers.
Our non-negotiables: LCP < 2.5s, CLS < 0.1, a11y AA in PRs, and experiments that don’t sandbag Core Web Vitals.
How we migrate without wrecking SEO
We design the exit on day one. If we start in Webflow and outgrow it:
- Freeze slugs and CMS structure.
- Stand up a headless CMS with matching fields.
- Migrate content; ship 1:1 redirects where needed.
- Re-platform in slices (home → product → blog).
- Verify hreflang, redirects, analytics; flip DNS behind a flag.
Going the other way (Jamstack → Webflow) is rare and tied to a product-to-brand pivot. Either way, URLs survive.
What about forms, search, and “little app” features?
- Forms: Webflow native is fine; on Jamstack we use the CMS + serverless handlers (and keep PII sane).
- Search: Basic → Postgres/FTS. Fuzzy/ranking → Algolia/Meilisearch.
- Personalization/experiments: Keep them server-side when possible to protect vitals.
- Media: Use an image CDN; never ship raw assets; set page-level budgets.
Two quick snapshots (receipts)
Global editorial site. We stayed in Webflow, introduced component discipline and page budgets, trimmed third-party bloat. Publishing moved from days to hours; p95 LCP improved ~30% across three regions. Editors truly own content; devs stopped shipping JPEGs by hand.
Category site with programmatic pages. Jamstack with Sanity + Astro for content, sprinkling islands for calculators/forms. Thousands of long-tail pages shipped with near-zero JS; search ran on Algolia; editors finally got previews and approvals that matched reality.
No fairy dust—just the right tool for the job.
Risks we avoid on purpose
- Framework tourism. New toys slow teams; we graduate tools after a spike + pilot.
- Over-personalization. If it doesn’t move a KPI, it’s decoration (and a perf hit).
- “One stack to rule them all.” Marketing sites and apps have different physics—respect that.
Bottom line
Use Webflow when the win is editorial speed and non-dev ownership (operate with ~0–0.5 FTE dev).
Use Jamstack when the win is modeling complexity, integration depth, and scale (operate with ~1–2 FTE devs).
Say what the site is, pick the lane, and write the exit plan before you fall in love. If you want our one-page rubric (scoring grid + team plan + migration checklist), ping us—we’ll apply it to your site and send back a plain-English recommendation with costs and risks.