How to migrate Drupal to WordPress without losing SEO

01What moves cleanly and what breaks

Unlike a hosted builder, Drupal doesn't lock you in. It's open-source software running on a database you control, so your articles, fields, and taxonomies can genuinely be exported and re-imported. That makes a Drupal-to-WordPress move a true migration rather than a from-scratch rebuild.

But "can be exported" is not the same as "transfers perfectly." Drupal and WordPress model content differently. The honest picture is that your text and media come across well, while your structure and theme need deliberate re-mapping. Knowing which is which up front is what keeps the project calm.

Read that table as a workload, not a warning. The rows that move cleanly are the bulk of your content; the rows that break are predictable and have known fixes. Nothing here is a surprise if you plan for it before you touch the live site.

02Pre-flight checklist before you touch anything

Before any migration tool runs, spend an hour taking inventory. Drupal sites tend to accumulate content types and modules over the years, and you want a clear picture of what you actually have before you decide what comes across.

Inventory and back up first

• Take a full backup of the Drupal database and files directory, and confirm you can restore it. Never migrate off your only copy.
• List every content type and field in Drupal admin so you know exactly what needs a home in WordPress.
• Export your URL list with a crawler so you can see every path alias before you change anything.
• Note your traffic and backlink pages from Search Console and analytics — these are the URLs that must redirect.
• Record your current Drupal version, since the available migration tools differ between Drupal 7 and newer releases.

This inventory becomes your map for the whole project. Skip it and you'll discover a forgotten content type halfway through, after you've already designed the WordPress side around the wrong assumptions.

03The step-by-step on a staging copy

Do all of this on a staging site — a private copy nobody but you can see — and only repoint your domain when everything works there. Here's the sequence that keeps the live Drupal site untouched until the very end.

• Stand up fresh WordPress on your new host and install it on a staging subdomain or environment.
• Choose a theme that matches your Drupal site's structure — header, menu, content area — rather than chasing a pixel clone.
• Run a content migration tool (FG Drupal to WordPress is the common one) to import nodes, taxonomies, and media.
• Map content types to WordPress post types and fields, deciding what becomes a post, a page, or a custom type.
• Set your permalink structure under Settings, Permalinks before you build redirects, so URLs stop shifting.
• Build the URL map and 301 redirects for every old Drupal path, covering /node/ aliases and taxonomy paths.
• Rebuild SEO fields — titles, descriptions, sitemap — with an SEO plugin, then test the whole site before going live.

The two steps people rush are mapping content types and setting redirects. The first decides whether your site makes sense in WordPress; the second decides whether Google notices the move. Each gets its own section below.

04Mapping content types and migrating the content

This is where Drupal sites differ most from a simple blog. Drupal lets you build arbitrary content types with custom fields — a "Recipe" type, an "Event" type, a "Staff Profile" type. WordPress's default world is posts and pages, so you have to decide how each Drupal type lands.

A migration plugin like FG Drupal to WordPress reads your Drupal database directly and pulls nodes, taxonomies, users, and media into WordPress. It does the heavy lifting of getting content across, but it works from your mapping decisions — so make those decisions deliberately before you run it.

How to map Drupal content into WordPress

• Articles and basic pages map naturally to WordPress posts and pages — that covers most of a typical site.
• Custom content types become either WordPress custom post types or pages with extra fields via a fields plugin like ACF.
• Drupal taxonomies become WordPress categories and tags; decide which vocabulary maps to which before import.
• Check media after import, because Drupal stores files differently and the importer can leave broken image links to fix.

Run the import on staging, then spot-check a sample of each content type by hand. The importer is good but not flawless, and the patterns of what it misses tend to repeat — fix one Recipe and you'll know how to fix them all.

05Preserving SEO: URLs, redirects, and canonicals

This is the step that protects your search traffic, and it's the one most likely to go wrong. Drupal's URLs — whether clean path aliases or raw /node/123 paths — almost never match WordPress's defaults. Recreate the site without a plan and those addresses break.

The fix is a URL map built before you change anything: every old Drupal path paired with its new WordPress address. Once the domain points at WordPress, any old URL without a redirect becomes a dead page that bleeds the rankings and backlinks that path had earned.

Lock down your URLs and redirects

• Try to match WordPress permalinks to your Drupal path aliases where you can, which shrinks the redirect list you have to build.
• Set a 301 (permanent) redirect for every path that does change, pointing each to its closest match — never blanket-redirect to the homepage.
• Cover the /node/ID paths explicitly if your Drupal site exposed them, since those rarely survive a migration untouched.
• Confirm canonicals point to the new WordPress URLs, so you don't leave Drupal canonicals quietly telling Google the old address is authoritative.

Drupal's SEO settings don't travel either, so budget time to re-enter titles and descriptions for your important pages with an SEO plugin like Yoast or Rank Math. It's manual, but it's the difference between a move Google barely registers and one that costs months of recovery.

06The tools that help

You don't have to do all of this by hand, and you shouldn't. A few tools take the worst of the manual work off your plate — just keep your expectations honest about what each one actually does.

• A Drupal-to-WordPress migration plugin (FG Drupal to WordPress is the established one) reads your Drupal database and imports nodes, taxonomies, and media.
• A site crawler (Screaming Frog's free tier) lists every Drupal URL so nothing slips through the redirect net.
• A redirect plugin (Redirection, or your SEO plugin's manager) turns your URL map into live 301s without editing server config.
• An SEO plugin (Yoast or Rank Math) rebuilds the titles, descriptions, and sitemap your Drupal modules won't export.
• A custom fields plugin (ACF) gives your Drupal custom fields a home when posts and pages aren't enough.

Staging is worth singling out. A staging site is a private copy where you run the import, set redirects, and test the whole site before any visitor sees it. You verify everything there, then push live in one move — turning a nerve-wracking switchover into a calm one.

07Common pitfalls

Most failed Drupal migrations fail in the same few places. None of them are mysterious, and all of them are avoidable if you know to watch for them before launch day.

• Skipping the redirect map is the big one — the migration looks fine, then traffic quietly drops over the following weeks as old URLs 404.
• Forgetting a content type because it wasn't in your inventory, leaving a whole category of pages stranded on the old site.
• Broken images from Drupal's file paths that the importer didn't rewrite — always check media after import, not after launch.
• Leaving Drupal canonicals in place so Google keeps treating the old URL as authoritative even after the redirect.
• Repointing the domain before testing, which exposes every unfinished step to real visitors instead of catching it on staging.

Walk this list before you go live and almost every common failure is caught on staging, where it's a quiet fix rather than a public outage.

08A note on hosting

Drupal often ran on hosting you chose deliberately, so you likely already value control — and you should carry that instinct into WordPress. Pick a host that gives you a real staging environment, because testing this migration privately is what makes it safe.

Cloudways is one option worth knowing here: it's managed cloud hosting with free staging built in, so you can clone your new WordPress site, run the import and redirects on the copy, and only push live once everything checks out. It's not the only host that does this, but free staging is the feature that actually matters for a migration — so weigh any host on that.

Whatever you choose, the principle from leaving Drupal still holds: favor hosting you can leave on your own terms. The whole point of staying on open software is that you're never locked to one provider, so don't trade one lock-in for another.

09FAQ

Is there a tool to migrate Drupal to WordPress automatically?

Partly. Plugins like FG Drupal to WordPress read your Drupal database and import nodes, taxonomies, and media into WordPress, which is far more than a closed builder allows. But they work from your content-type mapping and they don't move your theme, so expect to make decisions and check the results rather than press one button.

Will migrating from Drupal to WordPress hurt my rankings?

Only if you change URLs without redirecting them. Drupal and WordPress use different URL structures, so the risk is real if you skip the map and the 301s. Map every old path, redirect each one, keep the content intact, and confirm canonicals point to the new URLs — most sites then see no lasting drop.

What happens to my Drupal custom content types?

They don't have a built-in equivalent, so you map them. Simple types become WordPress posts or pages; richer ones become custom post types or pages with extra fields via a plugin like ACF. Decide the mapping before you run the import, because the importer follows your plan rather than guessing for you.

Do I need a developer to move off Drupal?

Not always. A straightforward content site can be moved with a migration plugin and a redirect plugin — filling boxes, not writing code. A large site with many custom types, or complex Drupal modules, is where a developer or your host's migration team earns their fee. Match the help to the complexity.

This is general, experience-based guidance from running a theme shop, not financial or professional advice for your specific site, and the tools named here change over time — verify current behavior with each vendor before you rely on it. When a site carries real revenue or traffic you can't afford to lose, treat that as the signal to bring in a professional or your host's migration team.