How to Move from WordPress to Astro Without Losing Your Rankings

Moving WordPress to Astro does not automatically make a website faster.

After I migrated my own WordPress website to Astro, the PageSpeed score I was using to track Core Web Vitals improved by only two points. I could not see much difference in normal human use. It was an improvement, but certainly not the dramatic before-and-after story often used to sell static websites.

Most ranking losses after a website migration are not caused by the new platform either. They happen because someone changes the content management system, design, URLs, hosting and content at the same time. When traffic drops, nobody knows which change caused it. A WordPress-to-Astro migration should be an infrastructure project first. Preserve the public website, replace the delivery layer, test everything, then improve the design later.

Why I still moved after gaining two points

Two points is not a transformation. PageSpeed is also a test, not a stopwatch held by every person who visits the website. Google separates lab measurements from field data because controlled tests and real users do not experience a page under the same conditions. The difference matters when someone uses one score as proof of a faster website. You can read Google’s explanation of lab and field data.

I still preferred the Astro architecture. The public site no longer needed WordPress, PHP and a database to assemble an ordinary page request. The output could be built in advance, reviewed and deployed as files. That changed the maintenance model even when the human-perceived speed barely moved.

The distinction is simple. Performance is what a visitor experiences. Architecture is how the system produces that experience. Changing the architecture can make the system easier to control without producing a dramatic visual difference.

What Astro did not fix

Astro does not compress an oversized hero image by itself. It does not remove a badly configured consent platform, reduce a heavy webfont or stop a marketing team from adding five tracking scripts. If those assets lead the loading time, replacing PHP with static HTML may not feel different.

It also does not improve weak content, confused navigation or an inaccessible interface. These are design and editorial problems. A framework change cannot make the decisions on your behalf.

This is why I would not sell a WordPress-to-Astro migration as a speed service. Measure the existing site first. If the delay comes from images, JavaScript or third-party code, fix those things. Rebuilding the entire platform is an expensive way to avoid opening the browser waterfall.

When WordPress is still the better tool

WordPress is useful because non-technical people can operate it. That advantage is easy to dismiss when the migration is being planned by developers.

I would keep WordPress when the website depends on WooCommerce, memberships, learning management, complicated publishing permissions or plugins that contain important business logic. I would also keep it when editors need to build and rearrange pages without asking a developer to deploy the site.

WordPress can remain as a headless CMS while Astro handles the public front end. This preserves the editor, but it creates two systems. Sometimes that is sensible. Sometimes it doubles the work for no meaningful gain.

What must survive the migration

The new codebase is not the starting point. The existing public website is.

I build the inventory from the sitemap, a crawl, WordPress records and Google Search Console. Search Console is important because it often exposes old pages that still earn impressions even when they are absent from the current navigation.

For every indexable page, record:

• the public URL and response status
• the title, meta description, canonical URL and robots directive
• the H1, main content, structured data and internal links
• images, documents, forms and other functions used on the page

The inventory is also the acceptance test. A page has not migrated merely because an Astro route exists. It has migrated when the new route contains the information and behaviour people relied on before.

How I would handle the migration

1. Freeze the public URL map

If the WordPress article is at /example-article/, publish the Astro version at /example-article/. The folder structure inside the repository is irrelevant. Do not add /blog/ because it looks tidier to the developer.

Use a permanent redirect only when a public URL genuinely changes. Point it directly to the closest replacement. Deleted pages without a suitable replacement should return 404 or 410, not redirect to the home page. Google’s site-move guidance covers URL maps, redirects and monitoring. My website migration cycle separates the checks before and after launch.

2. Save what the browser receives

A normal WordPress export is not enough for a page-builder website. Bricks, Elementor and similar builders may store important layout data outside the post body. The REST response can be valid and still contain very little of the visible page.

I save rendered HTML, the loaded CSS and screenshots of each template at desktop and mobile widths. The export is a reference, not code to paste into Astro. Copying every builder wrapper and class would carry the old system into the new one under a different filename.

3. Decide where content will live

Markdown is fine for a developer or solo technical editor. It is a poor answer for a marketing team that expects a visual editor.

Astro can load local files or fetch content from a CMS. Whichever source you use, define the fields that every article needs: title, description, publication date, modified date, canonical URL, featured image and alternative text. Validation should stop the build when required information is missing.

I prefer content models that can leave the framework later. A collection of clearly named fields is easier to move than another decade of layout data stored inside shortcodes or builder JSON.

4. List every plugin function before removing WordPress

Plugins often do more than their names suggest. A form plugin may handle validation, spam checks, email delivery, database entries and CRM integration. Replacing it with a static form element replaces none of those jobs.

Write down what each public function does. Rebuild only what the website still needs, then test the complete path. For a contact form, that means submitting it from the deployed site and checking that the intended person receives the message. A green deployment tick is not proof of email delivery.

5. Compare the old and new output

I crawl both versions and compare the results by URL. The check includes response codes, titles, descriptions, canonical tags, headings, internal links, image paths, structured data and robots directives.

I also check the pages in a browser. A crawler will not tell you that the mobile menu is trapped behind another element or that a form success message cannot be seen. Keep the mobile layout intact during the migration. Redesign it later if the evidence supports a redesign.

6. Keep a way back

I keep the old WordPress files and database recoverable after launch. The Astro release should also have a known working deployment that can be restored quickly.

Do not delete the old system on launch day to prove confidence. Confidence is not a rollback method.

The SEO work is mainly preservation

There is no Astro setting that preserves rankings. Search engines receive URLs and HTML. They do not award points because the repository uses a newer framework.

Keep the existing URL when possible. Reproduce the title, description, canonical tag, heading structure, useful content, internal links and accurate structured data. Generate the sitemap from the routes that are meant to be indexed. Remove staging noindex rules before launch.

After launch, watch Search Console, server logs, organic landing pages and enquiries. A short fluctuation is not automatically a failure. A sudden group of 404 errors or missing canonicals is a fault and should be fixed. The post-migration SEO audit checklist covers the checks in order.

Conclusion

My move from WordPress to Astro improved the PageSpeed score by two points. The website did not suddenly feel faster. I am not going to turn that result into a speed case study.

The migration was still useful because it changed how the public site is built, deployed and maintained. That is a technical architecture decision. It only makes sense when those operational benefits are worth the cost of changing the publishing system.

If you are considering the same change, start with a website migration and SEO audit. Find out what must survive before anyone starts rebuilding it.

Frequently Asked Questions

Will Astro make my WordPress website noticeably faster?

Not always. My own PageSpeed result improved by two points and I noticed little difference in normal use. Measure where the existing delay comes from before assuming the WordPress runtime is the main problem.

Will rankings drop after moving from WordPress to Astro?

Some movement can occur while Google recrawls changed pages. Keeping the same URLs and equivalent search signals removes avoidable risk. Nobody can guarantee unchanged rankings.

Can I keep the existing WordPress design?

Yes. Save the rendered pages and rebuild their visible behaviour as Astro components. Do not combine the platform migration with a redesign unless you are prepared to diagnose both changes at once.

Do I have to use Markdown?

No. Astro can use local files or content from a CMS. Choose the editing method around the people who publish the site.

What happens to WordPress forms?

They must be replaced or connected to another endpoint. Test validation, spam handling, delivery and failure messages on the deployed site.

Should I switch off WordPress immediately after launch?

No. Keep a secure, recoverable copy until the Astro site has passed post-launch checks and real enquiries are arriving correctly.

For the delivery scope behind this issue, see Ulement’s technical SEO service.