How to Migrate from WordPress to Next.js in 2026

The number of teams migrating off WordPress has accelerated sharply in 2026. The combination of the Automattic governance crisis, plugin supply-chain risk, and the structural impossibility of retrofitting AI-native features onto a 2003 PHP architecture has pushed a generation of digital teams toward modern JavaScript frameworks. Next.js — specifically Next.js 15 App Router paired with a Firebase backend — has emerged as the most practical destination.

This guide covers the complete migration process: what to export, how to map routes to preserve your SEO, how to import to Firestore, and how to verify nothing broke before you cut over DNS. It takes most teams 2–4 weeks. With Infinity Press's pre-wired stack, the infrastructure work is already done.

Before you start: use the WordPress True Cost Calculator to confirm the migration makes financial sense for your stack. Most teams running WP Engine or Kinsta with 10+ premium plugins are paying $3,000–$8,000/yr more than they need to.

Why teams are leaving WordPress now

The case against WordPress in 2026 is not “it's bad.” WordPress still powers 43% of the web. The case is that it was designed for a world that no longer exists — and the cost of working around its architectural limits has become untenable.

The specific failure modes:

• Weekly security patches. Core, plugins, and themes all have independent update cycles. A typical WordPress site has 14 plugins. Any one of them can introduce a zero-day. The maintenance overhead is real, and the attack surface is large.
• Performance ceiling. WordPress's median LCP is 4.2 seconds (PageSpeed data, 2026). Next.js with static generation and CDN delivery routinely hits sub-1.8s. The gap affects ad quality scores, organic rankings, and conversion rates.
• AI integration impossibility. Adding a real-time voice agent, streaming chat, or agentic AI features to WordPress requires a tangled mess of external SaaS, iframes, and webhooks. Next.js handles these natively — server components, streaming responses, WebSocket connections, all first-class.
• Governance risk. The Automattic v. WP Engine litigation is still active in 2026. It has created licensing uncertainty around the plugin ecosystem, access controls, and the wordpress.org platform itself. If your business runs on WordPress plugins, you are exposed to a third-party legal dispute you have no control over.

What you need before you start

Run this checklist before touching anything:

1. Google Search Console access — you will need to file a Change of Address after cutover. Get owner access if you don't already have it.
2. Current sitemap export — download your existing sitemap XML. This is your URL inventory. Every URL on it needs a corresponding route in the new app.
3. Analytics baseline — take a GA4 or Ahrefs snapshot of your current traffic, rankings, and top-performing pages. You'll use this to verify nothing regressed post-migration.
4. 301 redirect plan — if any URLs will change (e.g., WordPress used /category/post-slug/ and you want /blog/post-slug/), document every redirect now. Missing redirects lose link equity permanently.
5. Content inventory — list every page, post, custom post type, and media file. Decide what migrates and what gets retired.

Step 1: Export your WordPress content

The cleanest approach is the WP REST API. It returns JSON that maps directly to Firestore documents. For most sites, a single script exports everything in an hour.

Core export endpoints:

# Export pages
curl https://yoursite.com/wp-json/wp/v2/pages?per_page=100 > pages.json

# Export posts (paginate for large sites)
curl https://yoursite.com/wp-json/wp/v2/posts?per_page=100 > posts.json

# Export taxonomy
curl https://yoursite.com/wp-json/wp/v2/categories > categories.json

# Export media library
curl https://yoursite.com/wp-json/wp/v2/media?per_page=100 > media.json

For each post, capture: id, slug, title.rendered, content.rendered, excerpt.rendered,date, modified, status, categories, featured_media, and any custom fields from meta or ACF.

The content.rendered field is HTML. You have two options: store it as HTML and render it with a sanitized dangerouslySetInnerHTML, or convert it to Markdown with a library like turndown and render with your preferred MDX/Markdown renderer. Firestore stores either format fine. Most teams keep HTML for existing content and write new content in Markdown.

Images: download media library files to your Firebase Storage bucket. Use the Firebase Storage URL as the new src in content. Don't rely on your old host serving images after you cut over DNS.

Step 2: Map your routes (this is where SEO is won or lost)

Every WordPress URL must resolve to an equivalent Next.js route with identical or canonical-redirected URL. The golden rule: preserve slug structure wherever possible.

Common mapping patterns:

• WordPress pages (/about/, /services/) → Next.js static routes at the same path. Create src/app/about/page.tsx, src/app/services/page.tsx, etc.
• WordPress posts (/2026/01/my-post-slug/ or /blog/my-post-slug/) → Infinity Press dynamic route. The src/app/blog/[slug]/page.tsx pattern with generateStaticParams serves these from Firestore at build time.
• Category archives (/category/news/) → a filtered view of the posts collection in Firestore.
• Date-based URLs → 301 redirect to the new slug-based URL. Date prefixes have no SEO value; clean slug is better.

Step 3: Import to Firestore

Infinity Press uses four Firestore collections for CMS content: pages, posts, categories, and settings/global.

A post document schema:

{
  "slug": "my-post-slug",
  "title": "My Post Title",
  "content": "<p>HTML content...</p>",
  "excerpt": "Short description",
  "status": "published",
  "categories": ["news", "products"],
  "featuredImage": "https://storage.googleapis.com/...",
  "publishedAt": "2026-06-01T00:00:00Z",
  "updatedAt": "2026-06-10T00:00:00Z",
  "seoTitle": "Custom SEO title",
  "seoDescription": "Meta description"
}

Step 4: Build and test the new site

With Infinity Press already deployed to Firebase Hosting, your new site is accessible at the Firebase default origin (*.web.app) before DNS cutover. Test everything there:

• Run your old sitemap URL list against the new site. Every URL should return 200 or 301 — never 404.
• Check Core Web Vitals with PageSpeed Insights on 5–10 of your most-trafficked pages.
• Verify canonical tags point to your new primary domain, not the *.web.app origin.
• Test the contact form, any Stripe payments, and authenticated flows end to end.
• Check that robots.txt allows indexing and that the sitemap URL resolves and contains all content.

Step 5: DNS cutover

The cutover is a two-step process: add the domain to Firebase Hosting, then update DNS at your registrar.

1. In Firebase Console, add your custom domain under Hosting → Add custom domain. Firebase gives you two A records and a TXT verification record.
2. At your DNS provider, add the Firebase A records. Keep TTL low (300s) for 24 hours before cutover so you can roll back quickly if needed.
3. After DNS propagates (~30 minutes to 1 hour for low TTL), Firebase automatically provisions an SSL certificate via Let's Encrypt.
4. Verify your domain resolves to the new Next.js app and SSL is active.
5. Remove or redirect the old WordPress host. Do not delete the server for 30 days — keep it as a rollback option.

Step 6: Post-migration SEO verification

File a Change of Address in Google Search Console within 48 hours of cutover. This signals that the old domain (or old hosting) is not the canonical authority — helpful if you changed from www. to bare domain, or from an old domain to a new one.

Submit your new sitemap at https://yourdomain.com/sitemap.xml. Infinity Press generates this dynamically from Firestore — it updates automatically as you publish new content.

Monitor these signals for 4–6 weeks post-cutover:

• Index coverage in GSC — all your old URLs should be indexed under the new host within 2–3 weeks.
• Core Web Vitals in GSC — should improve from the WordPress baseline.
• Organic traffic in GA4 — expect a brief dip (1–2 weeks) as Google re-crawls, then a return to baseline or better.
• 404 errors in GSC — catch any missed redirect mappings.

The done-for-you option

If you have a large content library (500+ posts), complex custom post types, WooCommerce, or a multi-site WordPress install, the migration requires more engineering than a straightforward blog-to-Firestore port. The edge cases compound fast: custom Gutenberg blocks, plugin-specific shortcodes, ACF field mappings, membership-gated content.

Our done-for-you migration service covers the full process at a flat fee starting at $4,997 — content export, Firestore import, route mapping, redirect implementation, DNS cutover, and a 4-week monitoring window post-launch. The average client recoups the migration cost in 8–14 months from hosting and maintenance savings alone.

Not sure if the math works for your setup? The WordPress True Cost Calculator will show you your current annual spend and what you would save on Infinity Press. Most teams are surprised how quickly the numbers add up.