Dynamic Headlines for Your Website: 3 Ways to Build Them

A dynamic headline is a headline that changes based on who's looking at it. Same page, same URL — different words for the Google visitor, the LinkedIn visitor, and the person coming back for the third time. Three ways to build this:

Approach 1: Server-side rendering swap

The server decides which headline to render before the HTML reaches the browser. Minimal Express example: a variants map keyed by utm_campaign with a default fallback; server reads req.query.utm_campaign or a cookie, renders the headline into the template. Pros: no flicker, no layout shift, fast. Cons: caching gets complicated (vary cache by campaign or bypass it — where most attempts die); you own the variant map (every new campaign = code change + deploy + QA); doesn't fit static/JAMstack without edge functions; limited signals (server sees URL, headers, cookies only). Best for: server-rendered apps with modest campaign counts and someone to own the variant map and caching.

Approach 2: Client-side JavaScript swap

Page renders with a default headline, then a script swaps it based on the URL: read utm_campaign via URLSearchParams, look up a variants object, set textContent, keep the original as fallback (never blank). To avoid flicker, hide the headline with visibility:hidden (keeps layout space — no shift) until the swap decision runs, then reveal. Pros: works everywhere (any HTML, any host, any CMS), free, simple. Cons: flicker-or-delay tradeoff; you own everything (variant map, cookie logic, QA, edge cases — a typo'd UTM falls back to default only if you built the fallback); URL-only signals out of the box; it rots (variant maps in code go stale — the real cost of DIY is maintenance, not building). Best for: one or two campaigns, a technical team, acceptable brief flicker.

Approach 3: The snippet approach (what Prept does)

One snippet before plus data-prept="headline|subcopy|cta" tags. Variants managed in Prept's dashboard, mapped to UTM campaigns, referrer, new vs. returning, geo, company-level enrichment. Swap after paint with reserved layout space; original text always the fallback; 10% control holdout on the original. Pros: no code per variant (marketing edits in dashboard, no deploy); richer signals built in; fallback guaranteed by construction; holdout tells you if it's working. Cons: third-party script; swap after paint; costs per visit (1 credit new, 0.25 returning — 60k visits/month at 40k new/20k returning = 45,000 credits, covered by the $129 50k pack); Prept does not do A/B testing.

Side-by-side: Server-side — no flicker, no shift, needs edge/server, signals DIY, fallback your code, maintenance via deploys, cost = dev time. Client-side DIY — flicker unless hidden, no shift if done right, works on static, signals DIY, fallback your discipline, rots silently, cost = dev time. Prept snippet — brief swap after paint, no shift (space reserved), works on static, signals built in, fallback by construction, dashboard maintenance, cost = per-visit credits, no A/B testing.

When to DIY vs. when to use Prept

DIY when: server-rendered stack with an owner; small stable campaign count; simple variant logic; flicker-free first paint justifies the caching work. Use Prept when: variants change often or are owned by non-developers; you want unbuilt signals (returning visitors, referrer, company-level); the variant map became a second codebase; you'd rather pay ~$0.002/visit than maintain machinery. Middle path: DIY the one or two biggest campaign mappings, let Prept handle the long tail. Avoid: building DIY "temporarily" — temporary headline scripts become permanent, unmaintained, and wrong.

Further reading: Website headline personalization: what it is and how it works — Migrating from Google Optimize: a practical guide — Personalize your landing page by ad campaign. CTA: Install the snippet →.