Moving off WordPress: what to check before you migrate

The short answer: Before moving away from WordPress, list every URL and every plugin, and note the job each plugin does: forms, redirects, SEO titles, tracking. Each job needs a new home. Then map every old URL to its new page with a permanent redirect, export your content and form entries, agree who edits the new site, and re-crawl after launch.

Pinecone Agency is a Melbourne design and development agency that moves sites off WordPress to Webflow or custom Astro, and stores to Shopify, with every URL mapped first.

What did your plugins do, and where does each job go?

Go through Plugins > Installed Plugins and write down the job each active plugin does, not its name. Then give each job a home on the new site: a platform feature, an outside service, something built for the site, or nothing, if you no longer need it.

The jobs that cause trouble are the ones a plugin did quietly. Their data often lives in the plugin's own settings, so a crawl of your pages won't show it.

Also check caching, image optimisation, security, backups and translation plugins. Most of those jobs belong to the new host, but confirm it rather than assume. A shop or membership area is a project of its own.

How do you build a URL inventory and redirect map?

Pull URLs from several sources into one spreadsheet, and give every row a destination before the build starts. Google's site-move guide points to sitemaps, analytics, Search Console's Links report and server logs. Add a crawl of the live site and the Pages tab of Search Console's Performance report.

WordPress also makes URLs nobody created by hand: category, tag and author archives, paginated lists, attachment pages, feeds, and files under /wp-content/uploads/. They all belong in the sheet.

Use these columns: old URL, status code, clicks, linked from other sites, new URL, action (keep, redirect, merge or drop) and notes. Then follow Google's guidance:

• Redirect each old URL straight to its closest match with a server-side permanent redirect (301 or 308). If a chain is unavoidable, keep it to three hops or fewer.
• Where nothing replaces a page, return a 404 or 410 rather than sending it to the homepage.
• Keep the redirects for at least a year.

Check whether your current URLs end in a slash and pick one rule for the new site. And check the new host's defaults. Cloudflare's _redirects file, for example, uses a 302 (temporary) redirect unless you write 301 on the line.

How do you export WordPress content and custom fields?

Use Tools > Export. WordPress produces one XML file holding your posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies and users. That's the starting point for any CMS migration, whatever the destination.

For each content type, list its fields, what type each one is, whether it's required and which template uses it. Then decide what each becomes on the new site before anyone designs templates.

Two things don't come across in that file:

Media files. The export lists your media but doesn't contain the files. WordPress keeps uploads on the server, separate from the database, so download /wp-content/uploads from your host. Your crawl lists every image's alt text too, so you can carry it over and fix any that are empty.

Page-builder layouts. Pages built with Elementor-style builders store their layout as builder markup and shortcodes (text in square brackets). That markup only renders while the plugin runs. Elsewhere, you get raw code or broken layouts, so budget to rebuild those pages as templates and components.

Who should edit the site after moving away from WordPress?

Decide this before you choose a platform, because it decides the platform. A marketing team that edits pages visually needs something different from a store team managing products, or developers who make changes in code.

Write down who publishes today, how often, and what they change: blog posts, landing pages, prices, team bios. Then check each candidate platform against that list. We go through the trade-offs in choosing a CMS for the team that uses it.

Who controls the domain, DNS, hosting and logins?

Confirm who holds every account before anything changes. A move stalls quickly when nobody can log in to the domain registrar.

• Domain and DNS. Who owns the registrar account, and where is DNS managed? Note every record, especially email (MX, SPF, DKIM), so a DNS change doesn't break your inbox.
• Hosting. Who pays for it, and when does it renew? Keep it running until the new site is live and you've taken a full backup: the export file, the database and the uploads folder.
• Search Console and GA4. Who are the owners? Google's help says an HTML file or meta tag verification needs that file or tag on the site, so it can disappear with the old site. DNS verification on a domain property doesn't depend on the site.
• Tag Manager, ad accounts and form services. Make sure someone at your business, not only a past contractor, has admin access.

What should you check before and after launch?

Test the new site as if it were live, then run the same tests on the real domain.

Before:

• Crawl staging and compare titles, descriptions, H1s and schema with a crawl of the old site.
• Each new URL should carry a self-referencing canonical, Google says. Make sure it uses the live domain, not staging.
• Update links in your content to the new URLs rather than leaning on redirects.
• Prepare the live robots.txt and list every noindex to remove at launch.
• Run the full redirect list. This prints each old URL, its status and where it points:

xargs -n1 curl -s -o /dev/null -w "%{url_effective} %{http_code} %{redirect_url}\n" < old-urls.txt

Each line should match the action in your map: 301 or 308 for a redirect, 200 for a page you kept, and 404 or 410 for one you dropped. Then put the new URLs in a file and run the same line on it. Every one should return 200.

• Submit every form and check the email, CRM entry and tracking event arrive.
• Confirm the 404 page returns a real 404 status.

After:

• Rerun the redirect list on the live domain the day you switch.
• Submit the new sitemap in Search Console, plus a sitemap of the old URLs, as Google suggests, so you can watch the old ones drop out.
• Watch the Page indexing report for new Not found errors and fix each with a one-hop redirect.
• Compare key events and form submissions with the weeks before launch.
• Update links you control, such as Google Business Profile, social profiles and ad landing pages.

The website migration checklist

Copy this site migration checklist into your project tracker.

• List every active plugin, the job it did and where that job goes
• Export redirect plugin rules and stored form entries
• Export URLs from the sitemap, Search Console, GA4, a crawl and server logs
• Build the redirect map: old URL, status, clicks, links, new URL, action
• Run Tools > Export and list every content type and field
• Download /wp-content/uploads
• Flag page-builder pages to rebuild
• Agree who edits the new site
• Confirm who controls the domain, DNS, hosting, Search Console, GA4 and Tag Manager
• Crawl for titles, descriptions, H1s, canonicals, schema and alt text
• Pre-launch: crawl staging, test redirects, forms and tags, back up the old site
• Post-launch: rerun redirects, submit sitemaps, watch Page indexing and key events

Frequently asked questions

Sources

Checked 4 November 2026.

• W3Techs, Usage statistics and market share of WordPress (figure dated 3 November 2026)
• Google Search Central, How to move a site
• Google Search Central, Redirects and Google Search
• WordPress.org, Tools Export screen
• Cloudflare Docs, Redirects (Workers static assets)
• Search Console Help, Verify your site ownership

Moving off WordPress with Pinecone Agency

Pinecone Agency moves sites off WordPress to Webflow, to Shopify for stores, or to a custom Astro build on Cloudflare. We choose the platform with you on a discovery call, based on who edits the site and what it has to do.

Book a discovery call