A Landing Page Factory on Claude Design + Claude Code: design, static HTML, SEO, A/B, and auto-deploy out of the box

A complete guide for webmasters: how to build a system that takes a landing page from brief to a deployed, indexable, measurable page — reproducibly, without "luck of the prompt," and without the manual grind of meta tags.

Why this matters to a webmaster

If you make money from websites — media buying, lead gen, affiliate, selling services, content projects — you rebuild landing pages constantly. New hypothesis, new landing. New campaign, another one. Plus a blog, plus pages targeting specific keywords. And every time the same routine repeats:

• don't forget <title>, meta description, and Open Graph;
• wire up analytics and don't break it on the next edit;
• don't wreck indexing with duplicates and wrong canonicals;
• ship it, check the social preview, check the speed.

Any AI assistant speeds this up noticeably. But if you just "prompt from scratch" every time, quality bounces around: today the model carefully added a canonical and JSON-LD, tomorrow it forgot. The result depends on how well you happened to phrase the request this time. Across dozens of landings, that turns into a lottery — and mistakes in the SEO scaffolding cost money and traffic.

The fix is to stop reinventing the process and lock it down as a system. In this guide we'll build that system on two Anthropic tools that complement each other well:

• Claude Design — the visual phase: explore the look, assemble the layout and variants on a canvas through conversation;
• Claude Code (via the skills mechanism) — the production phase: turn the design into self-contained static HTML against a strict contract, run it through a validator, version it, test it, and deploy it.

By the end of the article you'll understand how to assemble a template repository, a set of skills, a contract with an automated check, CI with branch-routed auto-deploy, A/B without cloaking, and a change journal. Value first, theory along the way.

The idea: a two-tool pipeline

The core insight: design and production are two different jobs, and solving them with one tool is awkward. So the system is a pipeline.

1. Brief. A single input format: what the product is, who it's for, the offer, the hero screen, the target action, the tone.
2. Visual phase (Claude Design). From the brief, explore the direction: hero composition, typography, color, block structure. This is where it's cheap to try several looks.
3. Handoff to Claude Code. The design moves into code. This is where the main safeguard kicks in — the static landing contract.
4. Production phase (Claude Code skills). The skills fill a neutral skeleton with content against the contract, run the validator, and record changes in the journal.
5. Deploy. CI ships the page by branch: production is indexed, staging and previews are not.
6. Measurement. Analytics and A/B on a single URL: see what actually converts.

The key intuition to hold onto: Claude Design owns how the landing looks; Claude Code owns what actually ships to production. Appearance is exploration; the production artifact is an engineering task with invariants, checks, and a pipeline. Split them and you get both the beauty and the predictability.

What Claude Code skills are

A skill is a folder with a SKILL.md file (instructions plus a "when to use" description) and, optionally, supporting files: references, templates, scripts. When you invoke a skill by name, the assistant picks up those instructions and performs the task strictly by them.

It's a way to turn a one-off lucky prompt into a reproducible process. Not "however it goes today," but by contract, with self-checking. In essence a skill is a frozen standard operating procedure for the assistant: the rules live in files alongside your code and CI, versioned in git.

Our system will have five skills:

Skills are the "rules and checks" — the part that makes the result predictable. Design enters the picture as a separate tool, and that's where Claude Design comes in.

What Claude Design is, and its role here

Claude Design is an Anthropic Labs product, launched in research preview in April 2026 and powered by the Claude Opus 4.7 vision model. It's a workspace with a canvas: chat on the left, canvas on the right. You describe what you need, get a first version, then refine it through chat messages, inline comments, direct edits, and adjustment sliders. It produces visual artifacts — prototypes, landing pages, dashboards, decks, one-pagers.

For a webmaster, three of its properties matter in this system:

First, cheap exploration of variants. Even experienced designers usually ration exploration: there's little time, so they limit themselves to a couple of ideas. Claude Design removes that constraint — you can look at several different hero compositions in one sitting before writing any code. For high-volume hypothesis testing, that's exactly what you want: you pick a direction visually, not blindly in code.

Second, it understands your brand. Claude Design can read a repository to pick up your design system, and on team plans it automatically inherits your organization's styling. At the same time it doesn't edit your codebase and doesn't run commands — it works on the canvas, not in production. That's precisely the division of responsibility we need.

Third — and this is the key to the integration — it has a built-in handoff to Claude Code. When the design is ready, the Export menu packages the design intent into a bundle that Claude Code (a local agent or the web version) picks up with a single instruction. There's also export to Canva, PDF, PPTX, standalone HTML, and link sharing — but for our landing factory, the bridge into Claude Code is the one that matters.

An important caveat about roles. Claude Design can output ready HTML. But for an SEO landing page we don't ship its export as-is. The design from Claude Design is the source of the look and structure; the final production file still passes through the contract and validator on the Claude Code side. That's how we get a beautiful layout without losing indexing, speed, or predictability. Why that matters comes in the next sections.

The foundational decisions the system rests on

This is the load-bearing wall of the whole structure. Four decisions, each removing a specific webmaster pain.

Decision #1: a landing page is static HTML, not a SPA

First and most important. If your landing is built as a SPA (say, React rendered in the browser), it can look great to a human, but search bots and social-preview bots see roughly this:

<div id="root"></div>

An empty container. JavaScript draws the content in after load — and the crawler doesn't wait for it. For a page whose entire purpose is to arrive from search and preview nicely when shared, that's a failure.

So the system locks in a hard invariant: a landing page is a self-contained static HTML file, content lives in the markup, zero JS on the critical path. CSS and minimal vanilla JS are inline. No client-side rendering of content, no external CSS/JS blockers.

What this gives you:

• content is visible without JavaScript → the page is indexed and previews correctly;
• the page loads instantly — no framework on the critical path;
• deployment is trivial: what's in the repo is what's in production, with no build step.

This invariant isn't a preference — it's something no skill is allowed to break. It's recorded in a dedicated architecture decision record (ADR) and checked automatically.

This is exactly where the split with Claude Design pays off. A design tool tends to generate rich interactive markup with external dependencies. That's wonderful for a prototype — and unacceptable for an SEO landing. The contract on the Claude Code side "lands" the design into static HTML.

Decision #2: a contract + validator instead of "luck of the prompt"

The main problem with LLM generation is nondeterminism. Today the model adds a canonical and JSON-LD, tomorrow it forgets. This isn't cured by "a longer prompt" but by a contract and a check.

The new-landing skill has three parts:

1. landing-contract.md — what any landing must contain: <title> and meta description within sane limits, canonical, Open Graph and Twitter Card, JSON-LD, exactly one <h1>, guarded analytics, and no external CSS/JS on the critical path.
2. landing-skeleton.html — a neutral skeleton that already conforms to the contract: system fonts, inline styles, a full SEO block. The model fills it with content instead of inventing the structure from scratch.
3. check_landing.py — the validator. It runs over the finished file and returns a nonzero code if the contract is violated.

The piece that checks the invariant is just a few lines, but it's exactly what catches the trickiest mistake:

# no external CSS/JS on the critical path — otherwise the point of "static" breaks

ext_scripts = re.findall(r'<script\b[^>]*\bsrc=', html, re.I)

ext_css = re.findall(r'<link\b[^>]*rel=["\']stylesheet["\']', html, re.I)

if ext_scripts:

err("external <script src> on the critical path — invariant: JS inline")

if ext_css:

err("external <link rel=stylesheet> — invariant: CSS inline")

A telling moment: run a validator like this over a typical "old" landing page and it'll almost certainly find a violation right away — for example, a render-blocking Google Fonts load via <link>. The tool pays for itself on the very first run, catching what people did by hand for years.

This same validator is the safety net at the seam with Claude Design: whatever the design handoff brings in, the output is either contract-compliant or CI won't let it through.

The generator has a single input — a brief in a unified format. To make it easy to assemble even for a non-developer, keep a prompt-interviewer alongside it: paste it into any AI, it conducts an interview and hands back a finished brief. One format, two inputs: either the skill asks itself, or the brief arrives from outside.

Decision #3: branch = environment, branch = preview

Make deployment branch-routed via GitHub Actions. The logic is as simple as possible:

That is, any branch automatically spins up a preview at its own URL. Handy for showing a client or partner, or trying a hypothesis without touching production. Under the hood: a reverse proxy (e.g., Traefik) in front of nginx containers; the preview folder is cleaned by a separate workflow when the branch is deleted.

Decision #4: only production is indexed

Only production belongs in search. Staging and all previews return X-Robots-Tag: noindex at the web-server level — more reliable than a meta tag, and it covers staging and all previews at once (they're in the same container). Otherwise you create duplicates in the index yourself and cut into your own traffic.

Step by step: building the system yourself

The most practical part. Here's the order of operations that turns those decisions into a working factory.

Step 1. Prerequisites

What you'll need:

• access to Claude Code and to Claude Design (the latter is available on Pro, Max, Team, Enterprise plans; on Enterprise an org admin enables it);
• a GitHub repository;
• a domain and a server (or at least a staging domain) for auto-deploy;
• basic git knowledge.

Set up a folder structure: a directory for skills (each its own folder with a SKILL.md), a templates folder (skeleton, contract, validator), and CI configuration.

Step 2. A unified brief and a prompt-interviewer

Define the brief format: product, audience, offer and USP, hero screen, target action (CTA), required blocks, tone, and brand constraints. Alongside it, keep a prompt-interviewer — text that, pasted into any AI, runs a mini-interview and outputs a brief in the right format. This lets you kick off the process even with a non-technical teammate.

Step 3. The visual phase in Claude Design

Hand the brief to Claude Design and describe the task: a landing for such-and-such offer, this hero screen, this target action. Get a first version on the canvas and refine it through conversation:

• compare 2–3 hero-composition directions;
• tune typography, color, and block density with comments and sliders;
• if you have a brand repository, let Claude Design read it so the styling stays "on brand."

At this step it's important not to drift into production details (meta tags, analytics, indexing) — that's the Claude Code zone. The goal of this phase is to settle the look and structure.

Step 4. Handoff to Claude Code

When the layout works, use the built-in handoff: Claude Design packages the design intent into a bundle, and Claude Code picks it up with a single instruction. From this point the design becomes raw material for the production skill, not the final artifact. From here on, the contract is in charge.

Step 5. The landing contract (landing-contract.md)

Lock down the checklist of must-haves and explain each item in SEO and sharing terms: a correct <title> and meta description within sane limits; a canonical (especially critical when you spin up similar landings for campaigns); Open Graph and Twitter Card (these directly affect CTR on sharing); JSON-LD for the page type; exactly one <h1>; guarded analytics (doesn't load without an ID); and the invariant "zero external CSS/JS on the critical path."

Step 6. The neutral skeleton (landing-skeleton.html)

Build a frame that already conforms to the contract: a full SEO block, system fonts, inline styles, content placeholders ({{TITLE}}, etc.). The skeleton's job is to make the model (and the design arriving from Claude Design) fill a ready, correct structure rather than reassemble the SEO scaffolding from scratch every time.

Step 7. The validator (check_landing.py)

Write a script that checks the finished file against the contract and returns a nonzero code on violation: presence and lengths of title/description, a single <h1>, the presence of canonical/OG/JSON-LD, and the absence of external <script src> and <link rel=stylesheet> on the critical path. Make the validator run a mandatory step — the model doesn't consider the task done until the validator returns zero.

Step 8. The new-landing skill

Tie the contract, skeleton, and validator together in a single SKILL.md. Spell out when the skill applies, and make self-checking the final gate. Now generating a landing is: take the brief → take the design from the handoff → fill the skeleton → run the validator → get a file ready to deploy.

Step 9. The landing-experiment skill — A/B

The logic: variant A (control) lives in the HTML, variant B is applied on top by a lightweight script via a cookie split, and the variant is passed into analytics as a visit parameter. Both variants' content is real and available to the bot.

Claude Design helps here again: the visual variant B is convenient to draw on the canvas (a different hero, a different CTA block), then land it into code via the same handoff and bring it into compliance with the contract. So design variation lives in Claude Design, while the correct split technique and measurement live in the skill.

Step 10. The landing-journal skill — project memory

Build in an audit journal. Every significant action — creating a landing, adding a variant, starting a test, a decision, a rollout — is written append-only to journal.jsonl, with git as the lower layer (the commit hash in each record). History is immutable: made a mistake — add a corrective record, don't rewrite old ones. It's essentially the project's "black box": when you're churning through hypotheses, it's easy to forget what changed when and how it ended.

Step 11. The landing-ads skill — ad materials

The skill generates UTM tags, ad copy, and keywords for search and display campaigns, aligned with the content of the specific landing. This closes the gap between the page and the campaign driving traffic to it.

Step 12. The init-landing-system skill — portability

Since the system is depersonalized, it makes sense to be able to install it anywhere. The skill takes a snapshot of the whole system and deploys it into an existing project, substituting its domains and containers in place of placeholders. Important detail: it substitutes only infrastructure placeholders (domains, container names), and doesn't touch the skeleton's content placeholders ({{TITLE}}, etc.) — those get filled by new-landing at generation time. And it's merge-aware: it doesn't overwrite existing files without an explicit flag.

Infrastructure and deployment

CI on GitHub Actions. The minimal branch-routed deploy logic from Decision #3: main → production, dev → staging, all other branches → a preview at their own URL.

Proxy and containers. A reverse proxy (Traefik) in front of nginx containers. Previews are served from folders like staging-domain/{branch}. A separate workflow deletes the preview folder when a branch is deleted, so junk doesn't pile up.

Indexing at the server level. X-Robots-Tag: noindex for staging and previews is configured in nginx — more reliable than a meta tag, and it covers all previews with one rule.

Secrets and DNS. Honestly: this part is set up by hand — GitHub secrets, DNS records, proxy routes. You can't automate it "from dev-time," so keep a checklist that the init script simply prints on deploy.

SEO depth for people who live on traffic

• Why static wins over heavy site builders and bulky SSGs: full control over the markup and predictable speed with no framework on the critical path.
• Canonicals across many similar landings for campaigns are your main weapon against cannibalization and duplicates. When you spin up pages in batches, this is where traffic most often leaks.
• Open Graph and Twitter Card aren't "for show" — they're a CTR factor on any share: in messengers, social media, partner chats.
• JSON-LD — pick the schema for the page type; for landings that's usually organization/product/service.
• Core Web Vitals out of the box — a direct consequence of the "zero JS on the critical path" invariant. You get good speed metrics from the architecture itself, not from after-the-fact optimization.

And specifically on Claude Design's role in SEO: a design tool thinks about beauty, not the crawler. So everything it hands over must pass through the contract. That's not a limitation but a safeguard: you take the best of the visual exploration and don't pay for it with indexing.

A/B tests without cloaking

A/B tests for landings are often done on different URLs — and that easily turns into cloaking: one content for the bot, another for people. Search engines penalize this. In our system the test runs on a single URL: variant A lives in the HTML, variant B is applied on top by a lightweight script via a cookie split, and the variant is passed into analytics as a visit parameter. The content is real and available to the bot — this is not cloaking.

Two rules to keep tests meaningful:

• One active test at a time — otherwise you can't separate the effects.
• A traffic gate — you can only draw real conclusions with enough traffic; otherwise the test won't reach statistical significance and you'll be making decisions on noise.

Where Claude Design helps and where Claude Code does

To keep the tools straight, hold this division of responsibility in mind:

Claude Design is responsible for:

• exploring the look and quickly running through directions;
• hero composition, typography, color, block structure;
• visual variants for A/B;
• a quick mockup to show a client before any code exists.

Claude Code (skills) is responsible for:

• landing the design into self-contained static HTML;
• enforcing the contract and auto-checking with the validator;
• versioning, the journal, CI, and deployment;
• the A/B split technique and indexing.

The boundary is simple: as long as it's about "how it looks," you're in Claude Design. The moment it's about "what ships to production and how it's measured," you're in Claude Code. The handoff between them is the point where a beautiful prototype becomes a reliable production landing.

Honest about the limits

So this doesn't read like an ad, here are the edges of the system:

• The server side is manual. nginx containers, proxy routes, DNS, and secrets are set up yourself; the script only prints a checklist.
• Analytics is vendor boilerplate. The skeleton holds standard analytics snippets under a guard (they don't load without an ID). That's an integration example, not "system magic."
• It's not a generator engine yet. A new landing is a skeleton plus filling (by design and model), not an assembly from a content model and a block library.
• Claude Design is in research preview. It has its rough edges (for example, quirks with persisting inline comments), and it doesn't replace Figma/Canva — it's a tool for exploration and prototyping, not final production. In our pipeline it deliberately sits before the contract, not instead of it.
• Complex interactive pages are outside the pattern: the system is tuned for fast SEO landings, not web apps.

Where to take it next

• Turn the pattern into a full generator: a content model, a block library, assembling a landing from data rather than just filling a skeleton.
• Connect a CRM and call tracking so the journal stores not just actions but outcomes (leads, sales).
• Multilingual support and automatic generation of the "landing + ad materials" bundle per market.
• Use the brand repository in Claude Design more deeply so every variant comes out on-brand from the start.

Checklists

Landing contract:

• <title> and meta description within sane limits
• canonical points to the canonical URL
• Open Graph and Twitter Card filled in
• JSON-LD for the page type
• exactly one <h1>
• guarded analytics (doesn't load without an ID)
• zero external <script src> and <link rel=stylesheet> on the critical path
• validator returned 0

Before indexing production:

• staging and previews return X-Robots-Tag: noindex
• no duplicates or conflicting canonicals in production
• previews of deleted branches are cleaned up
• analytics verified with a real ID

FAQ

Do I need to know how to code? To build the system — basic understanding of git, CI, and nginx helps. To use a ready one — assembling a brief and going through the visual phase is enough; the contract and checks handle the technical part.

Why two tools — can't it all be one? It can, but worse. A design tool thinks about beauty, not the crawler; the production skills do the opposite. The split gives you both a beautiful result and predictable indexing.

Can I just ship HTML straight from Claude Design? Technically it can output standalone HTML, but for an SEO landing that's risky: you lose the contract's guarantees. The right path is the handoff to Claude Code and a pass through the validator.

Will this work for a multi-page site? The system is tuned for fast landings. Multi-page projects and web apps are a different class of task.

How is this better than site builders? Full control over markup and speed, trivial deployment, versioning and reproducibility, plus A/B without cloaking and a journal of decisions.

How do I measure conversion? Through the guarded analytics in the skeleton and A/B on a single URL with the variant passed into a visit parameter; the traffic gate protects against drawing conclusions from noise.

Can I hand the system to a contractor? Yes. The portability skill deploys the depersonalized system into another project, substituting infrastructure placeholders and leaving content placeholders untouched.

Bottom line

The main takeaway isn't about landings — it's about a way of working. Two tools cover two different jobs: Claude Design crystallizes the visual exploration, and Claude Code skills crystallize the repeatable production process — moving the rules into a contract, adding self-checks, and freeing you from depending on how you happened to phrase the prompt today. The handoff between them is the bridge from a beautiful prototype to a reliable, indexable, measurable page.

Landings are simply the first domain where this pays off especially fast. Start small: assemble a brief, run the visual phase in Claude Design, land the result through new-landing with the contract and validator — and expand the system with more skills as your volume of pages grows.