How I rebuild a whole website with AI agents, step by step

Most consultants guard their process like it is the recipe for Coke. Here is mine, in full. This is the exact playbook I use to rebuild whole websites with AI agents: extraction, a single brand file, parallel agents that each own their files, SEO and AI wiring from day one, a content engine switched on at launch, and verification in a real browser before anything gets called done. Every step, every gotcha we hit, nothing held back.

Before the method, the why. A rebuild is not about the technology, and it is mostly not about the design. It is about traffic: the commercial point of moving to a site where content is data is that it can grow, publish every day and keep getting found. Every step below, the database, the SEO wiring, the content engine, serves that one outcome.

My position on giving this away is simple: hand over the keys, because people won't do it. The method is not the moat. The work is. Most people who read this will nod along, bookmark it and never run a migration. A few will start, hit their first mystery 404 at two in the morning, and quietly go back to the old site. The handful who push through every step have earned it, and they were never going to hire me anyway.

For context: this is the playbook behind the site you are reading now. The Operosus rebuild went from nothing to a live staging site in a day, then got upgraded the same day by 7 review agents and 7 research agents feeding one improvement plan, implemented by 13 agents working in parallel. The sitemap has 114 URLs and every one returned a 200 in production before launch. The playbook itself is a folder of markdown files I point agents at. You can write your own by the end of this page.

Step 1: extract everything from the old site before you build anything

Do not start with a blank Next.js project and a vision. Start with a complete copy of what exists. Pull every page, blog post, image, meta title and URL out of the old platform, whether that is Webflow's API, Duda's API or a straight scrape of the live site. Land all of it in a database, not in a folder of files. I use Supabase.

This matters for two reasons. First, the old site is your redirect map. Every URL that ever earned a link or a ranking needs to point somewhere on the new site, and you cannot map what you have not catalogued. Second, content in a database means the new site reads from data instead of having copy hardcoded into components, which is what makes everything after this step possible.

Step 2: one file owns the brand

Before any page gets built, create a single source of truth for everything brand-specific. One file holds the company name, address, contact email, every CTA link, every social URL, every pricing tier. Nothing else in the codebase is allowed to hardcode any of it.

This sounds like tidiness. It is actually what makes parallel agents safe. When 13 agents are building pages at the same time, they all import the same brand file, so no agent invents its own phone number or links the wrong booking page. When the address changes, it changes in one place. Skip this and you will find three different contact emails on the site a month after launch.

Step 3: stand up the skeleton

Next.js, content fetched from Supabase, deployed on Cloudflare Workers via OpenNext. I default to Cloudflare because on one migration we lost around six hours to opaque "team configuration" deploy errors on Vercel that never resolved cleanly. Cloudflare worked first time once the gotchas were known, and the gotchas are further down this page.

The skeleton includes the boring pages people forget: privacy policy, terms, a contact form that writes to the database with a honeypot field so bots fill in the trap instead of your inbox. Get the dull stuff standing before the interesting stuff starts.

Step 4: split the build across parallel agents, each owning its files

This is the step people assume is magic. It is mostly admin. Write one design brief that covers voice, colours, typography and animation rules. Then split the site into workstreams: one agent on the homepage, one on services, one on case studies, one on the guide templates, and so on. Every agent reads the same brief. The one hard rule: no two agents touch the same file. File ownership is what lets them run simultaneously without trampling each other's work.

On the Operosus rebuild, the upgrade round ran as 7 reviewers critiquing the first version, 7 researchers studying the best sites in the category, one plan merging all of it, then 13 implementation agents in parallel. One of the reviews found the word "ship" 36 times across the site. The agents are good at building things and equally good at overdoing a word they like, which is why the review pass exists.

One more rule from a scar: do not trust an agent's claim that work is done. On a previous migration an agent reported it had committed files that were never staged. Check the git log yourself, every time.

Step 5: wire SEO and AI plumbing from day one

This is not a post-launch task. Build it into the skeleton: sitemap generated from the database, robots file, llms.txt so AI assistants can read a clean map of the site, structured data for the organisation, the founder and every article, breadcrumbs, proper Open Graph tags.

Two details most rebuilds miss. Numbers must render on the server: if your stats animate from zero with JavaScript, crawlers and AI models read zero, which is the single worst thing your proof section can say about you. And the staging site must send a noindex header on any host that is not the production domain, so Google does not index your half-finished workers.dev URL. Do it in middleware keyed on the hostname and it switches itself off automatically at cutover.

Step 6: switch the content engine on at launch

A rebuilt site with three pages of content is a brochure. Launch with the library already in the database. This site went live with 10 blogs, 20 guides, 5 case studies and 19 newsletter issues, all written, internally linked and synced to Supabase before the DNS moved.

Behind it sits a topic queue: a database table of titles waiting to be drafted, with a pipeline that generates, reviews and publishes on a schedule. One rule keeps it honest: automated generation stays switched off until one manual run has been verified end to end. Generate one piece, read every word, check it landed in the database and renders correctly, then let the machine loose.

Step 7: verify in a real browser before calling it done

A green build is not a working website. Type-checks confirm the code compiles, not that the form submits, the menu opens on a phone or the animation does not glitch on loop. Open the real site, click everything, submit the forms, screenshot the pages. On this rebuild we found a hero animation that reset with a visible jump every loop. The build was green the whole time.

Where this goes wrong

Three gotchas cost us real hours. They are documented in the playbook now so they only get paid for once.

1. Runtime secrets on Cloudflare Workers. Secrets available at build time do not exist at runtime unless you push each one to the deployed worker separately. The symptom is brutal: server-side queries silently return nothing, dynamic pages 404, and Cloudflare caches that 404 for 24 hours, so the bug outlives the fix. Push runtime secrets immediately after the first deploy, and script it so it never gets forgotten.
2. SVGs and the image optimiser. The Workers image pipeline rejects SVGs, so every logo run through the standard image component breaks quietly. Mark SVGs as unoptimised. They are vectors; there was nothing to optimise anyway.
3. The staging noindex flip. If staging never gets a noindex header, Google indexes the wrong domain. If the header is set manually, someone forgets to remove it at cutover and the real site is invisible. Key it on the hostname so it cannot be wrong in either direction.

What it actually takes

Honest accounting. This is days of focused work, not an afternoon, and the agents do not remove the need for judgement, they multiply the output of it. You need enough comfort with code to read a diff, run a build and check a git log. You need the patience to write briefs precise enough that 13 agents working blind produce one coherent site. Most of all you need the stamina to verify everything: every route, every form, every number, in a real browser, when you are tired of looking at it and the build has been green for hours. That last stretch is where most rebuilds quietly stop, and it is the entire difference between a demo and a website.

That is the whole method. Take it and run it. And if you would rather I just did it, book a consultation and tell me about the site you are stuck with.