From Claude Artifact to Production: Shipping an AI-Designed Landing Page

There is a graveyard of Claude Artifacts that will never become websites.
I have seen it. I have contributed to it. You probably have too.

You describe a landing page to Claude. Claude designs something genuinely nice. You screenshot it, you get excited, you hit the export button, and then you discover that the beautiful artifact on the left-hand side is not, in any meaningful sense, a shippable website.

This is the most common dead-end in AI-assisted design right now: the prompt-to-artifact loop works, the artifact-to-production leap doesn't. And it's not Claude's fault. Artifacts were designed as conversational design previews, not deploy-ready projects.

This guide walks through exactly what it takes to turn a Claude Design artifact into a real, deployed landing page. The honest version. No hand-waving. I'll show the manual path step by step so you can see the shape of the pain, and then the shortcut I actually use in practice.

What You'll Learn

1. Why a Claude Artifact isn't a production site, technically
2. The six steps of the manual "artifact to production" path, and what breaks at each one
3. A saner shortcut that skips the porting work
4. When each approach makes sense

Let's dive in. 🏊‍♂️

The Claude Artifact Graveyard

Before we get into the how, a quick reality check.

Claude Design (part of Anthropic Labs) is a genuinely useful tool. The conversational design loop is fun. The iteration is fast. If all you need is a visual direction to screenshot and show to a co-founder, it's excellent.

But most people using it for landing pages are not stopping at the screenshot. They want the artifact to become a real website. And that's where the graveyard starts.

Here's what actually happens:

• You copy the artifact code. It's a single React component with inline styles.
• The styles break at anything beyond the md: breakpoint.
• There's no routing. No app/layout.tsx. No metadata export.
• No meta tags, no canonical, no sitemap, no OG images.
• No blog. No MDX. No RSS. No search.
• No theme system. Your colors are hex values hard-coded into the JSX.
• No deploy config. vercel deploy on this thing would ship a single page and call it a day.

You end up with one of three outcomes:

1. You copy the artifact into a fresh create-next-app, spend an afternoon rewiring the styles, and eventually ship something that's 70% the original idea.
2. You get bogged down three steps in, get distracted, and forget the idea ever existed.
3. You keep the artifact tab open for weeks as a reminder that you meant to ship a landing page. One day you close the tab.

💁‍♂️ Option 2 is the majority case. Sorry.

The problem isn't that Claude produces bad output. It's that a landing page is not one file, and the artifact format can only ever return one file.

Why Artifacts Aren't Production Sites

It's worth spending a minute on why. If you understand the shape of the gap, the rest of this guide lands harder.

A production marketing site is a dozen-plus concerns glued together:

• Routing: the app/ directory, layouts, loading states, not-found.tsx.
• Metadata: export const metadata = { ... } on every page, plus OpenGraph images and Twitter cards.
• SEO primitives: sitemap.ts, robots.ts, JSON-LD structured data.
• A blog system: MDX parsing, Contentlayer or a similar pipeline, tag pages, RSS, search.
• A theme: color tokens, typography scale, dark mode, a consistent spacing system.
• Deploy config: vercel.json or equivalent, image optimization, edge caching.
• Legal pages: Terms, Privacy. Starters at minimum.
• A build that passes: TypeScript strict mode, ESLint clean, no unused imports, no missing dependencies.

Claude Design produces ~5% of that list. It produces the hero and maybe two feature sections, inside a single React component, with inline styles, inside a sandbox that doesn't even know what next/link is.

That's fine! That's what artifacts are for. The mistake is expecting the other 95% to somehow write itself. It doesn't.

The Manual Path (What It Actually Takes)

OK, let's say you still want to take the manual route. You like to suffer. You have a weekend and no other obligations. Here's the real sequence.

Step 1: Copy the Code and Realize It's One File

The artifact dumps something like:

export default function LandingPage() {
  return (
    <div style={{
      fontFamily: 'system-ui, sans-serif',
      background: 'linear-gradient(180deg, #0a0a0a 0%, #1a1a1a 100%)',
      color: '#fafafa',
      minHeight: '100vh',
    }}>
      <section style={{ padding: '80px 24px', maxWidth: 1200, margin: '0 auto' }}>
        <h1 style={{ fontSize: 64, fontWeight: 700, lineHeight: 1.1 }}>
          Your product headline
        </h1>
        {/* ...500 more lines of inline styles */}
      </section>
    </div>
  );
}

Real artifact code. One file. Inline styles. No breakpoints. No design tokens.

Your first job is to un-inline every style into something Tailwind-shaped (or CSS modules, or whatever your existing project uses). Plan on an hour, minimum, for a single landing page. More if the artifact had any real visual complexity.

Step 2: The Responsive Breakpoints

Here's the one that catches everyone.

Claude Artifacts render in a Claude-sized sandbox frame. They look fine in that frame. The moment you render them in a real viewport, the first thing you notice is that responsive behavior is cosmetic, not structural.

Inline widths like style={{ maxWidth: 1200 }} become gross on mobile. Grids that look nice at ~800px collapse awkwardly at 375px. Font sizes that fit the sandbox frame overflow real screens.

The fix is to rewrite every layout primitive to use Tailwind breakpoints (sm:, md:, lg:, xl:) with actual design-system logic behind them. That's not a port. That's a rebuild.

Step 3: Wrap It in a Real Next.js App

Now you have a single component. You need a project.

npx create-next-app@latest my-landing \
  --typescript --tailwind --app --src-dir=false --eslint --turbopack
cd my-landing

Paste the de-inlined component into app/page.tsx. Run next dev. Notice that none of the images load because the artifact referenced data: URLs or public Unsplash links that hit rate limits after 20 reloads. Fix that too.

Step 4: Add the Metadata

Your site has no SEO. Real landing pages need, at minimum:

export const metadata: Metadata = {
  title: 'Your Product: One-Line Pitch',
  description: 'A 150-160 character description with primary keywords.',
  metadataBase: new URL('https://yourdomain.com'),
  alternates: { canonical: '/' },
  openGraph: {
    title: 'Your Product: One-Line Pitch',
    description: '...',
    url: '/',
    siteName: 'Your Product',
    images: ['/og.png'],
    type: 'website',
  },
  twitter: {
    card: 'summary_large_image',
    title: '...',
    description: '...',
    images: ['/og.png'],
  },
};

Plus a sitemap.ts:

import { MetadataRoute } from 'next';

export default function sitemap(): MetadataRoute.Sitemap {
  return [
    { url: 'https://yourdomain.com', lastModified: new Date() },
    // ...once you have more pages, add them here
  ];
}

Plus a robots.ts:

import { MetadataRoute } from 'next';

export default function robots(): MetadataRoute.Robots {
  return {
    rules: [{ userAgent: '*', allow: '/' }],
    sitemap: 'https://yourdomain.com/sitemap.xml',
  };
}

Plus an OG image (either a static PNG or, better, a dynamic route using @vercel/og). Plus favicons in at least four sizes. Plus a manifest.json.

None of this is hard. But each of them is an hour of Stack Overflow and Google if you've never done it before, and the Claude Artifact helped with exactly zero of it.

Step 5: The Blog

You probably want a changelog or a blog. Every SaaS has one. Even early-stage products benefit from one for SEO.

pnpm add contentlayer2 next-contentlayer2

Configure Contentlayer:

// contentlayer.config.ts
import { defineDocumentType, makeSource } from 'contentlayer2/source-files';

const Post = defineDocumentType(() => ({
  name: 'Post',
  filePathPattern: 'blog/**/*.mdx',
  contentType: 'mdx',
  fields: {
    title: { type: 'string', required: true },
    date: { type: 'date', required: true },
    summary: { type: 'string', required: true },
    tags: { type: 'list', of: { type: 'string' } },
  },
  computedFields: {
    slug: {
      type: 'string',
      resolve: (doc) => doc._raw.flattenedPath.replace('blog/', ''),
    },
  },
}));

export default makeSource({
  contentDirPath: 'data',
  documentTypes: [Post],
});

Then build the listing page, the single-post page, the tag pages, RSS, search. Plan on two to four hours if you've never wired Contentlayer before.

And that's just the blog. Want a tag cloud? Another hour. Want OG images per post? Another hour.

Step 6: Deploy

Set up a Vercel account. Connect the repo. Pick the right region. Configure environment variables. Point a domain. Confirm the canonical URL matches what your metadata is claiming. Re-check your OG image actually renders on Twitter (half the time it doesn't until you add the right metadataBase).

At this point you have a landing page live. It only took somewhere between four hours and an entire weekend, depending on your Next.js experience.

And the reason this stings is that the idea of the landing page, the thing Claude actually designed, took forty minutes of back-and-forth. The remaining 90% of the work was structural scaffolding that Claude Design can't produce by its nature.

There Has to Be a Better Way

Reading back over that, a reasonable reaction is: "wait, most of those steps are copy-paste patterns any landing-page starter kit already has."

Correct. That's the whole point.

The reason the manual path is painful is that Claude Design only owns the first 5% of the pipeline, and you own the other 95% yourself. If something else owned all 95% of the scaffolding and you kept the 5% of creative direction, you'd be fine.

That's the model I actually use with PageAI. Same prompt-based generation loop. Same "describe what you want, see it take shape." Totally different output: not a sandboxed artifact, but a real Next.js + TypeScript + Tailwind + Shadcn UI codebase with all the scaffolding above already wired up.

Instead of:

1. Artifact → copy code → fix styles → new Next.js project → add metadata → add sitemap → add blog → deploy

You get:

1. Prompt → full codebase with all of the above → 1-click Vercel deploy

The creative direction is still yours. The "I want a SaaS landing page for an indie observability tool, confident dev-native tone, dark theme, with hero, pricing, FAQ" decision is still yours. The scaffolding (the other 95%) is already there.

The PageAI Path (Briefly)

This isn't a pitch section. If you've followed along, you see the shape. Briefly, here's how the same "ship a landing page" task plays out with PageAI:

1. Describe the Site

Same prompt you'd give Claude Design. What does the product do, who is it for, what tone, what must-have sections. PageAI also asks clarifying questions if the brief is thin.

2. Get a Live Preview

Full Next.js codebase rendered in a live preview. Not a sandboxed frame. Hero, pricing tiers, FAQ, testimonials, blog index, SEO meta, OG images, Terms and Privacy starters. All present from the first generation.

3. Tweak via Drag-and-Drop

Change copy, re-order sections, swap theme site-wide (1000+ theme/font combinations), update icons. The drag-and-drop editor handles the "move this section up, change that accent color, rewrite this line" cases without re-prompting.

4. Download or Deploy

Download the repo, push to your own GitHub, or do a 1-click deploy to Vercel. The exported project is standard Next.js. No PageAI runtime. No lock-in. Once you have the code, it's yours.

The whole loop is what the Claude Artifact loop wanted to be, with the crucial difference that what you get out the other end is an actual deployable website.

When to Use Each

Honest version, because the Claude-versus-PageAI framing is too reductive:

Use Claude Design when:

• You want to explore a visual direction conversationally and all you need is a screenshot or a shareable preview URL.
• You're iterating with a co-founder or designer on the look-and-feel, not building a live site yet.
• You have a Claude subscription and no immediate shipping deadline.

Use PageAI when:

• The end goal is a deployed landing page, not a preview.
• You want SEO, blog, theme, legal pages, and deploy config wired up on the first generation.
• You value owning the exported code (and aren't interested in a permanent runtime dependency on any tool).
• You'd rather pay once and ship, instead of paying monthly and still writing scaffolding.

The two aren't mutually exclusive. A sane workflow is to explore the look in Claude Design, then use PageAI to build the production site once the direction is locked. Claude for design; PageAI for shipping.

The Shipping Layer

The mental model I want to leave you with is this:

Every AI design tool produces a surface. A good landing page is a system. The gap between them is the shipping layer: the scaffolding that turns "a nice-looking thing" into "a real, deployable, SEO-ready website you own and can extend."

The Claude Artifact graveyard exists because nothing in that loop owns the shipping layer. Artifacts produce the surface; you're expected to produce the system. Most people don't, and the artifact dies.

The question worth asking on your next landing-page project is not "should I use Claude or PageAI?" It's "who owns the shipping layer?" If it's you, and you have the afternoon, the manual path works. If you'd rather skip that part and spend your time on the product, this is what PageAI exists for.

Next Steps

• Comparing tools? Claude Design vs Lovable vs PageAI is an honest category-positioning essay about which tool is built for which job.
• Want the full agentic shipping workflow? The Agentic Workflow for Landing Pages has the prompt-to-design-to-code-to-deploy loop with full prompts.
• Just want to ship? Start a PageAI project and move the idea out of the Claude tab and into your domain.