I had two things when I started rebuilding amergrgic.com: a new design and an old site full of content I wanted to keep. The risk with that setup is obvious. Keep the design and lose the content, and the site is a shell. Keep the content and ignore the design, and I have only moved the old site into a new folder.
The design came from OpenDesign as HTML. The content came from a WordPress site that had been running for years. What sat between them was a migration, not just a redesign, and most of the work was in the details that never show up on the homepage.
The design gave the work a target
The HTML from OpenDesign was useful because it made the visual direction tangible. Instead of describing a layout in paragraphs, I could point at markup that already represented it. I gave that HTML to oh-my-pi and asked it to bring the content across. I wasn’t asking it to invent a personal site from a short prompt. I was giving it an example of what the site should look like and an existing source for what it needed to say.
The site needed to hold more than a homepage. There’s an About page, a blog, a podcast with individual episode pages, a projects section, and now the Bits vs Bytes archive. Each one needs a slightly different layout, and all of them need to feel like the same site.
I did the work through OpenCode Go, mostly with DeepSeek v4.1 Flash and GPT 6 Luna. Iterating on a running site needs quick turns, and both were fast enough to keep the review loop short.
The rebuild ended up as a static Astro site, with shared page structure and content stored in separate files. That gave the content its own place instead of leaving it tangled in page markup.
The move
The old site was WordPress. Rather than copy pages by hand, I wrote a script that pulled the posts and episodes out through the WordPress REST API, downloaded the episode audio, and wrote everything into Astro content collections as MDX. The podcast had to come across as structured records rather than scraped HTML, because every episode needs its own page, feed entry, and audio link.
The new site builds to static files. Content lives in src/content, pages are templates, and a post or episode is a file instead of a database row. That sounds like a small difference until you have to move years of posts and episodes. Then it’s the difference between a migration script and a week of copy and paste.
Deployment runs through GitHub Actions. A push to main builds the site and rsyncs dist/ to a server over SSH. The episode audio stays on the server rather than travelling through the repository on every deploy, and the feeds carry the byte lengths so podcast apps show the correct file sizes.
I built it on a staging host first, checked it, and then switched the domain over. That gave me somewhere to compare old and new pages side by side without breaking the live site.
The part that mattered most was the redirects. A move isn’t finished when the new pages render; it’s finished when the old URLs still lead somewhere. The old About pages point to /about/, /author/... and /category/blog/ go where you would expect, /feed/ points at the blog RSS feed, and the old WordPress API returns 410 Gone instead of an empty page. Without those, every old link and search result that still points at the WordPress site lands on a 404.
The old site supplied the content
“Copy the content over” is only part of a migration. The information has to land in the right places. A podcast episode has different details from a blog post. An About page is not just another article. A project needs its own short description and links.
I reviewed how that information appeared in the new pages. The goal was to keep the details that made the site mine while fitting them into the new design. If the result looked right but lost useful information, it wasn’t a successful rebuild. And if every page preserved its text but ignored the shared design, I’d only have moved the old site into a new folder.
The Bits vs Bytes archive came along too
The rebuild also connected to a separate migration: the old Bits vs Bytes archive moved from bitsvsbytes.com to its own section on amergrgic.com. It contains 89 episodes from 2018 to 2020, with show notes and audio, not just a list of old links.
The WordPress episode records became a separate Astro collection with their own pages and RSS feed. I kept it separate from Amer’s Podcast so the older show wouldn’t get mixed into the current feed. Two shows, two feeds, one site.
Hermes helped with the next passes
Once there was a working site to inspect, I used Hermes to review it and point out what could be improved. That changed the rhythm of the work. Instead of asking for one large rebuild and treating the result as done, I could look at the running site, pick a problem, and work through a focused round of changes.
Some of the fixes were visual. The mobile navigation needed to work on a phone, which meant an accessible toggle, closing the menu on a link click and on Escape, and a layout that didn’t assume a wide screen. The images were larger than they needed to be, so they got better crops and responsive sizes.
Others were less visible: metadata for search and sharing, listening links for the podcast, and making sure unpublished writing stayed out of production builds. A draft should be a draft in the editor, not a page that is live until someone notices. The build filters out drafts and future posts, so neither reaches the site or the feeds.
Those details are easy to miss if I only judge the site by its first impression. A page can look polished and still have a navigation problem on a phone, an image that takes too long to load, or draft content showing up where it shouldn’t. I wanted to check the result as a site people would use, not just as code that compiled.
What I’d do again
I’d start from the same two sources: a concrete idea of how the site should look and the existing material it needs to preserve. That gave the coding assistant less room to guess about either.
I’d also expect the first pass to need review. The useful cycle was: give the tools real inputs, look at the generated site, decide what was missing or awkward, then make the next change. Hermes was most useful in that review-and-refine part of the work. The final decision always came down to whether a change fit the site I wanted and whether it held up when I checked it.
The rebuild involved several tools, but the handoff was simple: OpenDesign supplied the design, oh-my-pi used it and the old site to bring the content across, and Hermes helped me inspect and refine what was there.
The site is live, the archive is intact, and the old URLs still point somewhere useful. That was the bar. Everything else was iteration.
