From WordPress to Astro: Three Days to Reclaim Control

When performance, simplicity, and control replace endless maintenance.

---

1. The Tipping Point: When Maintenance Becomes Exhausting

I had two WordPress blogs: one for my technical articles (Python, AI, software architecture), and another focused on WordPress itself and its ecosystem—hosting, plugins, themes, customization, security... Two platforms, two sets of extensions, two databases to monitor—and inevitably, twice the maintenance.

With WordPress, every update can trigger a domino effect: a theme breaks, a plugin stops being maintained, or gets removed from the WordPress repository—sometimes for legitimate security reasons, sometimes for less clear ones. The governance of the ecosystem, increasingly centralized around Matt Mullenweg, adds another layer of uncertainty.

Day-to-day, this becomes a task in itself. Not development, not writing—just maintenance.

And that's not counting the constant performance monitoring: Core Web Vitals, server response times, mobile compatibility... Eventually, I felt like I was maintaining a living system rather than running a publishing space.

"At some point, I was maintaining more than I was creating."

1.1 When Plugins Turn Against You

"I'm sorry Dave, I'm afraid I can't do that."

Let's be honest: this is where I checked out. The breaking point? Plugin incompatibilities that turn every update into a game of Russian roulette.

Classic example: Editor's Kit. Supposed to enhance Gutenberg, it ended up causing more problems than it solved—display bugs, CSS conflicts, erratic behavior. I disabled and deleted it after hours of pointless debugging.

Same story with WP-Typography: excellent concept, but a resource hog. The plugin would regularly blow through PHP memory limits—fatal errors, timeouts, the whole package. I had to add my own workarounds to prevent overflows.

That's when you realize that plugin-stacked architecture has its limits: cross-dependencies, unpredictable updates, philosophy changes overnight, and an ever-growing attack surface.

Between wasted resources and potential security vulnerabilities, the benefit-to-risk ratio no longer made sense.

2. Hugo: The First Attempt at Simplicity

Before Astro, I tried Hugo. And honestly, I loved part of the experience:

• Instant builds
• Flat Markdown files
• The feeling of a site where you write and publish without friction

But the charm wore off quickly. Hugo's ecosystem is solid but less dynamic. Go templating is efficient but not intuitive. And themes, often rigid, leave little room for quick customization.

Hugo showed me the path to lightweight, but I never quite settled in. It's a perfect framework for an institutional or documentation site, less so for a living blog. It taught me one essential thing: raw performance isn't enough. You need an environment that's pleasant to maintain and evolve.

Technically, it worked. But I never took the step to go live—the result didn't inspire me. I actually wrote about this in WordPress vs Hugo: When Reality Challenges the Speed Myths.

3. Astro: The Turning Point

I didn't know Astro before this migration. I stumbled upon it almost by chance—and had one of those little pivot moments: "wait, this is different."

Within a few hours, I understood that the framework had found the right balance:

• The simplicity of a static site
• The modularity of a modern environment
• Compatibility with front-end libraries without forcing them

Astro is designed for a lean and intelligent web. Each component has a clear role. Each Markdown file becomes truly versionable content. And the final build is clean: no dead code, no unnecessary dependencies.

Why Astro over Eleventy or Next.js? Three reasons:

• Eleventy: Excellent philosophy, but a limited theme ecosystem. Starting from a clean slate would have required too much formatting work.
• Next.js: Powerful, but heavy and prone to frequent version incompatibilities. Exactly the kind of maintenance I wanted to escape.
• Astro: The sweet spot. A growing theme ecosystem, Islands Architecture that loads JavaScript only where needed, and the ability to import React, Vue, or Svelte components without bundling their full runtime by default.

"Astro genuinely changed how I see things."

3.1 Taking Back Control of Your Ecosystem

What I particularly appreciated is the modularity. I added comments via Giscus in a few lines, no plugin, no hidden dependencies. Same for SEO, sitemap, or metadata: everything is explicit, configurable, readable.

Where WordPress enforces its own framework, Astro lets me choose my building blocks. I can understand them, version them, evolve them at my own pace. It's a return to clarity:

I know what my site does, and why.

3.2 Search: Finally Usable

On WordPress, native search is... let's say frugal. It rummages through titles and content without any notion of relevance, weighting, or finesse. Worse than Google alpha 0.1.

I tried Relevanssi to improve this—I actually wrote about it in this article (French only, sorry). It worked, but at the usual cost: memory consumption, extra SQL tables, configuration to maintain, risk of conflicts with other extensions... Result? I ended up disabling all search on my blogs. Better to offer nothing than something unusable.

With Astro, I integrated Pagefind: automatic indexing at build time, instant client-side search, real relevance. No server requests, no database queries, no plugin to monitor. Just search that works, finally.

For the first time in years, I reactivated search on my site. And it's better than anything I could get with WordPress.

4. The Migration: Three Days to Transform Everything

I took advantage of a long weekend to switch everything over. Three days, no more. But I had a good foundation: a tool I'd developed for Hugo.

4.1 Homemade Tools

I dusted off my wp2md script, which I outline in the article Migrating from WordPress to Hugo in 2025: The Complete Guide (French only). Originally, I designed this tool to transform WordPress WXR exports into Markdown files. It handles:

• Text extraction
• Metadata
• Categories and tags
• Automatic image downloading
• Generation of AVIF and WebP formats from PNG or JPG images

I just had to adapt the formatter for Astro's front-matter, adding the right fields (title, description, pubDate, image, etc.).

python3 wp2md.py --input export.wxr --output ./src/content/blog/

Big thanks to Claude from Anthropic, which generated several scripts for me:

1. One to rebuild internal links after merging my two domains
2. One to recreate the base structure of the Astro project
3. And a last one to automatically regenerate all images in 320, 640, 1024, 1280, and 1440 pixel widths, in WebP and AVIF for optimal responsive rendering

And to ChatGPT for generating an optimized version of that last script.

4.2 From Two Blogs to One

I wasn't just migrating—I was merging two sites: one focused on the WordPress ecosystem, the other serving as a lab for my technical experiments. The domain name was changing, slugs too. So I had to:

• Rebuild internal links
• Verify cross-references
• Review the category structure

My initial script wasn't designed for this case, so I added logic for URL reconstruction and systematic internal link correction.

4.3 Theme and Customizations

I didn't take an Astro theme "out-of-the-box". I chose one as a base (Frosti, minimalist, well-structured), which I slightly reworked:

• Tweaks to the header and footer
• Added the OptImg component to handle responsive images
• Integrated Comments.astro via Giscus
• Performance adjustments and LCP preloading

This was also an opportunity to rationalize: a single main layout, unified style, simplified Tailwind classes. Each modification had a clear objective: speed, readability, simplicity.

4.4 Going Live and Validation

For deployment, I kept OpenLiteSpeed (OLS)—a continuity choice. I know the environment well, it's reliable, and coupled with aaPanel or CyberPanel it offers flexible management. Everything goes through Cloudflare for CDN and security.

A few minor adjustments in caching and compression rules, and the site was live. Lighthouse tests spoke for themselves:

• LCP cut in half
• TBT reduced by 70%
• SEO at 100/100 on Lighthouse. Too early to measure real impact on traffic or Google rankings, but the technical foundations are solid: semantic markup, complete metadata, clean sitemap, minimal loading times.

In three days, everything was migrated, tested, and published.

5. What I Gained—and What's Next

5.1 Immediate Benefits

• Peace of mind: No more updates, no more conflicts
• Performance: Instant pages, green Lighthouse scores
• Simplicity: Clear content folder, versioned in Git
• Predictability: The build always gives the same result

And above all, control. Every line of code, every image file, every piece of metadata goes through me. No "black box" between source and served page.

Modern image formats like AVIF are natively supported—no need for premium plugins.

And advanced features aren't locked behind monthly subscriptions that accumulate until they exceed infrastructure costs.

Concretely, I'm saving at least one hour per week—time I used to spend checking updates, testing incompatibilities, monitoring error logs. That time now goes into writing.

Infrastructure-wise, the difference is spectacular. Where WordPress requires a robust server (4 cores, 8 GB RAM in my case), Astro runs smoothly on 1 CPU core / 1 GB RAM. With Cloudflare absorbing most traffic via its CDN, the origin server only serves a fraction of requests. No PHP, no database, no application cache: just static files. Pure efficiency.

5.2 Next Steps

Astro now makes me want to go further. I'm working on a lightweight editing interface to simplify writing and image uploads, with automatic generation of responsive formats (WebP and AVIF). The goal: keep the simplicity of Markdown files while improving daily writing comfort.

5.3 What Astro Isn't

Let me be honest: Astro has its limits too.

• Smaller community than Next.js or Hugo. Fewer resources, fewer "ready-to-use" themes, fewer third-party plugins. Sometimes you have to roll up your sleeves.
• Node.js dependency: Unlike Hugo (a simple binary), Astro requires a complete JavaScript environment. Not a problem for me, but it could be depending on your setup.
• Learning curve: If you want to use advanced features (islands, hybrid SSR, complex integrations), it takes time. It's not a "no-code" tool (if you don't want to code at all, go to a publishing platform like Squarespace).

But I accepted these trade-offs knowingly. Because in exchange, I get exactly what I was looking for: control, lightness, and scalability.

And most importantly: if Astro were abandoned tomorrow, my content remains in pure Markdown. No proprietary dependencies, no exotic formats. Migrating to another static generator would take hours, not weeks.

6. Beyond the Blog: A Long-Term Vision

This migration isn't an end, it's a beginning. Eventually, I plan to move all my projects—including a newsletter—onto a single Astro foundation. One unified, versioned framework that I can evolve without external dependencies.

Managing multiple WordPress sites would have been a logistical nightmare. With Astro, I can multiply spaces without multiplying systems. One site = one Git repo = one predictable build.

I didn't just migrate two sites. I laid the first stone of a leaner, more coherent ecosystem.

7. Conclusion: Becoming Master of Your Tool Again

WordPress remains a powerful platform, but it has drifted toward a heavy, complex, sometimes unpredictable model. Astro, on the other hand, brought me back to essentials: publishing content, not managing dependencies.

What I found is a form of technical serenity. A readable, fast environment that I understand and can explain. And beyond performance, a philosophy:

Keep it simple, keep it clear, keep it sustainable.

I didn't leave WordPress out of rejection, but to regain the freedom of code I control—and the peace of mind of a site that does exactly what you ask it to, nothing more.

---

Technical Sidebar—Tools and Scripts Used in the Migration

⚙️ Infrastructure

• Web server: OpenLiteSpeed (OLS), managed via aaPanel
• CDN and security: Cloudflare
• DNS and SSL management: Cloudflare + OLS
• Hosting: Layer7 VPS (4 vCPU, 8 GB RAM)

🧩 Framework and Build Environment

• Framework: Astro (modified Frosti theme)
• Languages: TypeScript, JavaScript, Markdown, TailwindCSS
• Astro Plugins: @astrojs/image, @astrojs/rss, @astrojs/sitemap, Giscus (comments)

👨‍💻 Migration and Automation Scripts

• WordPress Export → Markdown: Python script wp2md
  • WXR file conversion to Markdown
  • Content, category, tag, and front-matter extraction
  • Automatic image downloading
• JavaScript scripts (generated with help from Claude from Anthropic)
  1. Internal link reconstruction after domain merging
  2. Base structure creation for Astro's /src directory
  3. Automatic image generation at different sizes (320, 640, 1024, 1280, 1440 px)
• Script optimization: Corrections made to speed up processing and avoid unnecessary regeneration of already-produced images

💡 Overall Workflow

1. WXR export from WordPress
2. Conversion via wp2md
3. Cleanup and reformatting via JavaScript scripts
4. Integration into /src/content/blog/
5. Lighthouse testing + SEO verification
6. OLS + Cloudflare deployment

Astro for lightness, OpenLiteSpeed for reliability, Cloudflare for peace of mind—and a few well-crafted scripts to tie it all together.