We migrated off WordPress and discovered most of the “missing” content was already written internally, just never published

I run a small hardware/software company and we finally rebuilt our product site — WordPress to Astro. Writing this up because the useful lessons weren't the ones I expected, and I see a lot of people here postponing the same thing because it feels expensive.

What was actually broken (all verified on the live site, all found in the first half hour):

– The `www` version of our domain returned an error page while the bare domain worked. I had personally been sending customers the broken link for months.

– Our technical specification page wasn't in the menu and nothing linked to it. The only way to reach it was a URL I pasted into chat manually.

– The first screen of that page was an empty frame — the drawing loaded below the fold.

– Our board dimensions existed only inside a PNG. Invisible to search engines, invisible to AI assistants, impossible to copy into a calculation.

– Two finished pages existed in the codebase but had never been deployed.

The part I didn't expect. When we listed what the site was missing, I assumed we'd have to write it. Instead we kept finding it already written, internally:

– an integration procedure documented in Confluence in 2023, never published

– a five-year warranty and a 0.8% defect rate, stated to a customer in a chat thread but nowhere on the site

– a shipped feature (picking the cheapest electricity hours) mentioned publicly nowhere

So the bottleneck was never writing content. It was routing content that already existed. That's the reason the rebuild took a day instead of a month — most facts didn't have to be invented.

Context on effort: the working window was one day, of which roughly an hour was AI generation. The rest was decisions, testing and waiting on DNS. Anyone telling you a full site migration takes an hour of wall-clock time is measuring the wrong thing.

What I'd do differently:

1. We took no baseline metrics before changing anything. Positions, traffic, everything — now only measurable "after". This is the biggest mistake on the list.

2. We shipped the platform migration and a content restructure the same night. If numbers move, we can't tell which caused it. Two releases would have been correct.

3. We ran the colour-contrast audit last instead of first. A button with a 1.02:1 contrast ratio — effectively invisible text — survived the entire build.

4. We shipped new language locales before their content was ready. Empty pages in an index are worse than no pages.

One practical tip if you're using AI in this: "check your work" gets you reassurance. "Compute the contrast ratio for every colour-on-background pair" gets you a bug report. Vague self-review is theatre; a specific mechanical instruction is an audit.

Happy to answer questions about the Astro side or the migration itself.

(Disclosure: this is our own company's site — full write-up with the numbers is on our blog if anyone wants it, but everything useful is above.)