AI · Workflow

Plan 9
11 Oct 2026
9 min read

How we built an SEO-ready .NET website without writing a line of code

A practical guide to how plan9.co.uk went from a Claude Design prototype to a live, prerendered site on IIS in just a few days, scoring 100 for SEO, with every line of code written by Claude.

AI · Workflow

Prototype → Design → Configure → Publish → Repeat

In just a few days, the site you’re reading went from a Claude Design prototype to a live, prerendered ASP.NET Core website on IIS. It scores 100 for SEO and 91 for mobile performance in Lighthouse. Nobody on our team typed a line of code. Every line of C#, MSBuild and Node was written by Claude Cowork.

This is the guide we wish we’d had at the start. If you run your sites on Windows, IIS and .NET and want to use Claude to build a fast, search-friendly website, this is how we did it, what went wrong and what we’d do again.

This is the how-we-did-it article. For why we built our own site this way, read The cobbler’s children go barefoot.

Key takeaways

Zero codingWe set direction, reviewed and tested. Claude did the heavy lifting.

Split the workClaude Design for pages and content, Claude Cowork for server-side functionality, prerendering and publishing.

Prerender for SEOEvery crawler sees finished HTML, not JavaScript placeholders.

Publish in two stepsExport a zip, press Publish.

Measure and tuneAfter a Lighthouse review mobile performance went from 83 to 91. All metrics are in the 90s.

You don’t need to code, but you do need to know the landscape

Claude wrote every line of code. Our job was to describe what we wanted, review the results and test them. That only works if you understand the tools involved, such as Visual Studio, IIS, Cloudflare, DNS, email delivery and Google Search Console, well enough to spot when something isn’t right. Think of it as directing the build rather than doing it.

Two Claudes, two lanes

The most useful decision we made was splitting the work between two tools and keeping each in its own lane.

Claude Design: look and contentDesigned every page, wrote the copy and case studies, generated all the pages from one master file and exported the site as a zip.

Claude Cowork: server and plumbingLinked to our local development environment, it wrote the .NET, email, SEO and publishing code, tested changes in its own sandbox and checked the live site in a browser.

Short Markdown briefs in betweenThe two passed work to each other through small notes left in the project folder, such as CONTACT-FORM.md (what the form sends and expects back) and PRERENDER.md. Each side knew exactly what the other needed.

The stack

Visual Studio and .NET 10Builds the app. The Publish button deploys it to IIS with Web Deploy.

IIS on AWSHosts the app on a Windows server in Amazon Web Services.

CloudflareDNS, HTTPS, caching and compression in front of the server.

Amazon SESSends the contact form emails.

Node.js and PlaywrightBuild-time tools that run in our development environment during Publish. Nothing extra runs on the live server.

We started with an empty ASP.NET Core project whose only code said “Hello World!”, and copied the Claude Design export into wwwroot.

Step 1: serve the static site

The first fix was simple. The app wasn’t serving wwwroot, so every visit showed “Hello World!”. Claude Cowork switched on static files so each folder’s index.html loads at a clean address like /work/alliance-wine/, set sensible caching, hid working files such as design notes and build scripts, and added an HTTPS redirect for production.

Step 2: a working contact form

Claude Design defined the form and wrote a short contract describing it. Claude Cowork built the server side to match.

An /api/contact endpointChecks the name, email and message on the server, then emails the enquiry to our inbox through Amazon SES, with the visitor as Reply-To.

A branded acknowledgement emailClaude Design made the email template in the site’s style. The server fills in the visitor’s details and sends it with a plain-text version.

Spam protectionA limit of five submissions per visitor every ten minutes, plus a hidden honeypot field that only bots fill in.

Secrets out of the codeEmail credentials are held in secure environment configuration on our development and production servers, never in source control.

Step 3: a real 404 page and redirects

Missing pages now show our designed 404 page with a genuine 404 status, so search engines don’t index broken links. Old addresses from the previous site redirect permanently to their new homes, and adding a redirect is one line in a list.

Step 4: prerendering for SEO

This was the most important step. Claude Design pages are templates filled in by JavaScript in the browser. Google copes, but Bing, LinkedIn previews, AI crawlers such as ChatGPT, Perplexity and Claude, and most SEO tools saw raw template placeholders in curly brackets instead of headings and text.

Render once, at publishA Playwright script opens every page in sitemap.xml in a hidden Chrome browser, waits for it to finish rendering and saves the result as finished HTML, including titles, descriptions, canonical links and structured data.

Nothing changes for visitorsThe original template is kept in the page and swapped back in before the site’s JavaScript starts, so the menu, filters, theme switch and form work exactly as before.

Personal bits left outThe cookie popup, page-weight note and visit counter aren’t saved into the HTML, because they differ for every visitor.

A safety netPublishing fails if any page still contains an unfilled placeholder, so a half-rendered site can never go live.

If a crawler can’t read it, it doesn’t exist. Prerendering made every page readable by every crawler.

Step 5: one-click publishing

Updating the site is now two actions:

1. ExportDownload the site from Claude Design as a zip and save it into a design-drop folder in the project.

2. PublishPress Publish in Visual Studio. The build unzips the site into wwwroot, optimises it, prerenders every page, deploys to IIS and goes live through Cloudflare. Any failure stops the publish, so the live site is never left half-updated.

The extra steps run automatically on every Release build, so normal debugging stays fast. The only one-off setup is installing Node.js in the development environment and letting the first publish download Playwright’s browser.

Step 5a: the team alternative, Git and a runner

Publishing from Visual Studio suits a small team. If several people work on the site, publish to a Git repository instead, and set up a runner on your server, such as a GitHub Actions or GitLab self-hosted runner. Each time changes are pushed, the runner builds, prerenders and deploys the site automatically, so everyone works from the same source and every release is recorded.

Step 6: tuning with Lighthouse

We ran Lighthouse in an incognito window and pasted the report into both tools. Claude Design fixed the content side: the page language, a home page H1 and image sizes. Claude Cowork fixed the server side: long-term caching with versioned file names, a non-blocking main script, React served from our own server, Google Tag Manager loading after the page, and minified scripts roughly half their original size.

Performance83 → 91

Accessibility92 → 96

SEO100

Main content appears4.0s → 2.4s

Tips if you want to do the same

Give each tool one jobLet the design tool own pages and content, and the coding tool own the server. Don’t let both edit the same files.

Hand over in writingShort Markdown briefs in the project folder kept both sides in step and became our documentation.

Keep a standing notes fileA CLAUDE.md file with workflow rules, such as “every new page must be in sitemap.xml”, means you don’t repeat yourself every session.

Prerender from day oneIf your pages are built in the browser, prerender them at publish. It’s the difference between a pretty site and one that gets found.

Make publishing fail loudlyAutomated checks that stop a bad publish are worth more than any amount of manual testing.

Test like a visitorCheck the live site in an incognito window, on your phone and in LinkedIn’s Post Inspector. Cached previews and stale CDN copies catch everyone out.

What this means for our clients

This site is deliberately simple: a small number of pages, edited by the people who built it. For clients who need editors, workflows and integrations, Umbraco is still the right answer. But the same approach, with AI doing the routine work and experienced people reviewing every change, now runs through our client projects too. It’s faster, it costs less, and it leaves our developers more time for the problems that need them.

If you’d like help building something similar on your own .NET and IIS setup, get in touch.