Landing page production at campaign speed

Ask a marketing team why a landing page takes a week and they will say "development". Watch the process and the development is usually a day. The week is made of waiting.

A brief goes to a designer, who produces a comp. The comp goes to a developer, who asks two questions and waits for answers. The page is built, then reviewed by someone who wants the headline changed, which means another round. Then it needs tracking, which means a second person. Then it waits for a release window. Nobody in that chain is slow. The chain is the problem, and adding developers to it makes the handoffs worse rather than better.

The observation that matters: almost none of that work is unique to the campaign. The hero was a hero last time. The three-up benefit row was a three-up benefit row. Perhaps ten per cent of a typical campaign page has never existed on the site before, and the process treats one hundred per cent of it as new.

A section library is a set of composable, tested sections that a merchandiser arranges in the theme editor without touching code. It is not a novel idea — it is what Online Store 2.0 sections are for — but most stores have a theme whose sections were built for the home page and never generalised, so campaign pages fall outside them.

Start by auditing the last ten campaign pages you ran and listing what was actually on them. The list is shorter than anyone expects, and it is roughly this: a hero with an image and one call to action, a value-proposition row, a feature or benefit block with an image beside it, a product grid you can point at a collection or a hand-picked set, social proof, a comparison table, an FAQ, a rich-text block, a countdown or urgency band, and a closing call to action.

That is ten sections. Build them properly once — responsive, accessible, with constrained settings — and the eleventh campaign page costs an afternoon of copywriting. Shopify's own limits are nowhere near binding here: a JSON template can render up to 25 sections with up to 50 blocks each, and a theme can hold up to 1,000 JSON templates. The ceiling on your throughput is organisational, not technical.

Constrain the settings deliberately. The temptation when building a reusable section is to expose everything — every colour, every spacing value, every alignment — so that it can do anything. Do that and you have rebuilt a page builder, badly, and every page produced with it will be slightly off-brand in a different way. Expose the choices that vary between campaigns and hard-code the ones that should not. Fewer settings produce better pages faster, which is not intuitive until you have watched both.

This is where these programmes succeed or quietly fail, and it is a conversation rather than a technical control.

A campaign will need something the kit does not have. The request arrives as "just this once" and it is always genuinely reasonable. The cost is not the day it takes: it is that the section now exists forever, in a theme somebody will inherit, with settings nobody documented, used on one page that was taken down in December.

Two rules make this manageable without being obstructive. First, the answer is "which existing section is closest, and what would it need?" — often an extra setting on something that already exists, which is a small change that makes the kit better rather than bigger. Second, anything genuinely new goes on a list, and the list is reviewed quarterly; a pattern requested three times is a real gap and should be built as a proper, general section. A pattern requested once was a comp, not a requirement.

Say no to enough of these and the kit stays learnable. A library of fifteen sections is something a new marketer understands in an afternoon. A library of sixty is a codebase, and it will be used like one — which is to say, by a developer, which is where you started.

Once the sections exist, the remaining delays are administrative, and they are worth standardising precisely because they are dull enough that nobody owns them.

URLs. Decide the pattern before the first page, not the fifth. Campaign pages accumulate, and a store with /pages/black-friday, /pages/bf-2025 and /pages/black-friday-sale-new has three pages competing for the same term and no one willing to delete any of them.

Tracking. If adding a conversion event to a new page requires a developer, every page still requires a developer. Handle it in the section or in tag management so the page inherits it.

Images. Publish the sizes and the crops with the kit. Most of the visible quality difference between a good campaign page and a bad one is whether the images were produced to the slot or dropped in and stretched.

A QA checklist. Ten items, the same ten every time: one h1, meta description written, images have alt text, the page renders on a phone, the call to action goes where it claims, tracking fires, no placeholder copy, the price shown matches the price charged, the page is not indexed if it should not be, and the discount code actually works. That last one has ruined more campaigns than any rendering bug.

An end state. Every campaign page needs a decision made in advance: does it stay live, redirect somewhere, or get deleted? Without that rule a store ends up with sixty dead campaign pages, some still promoting expired discounts, all of them crawlable.

The obvious alternative is a drag-and-drop page builder from the app store, and it does solve the throughput problem. It is worth being clear about what it costs, because the trade is real and the sales pitch does not mention it.

You are adding a rendering layer between your theme and your pages. Your campaign pages now live in that vendor's data rather than in your theme, so they are not in version control, not reviewable in a pull request, and not portable if you change theme or leave. They render through the vendor's JavaScript, so they perform however the vendor performs, on your most commercially important pages of the year. And the pages usually stop working properly if you stop paying.

For a store that will build five campaign pages ever, that is a perfectly rational trade. For a store running campaigns continuously, the kit is cheaper within a year, faster at the point of use, and the pages are still yours. The honest distinction is volume: below a handful of pages a year, do not build the library — the platform tax is smaller than the build.

The version we would push back on is the third option, which is what most stores are actually doing: no kit, no builder, and a developer ticket per page. That one has all the cost and none of the speed.

• Shopify section library
• Shopify landing page production
• Collection pages are your best SEO asset