Your AI Landing Page Was One HTML File. Here's How to Develop It Into a Real Multi-Page Site Without Starting Over

(No screenshots of some perfect project in this one — this is the path I'd actually take with a live one-pager that's already earning its keep, written for the moment you realize "site" and "landing page" stopped being the same word.)

---

Every post on this blog starts from the same place: Claude or ChatGPT wrote you a landing page, you shipped it, it works. And for a while, one page is a site. Then someone asks where your pricing page is. Then you want a contact page that isn't a form bolted to the bottom of the fold. Then, inevitably, the word "blog" comes up.

The moment a one-pager outgrows itself is where most AI-built sites die — not because the tech can't handle it, but because the instinct at that moment is wrong in one of two directions. Either you open a fresh chat, describe the site from memory, and ask for "a full website with five pages" — which hands you a handsome stranger that looks nothing like the page that's already live. Or you keep cramming everything into the one HTML file until it's 3,000 lines long and every edit is surgery.

There's a third path: develop the file you have into a real multi-page site, in stages, without ever regenerating the thing that works.

Step zero: get the live file as your source of truth

Before any prompting happens, you need the actual HTML that's deployed right now — not the version from three edits ago in some chat scrollback.

If you've been following Your AI Site Isn't Done, It's on Version One: The Safe Edit Loop for Sites Claude and ChatGPT Built, you already have this in git and you can skip ahead. If you don't, this is the day to start: download the live file from your host, name it index.html, and commit it to a repo with a message like "last known good — single page." That commit is your rollback point and your seed. Everything that follows grows out of it.

Design the file structure before you prompt

This is the step everyone skips, and it's the reason AI-refactored sites end up with folders like new-site-final-v2. Claude will structure your site however you ask — including badly. So decide the shape first:

index.html
about.html
pricing.html
contact.html
blog/
  index.html
css/
  styles.css
js/
  main.js
images/

A few principles baked into that tree:

• Keep it shallow. Pages at the root, one folder for the blog if you need one. Deep nesting buys you nothing on a small site and makes every relative path a chance to break.
• Use relative paths everywhere (./css/styles.css, ./about.html). This matters more than it looks: relative paths mean the site works identically on your host, on a local preview, and if you ever move hosts — which is exactly the portability this whole blog is about.
• Name pages to match navigation. pricing.html for the Pricing link, not page3-final.html.

Paste that tree into your prompt as part of the instruction. You're not asking Claude to design a site; you're telling it where things live.

The prompt: refactor in stages, not in one shot

The single biggest mistake is asking for the whole transformation at once: "convert this into a five-page website." That's one prompt producing five interdependent files, and if any of them is subtly wrong, you won't know which. Instead, break the refactor into passes, and commit between each one.

Pass one: extract, don't expand. Get the CSS out of the <style> block and the JavaScript out of the <script> tag, into linked files:

Take the CSS in the <style> block of index.html and move it to css/styles.css,
linked with a relative path. Take the JavaScript and move it to js/main.js.
Change NOTHING else — same classes, same structure, same copy. The rendered
page must be pixel-identical.

Then verify index.html renders exactly as before before touching anything else. This is the least glamorous step and the most important: every later page inherits from these shared files, so they need to be proven correct in isolation.

Pass two: clone pages, swap content. Once the shell is shared, new pages become cheap:

Create about.html and pricing.html using the exact structure of index.html —
same css/styles.css link, same js/main.js link, same header and footer markup.
Only the <title>, meta description, and main content area change. Do not
"improve" the header, do not regenerate styles, do not add new fonts or
libraries.

That last sentence is doing real work. Left unsupervised, an LLM asked for a "new page" will happily hand you a redesigned one — a slightly different header, a font it likes better, a CSS variable renamed. On a one-page site that's annoying. On a multi-page site, an inconsistent header on the About page reads as broken to every visitor who clicks between them.

Shared headers and footers: the honest tradeoff

Here's the part the tutorials gloss over: plain HTML has no built-in way to share a header across pages. You have three real options, and the right one depends on how many pages you'll actually have.

Option one: duplication. Every page carries the full header and footer markup. It works everywhere, it costs zero runtime performance, it's perfectly indexable, and — critically — you have an LLM sitting next to you. "Update the nav in all five pages" is exactly the kind of tedious, mechanical, multi-file edit Claude does without getting bored or sloppy. For sites under roughly ten pages, this is my default, and I'd push back on anyone who calls it a hack. It's just how the web worked for decades.

Option two: a JavaScript include. One header.html fragment, injected at load:

fetch('./includes/header.html')
  .then(res => res.text())
  .then(html => {
    document.getElementById('site-header').innerHTML = html;
  });

One place to edit — genuinely nicer for a growing site. But know the tradeoffs: the header renders a beat after the page, it needs JavaScript enabled, and search engines may index pages before the nav exists. Fine for a footer or a secondary element; I'd think twice about a nav that only exists via script.

Option three: a build step. A tiny static site generator (Eleventy, Astro and friends all do "partials" natively) gives you real templating: one header file, compiled into every page at build time. This is the correct destination — eventually. If your site's next phase is actual blogging with RSS and recurring posts, that's the point where this becomes the right answer, and Create a Blog With AI, Then Own It: Publishing, RSS, and Updates Without a Site Builder covers that handoff in detail. Don't jump there on day one; most small business sites live happily at five to eight static pages for years.

Per-page SEO: don't clone the meta

Your one-pager had one <title>, one meta description, one set of Open Graph tags — tuned, if you followed The Brief Is the Build: What to Tell Claude or ChatGPT So Your AI Landing Page Actually Converts Paid Traffic, for exactly one job. Five pages sharing that same set means five pages competing with each other in search results.

Every new page needs its own:

<title>Pricing — Acme Studio</title>
<meta name="description" content="What Acme Studio costs and what's included.">
<link rel="canonical" href="https://acme.example/pricing.html">
<meta property="og:title" content="Pricing — Acme Studio">

Fold this into your page-creation prompt explicitly, or it won't happen — and if you cloned the shell via copy-paste of index.html, check that the old title didn't ride along. Ask Claude to list the title and description for every page at the end of a pass so you can eyeball them all in one place.

Diff before deploy, one page at a time

The deploy discipline is the same one the safe-edit post teaches, applied to a bigger surface. New pages go live before you ever touch index.html — they can't break traffic that's already converting, so they're the cheap place to discover your nav has a broken link or the stylesheet path is wrong. And if you're about to send paid traffic at any of these pages, run them through Before You Send Paid Traffic: The 12-Point QA Checklist for Any Site Claude or ChatGPT Built first — a new page inherits none of the QA your original page earned the hard way.

And treat index.html with respect: after the initial extract-CSS pass, it should change rarely. If a refactor prompt produces a diff on index.html you didn't ask for, that diff is the whole review. Read it line by line before it deploys. The tracking, the form wiring, the copy you tuned — all of that lives in that one file, and a fresh generation would reset all of it. That's the entire reason you're developing instead of regenerating.

When this stops being the right shape

You'll know it's time to graduate — to a generator, a templating setup, maybe a real publishing stack — when content changes stop being occasional and start being weekly, or when people who aren't you need to edit pages. Until then, a shared stylesheet, a consistent header duplicated across a handful of files, and a diff-everything habit is a real, grown-up website. Not a landing page with ambitions. A site.

The chat that built your first page ended months ago. That was never the product — the file was. Keep developing the file.