A WordPress to Astro migration playbook: real cost and timeline ranges, the five checks that protect rankings, and where migrations actually lose traffic.
A WordPress to Astro migration is not a redesign with a new coat of paint. It is a one-time, high-stakes technical SEO project where every redirect, every schema block, and every canonical tag either survives the move or costs you rankings you spent years earning. Treat it like the CI-gated, redirect-mapped, audited process real migration agencies actually run, and the framework change becomes the easy part.
This post covers what the move actually costs and takes, the five non-negotiables that protect your rankings, and what changes for your content team once you land on git.
The pull is Core Web Vitals and workflow, not the CMS interface. Astro renders content to static HTML by default and ships zero JavaScript unless a component explicitly asks for it, which is why a content-only blog on Astro tends to clear Google's performance thresholds without any tuning. We covered the mechanics of that gap in Astro vs Next.js SEO; the short version is that a plugin-heavy WordPress install carries JavaScript and database overhead a static-first framework never touches in the first place.
The second pull is workflow, and it matters more for dev-tool teams specifically. A WordPress post lives in a database, editable through a browser, invisible to your normal engineering process. A Markdown post lives in the same repo as your product code, reviewable in a pull request, deployable through the same CI pipeline that ships your app. For a team that already lives in git, that is not a nice-to-have, it is the difference between a blog the engineering team can actually touch and one that requires a separate login and a separate mental model.
Neither reason is a reason to migrate carelessly. Astro's own migration guide is explicit that you have a choice here, not a forced full rebuild: keep WordPress running as a headless CMS behind an Astro frontend, or migrate every post to Markdown or MDX files and drop the database entirely. The headless path keeps your existing WordPress editor and content team workflow while you get Astro's frontend performance. The full migration path gets you the git-based workflow but is more work up front, and Astro's own docs warn that you may need to make manual adjustments to the result if you convert a large or complicated WordPress site to Markdown, an automated export is a starting point, not a finish line.
The honest answer is that it depends entirely on what is actually in your WordPress install, not just how many posts you have. Lucky Media, an agency that specializes in this exact migration, quotes 6-12 weeks for a standard marketing site with a typical content structure, and 16 weeks or more once you add custom post types, WooCommerce, or multi-language content. Their process runs six phases: a WordPress and SEO audit, content model design, content migration, the Astro frontend build, SEO verification (canonicals, redirects, schema), and deployment with 30 days of post-launch support. That structure is worth copying even if you do the migration yourself: skip the audit phase and you find out what you missed after launch, when it is a ranking drop instead of a checklist item.
Pricing scales with the same complexity driver as timeline. Lucky Media's own site does not publish flat tiers; it offers a fixed-scope estimate after a discovery call, because the real cost variable is how much of your content, taxonomy, and custom functionality has to be modeled and migrated by hand rather than how many pages exist. A marketing site with a couple hundred standard blog posts and no custom post types is a fundamentally different project than a 500-page content library with faceted taxonomy, or a WooCommerce store where product data, variants, and checkout logic all need a new home.
The three profiles below drive nearly all the variance in the numbers above:
| Profile | What drives the effort | Realistic timeline |
|---|---|---|
| Small marketing site (blog + a few static pages, no custom post types) | Content volume is low; the work is mostly redirect mapping and template parity | Weeks, not months, with a small team |
| 500-page content library (deep taxonomy, tags, categories, related-post logic) | Content modeling and pagination/taxonomy parity in Astro's content collections | 6-12 weeks per Lucky Media's standard tier |
| Headless WooCommerce (product data, variants, checkout) | Commerce data migration and integration, not just content | 16+ weeks per Lucky Media's complex tier |
If you are not sure which bucket you are in, count your custom post types and check whether any of them touch commerce or user accounts. That single question moves a project from the top row to the bottom one.
Everything below is checkable before launch. None of it requires guessing how Google will react, because Google has published exactly what it wants.
Every URL on your old WordPress site needs a mapped destination on the new Astro site, and the redirect itself needs to be a server-side 301 or 308. Google's own site-move documentation is direct about this: "Although Googlebot supports several kinds of redirects, we recommend that you use HTTP permanent redirects if possible, such as 301 and 308." Client-side JavaScript redirects and meta refresh tags are weaker signals and slower for Google to process.
Two mistakes do the most damage here. The first is redirecting many old URLs to one irrelevant destination, usually the homepage, because there was no time to map them individually. Google's guidance calls this out specifically as something to avoid; a redirect has to point somewhere actually relevant to the old page's content, or it reads as a soft 404 rather than a real move. The second is chaining redirects, old URL to an intermediate URL to the final URL. Google can technically follow up to 10 hops, but its own advice is to "keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5." A redirect map you build once and audit is worth the two or three days it takes; a redirect map you patch reactively after launch is the single most common reason migrations lose traffic they didn't have to.
Keep the old redirects live for a long time after launch. Google's guidance is specific: "Keep the redirects for as long as possible, generally at least 1 year," because that window is what lets Google transfer link signals from other sites still pointing at your old URLs.
A visual rebuild is not a migration if the structured data underneath it disappears. Before you touch a single template, audit what schema markup currently exists on the WordPress site using a validator, then explicitly map each schema type to its equivalent in the new Astro templates rather than assuming the rebuild will "just work." That mapping step is the part teams skip, because schema is invisible in a browser and easy to forget when the whole team is focused on how the new site looks.
Do this page-type by page-type, not site-wide. A blog post's Article schema, a product's Product schema, and an FAQ page's FAQPage schema are three different mapping jobs, and a template that silently drops one of them can cost rich-result eligibility across every page that uses it, without a single visible symptom until an SEO audit catches it weeks later. If your migration touches AI Overviews or AI Mode visibility specifically, our schema markup for AI Overviews post covers what structured data needs to look like beyond classic rich results.
The entire performance case for moving to Astro evaporates if nobody actually checks Core Web Vitals before launch. "Looks fast" in a manual spot check on a fast office connection is not a Core Web Vitals check; a Lighthouse assertion in your CI pipeline that fails the build when LCP, CLS, or INP crosses Google's thresholds is. If you are setting this up for the first time, our GitHub Actions SEO checks post walks through a four-job workflow, broken links, canonical/meta validation, JSON-LD linting, and Lighthouse budget assertions, that gates the merge instead of relying on someone remembering to check.
This matters more during a migration than at any other point in a site's life, because you are rebuilding every template at once. A single slow font load or unoptimized hero image pattern, copied across every post template, becomes a site-wide regression instead of a one-page mistake.
Submit your new Astro sitemap in Search Console as soon as the migration is live so Google has a direct map of your new URL structure to crawl. Keep both sitemaps submitted side by side rather than deleting the old one on launch day. Google's own guidance describes watching the indexed-page counts trade places: the new sitemap starts near zero indexed pages while the old one still shows many, and "over time the number of pages indexed from the old URLs sitemap would drop to zero with a corresponding increase of indexing of the new URLs." Once that handoff shows up in Search Console, you can remove the old sitemap, since Google will use the new one going forward.
Also plan for a crawl spike you did not have to ask for. Google states plainly that after a site move, it "will crawl your new site more heavily than usual," because requests to old URLs get redirected into new-site crawl activity on top of your normal crawl demand. If your hosting or server capacity is sized for typical traffic, a migration is the wrong week to find out it can't handle a crawl surge.
Decide what actually deserves a place in the new site before you migrate it, not after you've already rebuilt every template around content you didn't need. A migration is the natural moment to run a content audit: which posts are still getting search traffic, which are decayed and need a rewrite instead of a straight port, and which should be merged, redirected, or retired outright rather than carried over as dead weight. Our content refresh strategy post covers the decay-detection workflow, which is the same Search Console analysis that should run before a migration, not just as an ongoing maintenance habit.
Skipping this step means you migrate your problems along with your content, and you do it at the exact moment you have the least visibility into what's actually working, because the new site has no ranking history yet to tell you.
The honest tradeoff is editorial convenience versus engineering control, and it splits cleanly along team type. A marketing team used to WordPress's browser-based editor loses that interface entirely on a full Markdown migration; every post becomes a file, edited in a text editor or a headless CMS UI, then committed through git. That is a real cost for a team that isn't used to it.
What you get in exchange is a publishing pipeline that behaves like your product's codebase instead of a separate system nobody on the engineering side ever opens. Every post change is a diff. Every change goes through the same review and CI process as a code change. Nothing publishes without someone approving the pull request, which is a different failure mode entirely from a WordPress post going live the moment someone clicks Publish.
If your team wants the performance win without giving up the WordPress editor, the headless path from Astro's own migration guide solves exactly that: WordPress stays the CMS, Astro becomes the frontend, and your content team's day-to-day workflow doesn't change at all.
Google's own guidance sets the baseline expectation: a small to medium site can take "a few weeks for most pages to move" after a migration, and ranking fluctuation during that window is expected, not a sign the migration failed. Kevin Gibbons, a search consultant quoted in a Search Engine Journal analysis, frames the real risk differently: "A smooth migration doesn't start on launch day; it starts way before. SEO needs to slot into your QA and development process from the beginning." That same piece puts typical recovery at four to twelve weeks, with the exact timing shaped by migration scope, site size, and how much content actually changed, and treats a temporary traffic dip as recoverable, not catastrophic, as long as the technical basics hold.
The wide end of that range is real too. One aggregated analysis of 892 domain migrations found an average recovery time of 523 days, about 17 months, to match prior organic traffic, with the fastest recoveries at 19 to 23 days and 17% of sites still below their old baseline after 1,000 days. That spread is not a reason to panic; it is a reason to notice how much of the variance is explained by execution quality rather than the migration itself. The sites recovering in three weeks and the sites still down after three years both moved off WordPress. The difference was whether the five non-negotiables above were actually checked before launch.
Where projects lose rankings, consistently, is the boring stuff: a 301 that was never mapped, a noindex tag copied from a staging environment and left in production, an internal link that still points at a URL with no redirect, or JavaScript-rendered content that shows a crawler something different from what a visitor sees. None of these are framework problems. They are QA problems that a migration makes easy to introduce and easy to miss, because everything about the site changed at once and there's no single obvious place left to check by eye.
Once your content lives as Markdown files in a repo, the actual publishing question changes from "who has WordPress admin access" to "what does our git workflow look like for content." A new post is a new file on a branch. Editorial review happens as PR comments instead of a WordPress revision history nobody checks. A merge to main triggers the same build and deploy pipeline your product already uses.
This blog you're reading runs on exactly that model. Every post here is a Markdown file with YAML frontmatter, built statically at build time, and shipped through a pull request before it goes live, the same workflow this section is describing, not a hypothetical one. We didn't pick that setup for this post's sake; it's the only way we'd run a blog ourselves.
That handoff is also where a repo-native writing tool actually fits, instead of bolting a WordPress plugin onto a database that no longer exists. A git-based AI blog writer reads your repo's conventions, drafts a post as a Markdown file on a branch, and opens a pull request the same way a human contributor would, so nothing auto-publishes and your existing review process still gates every post. It's the same argument we made for developer-facing teams in an AI blog writer built for developers: once your content is code, the tools that write it should behave like the tools that write your code. If you're planning a migration and want to see that workflow running against your own repo before you commit to it, talk to the founder.
The first 90 days after launch are when the redirect map and schema mapping either hold or reveal what was missed. Watch Search Console's Coverage report daily for the first two weeks for a spike in 404s or a jump in pages excluded by noindex, both are early signals of a redirect gap or a leftover staging tag. Watch the Performance report weekly for impressions and clicks by page, not just site-wide totals, since a site-wide average can hide a handful of high-value pages that lost their redirect while everything else transferred cleanly.
Check crawl stats for the heavier-than-usual crawl activity Google warns to expect, and confirm your server capacity is actually handling it rather than silently rate-limiting Googlebot. Re-run your structured data validator against a sample of live URLs, not just staging, since a mapping that worked in a test environment can still break on a production build with different data. And keep the old sitemap live in Search Console until Google's systems clearly reflect the new site, only removing it once that transition shows up in your coverage data, not on a fixed calendar date.
If you're still weeks out from launch and want to see how a git-based publishing pipeline behaves before you commit to one, join the waitlist and we'll keep you posted as Lyra opens up more capacity.
Once your migration lands on git, Lyra can pick up the publishing work from there, reading your repo's conventions and opening a pull request for every new post, the same review gate you already use for code. Talk to the founder → · Join the waitlist
FAQ
Not if you treat it as a technical SEO project instead of a redesign. Google's own guidance says ranking fluctuation during a move is expected, and a small to medium site typically settles within a few weeks. The risk is not the framework change, it is missing 301 redirects, dropped schema, or a canonical pointing at the wrong URL, all of which are checkable before launch.
A standard marketing site with a typical content structure runs 6-12 weeks with an agency doing it properly. Sites with custom post types, WooCommerce, or multi-language content run 16 weeks or more. A solo developer moving a small blog by hand can move faster, but the redirect mapping and schema verification still take real time regardless of team size.
Astro's own migration guide gives you both paths. Keep WordPress as a headless CMS behind an Astro frontend if your team wants to keep the WordPress editor, or migrate every post to Markdown or MDX files if you want a git-based workflow with no database. Astro's docs warn that a full migration of a large or complex WordPress site to Markdown usually needs manual adjustment, not a clean automated export.
Missing or incorrect 301 redirects top the list, followed by noindex tags accidentally carried over from a staging environment, broken internal links, and JavaScript-rendered content that changes what a crawler actually sees versus what a visitor sees. All four are catchable in a pre-launch audit, which is exactly why they are still the most common cause of migration traffic loss.
Google says a small to medium site can take a few weeks for most pages to move over, with larger sites taking longer. A Search Engine Journal analysis puts typical recovery at four to twelve weeks, with the range shaped by migration scope, site size, and how much content actually changed. A separate aggregated analysis published by Digital Applied, covering 892 domain migrations, found an average of 523 days to fully recover prior traffic, with the fastest recoveries in 19 to 23 days, a reminder that execution quality, not just time, decides which end you land on.
Built by the tool you're reading about
Lyra finds the topics worth ranking for, writes them in your repo's voice, fact-checks every claim, and opens a pull request scored and ready to merge. You review and hit merge. Want to see what she'd write for you? Tell us about your blog and the founder will walk through it with you.
Keep reading
Docs SEO and documentation SEO for the AI era: why API docs get cited differently than blog posts, and the structural fixes that make them extractable to LLMs.
How many blog posts per month should a SaaS company publish? The data says 2-4 focused posts beat 16 generic ones, and how to set a cadence you can sustain.
AI blogs sound generic without a real guide. What belongs in a brand voice AI content style guide, and how to keep it current as your product evolves.