Migrate WordPress to Astro without losing your URLs
Our free WordPress to Astro converter reads your published posts and pages through the WordPress REST API and gives you a working Astro project: Markdown files, your images, and every converted post at the address it has today. This guide covers what it does, what you fix by hand, and how to put the result live on your own domain.
The short answer
Paste your site into the converter to see what comes across, then download the project or deploy it on a $3/mo InstaPods pod. Converted posts and pages keep their paths, so links and rankings carry over; plain ?p=123 links and the old feed and sitemap addresses get 301 redirects. Comments, forms, search, shortcodes from inactive plugins and your theme do not come across. If non-developers edit the site, EmDash is the better exit.
What the WordPress to Astro converter does
The converter reads the same public JSON any visitor can fetch from your site's REST API and builds an Astro 5 project from it. It never logs in and never touches your database.
| From WordPress | In the Astro project |
|---|---|
| Published posts and pages | Markdown files in src/content/posts/ and src/content/pages/, with title, date, last update, slug, permalink, categories, tags, excerpt and featured image in the frontmatter |
| Blocks that do not convert cleanly | Kept as HTML inside the Markdown (tables, embeds, galleries, page-builder layouts), never dropped |
| Images on your own domain | Downloaded to the same /wp-content/uploads/... path and re-linked. Images on other domains keep loading from there |
| Your URLs | Every post, page, category and tag archive built at the path it has today |
Plain ?p=123 links, /feed/, the old sitemap | 301 redirects in redirects.json and public/_redirects |
| RSS and sitemap | /rss.xml and /sitemap-index.xml, generated on every build |
| Theme, menus, widgets | Not readable through the REST API. You get a plain layout and a menu built from your top-level pages |
Limits per conversion: the newest 500 posts by default (up to 1,000 on request), 200 pages and 40 MB of images (8 MB per file). Anything past a limit is noted in the project's MIGRATION-NOTES.md. The project targets Astro 5, which runs on Node 18.20 and newer.
Step 1: Preview the conversion
The preview shows how many posts and pages the converter can read, one post converted to Markdown with its frontmatter, and a list of what will not come across, before you commit to anything.
Paste your site's address into the converter. The preview needs no account. It makes at most 25 requests to your site and downloads no images, so it takes a few seconds and puts no real load on your site.
If it says it could not find a REST API, a security plugin has probably turned it off, or the site is not WordPress. Turn the REST API back on for the migration, or use the static snapshot instead, which saves the HTML your site serves and works on any public site.
If your blog lives in a subfolder (example.com/blog/) and the preview finds no posts, the API it reached may belong to the main site at the domain root. Try the subfolder's own API address, example.com/blog/wp-json/, in a browser to check it is public.
Step 2: Download the project or deploy it
Both buttons in the preview lead to the WordPress to Astro tab in your InstaPods dashboard: one downloads the project as a zip, the other builds it on a pod.
- Download: free with an InstaPods account. You get a standard Astro project; run
npm installthennpm run devand openhttp://localhost:4321. Nothing ties it to InstaPods. - Deploy on InstaPods: creates a pod on the Launch plan at $3/mo (1 vCPU, 512 MB RAM, 10 GB disk) that runs
npm installandnpm run build, then serves the built site with your redirects applied. Deploying needs a card on file, and the first card adds a one-time $10 credit. - From the command line:
instapods import https://myblog.com --astro --dry-runshows what you would get, and dropping--dry-runconverts and deploys. Add--max-posts 1000for a bigger archive.
Step 3: Check permalinks and redirects
Keeping URLs is what protects your search rankings, and the converter keeps them: each converted post and page is built at its current path, and plain ?p= links plus the old feed and sitemap get a 301.
A post at /2026/10/my-post/ on WordPress is built at /2026/10/my-post/ in Astro. The path is stored as permalink in each post's frontmatter. Sites on plain permalinks (?p=123) cannot keep those addresses as files, so each post gets a clean path and the old link a 301; internal links inside your posts are rewritten to match.
Three kinds of WordPress URL are not rebuilt: archive pagination (/category/news/page/2/, since each category and tag archive is one page listing all its posts), author and date archives, and feeds other than the main one. Posts past the conversion limit are not built either. If those pages get search traffic, add redirects for them, for example from each paginated archive to its first page.
The redirect list lives in two places kept in sync: redirects.json, which the included serve.mjs answers with a 301 (that is how a converter-made pod serves it), and public/_redirects in the format Netlify and Cloudflare Pages read. On any other host, copy the entries into its redirect settings. If you later change a post's permalink, add the old one to redirects.json.
Before switching DNS, open five or six old URLs from your WordPress sitemap on the new site, including one category page and the feed, and confirm each one loads or returns a 301.
Step 4: Check images
Images stored on your own domain are downloaded into the project at the same /wp-content/uploads/ path, so their addresses do not change.
Sites on Jetpack's image CDN (i0.wp.com) are handled too: those references are mapped back to your domain and the image is saved at its original path, at the size the CDN serves it. Images hosted on another domain entirely stay where they are and keep loading from there, which is fine until that host goes away. The conversion has a 40 MB image budget; images past it are left pointing at your WordPress site and counted in MIGRATION-NOTES.md, so find and download those before you shut WordPress down.
Step 5: Replace what does not come across
The result is a static site: no PHP runs, so anything WordPress did at request time stops working and needs a replacement or has to go.
| What breaks | Why | What to do |
|---|---|---|
| Comments | Not converted. The REST API can expose them, but a static site has nowhere to post new ones | Export them from WordPress (Tools, then Export) if you want to keep them; add a comment service for new ones |
| Contact and other forms | The form HTML may come across, but nothing on the server receives the submission | Point the form at a form service, or keep WordPress for that page |
| Search | WordPress search runs in PHP | Add a static search index or a hosted search service |
| Shortcodes | The converter saves the HTML WordPress renders. Shortcodes from inactive plugins show up as plain text like [gallery] | The preview flags any in its sample post, and the project notes list the rest; rewrite each as HTML or an Astro component |
| Drafts, private and password-protected posts | Only what anyone can read publicly is visible to the converter | Copy them across by hand |
| Custom post types (products, events) | Listed in the preview with their counts, but only posts and pages are converted | Rebuild them as another content collection, or keep WordPress if they are the site |
| Your theme | The REST API does not expose it | Restyle src/layouts/Base.astro; site name, tagline and menu are in src/data/site.json |
If a plugin does real work for your visitors (a store, memberships, courses, bookings), Astro is the wrong exit: see when to stay on WordPress.
Step 6: Decide how you will keep editing
After the move, a post is a Markdown file: you edit it in any text editor, commit it, and the site rebuilds. There is no admin unless you add one.
To write a new post, copy an existing file in src/content/posts/, change the frontmatter and write. For one developer that is usually the whole workflow, and the main reason to choose Astro at all.
If someone else writes and does not use git, add a CMS that edits the same Markdown files. Astro's CMS guide lists 45 options, among them Keystatic, Decap CMS, TinaCMS and Pages CMS, which work on content in your repository. If what your editors really want is the WordPress admin experience, EmDash is built on Astro, imports from WordPress itself and gives them an admin, on a $7/mo pod.
Step 7: Deploy and point your domain
Switch DNS last, once the new site's counts match and your old URLs load or redirect, because the moment the domain moves, WordPress stops answering on it.
- Add the domain: on the pod's Domains tab click Add Domain and enter it, for example
www.example.com. - Create the DNS record: at your DNS provider add a CNAME from that name to the pod's address, for example
my-blog.nbg1-1.instapods.app. On Cloudflare set it to DNS only (grey cloud). A root domain works if your provider supports CNAME flattening. - Verify: click Verify. InstaPods checks the record and issues a Let's Encrypt certificate, usually within minutes of the record propagating.
- Moving to a new domain?
siteinastro.config.mjsis set to your WordPress address so the sitemap, RSS feed and canonical links use it. Change it to the new address and rebuild. - Retire WordPress last: keep it and a full backup until the Astro site has run cleanly for a few weeks, and resubmit your sitemap in Search Console after the switch.
Frequently asked questions
Is there a free WordPress to Astro converter?
Yes. The InstaPods converter previews any public WordPress site for free with no account, and downloading the finished Astro project is free with an InstaPods account. Deploying it on InstaPods costs $3/mo. The manual route in Astro's own docs uses the open-source wordpress-export-to-markdown script on a WordPress export file.
Will I lose my Google rankings moving from WordPress to Astro?
Not because of URLs, if you use the converter: every converted post and page keeps its path, and plain ?p=123 links and the old feed and sitemap get 301 redirects. Archive pagination, author and date archives are not rebuilt, so redirect any of those that get search traffic. Rankings can still move with a new design, different page speed or content you leave behind, so watch Search Console for a few weeks after the switch.
Does the converter need my WordPress password?
No. It reads only the public REST API, the same JSON anyone can fetch from your site, so it never sees drafts, private posts, users or settings, and it never changes anything on your WordPress install.
What if my WordPress REST API is disabled?
The converter says so instead of guessing. Some security plugins turn the REST API off; switch it back on for the migration, or use the static snapshot, which saves the HTML your site serves and does not need the API.
Can I host the Astro site somewhere other than InstaPods?
Yes. It is a standard Astro project. Netlify, Cloudflare Pages, Vercel, GitHub Pages or any static host can run npm run build and publish dist/. Netlify and Cloudflare Pages read the included public/_redirects file; on other hosts copy the entries from redirects.json.
How big a WordPress site can it convert?
Up to 1,000 posts (the newest 500 by default), 200 pages and 40 MB of images per conversion. Anything past a limit is noted in the project's MIGRATION-NOTES.md so you know what is left to bring across by hand.
Sources
Read on 2026-10-24. Prices and plugin features change without notice, so check the source before you commit.