From WordPress to Astro: Why I Rebuilt jemmymongi.com as a Static Site

For years my personal blog lived on WordPress. It worked, but every page carried database queries, plugin overhead, and a theme stack I did not fully control. When I rebuilt jemmymongi.com, I chose Astro and a static output model.

This article is not “WordPress is dead.” WordPress still makes sense for many clients. This is about when a static rebuild is worth it—and what I learned moving my own content.

Why I moved away from WordPress for this site

My goals were specific:

• Speed by default — no PHP bootstrap on every request;
• Full control of HTML — less theme magic, clearer Core Web Vitals work;
• Content in Git — Markdown in the repo beats clicking through wp-admin for small sites;
• Bilingual routing — English default plus /id/ without a heavy i18n plugin;
• Lower attack surface — static files on a simple VPS, no wp-login brute force.

WordPress could still hit those goals with caching and hardening. For a personal site with mostly articles and portfolio pages, Astro was the lighter path.

What changed in the architecture

Before (WordPress)	After (Astro)
MySQL + PHP per request	Pre-built HTML at deploy time
Theme + plugins	Components + Tailwind
wp-admin editor	Markdown in src/content/blog/
/category/catatan/ URLs	Canonical slugs + 301 redirects
Mixed EN/ID in one install	Explicit en/ and id/ content folders

The mental shift: build time vs request time. Content is validated when I run npm run build, not when a visitor hits the server.

Content migration workflow

1. Export old posts — copy text from WordPress (or existing Markdown) into src/content/blog/en/ and src/content/blog/id/.
2. Normalize frontmatter — title, description, pubDate, category slug, tags, optional cover.
3. Map legacy URLs — old category paths like /blog/category/catatan/ redirect to /blog/category/notes/.
4. Regenerate assets — featured images, favicons, and portfolio covers at sensible sizes.
5. Deploy static dist/ — rsync to the server; Apache serves files + custom 404.

Articles that existed only in Indonesian stay under /id/blog/…, with redirects from old English-style paths where needed.

Performance wins I saw immediately

After the rebuild:

• render-blocking third-party font requests removed (self-hosted fonts);
• hero and portfolio images got explicit dimensions and smaller srcsets;
• unused animation libraries deferred until after first paint;
• HTML/CSS inlined for critical pages.

The site stopped feeling like a CMS theme and started behaving like a product page—predictable markup, predictable weight.

What I still miss from WordPress

Honest list:

• Client-friendly editing — Markdown in Git is great for developers, not for every stakeholder;
• Plugin ecosystem — forms, SEO plugins, and comment systems are one click away in WP;
• Scheduled publishing — static builds need CI or a rebuild step unless you add a headless CMS.

For client sites that non-technical teams update daily, I still recommend WordPress (optimized) or a headless CMS + Astro front end.

When I recommend Astro instead of WordPress

Astro fits well when:

• the site is mostly marketing, portfolio, docs, or a personal blog;
• performance and security are non-negotiable;
• the team is comfortable with Git or a lightweight CMS;
• traffic spikes should not require database scaling.

WordPress fits when:

• editors need a familiar admin UI;
• WooCommerce or complex plugin stacks are core to the business;
• content workflows depend on roles, revisions, and scheduled posts out of the box.

Practical checklist before you migrate

• Inventory URLs that must redirect (categories, dated permalinks, attachments).
• Decide locale strategy (/id/ prefix vs separate domains).
• Set up RSS (/rss.xml) and sitemap so SEO signals continue.
• Replace wp-json/feed URLs with explicit redirects.
• Test 404 handling and legacy links before switching DNS.
• Keep WordPress read-only for a while as a rollback reference.

Closing thought

Migrating my own site forced me to confront every old URL, every mixed-language post, and every plugin I had stopped thinking about. The rebuild was work—but the result is a site that loads fast, deploys in seconds, and matches how I actually write today.

If you are weighing the same move for a brochure site or personal brand, start with one section (blog or portfolio), ship redirects, then cut over DNS when crawl errors are clean.