ExperienceKit: Drupal Canvas and AI Page Generation - What Digital Teams Should Know

This post is part of the ExperienceKit series. New to ExperienceKit? Start with the introduction, which the whole series builds on.

Digital teams keep asking how these relate: whether they compete, whether to wait for one before adopting the other, and what to invest in now so that neither effort is wasted. This article is an honest attempt to answer that, from a team that builds on the same foundation Drupal is building on.

A disclosure up front: we build ExperienceKit, an AI page generation solution for Drupal. We'll explain where it fits at the end. The first two-thirds of this article, though, is about Drupal Canvas and Drupal's component architecture on their own terms, because you can't make a good decision about either without understanding both.

What Drupal Canvas is

Drupal Canvas is Drupal's newest page builder: a visual, browser-based composition experience, the kind of drag-and-drop, see-what-you're-building interface that editors have long asked of Drupal and historically had to assemble from contrib (Layout Builder, Paragraphs, and a stack of supporting modules) or buy from proprietary tools.

It grew out of a major priority for the Drupal project announced in 2024, developed in the open and now released, alongside the Drupal CMS effort to make Drupal dramatically easier to adopt. A note on precision: Drupal Canvas continues to evolve quickly, and specifics (feature scope, what ships when) change from release to release. Check drupal.org for the current state rather than trusting any article's snapshot, including this one. What follows is the stable architectural picture, which has held steady even as details move.

The essential ideas:

• Editors compose pages visually. Instead of configuring layouts through form-heavy admin screens, editors place and arrange components on a live preview of the page. What you manipulate is what visitors get.
• Components are the unit of composition. Pages are built from discrete, reusable components, not freeform markup. The editor's creative space is the component library.
• Single Directory Components (SDC) are a foundational building block. Drupal Canvas is designed to work with SDC, the component format that became a stable part of Drupal core. This is the architectural decision with the longest consequences, so it's worth unpacking.

Why SDC is the part that matters most

Single Directory Components put everything a component needs (its Twig template, styles, JavaScript, and a YAML definition of its props and slots) in one directory, with a machine-readable schema describing what the component is and what inputs it accepts.

That schema is the quiet revolution. Before SDC, a "component" in a Drupal theme was a convention: a Twig partial whose expected variables lived in a developer's head or a README. With SDC, a component is a contract: here is a hero, it takes a title, an image, and an optional call to action; here is what's required, here are the allowed values. Machine-readable contracts change who, and what, can safely build with components:

• Visual builders can render a component palette, validate what editors place, and know which inputs to expose. Drupal Canvas can exist as a general-purpose tool precisely because components describe themselves.
• A governed component library gets an enforcement mechanism. Brand and accessibility stop being a PDF of guidelines and become the actual set of building blocks pages are made from.
• AI can be constrained. This is the connection to the second shift, and we'll come back to it.

If you take one action after reading this article, make it this: move your theme toward SDC. It is the common foundation under everything else discussed here, it's in core today, and it's valuable even if you never adopt a visual builder or an AI tool: you get encapsulated, testable, reusable components either way.

Where AI generation fits: a layer above composition

Drupal Canvas answers the question: how does a person visually assemble a page from components?

AI page generation answers a different question: how does a page get assembled from a description of what it should be?

The two complement each other by nature. A visual builder is an editing surface: a person makes each placement decision, one component at a time. That's exactly right for pages that deserve bespoke attention. But for a large class of pages (campaign landing pages, event pages, program pages, the pages organizations produce dozens or hundreds of times in structurally similar ways) the editor isn't making novel design decisions. They're translating a brief into an arrangement of familiar components. That translation step is what AI is good at.

The workflow that emerges: describe the page in natural language ("a landing page for the open day: hero with registration CTA, three program highlights, student testimonial, campus map, FAQ") and AI generates the composition: which components, in what order, with what content in which slots. A person reviews and refines, and a visual editing surface is the natural place to do that refinement.

Notice what makes this safe rather than reckless: AI selects and configures components from a defined library, against their schemas. The same property that lets Drupal Canvas validate what an editor places lets an AI generation layer keep what it produces made only of approved components with valid inputs, so pages come out on brand and accessible. General-purpose AI tools that make up each page from scratch can't offer that, which is why their output tends to stall in brand and accessibility review. Component-constrained generation is the version of AI page building that survives contact with an enterprise governance process.

So the honest architectural picture is a stack:

1. SDC: the component contract layer (in core today)
2. Visual composition: humans arranging components (Drupal Canvas's territory)
3. AI generation: descriptions becoming component compositions (the layer above)

Drupal provides layers one and two. The third layer is where we work.

Where ExperienceKit sits: same foundation, different layer

ExperienceKit uses AI to generate production-ready Drupal landing pages from a prompt, built entirely from a governed component library we build for your brand. It has two inseparable parts:

• BrandKit is a governed component library built from SDC, delivered on your brand. Standard Drupal SDC with schemas, accessibility handled at the component level, and governance rules about how components may be used, all living in your own codebase. Because it's plain SDC, it is exactly the kind of component library the Drupal ecosystem (Drupal Canvas included) is designed to work with. There is no proprietary component format and no fork of Drupal's direction. We keep the components updated as support, without lock-in: if ExperienceKit disappeared tomorrow, you'd still own a standard SDC component library.
• CampaignKit is the generation engine: natural-language prompts become production-ready pages, assembled exclusively from BrandKit components. Generated from your approved components, so pages come out on brand and accessible.

The relationship to Drupal Canvas, stated plainly: we ride the Drupal wave, we don't fight it. Drupal Canvas gives editors a canvas; ExperienceKit gives organizations AI generation plus governed component library on the same SDC foundation. An organization can adopt both without conflict, because both consume the same component library. As Drupal Canvas matures, an SDC-based component library becomes more valuable, not less. Generated pages land in an ecosystem with ever-better tools for humans to refine them. Betting on Drupal's architecture is the whole point.

What ExperienceKit adds that Drupal, quite reasonably, doesn't aim to provide: the generation layer, and the opinionated governance around it. Drupal's job is to make component-based page building possible for everyone. Turning "brief" into "reviewed, on-brand, publishable page in minutes" for a specific organization's component library is where our solution lives.

What digital teams should do now

Practical guidance, in order of confidence:

1. Adopt SDC: no hedging on this one. It's stable core API, and it's the foundation for every future discussed here. If your theme is a monolith of templates, start extracting your most-reused patterns (hero, card, CTA, media-and-text) into SDC with well-defined schemas.

2. Treat your component library as governed infrastructure, not a parts bin. The difference is governance: documented usage, accessibility built and verified per component, and a deliberate answer to "who approves a new component?" Whether a human editor in Drupal Canvas or an AI is doing the assembling, output quality is bounded by library quality. Garbage components mean garbage pages, at any speed.

3. Adopt Drupal Canvas and plan around it. It is the newest visual page builder in Drupal; test it against your components. Note the dependency direction: Drupal Canvas needs a good SDC component library to be useful on your site. Nothing about building that library is wasted; the work is the same work either way.

4. Evaluate AI generation on one question first: what can it produce? If a tool makes up each page from scratch, everything downstream (brand review, accessibility, maintenance) inherits that risk. If it only composes your approved components, governance is structural rather than aspirational. Everything else about an AI page tool is secondary to this distinction.

5. Pick the right pages for AI. Prompt-to-page shines where volume is high and structure is familiar: campaign landing pages, events, program and department pages. Your homepage redesign still deserves human craft. With a component library in place, that craft gets faster too.

Questions we hear from Drupal teams

"Should we wait before deciding anything?" No, because the decision that matters most doesn't depend on it. Whether you end up using Drupal Canvas, an AI generation layer, both, or neither, the prerequisite is the same SDC component library. Build that now and you've made no bet you can lose. Deferring the component work just means starting later on the part that takes the longest.

"Does AI page generation require Drupal Canvas?" No. Generation targets the component layer, not the editing surface. CampaignKit generates pages from SDC components on Drupal sites today, independent of which visual editing tools are installed. What Drupal Canvas adds is a better surface for humans to refine what was generated. The two meet at the component library, not at each other's interfaces.

"We're on Layout Builder and Paragraphs. Is that all wasted?" The content and the patterns aren't wasted; the packaging changes. Most teams find their Paragraphs types map fairly directly onto SDC components, so the modeling work you did identifying your organization's building blocks carries over. Plan a progressive migration of your most-reused patterns rather than a rewrite, and let legacy structures coexist while you transition. (Migration paths from existing site-building approaches are also an active topic in Drupal itself, another reason the SDC investment aligns you with where Drupal is going.)

"Is AI-generated code going to pollute our codebase?" With component-constrained generation, AI produces a composition (which components, in what order, with what prop and slot values), and the page renders from your SDC templates, same as if an editor had assembled it by hand. Review the component templates once; every generated page renders through them.

The convergence, in one paragraph

Drupal's architecture is converging on a clear idea: pages are compositions of well-defined components. SDC made components contractual; Drupal Canvas made composition visual; AI generation makes composition promptable. Teams that invest in the shared foundation (a governed SDC component library) get to benefit from all three, whichever order they arrive in.

Next step

We wrote a technical whitepaper on governed AI page generation for Drupal: the architecture, how generation is constrained to SDC components, and what a BrandKit component library involves. Ask for it and we'll send you a copy, or book a technical demo and bring your hardest architecture questions.