a Drupal Landing Page With Layout Builder
Landing pages sit at the intersection of marketing intent and editorial control. A campaign manager in Brisbane wants to launch a product page tomorrow; a content editor in Perth needs to swap out hero imagery without bothering a developer; a designer in Melbourne wants the freedom to try new layouts without committing to a full theme rebuild. Drupal's Layout Builder answers these needs by turning page composition into a structured, repeatable activity rather than a code change.
For Australian teams running tight budgets across multiple sites, the value is pragmatic. The tool comes bundled with Drupal core from version 8.5 onward, which means no additional licensing, no per-seat fees, and no third-party vendor lock-in. It also plays well with the existing skills most Drupal shops already have, from site builders comfortable with blocks to front-end developers who prefer working with Twig templates.
The aim of this walkthrough is practical: enable Layout Builder, configure a sensible set of reusable components, and produce a landing page that satisfies both the marketing brief and the regulatory realities of running a website in Australia.
Getting Started With Layout Builder Concepts
Layout Builder treats every page as a vertical stack of sections. Each section is a row containing one or more columns, and within each column sits a block. A block can be anything Drupal already understands: a piece of text, an image, a view, a webform, or a custom block type you have defined yourself. The mental model is closer to a slide deck than to a traditional Drupal region-and-block configuration.
This structure has practical consequences. Because sections are entities in their own right, they can be reordered, duplicated, hidden on certain breakpoints, and exported as configuration. A campaign landing page built for a Sydney-based financial services firm, for example, can be cloned, swapped with new copy, and pushed to staging in a single commit rather than a tangle of ad-hoc blocks scattered across the database.
For site builders coming from page builders in other content management systems, the terminology will feel familiar, but the underlying machinery is different. Layout Builder does not store content as free-form HTML in a database column. Sections, blocks, and their configuration live in fieldable storage on the entity, which means they are revisionable, translatable, and exportable through the standard configuration management workflow that most Australian agencies already rely on.
Enabling Layout Builder on a Content Type
Before any landing page work can happen, the feature needs to be turned on for the content type that will host the page. Navigate to the content type's edit screen, open the Layout options vertical tab, and tick "Use Layout Builder." A second tick, "Allow each content item to have its layout customised," unlocks per-node overrides, which is what most landing page use cases actually require.
For a typical campaign page, the content type itself is often very light. A title field, a body field that can be hidden, and a handful of metadata fields such as publication date and campaign tag will usually be enough. The rich layout belongs in the sections, not in a giant text field. This separation keeps the content model maintainable and lets editors focus on structure rather than wrestling with markup.
It is worth spending time on permissions at this stage. Drupal exposes granular access controls for Layout Builder, including the ability to administer layouts, configure reusable layouts, and edit section overrides. A common pattern in agencies operating between Sydney and Melbourne is to give marketing roles "edit any content" but reserve "configure layouts" for a smaller group of trusted site builders. This keeps the surface area for accidental breakage small while still giving campaign owners enough freedom to act quickly.
Choosing Between Default and Override Layouts
| Aspect | Default Layout | Per-Node Override |
|---|---|---|
| Best suited for | Templates used by many pages | One-off campaign pages |
| Editor workload | Minimal, choose template | Full control over each section |
| Maintenance burden | Centralised, easy to update | Each node carries its own configuration |
| Configuration export | Single config file per template | Inline storage on the entity |
| Typical use case | Article, news, product | Landing page, campaign microsite |
| Risk of drift | Low | Higher without governance |
The choice between default and override layouts is the most consequential decision in any Layout Builder project. A default layout behaves like a page template that every piece of content automatically inherits. Per-node overrides, by contrast, allow the editor to break out of that template and assemble sections freely for a single piece of content.
For a landing page workflow, the realistic pattern is a hybrid. Most pages on the site use default layouts to keep visual consistency and reduce maintenance. Landing pages opt into per-node overrides because, by definition, each campaign is unique. Some Australian Drupal shops formalise this with a dedicated "Campaign page" content type that has overrides enabled from the start, while everyday content types remain template-driven.
If the team uses the configuration management system to deploy changes between local, staging, and production environments, the hybrid pattern needs clear documentation. Default layouts travel through the standard config sync pipeline, but per-node overrides usually live in the database. That is not a problem for a single site, but for multi-site deployments common in universities and government agencies across Australia, it requires an agreed workflow for shipping override changes.
Building the Section Structure for a Campaign Page
With the content type ready, the next step is to design the section library. A pragmatic landing page usually consists of a hero section, a feature row, a social proof block, a body content area, and a call to action. Each of these can be modelled as a section layout within the "Manage layouts" interface.
The hero section is often the most demanding. It typically combines a background image, a headline, supporting copy, and a button linking to a webform. Defining it as a single-column or two-column layout with a width constraint keeps the design tight across viewports. The feature row, by contrast, works well as a three- or four-column grid that collapses gracefully on mobile through Layout Builder's built-in breakpoint handling.
A useful habit is to keep the number of distinct section layouts small. Three or four well-chosen templates will cover the majority of campaign briefs a team will receive in a year. Anything more, and editors start facing decision fatigue. A common complaint from teams operating across multiple time zones in Australia, from Perth to Sydney, is that an overly flexible layout system slows down publishing rather than speeding it up.
Adding Reusable Components and Custom Block Types
Blocks are the unit of reuse inside Layout Builder, and investing in custom block types pays off quickly. A "Card" block type with fields for image, heading, body, and link can be dropped into any section, on any landing page, in any campaign. Once defined, the block instance can be reused across the site without re-entering the same fields.
For Australian projects, this is where the marketing-compliance angle enters the conversation. A "Call to action" block that always includes a checkbox acknowledgement tied to consent under the Spam Act 2003, or a "Lead capture" block that documents lawful collection under the Australian Privacy Principles, can be standardised once and reused everywhere. The block type then becomes a small piece of compliance infrastructure rather than a per-page decision.
Inline editing makes this workflow smoother. Editors can click directly into a block on the layout canvas and modify its fields without leaving the page. Coupled with the live preview that ships with Layout Builder, this reduces the back-and-forth between drafts and the live site and makes it easier for distributed teams in Adelaide, Brisbane, or regional centres to collaborate on a launch.
Accessibility, Performance, and Local Compliance
A landing page is only as good as its ability to be used. Layout Builder produces semantic HTML by default when blocks are configured correctly, but it is still possible to produce inaccessible output through misuse. Headings should follow a logical order, images need alternative text, and interactive blocks such as accordions require proper ARIA attributes. For Australian organisations, accessibility is not optional framing; the Disability Discrimination Act 1992 and the associated standards set clear expectations for digital services.
Performance matters just as much. Each section and block carries its own configuration overhead, and a landing page with twenty sections can become sluggish on slower connections common in regional areas. Caching strategies should be revisited whenever Layout Builder is enabled, because the per-node override model can defeat the default page cache. Page cache, dynamic page cache, and big-pipe together usually provide a workable baseline, but for high-traffic campaigns a CDN in front of the site is well worth the investment.
Privacy considerations deserve explicit attention as well. Any landing page that collects personal information through a webform, whether in Hobart or Darwin, falls under the Privacy Act 1988. The form should disclose what is being collected, why, and how it will be used, with consent captured before submission. Layout Builder makes it easy to add a consent block alongside the form, but the obligation to do so sits with whoever owns the campaign, not with the tool itself.