Migrating Prepa IN off WordPress in a Weekend with Claude Code

Prepa IN’s marketing site spent over six years on WordPress, since the company’s founding in 2019. It moved to Astro on Cloudflare in two days of work: I started on a Thursday morning and finished Saturday night. Friday and Sunday I didn’t touch it. On Monday I was building a new landing page, not cleaning up after the migration.

Six months later, June 2026 was the site’s best organic search month ever, and Google was showing the site 21 times more often than a year earlier.

This is the practical version of that story: the decisions that mattered and what the two days returned.

Why we left

Prepa IN is an online high school in Mexico for adults 18 and over. The marketing site is the top of the enrollment funnel, and the blog is where most of that demand arrives from Google.

We left for one operational reason. Our growth plan depended on publishing a lot of content and having every page load fast on the mid-range Android phones our students use. That points at a static-first site on an edge network. Everything else (plugin surface area, PHP hosting, the update treadmill) was a secondary benefit, not the argument.

The target: Astro for the content model, Cloudflare Workers for delivery, markdown in git as the source of truth. The student platform, a separate system entirely, stayed on WordPress on its own timeline.

The three decisions made before writing any code

Almost everything that went right traces back to a decision made before the migration started.

Every URL survives. This is the one that decides whether a CMS migration costs you traffic. Six years of accumulated ranking lives in those paths. We kept every original slug, plus the entire taxonomy: 17 categories and 23 tags carried across intact. It costs nothing if you decide it up front and it’s close to unrecoverable if you decide it after the rankings drop.

Tooling before content. The first hour went into linting, formatting, and a documented branching and release model, before a single page moved. That sounds like procrastination on a two-day project. It’s the reason two days of very fast work didn’t produce a mess, and it’s the direct counter to the idea that working with an AI makes you sloppy. The assistant is what made that discipline cheap enough to bother with on day one.

Rebuild the things worth rebuilding. A migration that ports everything faithfully inherits every old compromise. We decided up front which parts were worth re-doing rather than translating, and that list is what turned a port into an upgrade.

The two days

Thursday morning was setup and the homepage. Thursday evening was the entire blog: 87 posts exported from WordPress, 82 published ones converted, five drafts dropped.

The conversion is where the schedule came from. There was no plugin, no SaaS importer, no migration service. It was a throwaway Node script: parse the WordPress XML export, convert each post’s HTML into markdown, generate frontmatter matching Astro’s content schema, preserve the slug, carry the categories and tags. Written for exactly one site and thrown away afterward.

The migration took a weekend because the migration tool took an afternoon. That shift is more interesting than “the AI wrote code for me.” Writing bespoke tooling for a one-off job used to be indefensible: you’d spend a day building something you’d use once, so instead you’d spend a day evaluating three products that solve the problem generically and badly. That math has flipped. The disposable, perfectly-fitted tool is now the cheap option.

Spanish accents came out of the WordPress export mangled, every ñ and á and ¿ of them, and had to be repaired systematically. No English-language migration tutorial warns you about that, because nothing in the examples has an accent in it.

Saturday was the part that made this an upgrade instead of a lateral move. In one day the site got:

• Navigation rebuilt for accessibility, header and footer
• A sitemap and RSS feed
• A proper button and interaction design system
• Analytics moved off the main thread
• Core Web Vitals fixes: largest contentful paint, and eliminating the layout shift caused by the promo banner and hero image
• Structured data for search, and answer engine optimization: markup aimed at AI answer surfaces rather than only Google’s results page

That last one was January 2026, when most sites weren’t thinking about being cited by an assistant yet. It’s now a meaningful share of how people find the school.

Everything shipped through pull requests and code review, including an automated review running from the first afternoon. Speed and process stop being opposites when the assistant is the one paying the process tax. Review, conventions, and release discipline are cheap when you’re not the one typing them, which is why they were affordable on day one of a two-day project instead of deferred until the codebase “deserved” them.

The migration was done in a weekend; the polish took six more weeks. Over the following month and a half we found a missing redirect from the old WordPress author page, the structured data shipped on Saturday turned out to have a duplicate FAQ block in it, and a set of merge conflict markers went out inside a published post, which is exactly as embarrassing as it sounds.

What Claude Code changed

Two specific things, and neither is “it wrote the site.”

It made disposable tooling rational. The migration script is the clearest example, but the pattern repeated: small, exact, single-use tools instead of general-purpose dependencies.

It made process affordable. On a normal two-day sprint you skip the branch policy and the code review because they cost you the two days. Here they cost almost nothing, so we kept all of it, and the speed came out of the process rather than in spite of it.

The more useful question for anyone evaluating this approach is what has to exist so that moving this fast stays safe. For us that turned out to be four things: one canonical instruction file the assistant always reads, so the rules are context instead of folklore; a git hook that blocks bad branch operations, because a policy the tooling doesn’t enforce is a suggestion; isolated working copies so parallel work doesn’t interleave; and a single verify command running formatting, linting, type checks, content validation, tests, and a production build together.

The guardrails came from scars, not foresight. Bad branch bases and unintended releases had cost us work before, and writing that history down as policy is the honest reason the pace was survivable.

What it returned

Data below comes from Google Analytics 4 and Google Search Console, through mid-July 2026.

June 2026 was the best organic month in the site’s history at 9,473 sessions, beating a record set eighteen months earlier. April was up 74% year over year, May 82%, June 121%. It was the best quarter the site has ever recorded.

Visibility moved further than sessions did:

	June 2025	June 2026
Impressions	29,535	628,209
Clicks	2,173	7,390
Average position	15.3	6.6

Google now shows the site 21 times more often, and shows it on the first page instead of the second.

The number that matters most to me isn’t in that table. Comparing the same 90-day window year over year, clicks from non-brand searches went from 524 to 6,994, with average position improving from 18.9 to 6.8. A year ago almost everyone arriving from Google had already typed the school’s name. Today the site ranks on page one for the largest generic searches in its category. It stopped living on its brand and started capturing its market.

Organic also became the majority channel. It was under a fifth of sessions in 2023 and now runs around 58%. Engagement on that traffic sits near 65%, which is what real intent looks like rather than bot noise.

Being honest about attribution

The migration did not produce those numbers by itself. It removed the ceiling.

You can see the split in the data. In the first three months after launch, sessions were roughly flat year over year; the acceleration starts in April. What moves immediately is crawl visibility. Google impressions went from about 44,000 a month before the migration to 194,000 the month after and 517,000 by March, with average position improving from 7.8 to 5.8. That’s the platform change showing up: faster pages, clean structured data, a working sitemap, preserved URLs, and nothing sitting between Google and the HTML.

The compounding after that came from what we built on the new platform: an automated pipeline that researches, writes, reviews, and publishes, which I wrote up separately in how a fleet of Claude managed agents grew Prepa IN’s SEO and AI visibility 20x. Seven of the eight pages now earning the most clicks from Google are blog articles. The migration opened the door; the pipeline walked through it.

The return, plainly

Two working days of engineering plus roughly six weeks of part-time follow-up, in exchange for a channel that now delivers around 9,500 sessions a month, makes up the majority of the site’s traffic, and grows without ad spend. Paid channels stop the day the budget stops. This one compounds.

What I’d tell a founder considering this

Decide URL preservation before anything else. It’s free at the start and nearly unrecoverable later. It is the single difference between a migration and a traffic reset.

Spend the first hour on guardrails, not pages. Working with an agent multiplies your output and your capacity to make a mess. The guardrails are what keep only the first one.

Rebuild the parts worth rebuilding. A faithful port inherits every old compromise. Pick the short list of things to redo properly, and the migration becomes an upgrade.

Budget for the tail. The migration is two days. The missing redirects and the schema bug you shipped without noticing are the six weeks after.

A platform change is not a growth strategy. It removes a constraint. Something still has to fill the space it opens, and for us that was content, published relentlessly.

If you’re weighing a WordPress migration, or building a content engine on top of one, I’d enjoy comparing notes. You can find me on LinkedIn or X, and Prepa IN at prepain.mx.