WordPress to Astro in One Night with AI: What Actually Got Faster

Quick answer: We rebuilt a product website from WordPress to Astro in a single night, using AI for roughly one hour of generation time spread across the day. The output was 13 commits, 66 route files, 16 content paths, 4 languages and 6 purpose-built forms. But the honest lesson isn't the speed. When we audited what the site was missing, we found that almost all of it already existed inside the company — written years earlier, sitting in Confluence, Jira and chat threads, never routed to the website. The bottleneck was never content generation. It was content routing. That's the part AI compresses most, and almost nobody talks about it.

This is a case study of our own product site — the one for our smart heating hardware. We are an engineering company; we build connected products for clients. This time the client was us, which means we can show you the unflattering parts.

Why did one customer enquiry take six weeks?

The rebuild didn't start with a strategy meeting. It started five months earlier, with a purchase enquiry from a European heater manufacturer evaluating our control board for their own product.

Their first message asked about price, warranty, availability and whether the board supported rental scenarios. Our site answered none of those. So the conversation moved to the messenger, and stayed there.

Over roughly six weeks, before a single unit was ordered, that thread accumulated about 40 questions. Dimensions. Standards compliance. Integration steps. Documentation. Logistics. Customisation. At one point the customer sent a structured checklist covering 12 categories — compatibility, standards, functionality, UX, reliability, integration, documentation, price, logistics, supplier stability, customisation.

Here's the observation that reframed the whole project: that checklist was a finished content specification for our website. A buyer had done the work of telling us exactly what a buyer needs to know. Nobody on our side read it as a brief. We just answered it, one message at a time, by hand.

If you've ever written a project brief for a vendor, you know how much clarity a good one carries. This was the same document pointed in the opposite direction — and we missed it.

The account is worth roughly €15,000 a year. It consumed five months of founder attention, most of it spent typing answers that should have been on a page.

What was actually broken on the old site?

Not "the design felt dated." Specific, verifiable failures — each one visible to a customer:

• The www version of the domain returned an error page while the bare domain worked. The founder had been sending customers the www link for months. It took thirty seconds to find during the audit and thirty minutes to fix.
• The technical specification page had no entry point. It wasn't in the menu. Nothing linked to it. The only way to reach it was a URL pasted manually into a chat.
• The first screen of that spec page was an empty frame. The technical drawing loaded below the fold. An engineer opening the link saw a heading and a grey rectangle.
• The board dimensions existed only inside a PNG. 120 × 40 × 29 mm — invisible to Google, invisible to AI assistants, and impossible to copy into a calculation.
• Two pages existed in the codebase but not in production. Work had been done and never shipped.

None of these are exotic. All of them silently cost enquiries.

The real bottleneck wasn't writing — it was routing

This is the part worth your attention, because it almost certainly applies to your company too.

When we catalogued what the site needed, we expected to write it. Instead we kept finding it:

• A Confluence page describing the manufacturer integration procedure in five steps — written in 2023, never published.
• A list of white-label options — a branded app, a branded web page, CRM export — mentioned nowhere on the site.
• A product-vision document containing KPIs in the buyer's own language: time to test 100 devices, warranty repair rate. The website said "save time and resources."
• A five-year warranty and a 0.8% defect rate — stated to a customer in a chat thread, absent from the website.
• A shipped feature that selects the cheapest electricity hours — released, ticketed in Jira, and mentioned publicly nowhere.

That last one deserves a pause. It is arguably the strongest differentiator the product has. It had been built. And the three new markets we'd chosen to expand into are precisely the markets where dynamic electricity tariffs are common — so the feature and the market strategy pointed at each other perfectly, entirely by accident, because nobody had ever looked at them on the same page.

The company had known the answers for years. What was missing was a process connecting knowledge to the website. That gap is where AI produced the biggest gain — not in inventing text, but in collecting scattered material, normalising it, and shipping it as product.

It also explains the speed. The second phase took about ninety minutes largely because most facts didn't have to be invented.

What did AI actually do — and how fast?

Precision matters here, because "we rebuilt a website in an hour" is the kind of claim that deserves scepticism.

The honest version: the working window ran from just after midday to just before 5 a.m. the following morning. Within that window, roughly one hour was AI generation time. The rest was human decisions, waiting on DNS, reviewing output, and testing. Anyone claiming a full site migration takes an hour of wall-clock time is measuring the wrong thing.

What came out of it, verified against the repository rather than memory:

Note the last row. We're publishing it because a case study that reports a flawless outcome isn't a case study, it's an advert. Twelve of those 22 TODOs are untranslated news items for the new locales — meaning the content layer of those markets was not finished when this was written.

The categorical change is in the forms. The old site had a generic contact form. The new one has six, each attached to a specific intent: request documentation, request a sample, ask about certification, apply as a partner. A buyer's question now has a destination that isn't a founder's phone.

What about the bugs — did AI catch its own mistakes?

Seven bugs surfaced during the build. The tempting story is "AI found and fixed its own errors." That story is only partly true, and the nuance is the useful part:

• One build-configuration bug (environment variables not resolving inside Docker) was found after a human reported that a form didn't work, by reading logs.
• A colour contrast failure of 1.02:1 — effectively invisible text on a button — was found by a programmatic audit that a human asked for. Nobody spotted it by eye. Not the humans, not the AI, until something actually computed the ratio.
• A honeypot field collision was caught during a review of the technical spec, before it ever shipped. This was the only true prevention, and the most valuable one: the failure would have been silent, and leads would have vanished without a trace in any log.
• The remainder were caught during self-checks of the build.

The transferable rule: AI finds its own mistakes when asked in the right form. "Check your work" produces reassurance. "Compute the contrast ratio for every colour-on-background pair in the stylesheet" produces a bug report. Vague self-review is theatre; a specific, mechanical instruction is an audit.

What is llms.txt and why did we add it?

llms.txt is a plain-text file at the root of a site that describes, in a form language models can consume cheaply, what the site is and where its important content lives. It's the emerging convention for generative engine optimization (GEO) — being accurately quoted by AI assistants, not just ranked by search engines.

The reasoning is simple. A growing share of B2B research now starts with an AI assistant rather than a search box. If your specifications live inside a PNG and your warranty terms live in a founder's chat history, the assistant answering your buyer's question has nothing to work with — and it will answer using whatever your competitors published instead.

Two practical things followed from this:

1. Every specification became text. Dimensions, tolerances, protocols, warranty terms — copyable, indexable, quotable.
2. The competitor analysis had been aimed at the wrong target. Internal documents compared us against IoT platforms and consumer thermostat brands. The actual alternative buyers were evaluating was a category of low-cost board suppliers — the customer said so directly, in the messenger thread nobody had mined. A comparison page now exists for the real competitor, not the imagined one.

What we would do differently

Five honest process failures, because these are more useful than the wins:

1. We took no baseline measurements before changing anything. Positions, traffic, AI citation rates — all now measurable only "after." There is no before to compare against. This is the biggest mistake on the list.
2. We shipped a platform migration and a product restructure in the same night. If metrics move, we cannot separate which change caused it. Two releases would have been correct.
3. We ran the contrast audit last instead of first. A button with a 1.02:1 ratio survived an entire night and every build queue.
4. Locales shipped ahead of their content. Empty pages in an index are worse than no pages at all.
5. We removed a language locale that still corresponds to real operations. The decision is defensible on audience grounds, but it wasn't free.

What this means for your site

Three things transfer to almost any B2B hardware or software company:

Your customers have already written your content brief. Go read the last five sales threads. Every repeated question is a page you haven't published. If a buyer sends you a structured checklist, treat it as a specification, not as an inbox item.

Check whether your content exists before commissioning more. The most expensive way to fill a website is to write from scratch what your team already documented three years ago in a tool your marketing people don't open.

Measure the right number. Not sessions. Not bounce rate. For us the metric is how many questions a serious buyer must ask before placing a first order. It was about 40. If the rebuild takes it to 15, it paid for itself — because in a small B2B company the scarcest resource isn't engineering time, it's the founder's attention, and a website that doesn't answer questions converts that attention into typing.

FAQ

How long does a WordPress to Astro migration take?
For a site of this size — 16 content paths, 4 languages, 6 forms — the working window was under 24 hours, of which roughly one hour was AI generation. Without AI assistance, comparable scope would typically run two to four weeks. The variable that matters most isn't the platform; it's whether the content already exists somewhere.

Does AI actually write the whole site?
No. AI generated markup, page structure, translations and boilerplate quickly. Humans decided the information architecture, which facts mattered to buyers, what to publish and what to withhold, and reviewed everything shipped. The acceleration is real; the autonomy is not.

What is llms.txt?
A plain-text file at a site's root that tells language models what the site contains and where the important content is. It's part of generative engine optimization — making your product accurately quotable by AI assistants, not only findable by search engines.

Why move off WordPress at all?
Speed, security surface, and control over markup. A static-generated site removes an entire class of plugin and database vulnerabilities, loads faster, and makes structured data straightforward — which matters when you want machines to read your specifications correctly.

What's the single highest-return fix on a B2B product site?
Put your specifications in text rather than images, and give every buyer question its own destination. Dimensions locked inside a PNG are invisible to search engines, AI assistants and anyone trying to copy a value into a calculation.

How do you measure whether a rebuild worked?
Pick a metric tied to the sales conversation, not to traffic. We use the number of questions a buyer asks before ordering. Set the baseline before you change anything — which is exactly the mistake we made.

Building a product that has to explain itself?

If you're building connected hardware, the website is part of the product. Engineers evaluating your board will decide in minutes whether you look like a serious supplier — and they decide on specifications, documentation and clarity, not on hero imagery.

We design and build connected products end to end — electronics, firmware, cloud and apps — from one team in Tallinn, Estonia. And, as this article shows, we run the same process on ourselves.

Tell us what you're building and where the gaps are — we'll come back with sharp questions and a realistic plan. Request a quote → or book a call with our engineers →.

Request a quote →

---

GPO-Tech designs and builds connected products and commercial software end to end — from one team in Tallinn, Estonia.