Skip to content

Landing page systems

Landing-page systems: stop building every campaign page from scratch

Campaign pages built individually are slow to produce, inconsistent to maintain and impossible to learn from. A landing-page system makes variation deliberate — and makes every result improve the next page.

John M Granskou11 min read
Modules assembled into pagesModule libraryPagePagePage
Landing-page systems: stop building every campaign page from scratch

Most organisations build campaign pages the same way every time: a brief, a design, a build, a tracking request, a launch, a report and then silence. The page runs for six weeks, produces a number, and contributes nothing to the page built after it. Repeated a dozen times a year, that is a substantial budget spent on work that does not accumulate.

The cost of the one-off page

A bespoke page carries hidden costs beyond its build. Brand and message drift, because each designer resolves the same problems differently. Measurement drifts, because each page instruments itself in its own way and the results cannot be compared. Maintenance drifts, because nobody owns a page after the campaign that justified it has ended.

The decisive row is learning. One-off pages produce results; a system produces knowledge.

What the system is made of

A landing-page system is a small library of modules with clear jobs, plus rules about how they combine. Message modules state what the offer is and who it is for. Proof modules make the claim credible. Offer modules describe what the visitor receives and on what terms. Action modules capture intent and set expectations about what happens next.

One architecture, several page types. Variation is a configuration decision rather than a new build.

Audience and intent variants

The variants worth supporting are usually fewer than teams expect: paid traffic with a narrow message and a single action; search traffic with broader intent and multiple next steps; regional pages carrying local proof; and partner or referral pages that assume prior context. Each is a defined combination of modules, not a separate design language.

VariantTrafficWhat changes
CampaignPaid, narrow intentSingle message, one action, no site navigation, usually not indexed
ServiceSearch, mixed intentFull context, multiple paths, indexed and linked into the site structure
RegionalLocal search or local campaignLocal proof, service area, regional contact — same offer
PartnerReferral, warmAssumed context, shortened proof, faster path to action
Common variants and what changes between them.

SEO and paid pages are not the same object

Campaign pages that duplicate an existing service page for paid traffic should generally stay out of the index; pages built around real search demand belong in the site architecture, linked and structured like any other page, as described in SEO as architecture. Treating the two as interchangeable produces either thin duplicate pages in the index or campaign pages that are needlessly constrained.

Measurement has to be part of the module

If instrumentation is added per page, comparability is lost immediately. Events, naming and definitions should be built into the modules themselves so that every page reports in the same shape without anyone requesting it.

Which events matter is a separate decision, and worth making deliberately rather than by default — see measurement strategy.

Experimentation that compounds

Once structure and instrumentation are constant, testing becomes cheap and interpretable. A hypothesis is expressed as a module variant rather than as a new page, and a positive result can be adopted into the default for every future page.

This is the growth loop applied to internal capability: each cycle improves the starting point of the next.

Governance keeps the system honest

  • Every page has an owner and an end date, reviewed rather than assumed.
  • Naming and URL conventions are fixed, so pages are findable in analytics a year later.
  • Indexing rules are explicit per variant, not decided page by page.
  • New modules enter the library deliberately; per-campaign one-offs are the exception and are logged as such.
  • Retired pages are removed or redirected, not left running with stale offers.

It only works on a real design system

A landing-page system is the applied form of a design system: shared tokens, shared components, shared accessibility and performance characteristics. Where the underlying platform cannot support that — templates diverging, plugins introducing their own markup, tracking bolted on per page — the system degrades back into one-off pages with extra steps. That constraint is discussed in is WordPress still relevant? Progressive web apps and modern architecture.

Assembled properly, the system does two things at once: it makes execution fast enough that campaigns are worth running, and it makes the results legible enough that they improve the wider growth system rather than disappearing with the campaign.

Frequently asked questions

What is a landing-page system?

A reusable page architecture built from modular blocks — message, proof, offer, form, follow-up — combined with shared instrumentation and governance, so new pages are assembled rather than designed from scratch.

Does this make every page look the same?

No. It makes the structure consistent and the variation deliberate. Different audiences, offers and regions get different module combinations and different copy within one coherent architecture.

Should campaign landing pages be indexed?

Usually not, when they duplicate an existing service page for paid traffic. Pages built to answer real search demand should be indexable and belong in the site structure rather than in the campaign inventory.

How does a system speed things up?

Because the expensive parts — layout, components, tracking, form handling, accessibility, performance — are solved once. A new page becomes a content and configuration exercise measured in hours rather than weeks.

How does a system improve learning?

Consistent structure and identical instrumentation make results comparable across pages. A module that wins in one context can be tested and adopted everywhere, which compounds; a one-off win rarely leaves the page it happened on.

Who should own the system?

One owner for the module library and standards, with campaign owners assembling pages within it. Without that split, the library either stops evolving or fragments into per-campaign variants.