Three years ago a client rang me on a Thursday afternoon in an absolute panic. They'd handed a Drupal-to-WordPress migration to a cheap dev shop, the site went live on a Friday, and by Monday their organic traffic had dropped 67%. Gone. Six years of SEO equity, just... evaporated. No redirects. Thousands of broken URLs. Google's crawl budget torched.
I've rebuilt that kind of wreckage more times than I care to count. After 12,000+ migrations atSeahawk Media, I can tell you with some confidence: the technical move from Drupal to WordPress is actually the easy part. The SEO preservation is where everything goes wrong — and where it absolutely doesn't have to.
This is the playbook I follow. Every time.
---
Why Drupal-to-WordPress Migrations Are an SEO Minefield
Drupal and WordPress generate URLs differently. Drupal's default path system, combined with modules like Pathauto, often produces URL structures that have zero overlap with what WordPress generates out of the box. A Drupal node at/content/our-services/web-designbecomes/our-services/web-designor even/web-designon WordPress, depending on how you set permalinks. Those are different URLs. Google sees them as different pages. Without a redirect, the old one is dead.
And it's not just URLs. Drupal's taxonomy system maps to WordPress categories and tags — but not perfectly. Custom content types in Drupal become Custom Post Types in WordPress, and if you don't build those CPTs before you migrate, your content lands in the wrong bucket entirely. I've seen a Drupal-powered news site where 800 "article" nodes all got imported as standard WordPress Posts, overwriting the custom archive structure that their internal linking relied on.
Here's the thing most devs miss:every structural decision you make in WordPress before the migration directly affects which redirects you'll need after it. Get the architecture right first. Redirects are a patch, not a plan.
---
Step 1: Pre-Migration Audit — Know What You're Moving Before You Move It
Don't touch the Drupal installation until you have a complete crawl of the live site. I useScreaming Frogset to crawl up to 500,000 URLs (the paid version). Export everything: URLs, status codes, title tags, meta descriptions, H1s, canonical tags, inbound internal links, word counts.
Also pull your Google Search Console data. Filter by clicks over the last 16 months (not 3, not 6 — 16, because you want to catch seasonal content). Export every URL that has received at least one click. These are yourprotected URLs. Lose rankings on any of these and the client will notice.
What I'm specifically looking for:
- Duplicate contentalready existing on the Drupal site (fix it before migrating, not after)
- Thin content pagesunder 200 words that rank for nothing — these can be consolidated or deleted rather than migrated
- Non-standard URL patternslike
/node/1234URLs that Drupal sometimes exposes even when Pathauto is active - Taxonomy archive pagesthat rank —
/tags/,/category/,/topic/paths that have actual Search Console impressions
That last one catches people out constantly. Drupal taxonomy term pages often rank for long-tail queries. If you don't recreate equivalent WordPress taxonomy archivesandredirect the old paths, you've just thrown away passive traffic.
---
Step 2: URL Mapping — The Spreadsheet Nobody Wants to Build
Boring? Yes. Non-negotiable? Also yes.
Build a URL map in Google Sheets (or Airtable if you prefer, I've used both). Column A is every Drupal URL. Column B is the corresponding WordPress URL it will resolve to. Column C is a status:exact match,redirect needed,consolidate, ordelete.
For a 300-page site, this takes half a day. For an 8,000-page site — which Seahawk handled for a higher-education client back in 2021 — it takes a team of three about four working days plus one very tedious Friday evening. Worth it every time.
A few rules I follow:
- Preserve slugs wherever possible.If Drupal has
/blog/how-to-fix-crawl-errors, make WordPress use the same slug. Most of the time you can. The permalink settings in WordPress Settings → Permalinks let you match whatever pattern Drupal was using. - Never redirect to the homepage.Lazy devs do this. It kills link equity and confuses users. Every old URL gets a specific destination.
- Watch out for paginated URLs.Drupal pagination looks like
?page=1. WordPress uses/page/2/. Map these or leave them as 404s (which is usually fine — paginated pages rarely hold meaningful link equity, but confirm in GSC first). - Document query strings separately.Things like
/search?keys=wordpressdon't need redirects./events?date=2023-06might, depending on whether those pages rank.
---
Step 3: Content Migration — FG Drupal to WordPress and What Actually Happens
TheFG Drupal to WordPressplugin does the heavy lifting for most migrations. It connects directly to your Drupal database, pulls nodes, users, taxonomy terms, and media. For Drupal 7, it works brilliantly. For Drupal 9/10, you'll need the premium version, which is about €99 last time I checked. Worth every penny versus manual migration.
What the plugin handles well:
- Node body content (including embedded images if you configure the media path correctly)
- Taxonomy terms mapped to WordPress categories/tags
- Basic custom fields if you're on the premium tier
What it won't handle and you'll need to fix manually:
- Drupal Views— these are custom page layouts/queries. You'll rebuild these in WordPress using plugins like WPGridBuilder or just custom WP_Query loops
- Webforms— map these to Gravity Forms or WPForms manually; the logic doesn't transfer
- Complex field groups— Drupal's Field API supports some genuinely weird data structures. You'll need to export these to CSV and import via WP All Import
- Block content regions— Drupal's block system is nothing like WordPress widgets/FSE blocks. Design decision, not a migration task
One thing I always do after FG Drupal to WordPress finishes: run a row count. How many nodes were in Drupal? How many posts/CPT entries are now in WordPress? They should match (minus anything you deliberately excluded). A 3% discrepancy on a 5,000-node site is 150 missing pages. Go find them.
---
Step 4: Implementing Redirects Without Destroying Your Server
Once the URL map is built and content is live on the WordPress staging environment, it's time for redirects. Two tools: theRedirection pluginfor smaller sites (under ~1,000 redirects) and.htaccessrules for anything larger on Apache, ornginx.confblocks on Nginx.
Why the split? The Redirection plugin processes redirects via PHP, which means a server hit for every redirect check. At 5,000 redirects with 50,000 daily pageviews, that's real overhead. Server-level redirects are faster by an order of magnitude.
For large migrations, I export the URL map from Google Sheets, write a quick script to generate theRewriteRuleblocks, and drop them into.htaccessbefore go-live. Takes 20 minutes. Saves hours of debugging a sluggish site post-launch.
One thing people don't think about:redirect chains. If Drupal already had redirects in place (many mature Drupal sites do, via the Redirect module), you need to find those and collapse the chain. A → B → C needs to become A → C.Google's own documentationis pretty clear that chains slow down PageRank transfer, even if they don't eliminate it.
---
Step 5: Post-Launch — The 72-Hour Window
Go live on a Tuesday or Wednesday. Never Friday. I learned this the hard way with a client in 2018 — we launched a 1,200-page migration on a Friday afternoon and discovered a misconfigured permalink structure at 6pm. By Monday, Google had already crawled and indexed a wave of broken URLs.
Here's what I monitor in the first 72 hours:
- GSC Coverage report— watch for a spike in 404s. Some are expected (old Drupal system paths). A spike across your money pages is not.
- Screaming Frog re-crawl— crawl the live WordPress site the morning after launch. Compare URL count to your pre-migration baseline.
- Redirect spot-checks— manually test your 20 highest-traffic Drupal URLs from GSC. Paste them into a browser. Do they land where they should?
- Canonical tags— confirm WordPress is outputting the right canonical on every page. Yoast and Rank Math both do this automatically, but check anyway.
- XML sitemap submission— submit the new sitemap in GSC immediately. Don't wait for Google to find it.
One thing I do that most people skip:submit the old Drupal XML sitemap in GSC as well, after launch, pointing at the old domain or subdomain if you kept it up temporarily. This tells Google exactly which old URLs to crawl, follow the redirects, and update its index faster.
---
Step 6: The 30-Day SEO Health Check
A migration isn't done at go-live. The index takes time to update. Here's what I look at at the 30-day mark:
- Ranking position changes— use Ahrefs or Semrush to compare keyword positions 30 days pre-migration vs. 30 days post. Expect minor fluctuation (5–10 positions) on some terms. A drop of 30+ positions on a primary keyword needs investigation.
- Backlink targets— if you had external backlinks pointing to specific Drupal URLs, check that those URLs are redirecting cleanly. Ahrefs' Lost Backlinks report surfaces this. Broken backlink targets are link equity you're actively haemorrhaging.
- Page speed regression— WordPress sites are sometimes slower than well-tuned Drupal sites. Run a Lighthouse audit on your 5 most important pages and compare to your pre-migration baseline.
- Indexation rate— how many of your submitted URLs are indexed? At 30 days, you want at least 80% of your main content pages indexed. Anything under 60% suggests a crawlability problem (check robots.txt and make sure you didn't accidentally block Googlebot in WordPress Settings → Reading).
Seahawk had a fintech client last year where the 30-day check revealed 340 product pages had accidentally been set tonoindexby a misconfigured Yoast bulk action during migration. Caught at 30 days: fixable in an afternoon. Caught at 6 months: probably a ranking hole you're still trying to fill.
---
FAQ
How long does a Drupal to WordPress migration actually take?
Depends entirely on site size and content complexity. A 50-page brochure site: 2–3 days including QA. A 5,000-page news archive with custom content types: 6–10 weeks. The SEO work — audit, URL mapping, redirect implementation, post-launch monitoring — typically adds 30–40% to whatever the core development estimate is. Don't let anyone tell you otherwise.
Will I lose rankings after migrating from Drupal to WordPress?
Short-term fluctuation is normal and almost inevitable. If you've done the URL mapping, redirects, and canonical tags correctly, most rankings stabilise within 6–12 weeks. The sites I've seen suffer permanent losses all had the same problem: either no redirects, or mass redirects pointing to the homepage. Do the work. The rankings come back.
Should I migrate all Drupal content or start fresh?
Depends on what the content is doing for you. Pull your GSC data. Any content with zero clicks over 16 months and no backlinks is a candidate for deletion rather than migration. Migrating thin, low-value content bloats your WordPress site and can dilute crawl budget. Be ruthless. That said, never delete a URL that has any external backlinks, even if the page itself is rubbish — redirect it to something relevant.
What's the best WordPress theme to use after a Drupal migration?
Honestly, the theme choice has almost no SEO impact if you're using well-structured HTML and keeping page speed in check. I default toGeneratePressfor its clean markup and minimal overhead, or Kadence if the client wants more design flexibility. Avoid page-builder-heavy themes that output 400KB of unused CSS on every page load.
Do I need a developer or can I do this myself?
For a small site under 50 pages with simple content and no custom post types? You can probably manage with FG Drupal to WordPress and the Redirection plugin, following the steps above. For anything larger, or anything with CPTs, complex taxonomies, or a meaningful existing SEO footprint — get a developer. The cost of fixing a botched migration is always higher than the cost of doing it properly the first time.
---
The migration itself is maybe 40% of the job. The other 60% is the SEO infrastructure you build around it — the mapping, the redirects, the monitoring, the patience to watch the data for 30 days before declaring victory. I've seen beautifully built WordPress sites tank in search because the redirect work was sloppy, and I've seen scrappy, barely-themed WordPress installs hold every ranking because the URL map was meticulous.
Get the boring stuff right. The rest tends to follow.