For anyone with a Webflow site, a domain sitting unused, and no interest in learning to code just to fix that.
Wayside Stations has been live at a Webflow subdomain since the last few years. I bought the domain, waysidestations.com, at some point along the way and never got around to connecting it to anything. It sat parked, doing nothing, while the podcast lived at a wayside-stations.webflow.io address nobody could be expected to remember.
I finally moved it this week. Not because of a grand plan, but because Webflow’s pricing kept climbing, and a comment from their CEO during a recent round of layoffs made the direction fairly clear: the company is leaning toward enterprise customers, not solopreneurs running a podcast blog on a Freelancer plan. That was enough of a signal. I moved the whole thing to WordPress, hosted on Hostinger, sitting finally at the domain I’d owned the whole time.
The plan I was paying $192 a year for. Reasonable on its own, until you factor in where the company said it was headed.
What I Actually Had
Thirty-three episodes. Each with a title, a short prompt-style description, a category (Places, Music, Food, Discovery, Wildlife, Milestones), a piece of commissioned artwork, and an embedded Buzzsprout player. Four static pages on the old site: Home, Flavors, an About-style page called Idea, and a Contact page. A domain purchased through Namecheap that had been sitting idle since I bought it.
None of the podcast audio itself lived on Webflow. That was already on Buzzsprout. So the actual migration risk was smaller than it looked. I wasn’t moving audio files, just content, images, and structure.
The “Fifteen Minutes” Problem
Search for “build a website with AI” and you’ll find tutorials with that exact number in the title. Hostinger has a video called Build Your Professional Website in 15 Minutes with AI. A newsletter walkthrough on building a personal site with Bolt promises the same thing. Durable claims a complete site in thirty seconds flat. None of these are lying. If you’re generating a brand-new site from a text prompt, that’s a fair description of what happens.
Migration is a different claim, and even there the honest numbers are more modest than “minutes” suggests. Hostinger’s own migration page puts a standard transfer at around thirty minutes. Another host, 20i, says close to the same thing: average thirty minutes, “as quick as clicking migrate, making a coffee.” But that number describes moving the same kind of site between two servers that already speak the same language.
Buried further down in Hostinger’s own migration documentation is the real caveat: if your current site runs on a closed platform like Wix, Squarespace, or Shopify, their one-click tool doesn’t work at all. You start over on the new platform and copy the content across by hand. Webflow sits in that same category. It’s a proprietary CMS with no direct migration path into WordPress. The fast tools assume you’re either building from nothing or moving between two systems built the same way underneath. Neither was true here.
This took a few real hours, spread across two sessions: reviewing exports, fixing dates that Webflow had mangled, replacing broken embeds, going back and forth on layout decisions.
But the honest comparison isn’t the fifteen-minute demo against a few real hours. It’s a few hours against never. Before this week, the realistic alternative to “migrate with Claude” wasn’t “migrate slowly by hand.” It was leaving the domain parked indefinitely. Learning Webflow’s CMS export format, the WordPress import spec, enough PHP to fix a broken embed, and enough DNS to point a domain at a new host is exactly the kind of task list that never gets started. Not because any single piece is hard, but because the sum of it is precisely the thing you keep meaning to get to.
That’s the actual gain. Not speed. The removal of the excuse.
Why WordPress, Why Hostinger
I was open to anything, including using my Lovable credits, since I’d never touched that tool. Turned out to be a bad fit. Lovable builds React apps, not blogs with a CMS, and forcing a podcast archive into it would have meant rebuilding a category system and post editor from scratch. WordPress already has both, for free.
For hosting, I compared Bluehost, SiteGround, Hostinger, and GoDaddy on the numbers that actually mattered for a low-traffic site: renewal pricing, not the introductory rate, and whether there was a data center closer to my actual audience in India. Hostinger’s Mumbai data center and its honest-if-unglamorous pricing won. I picked the 12-month Premium plan rather than the 48-month deal. No reason to lock in four years to infrastructure I hadn’t tested yet.
Twelve months, not forty-eight. The renewal jump is real, but it’s a decision I can make again next year with actual data instead of a guess.
The Migration Itself
Webflow lets you export each CMS collection as a CSV — one for Blog Posts, one for the Flavors category list. From those two files, a WordPress import file (WXR format) got built, mapping every post’s title, slug, date, category, and body content into something WordPress could ingest in one shot. Thirty-three posts, six categories, done in a single import.
What didn’t survive the export cleanly: the featured images, which were metadata pointers to Webflow’s CDN rather than actual files, and the publish dates, which Webflow had collapsed. Fifteen of my earliest episodes all carried the identical timestamp of January 21, 2022, likely the day they’d been batch-loaded into the CMS rather than published one at a time. Both needed manual correction. I supplied the actual episode order and rough timing, and the dates got reconstructed and applied through WordPress’s Quick Edit, one batch at a time.
The images came from my own Dropbox archive, already named by episode number, which made reassigning them to featured images mostly mechanical: open post, set image, save, repeat thirty-three times.
Every post landed with the right category on the first import. What didn’t survive cleanly were the dates and the images, both fixed separately afterward.
Where the Automation Actually Ended
This is the part worth being honest about, because it’s the part that mattered most.
Claude could write the CSV-to-WXR conversion script, generate a PHP file to bulk-fix every broken podcast embed across all thirty-three posts, and reason through DNS nameserver changes. It also caught its own mistake in that PHP script before I ever ran it: a quoting bug that would have thrown a syntax error on the live server if I hadn’t asked for a review pass first. When it needed my Buzzsprout API token to look up every episode ID, I wasn’t going to paste a credential into a chat window, so it wrote a script for me to run on my own machine instead. One local call fetched all thirty-three IDs, rather than me copying embed codes out of Buzzsprout by hand.
What it could not do: click a button inside the Webflow dashboard, tell me which of thirty-three illustrations belonged to which episode, see what a page actually looked like without me sending a screenshot, or authenticate to my own Google Drive and Buzzsprout accounts on my behalf. Every one of those required me, specifically, sitting there, being meticulous. Matching image files to episodes, verifying every category page actually populated, checking that a redesigned Flavors page held together on the live site. None of that has a shortcut. It needed a human who knew the content.
The fix for all thirty-three broken audio embeds, run in one pass. Getting to this point took a rejected script, a caught syntax bug, and a fixed API authentication header first.
The honest split: Claude did the parts that were mechanical but error-prone, the kind of thing where a typo in a database script silently breaks a website. I did the parts that required judgment and eyes on the actual content. The Contact page from the old site never got rebuilt. Nobody was really using it, so we skipped it. That’s a small decision, but it’s the kind no script gets to make. Neither half was optional.
What Broke
The Buzzsprout embeds Webflow had generated were old Embedly iframes with fixed pixel dimensions, which is why every episode page showed a tiny audio player surrounded by dead white space. Buzzsprout’s own native embed code fixed it, but getting all thirty-three required a Buzzsprout API call, which returned a 403 the first time because the request was missing a User-Agent header. Buzzsprout blocks anything that looks like a bot without one.
Posts came in out of chronological order, more than once, because Webflow had collapsed several batches of episodes onto identical timestamps rather than their real publish dates. Each time, WordPress was sorting correctly. The underlying dates were just wrong. Fixed via Quick Edit, in the sequence I actually remembered publishing them.
Category archive pages returned empty results even though every post had a category assigned. The cause: WordPress’s default category URLs are /category/category-name/, and the Flavors page links pointed to /flavors/category-name/ to match the old site’s structure. Nothing was actually broken, the URLs just didn’t line up. The fix was a single field in the permalink settings, a custom category base set to “flavors,” but finding that it was the category base and not something in the import was the slower part.
None of these were catastrophic. All of them would have been confusing to debug without knowing exactly where to look, and all of them got caught by actually clicking through the live site rather than assuming the import had worked.
The Numbers
Hostinger: $47.88 for twelve months, Premium plan. The domain was already paid for, sitting idle. WordPress itself, the Astra theme, UpdraftPlus for backups, and Redirection: all free tiers, sufficient for a site this size. Total new spend: under fifty dollars for the year, replacing a $192-a-year Webflow subscription that would have renewed in August regardless of whether I used it.
Time: a few hours across two sessions, most of it going into fixing what the export didn’t carry cleanly rather than the migration itself.
What This Actually Means
I don’t think the interesting claim here is that AI makes migrations fast. Plenty of things about this were slow, fiddly, and needed me watching closely. The interesting claim is narrower. The barrier to doing this at all used to be knowledge: knowing WordPress internals, knowing enough PHP to fix a broken script safely, knowing what a WXR file even is. That barrier is mostly gone now. What’s left is attention. Sitting there, checking the work, deciding which image goes with which story.
The domain sat parked not because moving it was hard, exactly, but because the first step was never obvious enough to take. That’s usually the real obstacle. Not difficulty. Inertia.
waysidestations.com is live now. It should have happened a long time back.
If you’ve got a domain sitting idle behind a project you’ve been meaning to move, I’d be glad to compare notes — find me at @youplusai or on LinkedIn.