Service · Static migration
From WordPress to Astro, without losing a single URL.
We rebuild WordPress sites as static Astro builds: same content, same slugs, SEO preserved, a fraction of the weight. For site owners and publishers whose audit says the platform is the ceiling. For WooCommerce shops the honest answer is usually speed work on WordPress itself, and that is most of our practice.
This very site, WordPress versus the static build that replaced it. Old-site figures come from an archived capture of the WordPress homepage, new-site figures from launch-day measurements. The full table and method: the migration writeup.
Why sites move.
The benefits are structural, not tricks. 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.
The dogfood evidence.
We sell this work, so the site you are reading had to go first. This page is served by the static build that replaced our own WordPress install.
- Asset requests on the homepage202 CSS, 6 JS, 12 images21 CSS, 1 logo
- JavaScript on the homepagejQuery + theme + 4 plugin scripts0
- HTML document size79 KB34 KB
- Homepage TTFBmeasure it yourself on the archive54 msmeasure this page too
Every deploy since has been a git push, and the build finishes in under two seconds. Numbers, method, and the archive link:why we rebuilt wpspeedopt.net as a static site.
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 our 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 (our own RSS feed 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.
Is your site a candidate?
Most of our clients should not do this. We would rather tell you that up front than migrate something that belongs on WordPress.
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 our work, not the exception.
Staying on WordPress is not settling for slow. Over ten-plus years and 500-plus client engagements, almost all of our work has been making WordPress itself fast, and 433 of the 635 publisher sites in our largest white-label optimization program still pass mobile Core Web Vitals in field data, re-scanned July 2026. See it by problem on theportfolio, includingWooCommerce speed work, or read how on the blog.
Who does the work.
Pavle Marinković
Frontend Developer
Pavle is the frontend developer on this team. wpspeedopt is a two-person WordPress performance team from Belgrade, working with clients across Europe, from audits to full optimization.
Migration candidate or tuning candidate?
Free consultation, honest fit assessment, no obligation.
Start with a free audit