Service · Static migration
From WordPress to Astro, without losing a single URL.
Pavle Marinković and I rebuild WordPress sites as static Astro builds: same content, same slugs, SEO preserved, a fraction of the weight.
This site went first: WordPress against the static build that replaced it.
- Asset requests on the homepage202 CSS, 6 JS, 12 images21 CSS, 1 logo
- JavaScript on the homepage6 scriptsjQuery, theme, 4 plugins0at launch; analytics added since
- HTML document size79 KB34 KB
- Homepage TTFBn/ano archived figure54 msmeasure this page too
Measured on launch day. Old-site figures come from an archived capture of the WordPress homepage, and the old site's TTFB has no archived figure, so measure it yourself on the archive. Every deploy since has been a git push, and the build finishes in under two seconds. The full table and method.
Is your site a candidate?
Most of my clients should not do this. I would rather tell you that up front than migrate something that belongs on WordPress. For WooCommerce shops the honest answer is usually speed work on WordPress itself, and that is most of my practice.
A static migration fits when
- The site is content: pages and posts, not applications.
- It changes a few times a month, not edited daily in a visual editor.
- No user accounts, no gated member content, no store checkout.
- Your audit keeps pointing at the platform itself as the ceiling.
Stay on WordPress when
- An editor publishes through the dashboard every day.
- You need user accounts, forums, or logged-in personalization.
- You run a store: WooCommerce shops earn their keep on WordPress, and the win comes from cache coverage, checkout latency, and landing-page speed.
- The site already passes Core Web Vitals when tuned: a tuned WordPress site passing Core Web Vitals is the normal outcome of my work, not the exception.
Staying on WordPress is not settling for slow. Over ten-plus years and 500-plus client engagements, almost all of my work has been making WordPress itself fast, and 433 of the 635 publisher sites in my largest white-label optimization program still pass mobile Core Web Vitals in field data, re-scanned July 2026. See it by problem on the portfolio, including WooCommerce speed work, or read how on the blog.
Why sites move.
The benefits are structural. A static build is the cached page with the cache, the plugin, the database, and the PHP workers removed.
No uncached path, because there is no cache
Every visitor gets the finished HTML file. No PHP render on uncached requests, no database round-trip, no cache-miss edge case where the slow site suddenly reappears.
Less to patch, less to defend
No PHP execution, no plugin updates to track, no admin login and no database to protect. The surface an attacker can reach shrinks to the files you ship.
Hosting gets boring
The site is a folder of files that any web server can serve from anywhere. Deploys are repeatable builds from version control, not hand-tuned stacks that one plugin update can destabilize.
A head start on the metrics Google judges
With no PHP render, the server's share of response time drops toward disk-read speed, giving LCP the widest possible head start. Zero JavaScript removes script overhead from every interaction, and layout shift approaches zero. Honest caveats included: INP does not vanish, it just stops paying a JavaScript tax, and font swaps can still nudge CLS.
What a migration includes.
The same checklist we ran on this site. Nothing here is theoretical; each step is the generalized version of a tool or process that already exists in this site's own build pipeline.
- 01
Content parity
Every page and post extracted from WordPress and rebuilt in the static build under byte-identical slugs, so every URL Google has indexed serves the same content. Titles and meta descriptions carry over.
- 02
Redirects and SEO preservation
A 301 for anything that genuinely has to move (the RSS feed of this site moved from /feed/ to /rss.xml with a redirect in place), plus canonical, Open Graph, and sitemap parity checked page by page.
- 03
Image library mirror
The uploads library moves as a 1:1 path mirror, so legacy image links in search results, other sites, and old emails keep resolving.
- 04
Design system rebuild
Pages are rebuilt on a token system (type, color, spacing, components), not pixel-copied from a page builder whose layout data lives in database tables. You get a faster site and a cleaner one to maintain.
- 05
Forms and dynamic pieces
Static sites have no PHP to POST to, so contact forms and other dynamic elements are re-homed to static-friendly handlers and tested before cutover.
- 06
DNS cutover with rollback
DNS switches your domain to the new build with the old site left standing and restorable. Health checks run against real pages before anyone calls it done, and a failed check rolls the old site back.
- 07
Post-launch verification
A page-by-page parity report, a sitemap with accurate last-modified dates, search engines notified of the new URLs, and a field-data watch after launch to confirm nothing regressed.
Who does the work.
Milan Petrović
DevOps & CEO
Milan runs the server, caching, and measurement side, and every number on this page comes through him.
Pavle Marinković
Frontend Developer
Pavle builds the frontend, working with Milan from Belgrade on sites for clients across Europe.
Migration candidate or tuning candidate?
Free consultation, honest fit assessment, no obligation.
Get a free consultation