Most do not, and the ones that do need them for three specific jobs. A timed launch, a kill switch on a risky third party script, and gating a page to one audience. Everything else people reach for flags to do on a marketing site is better solved by a deploy or a redirect.
This is an unfashionable position. Feature flags are near universal in product engineering, and the tooling has become very good, so the instinct is to bring the same practice to the website. We think the trade is different when the site is static and public.
Here is the case on both sides, the specific technical traps, and where we land when a client asks.
It is a runtime switch that changes behaviour without a deploy. Your code asks a service whether a named flag is on for this context, and branches on the answer. The value can differ per user, per environment, or per percentage of traffic.
OpenFeature, which is a Cloud Native Computing Foundation incubating project, defines the standard vocabulary here. It describes an Evaluation API that the application author interacts with, an Evaluation Context holding arbitrary contextual data, Providers as the translation layer to a flag management system, Hooks for adding behaviour in the evaluation life cycle, and Events for reacting to state changes.
That vocabulary is worth learning even if you never adopt the spec, because every vendor implements some version of it. It also makes clear what a flag actually is. Not configuration, and not a build setting. A decision made at request time.
Because app teams ship into a runtime and marketing teams ship into a cache. In a product, a flag lets you merge unfinished code, dark launch it, and turn it on for ten percent of accounts. The deploy and the release become separate events, which is genuinely transformative.
A marketing site usually does not have that problem. There is no half finished feature sitting behind a login. Publishing a page is the release. If you want to change the hero, you change the hero and push, and the whole thing is live in ninety seconds.
The other reason is that most marketing sites are prerendered or heavily cached, and a runtime decision fights that architecture. Vercel's own flags documentation lists the benefits as rolling out gradually, testing in production, running experiments, and shipping independently of releasing. All four are worth more when the page is dynamic than when it is a static file at the edge.
A cached page has one body for everyone. The moment a flag changes what a page says, that page can no longer be a single cached artifact, or the flag does nothing for the visitors who get the cached copy.
You then have three options and each has a cost. Move the decision to the client, which means a flash of the wrong content and a hit to layout stability. Move it to the edge, which means a function runs on every request and you have traded away some of the speed you built the static site for. Or precompute every combination and cache them all, which works but multiplies your build.
None of these is fatal, and good platforms handle them well. But it is a real architectural change on a site whose main advantage was that it was simple and fast. Our piece on static versus server rendered covers the same tension in more depth.
It can, and the rule is clear enough to follow. Google's own website testing guidance says do not show one set of URLs to Googlebot and a different set to humans. It warns that violating spam policies can get your site demoted or removed from Google search results.
The practical reading is that flags which change small parts of a page are fine, and flags which serve a materially different page to a crawler than to a person are not. If you would be uncomfortable explaining the difference, that is your answer.
For anything running on separate URLs, Google says to use the rel="canonical" link attribute on all of your alternate URLs to point at the original, and to use a 302 temporary redirect rather than a 301 permanent one. It also says to remove all elements of the test as soon as you conclude it, and warns that running experiments for an unnecessarily long time may be read as deceptive.
The first is a timed launch. If a product announcement has to go live at a precise moment across a press embargo, a flag beats asking someone to click deploy at the right second. The content ships early, hidden, and flips on schedule.
The second is a kill switch. Third party scripts are the most common cause of a sudden performance or privacy problem on a marketing site, and being able to turn one off without a deploy is worth having. That is a flag whose value is entirely defensive.
The third is audience gating. A page that should only be visible to customers who received a link, or a region specific offer, is a real runtime decision and a flag is the honest tool for it. Notice that all three are about when or to whom, not about testing which version wins.
Less than people expect at marketing site scale. LaunchDarkly's published pricing lists a Developer plan at zero dollars a month, forever, including unlimited seats, unlimited feature flags, 30 idiomatic SDKs, and 5 service connections with 1K client side monthly active users per month, on 14 days of data retention.
The paid step is where it changes shape. Its Foundation plan is listed at 10 dollars per service connection per month billed yearly, plus 8.33 dollars per 1,000 client side monthly active users per month. On a public marketing site, client side monthly active users is essentially your traffic, so that meter scales with the thing you are trying to grow.
That is the cost detail worth checking before you commit. A flag system priced per authenticated user is cheap for an app and can be expensive for a website, purely because a website has far more unique visitors than an app has accounts.
Use the vendor neutral layer so you can leave. OpenFeature exists precisely so the evaluation call in your code does not name a vendor, and it publishes server side SDKs for languages including Go, Java, Node.js, .NET, PHP, Python, Ruby and Rust, plus client side SDKs for Web, Kotlin and Swift.
On the platform side, Vercel documents a Flags SDK described as a framework native library for Next.js and SvelteKit that works with any provider, alongside a Flags Explorer in the Vercel Toolbar for viewing and temporarily overriding flags during development. Its marketplace connects providers including LaunchDarkly, Statsig and Split.
Whatever you pick, log evaluations. Vercel's documentation points at Runtime Logs and Web Analytics for this. A flag whose state nobody can reconstruct after the fact is how you end up with a bug you cannot reproduce.
For scheduling, a scheduled publish in your CMS. Webflow, and most content platforms, can publish at a time without any runtime machinery, and the page stays a plain cached file. That covers the launch use case for many teams.
For experiments, use a purpose built testing tool rather than hand rolling variants behind flags. It handles the statistics, which is the part teams get wrong, and it is built to respect the search rules. We cover that side in our piece on A/B testing on Webflow.
For safe changes, use deploy previews. Reviewing the real page on a real URL before it goes live solves most of what a dark launch solves on a site this size, without adding a runtime dependency. Our guide to staging sites and deploy previews covers how we set that up.
Every flag is a branch that has to be maintained until someone deletes it. Six months after launch, a site with fifteen forgotten flags has a combinatorial number of possible states, and nobody knows which combination the site is actually in.
Product teams manage this with cleanup rituals because they feel the pain in their test suite. Marketing sites rarely have a test suite, so the debt is invisible until something breaks in a way nobody can explain.
If you adopt flags, adopt the removal habit at the same time. Every flag gets an owner and an expiry date at creation. Any flag past its date either gets extended deliberately or gets deleted. That single rule prevents almost all of it.
Skip flags on a standard marketing site. Use scheduled publishing for launches, deploy previews for safety, and a real testing tool for experiments. You keep the site simple and fast, which was the point.
Adopt flags when you have at least two of the three real jobs, or when your marketing site and product app share a codebase and a flag system already exists. In that second case the marginal cost is near zero and there is no reason to be purist about it.
If you are weighing this up on a specific build and want a straight answer rather than a vendor pitch, we are happy to look at it with you. You can reach our team at phoenix.studio and we will tell you when the simpler option is the better one.
Tell us where you want to go. We'll tell you how we'd get you there.