Campaign Landing Pages Without a Page Builder

Definition

Marketing teams composing full campaign and launch pages from theme-editor sections — hero, offer modules, takeover header, proof, CTA — with no page-builder app and no developer per launch. Also covers launch gating: passcode-gated early-access pages and branded password-protected pre-launch storefronts. The corpus contains whole section kits built for a single launch and reused across dozens of campaign templates.

The Evidence

• Evidence strength: 26 live, Deploi-attributed builds across 3 Shopify storefronts.
• Split by storefront: Three Ships 14, Nudestix 11, LUS Brands 1.
• Split by attribution: 22 Deploi-authored, 4 modifications of vendor theme code — named as such on each build page.
• Evidence quality: five carry code plus client working records. Twenty-one are documented from the code; no client-side record of the decision survives.
• Confidence: 4 strong, 22 moderate.
• Surfaces: landing pages first and by a distance, then home, with a few modules that also serve the product and collection pages.
• Status: Live, verified 2026-09-06.

That evidence profile is the weakest of the three hubs in this batch, and it is worth saying plainly. Campaign sections outlive the conversation that produced them: the page ships, the campaign ends, the code survives. Twenty-one of these 26 are read from the theme with no client-side record of why they were built that way. The mechanics below are what the code says; the intent behind any one of them is inference.

How It's Actually Built

A campaign page here is a JSON template plus a stack of sections, and the sections were written to be added rather than bound. That distinction is the whole capability: a section with a preset and a templates scope in its schema can be dropped onto any page from the theme editor, which is what lets a marketer assemble the next launch without a deploy. A section without one is furniture for one template.

Three platform facts shape everything that follows. A page template carries no product object, so anything commerce-shaped resolves a product from a picker or a collection setting rather than from context. Blocks cannot nest, so a three-column detail panel inside a card becomes nine flat settings. And section settings are scoped to the template, so one section on five campaign templates is five independent configurations.

The kit is unremarkable to describe and specific in execution. Value-prop strips compute their sizes string from section.blocks.size — one width at one or two blocks, a narrower one beyond that — because a three-up strip and a two-up strip need different image requests and the person changing the count is not going to open the code. A campaign hero can sell, and that is where the missing product object bites: the hero's CTA takes a product from a section setting and renders a real {% form 'product' %} inside the theme's <product-form>, variant in a hidden field, the button disabled when that variant is unavailable. The add is a plain browser POST, which is what keeps it working on a page assembled section by section where the cart script may never bind. Product rails on page templates keep the theme's <product-recommendations> element and its card, price and grid CSS and swap only the data source for a merchandiser-picked collection. Thin page shells render {{ page.content }} in a branded wrapper and load stylesheets with media="print" and an onload swap, so a mostly-text page carries no blocking CSS.

Lead capture is where the routing gets interesting. One section exposes a mode switch: off, it renders the native {% form 'contact' %}; on, it emits the form-builder app's mount div and skips the native form entirely. Making that a setting rather than two sections means a campaign page moves between them in the theme editor without a template rebuild. And because the same section is mounted by 51 templates, its heading is emitted as an h1 only when request.path is the real contact page and as an h2 everywhere else — one line of Liquid standing between a section kit and fifty pages with two first-level headings.

Reuse is the number that makes the case. That lead-capture section is on 51 templates; a collection-driven rail on eight; the landing-page hero kit on seven. Sections earn their cost through placement count, not cleverness.

The Buy-vs-Build Position

The corpus's own verdict opens: "The single largest lane of authored work: three storefronts run campaign pages from theme sections."

Being even-handed here matters more than on any other hub in this section, because page builders are a mature category and they are good at something real. PageFly, Shogun and Replo give a marketer a canvas, a component palette, page-level drafts, scheduling and version history, and — the part theme sections genuinely cannot match — the ability to invent a layout nobody has built yet, at eleven at night, without a developer. That is the product, not a gap in it.

Where a builder is the wrong tool is narrower than the usual argument admits. When the page has to sell — live price, live availability, the store's own cart behavior — a builder's blocks sit outside the theme's cart lifecycle, and you maintain a second way of adding to cart. When the layout is the same shape every campaign, a builder is renting flexibility you are not using. When it is a paid-traffic landing page, the builder's runtime is another script in front of the thing you paid to show someone. And when the content needs to be in the first HTML response — for crawlers, and increasingly for answer engines — a block rendered after paint is not there.

The corpus is honest about the end state. One of the three storefronts here runs a page builder and a full kit of its own campaign sections, both live, and that is the normal outcome rather than a compromise. Where the line landed on its own: the recurring, commerce-bearing modules moved into the theme, and the genuinely one-off campaign canvas stayed with the builder. Our fuller reasoning is on the landing page builder decision page.

The Builds

Four of the 26 have published pages. Of the rest — the offers and gifting pages, the community and press modules, the value-prop strips, the page shells and the lead-capture routing — twenty-one are documented and will follow. One won't get a page of its own; it was held at editorial review.

LUS Brands

• Marketing image banner with mobile art, typography controls and highlight headings — the campaign banner that opens most of this storefront's landing pages, forked from Dawn's and given real type control. Medium complexity, landing and collection.

Nudestix

• Homepage hero carousel v2 - video and split-image slides with per-slide typography control — the store's busiest campaign surface, composed entirely from theme-editor blocks. High complexity, home.
• Hero slide content renderer with per-breakpoint typography controls — one snippet renders every campaign slide's copy and CTA, across two sections. Medium complexity, home and landing.

Three Ships

• Landing-page hero sections with a no-JS add-to-cart on page templates — a block-repeating hero whose CTA can carry a merchandiser-picked product without the theme's cart script. Medium complexity, landing and home.

What This Rests On

• Liquid section schema and settings — 25 of the 26 builds. A campaign page is a settings surface with a layout attached.
• Theme blocks — 7 builds; the unit a marketer adds, reorders and removes.
• Theme editor presets — the difference between a section a marketer can add and one a developer has to place.
• JSON templates — what a campaign page actually is once the sections exist.
• Ajax Cart API — 3 builds; how a campaign section reaches the cart without inventing a second one.
• Metafields — the per-product and per-collection switches that turn a campaign behavior on without a deploy.
• Responsive images and deferred CSS — width-guarded srcset ladders and non-blocking stylesheets, on the pages paid traffic lands on.
• Storefront password form — the pre-launch half of the definition, where a launch is gated rather than published.

What Varies by Storefront

The split is the most interesting number on this page: 14 builds on one storefront, 12 on another, one on the third. That is not a judgment about LUS Brands — it is a taxonomy fact. Campaign work there is real; it lives in the hero and editorial section systems rather than a distinct landing-page lane, so it counts against art-directed heroes instead. A storefront whose campaign pages are built from the same sections as its homepage does not need a separate kit.

Nudestix treats campaign pages as merchandising pages — offers, gifting, community programmes, press. There is no content model behind them, so a promotions page is a section carrying dozens of settings rather than a metaobject with a template over it, and each offer's fine print sits with the offer as a disclosure rather than in a footnote. That is a legal-coherence decision as much as a design one: editing one tile does not silently change another's terms.

Three Ships treats campaign pages as the acquisition surface — creator pages, quiz entry points, gift finders, seasonal landings — so its modules are commerce-bearing more often than editorial. It runs Palo Alto 5.8.0 by Presidio Creative, a paid premium theme, so several of these sections sit beside vendor code rather than replacing it, and it is the one storefront here running a page builder alongside its own kit.

Where This Gets Hard

The honest limit is the one a builder's sales page leads with, and it is true. A section kit lets a marketer assemble a page; it does not let them invent one. A layout nobody has built is a developer ticket — "next sprint," not "this afternoon." If your team hits that wall weekly, with genuinely new compositions rather than new content in an existing one, sections are the wrong tool and no amount of settings will fix it.

The publishing model is the second cost, and it is structural. Theme-editor edits to the live theme are live. Instead of a page-level draft with a scheduled publish you get a duplicated theme, which has to be kept in step with whatever else shipped while the campaign was being built. Builders solve that properly; a theme does not, and pretending otherwise is how a half-finished campaign page ends up indexed.

Then there is template scoping. A section's settings belong to the template it is placed on, so the same offer strip on five campaign pages is five configurations and updating the offer is five edits. There is no "change it once, apply everywhere" for section settings, and every workaround trades one problem for another.

Not everything on a campaign page should be theme code, either. Email capture is the clearest case: consent, double opt-in and profile properties belong in the platform running the lifecycle programme, so handing the form to the ESP and keeping only the band around it authorable is the right split.

So there are storefronts we would tell not to build this. If you already run a builder your marketing team is happy with, do not stand a parallel section kit next to it for the same pages — two systems that have to look identical will drift, and the person who notices is a customer. If a page is genuinely single-use, a section built for it is something you own forever for one campaign. And if the real problem is that nobody on your side is comfortable adding a section in the theme editor, the constraint is not the tooling.

Related Capabilities

• Art-directed hero and banner systems — the section at the top of nearly every page counted here.
• Design system and reusable component library — why the fourth campaign section costs less than the first.
• Video and shoppable media modules — the media half of a campaign page.
• Editorial, blog and content hub systems — the same composition problem on content meant to last.
• Guided selling quizzes and finders — where a campaign page hands the shopper off when the offer needs a decision first.

Answers to Help You Make Smart Decisions

Can you build Shopify landing pages without a page builder? Yes, and three storefronts here do it as their default. A campaign page becomes a JSON template plus a stack of sections carrying presets, so marketing composes it in the theme editor. The trade is real: assembling from existing sections is fast, and inventing a layout nobody has built becomes a developer ticket rather than an afternoon.

When is a page builder the right choice? When your team invents new page compositions often, when page-level drafts and scheduled publishing matter, or when nobody on your side will maintain theme code. Those are things a builder does well and a section kit does not. The corpus reflects it: one of these storefronts runs a builder alongside its own sections, and both are live.

Do page-builder pages hurt SEO? Not by definition. What matters is whether the content is in the first HTML response and whether the page carries a second runtime. A block rendering after paint is not in the document a crawler or an answer engine reads first, and a builder's script is one more dependency in front of a page you are paying to send traffic to.

How do you put a working add-to-cart on a landing page? By having the section resolve a real product at render time rather than hard-coding an offer into campaign copy. A page template carries no product, so a merchandiser picks one in a section setting and the hero renders the platform's own buy control — a Liquid product form with the variant in a hidden field, and a disabled button when it is sold out. The add posts like any form, whether or not the theme's cart script has bound on that page.

Ready to Find Out Whether You Actually Need a Page Builder?

The answer is genuinely "sometimes," and it turns on how often your team needs a layout that doesn't exist yet. Contact us today and we'll look at your last six campaigns before anyone recommends anything.