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.
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.
In this series: Digital growth
Digital growth
- Digital growth as a system: how product, SEO, conversion and measurement work together
- Growth loops vs campaigns: building growth that compounds
- Conversion architecture: designing the path from attention to action
- Product, SEO and acquisition: why growth teams cannot work in silos
- Measurement strategy: what should you actually measure?
- Landing-page systems: stop building every campaign page from scratchYou are reading
Part of JMG Group services.
In this article
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.
One-off pages vs a landing-page system
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.
Modules assembling into distinct pages
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.
| Variant | Traffic | What changes |
|---|---|---|
| Campaign | Paid, narrow intent | Single message, one action, no site navigation, usually not indexed |
| Service | Search, mixed intent | Full context, multiple paths, indexed and linked into the site structure |
| Regional | Local search or local campaign | Local proof, service area, regional contact — same offer |
| Partner | Referral, warm | Assumed context, shortened proof, faster path to action |
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.
Hypothesis → variant → measurement → adoption
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.
