Free audit
Not sure whether your site is worth migrating?
Thirty minutes on your WordPress: your pages, what Google is actually indexing, how your languages are wired and which plugins you are stuck with. You keep the plan either way.
See the migration Accelerator →
For what it is worth: this site — every landing, every post, five languages — is Astro on Cloudflare Pages. We did not pick the stack for client work and keep our own site somewhere more forgiving. That is the whole of the proof I am offering. Take the argument on its merits, not on our numbers.
## The two decisions everyone postpones, and both get expensive
Migrations get sold on speed and rankings. The two things that actually determine whether the new site is better in three years barely come up in the sales conversation.
**The first is indexing.** Ask your team which URLs on your current site Google is allowed to index. On most WordPress installs nobody can answer, because the answer is smeared across an SEO plugin, robots.txt, archive settings, and whatever the theme decided about tag and author pages. So sites quietly ship thousands of paginated, filtered and near-duplicate URLs, and crawl budget goes to pages nobody wanted ranked. A migration is the one moment when you can make that explicit — a decision per template, written down in the codebase where changing it is a reviewed change rather than a toggle somebody flips at 6pm. Do it during the move or you will inherit the same fog on a faster stack.
**The second is language.** Multilingual on WordPress means a plugin that turns every page into a duplicate someone has to keep in sync, which is why agencies quote it as a surcharge and treat a third language as a complication. Modelled properly, each language is a route with its own content file, hreflang is generated from the content itself, and a missing translation surfaces when the site builds instead of when a customer finds it. That inversion — from "translations drift silently" to "translations fail loudly" — is worth more over three years than any Lighthouse score.
The third thing, and the one people do remember too late: keep the URLs. All of them. The redirect map is not migration paperwork, it is the migration. Build it in week one from your real Search Console inventory, not from an assumption about what the sitemap contains.
## Three things that break when the database goes away
Nobody sells you a migration by listing what stops working, so here is the list. All three are solvable, and all three are cheaper to solve on purpose than in a panic the week after launch.
**Search.** WordPress search is a database query. Take the database away and there is nothing to query. The answer is a static search index — Pagefind is the tool most Astro sites land on: it reads your finished site after each build, writes a compact index next to it, and the browser downloads only the fragments matching what someone typed. It is quick enough that results appear as you type, and it costs nothing to run because there is no server involved.
**Forms.** No PHP means no `mail()`, which means your contact form needs somewhere to go. On Cloudflare that is a small function on their network: it receives the form, screens for spam with Turnstile — which, unlike a CAPTCHA, usually asks the visitor to do nothing — and hands the message to an email service like Resend or SendGrid. Or you skip all of it and point the form at HubSpot, which is what most marketing teams already have.
**Soft 404s and redirect loops.** This is the one that quietly costs traffic. If someone requests a page that does not exist, the site has to answer with an actual 404 rather than politely redirecting them to the homepage with a success code — Google reads that second behaviour as a "soft 404" and it degrades how it crawls the whole domain. Multilingual sites make it worse: force HTTPS, add a trailing slash, add a language prefix, and you can chain three redirects for one visit. All of it belongs in a single hop, decided once. It is a boring thing to get right and an expensive thing to get wrong.
## Where this goes next
The interesting shift is not WordPress losing two percentage points. It is that the requirements for a business website changed underneath everyone at once: machine-readable by default, fast enough to be included in a generated answer, and cheap enough to change that your team stops treating the site as a quarterly project.
Some teams will get there on WordPress with discipline and a very short plugin list. More will decide that the simplest way to have nothing to patch is to have nothing running.
Transform by Epinium
We will tell you if you should stay on WordPress
The migration audit maps your pages, your indexing, your languages and your plugin dependencies, then gives you a fixed scope and a fixed date. If the honest answer is that migrating is not worth it for your site, that is the answer you get — and the plan is yours either way.
Book the migration audit →
## FAQ
### Is WordPress dying in 2026?
No. It still powers roughly 41% of all websites and around 59% of sites running a known CMS. What has changed is direction: after fifteen years of growth it has been slipping by one to two percentage points a year. For most of the world WordPress remains the default. The teams leaving tend to be the ones publishing at volume, in multiple languages, with engineering support available.
### What is an "AI-native" website, exactly?
A site whose content is readable by machines without a browser. In practice that means server-rendered HTML with clean semantics, content that does not depend on JavaScript to appear, an llms.txt file describing your site to language models, and often a plain Markdown version of each article. It is less a product category than a set of properties — and a static site gets most of them for free.
### Can we let an AI write directly into the site?
Safely, yes — but only once content has a schema. When every content type declares its fields and types, an agent can generate or update entries and anything malformed fails validation before it reaches a visitor, with the change arriving as a diff someone approves. Running the same automation against page-builder WordPress means editing generated markup and serialised database fields, which is how teams end up restoring backups instead of saving time.
### How do you keep control of what gets indexed?
By deciding it per template, in the codebase, before the site ships. Tag archives, author archives, paginated series and filtered views each get an explicit answer — index, redirect or retire — and sitemaps, canonicals and robots rules are generated from the build rather than hand-edited. The practical test is whether someone on your team can state today which URL patterns are indexable without opening a plugin's settings screen.
### Can I keep WooCommerce if I move to Astro?
Not inside Astro, and this is the clearest disqualifier in the whole decision. A transactional storefront belongs on Shopify or a headless commerce backend, with Astro as the front end if you want one. If WooCommerce is where your revenue lands, migrate the content site around it and leave the checkout alone.
### How will our marketing team publish without wp-admin?
Two workable paths. Markdown files in git with a visual editor on top suits technical-ish teams and costs nothing. A headless CMS — Sanity, Contentful, Decap, Keystatic — gives editors a familiar interface and connects to the same build. Publishing triggers a rebuild; on our site that takes under a minute for the whole thing.
### What happens to our plugins?
Each one gets mapped to a replacement before the project starts, or it gets flagged. Forms move to HubSpot or a serverless endpoint. SEO metadata becomes typed frontmatter that fails the build when it is wrong. Caching and CDN are the hosting platform. Security plugins become unnecessary because there is no runtime to attack. Anything with no equivalent should surface in the audit, not in week three.
### Is Astro suitable for a site with thousands of pages?
That is where it earns its keep — this site runs on it across five languages and several thousand pages. Content collections give you typed, validated content, so a malformed date or a missing alt attribute breaks the build instead of shipping a broken page to production. The larger the catalogue, the more that matters: nobody proofreads page 1,800 by hand.
### We already invested heavily in a page builder. Does that change the maths?
It raises the migration cost, because builder output has to be rebuilt as components rather than exported. It also raises the cost of staying, since builder markup is usually the heaviest thing on the page and the least legible to crawlers. Sunk cost is not a reason either way — compare the next three years of both options, not the last three.
### What is the minimum size where this makes sense?
Roughly: more than a few hundred pages, or more than one language, or a team that publishes weekly and is blocked by the current stack. Below that, hardening your existing WordPress is usually the better spend. We say so in audits more often than people expect.
### How long does a migration take?
A content site of a few hundred pages typically runs four weeks from kickoff to cutover. Thousands of pages, several languages, or a headless CMS on top pushes it to six or eight. The URL audit in week one is what makes the estimate real rather than optimistic.