Drupal to WordPress Migration: What to Move, Fix, and Protect

A Drupal to WordPress migration is rarely just a content export. You’re moving page structure, URLs, metadata, media files, menus, redirects, forms, search visibility, and years of editorial decisions into a new content management system.

The specific angle here is practical: what should move, what should be rebuilt, and what must be protected so the switch from Drupal to WordPress does not create broken pages, missing images, traffic drops, or a messy WordPress admin that is hard to manage after launch.

Key Takeaways

• A clean migration starts with a Drupal content audit, not a WordPress import.
• Custom Drupal content types need careful mapping to WordPress post types, pages, taxonomies, and custom fields.
• SEO protection depends on URL mapping, 301 redirects, metadata transfer, internal link cleanup, and post-launch monitoring.
• Old Drupal pages should not all be moved automatically. Some should be merged, redirected, rewritten, or removed.
• The best migration process uses staging, backups, crawl comparisons, and a launch checklist instead of changing everything live.

Why Drupal to WordPress Migration Needs More Than an Import Tool

Drupal and WordPress organize content differently. Drupal often uses content types, views, blocks, taxonomy vocabularies, custom fields, and contributed modules to control how content appears. WordPress uses posts, pages, custom post types, taxonomies, templates, plugins, and theme files.

That difference matters. When you migrate Drupal to WordPress, the visible page content is only one layer. The real work is translating Drupal’s structure into a WordPress setup that is easier for your team to use without losing the logic that made the old site work.

Drupal’s own Migrate API documentation describes migration as moving data from a source system into destination structures, which is the right way to think about this project. You’re not copying pages one by one. You’re mapping source fields, relationships, files, and URLs into a new system that behaves differently. Drupal’s Migrate API overview is useful background for understanding why structured content needs planning before it is moved.

A small business site with 40 mostly static pages might be straightforward. A Drupal site with hundreds of resources, staff profiles, location pages, blogs, downloadable PDFs, and custom landing pages needs a more controlled process. That is where many CMS migration to WordPress projects go wrong.

The mistake is treating “content imported” as “migration complete.” It isn’t. A migration is complete when old URLs resolve correctly, important content is preserved, editors can manage the new site, search engines can crawl the new structure, and users can complete the same actions they could before.

What to Move From Drupal to WordPress

Start with a full inventory. Crawl the Drupal site using Screaming Frog, Sitebulb, Ahrefs Site Audit, or a similar tool. Export every indexable URL, title tag, meta description, canonical tag, status code, word count, H1, internal links, image URLs, and PDF file path.

Then compare that crawl with Drupal’s admin exports. Crawlers only see what is public. Drupal may also contain unpublished pages, archived content, media library items, old redirects, and content that is still useful but no longer linked from the menu.

For most Drupal website migration projects, the inventory should include:

Drupal item	WordPress destination	Notes
Basic pages	WordPress pages	Keep only pages with current business value or search value.
Blog posts or articles	WordPress posts	Preserve publish dates, authors, categories, tags, and featured images.
Custom content types	Custom post types or pages	Use custom post types for repeatable content like team members, resources, locations, or case studies.
Taxonomy vocabularies	Categories, tags, or custom taxonomies	Avoid dumping every Drupal vocabulary into WordPress tags. Map based on how users browse.
Media library files	WordPress Media Library	Preserve filenames where practical, but clean duplicates and unused files.
Menus	WordPress navigation menus	Rebuild intentionally instead of importing every old menu item.
Blocks and views	Theme sections, blocks, templates, or plugins	Recreate layout logic rather than forcing Drupal structures into WordPress.
Webforms	WordPress form plugin	Rebuild forms and test notification routing, spam protection, and CRM connections.
Redirects	Server-level or plugin-managed 301 redirects	Build a redirect map before launch.
SEO metadata	SEO plugin fields	Transfer titles, descriptions, canonical rules, Open Graph data, and noindex settings.

The most useful working document is a content mapping spreadsheet. Add one row per URL and include these fields:

Old Drupal URL

New WordPress URL

Content type

Migration action

Redirect target

Title tag

Meta description

H1

Canonical

Priority

Owner

QA status

For the “migration action” column, use clear labels: move, rewrite, merge, redirect, remove, or rebuild. This prevents the common problem where every old Drupal page gets pushed into WordPress even though some pages are outdated, duplicated, or no longer useful.

A practical example: an old Drupal site may have five separate pages about “support,” each created by a different team over several years. One might be linked from the footer. One might rank in Google. One might be an outdated campaign page. Moving all five into WordPress creates duplication. A better plan is to choose the strongest page, rewrite it into one current support page, and redirect the weaker URLs into it.

What to Fix Before the Migration

The move from Drupal to WordPress is a good time to clean the site, but it is a bad time to make every possible change at once. Separate migration-critical fixes from nice-to-have redesign work.

Migration-critical fixes are problems that will create broken pages, SEO loss, editor confusion, or security risk if ignored. These should be handled before or during the move.

One of the first fixes is URL structure. Drupal sites often have URLs shaped by aliases, content type paths, or old campaign structures. WordPress can support clean URLs, but you need to decide whether to preserve the current paths or simplify them.

Preserving URLs is usually safer when the page already ranks or has backlinks. Changing URLs may still make sense when the current structure is messy, but only if every old URL has a precise redirect target.

The second fix is content duplication. Drupal sites often accumulate near-duplicate pages after years of edits, campaign launches, department requests, and SEO experiments. If you migrate website to WordPress without cleaning those duplicates, WordPress inherits the same problem.

The third fix is media clutter. Many Drupal sites contain years of unused PDFs, resized images, icons, and duplicate uploads. Do not migrate every file blindly. Export the media list, identify files used on live pages, and flag anything that should be archived.

The fourth fix is form handling. Drupal Webform setups can include conditional fields, email routing, confirmation messages, hidden tracking fields, and integrations. Rebuild these in WordPress before launch and test them with real submissions.

Tools that are often useful during this stage include:

• Screaming Frog or Sitebulb for crawling old and staging sites.
• Google Search Console for identifying pages with impressions, clicks, indexing issues, and external links.
• Ahrefs, Semrush, or Majestic for backlink discovery.
• WP All Import, WP-CLI, or custom scripts for structured imports.
• Advanced Custom Fields or custom post types for Drupal-style structured content.
• Redirection, Rank Math, Yoast SEO, or server-level rules for redirects and SEO metadata.

If the new WordPress site is also being redesigned, keep the migration map separate from the design brief. Design decisions should not erase important URLs, metadata, or content relationships by accident.

For businesses planning a broader rebuild, a structured development process helps keep migration, design, and launch tasks from blending together. This is where professional WordPress development services can be useful, especially when Drupal content types need to become custom post types, reusable blocks, or editor-friendly page templates.

How to Protect SEO During a Drupal to WordPress Migration

A Drupal to WordPress SEO migration has one main goal: make the new WordPress site easy for Google and users to understand after the switch.

Google’s site move documentation explains that URL changes can affect search visibility and should be handled carefully with redirects, sitemap updates, and monitoring. Google Search Central’s site move guidance is the reference to follow when URLs change during a website migration to WordPress.

The redirect map is the most important SEO asset in the project. Every valuable old URL should point to the most relevant new URL. Do not redirect everything to the homepage. That creates a poor user experience and gives search engines a weak relevance signal.

Use this redirect logic:

Old page situation	Best action
Same content, same intent	Redirect to the equivalent WordPress URL.
Same topic, improved page	Redirect to the updated WordPress version.
Duplicate or thin page	Merge into the strongest related page, then redirect.
Expired campaign page with no replacement	Redirect to the closest useful parent page.
Deleted page with no useful replacement	Consider a 410 only if the page has no search or user value.
PDF replaced by HTML page	Redirect the PDF URL to the new HTML resource if it serves the same purpose.

Permanent redirects should be used when the move is final. Google’s redirect documentation states that a 301 or 308 permanent redirect signals that the destination should be treated as the canonical target. Google’s redirect documentation is clear on using permanent redirects when the change will not be reverted.

SEO metadata also needs attention. Export Drupal title tags, meta descriptions, canonical tags, robots directives, Open Graph images, and schema where available. Then decide what should be migrated as-is and what should be rewritten.

Do not preserve bad metadata just because it exists. If an old Drupal page has a stuffed title tag or duplicated meta description, fix it during the move. If a page already ranks well, be more conservative. Change the CMS first, then adjust copy and metadata later if needed.

Internal links are another common issue. After import, many WordPress pages may still link to old Drupal paths. Run a staging crawl and export all internal links that still point to the old URL pattern. Replace them before launch so users and crawlers do not rely on redirects inside your own site.

XML sitemaps should be regenerated from WordPress after launch. Submit the new sitemap in Google Search Console. Keep the old crawl export so you can compare expected URLs against the live WordPress sitemap.

A Practical WordPress Migration Checklist

A WordPress migration checklist should be specific enough that a developer, SEO editor, and project manager can work from the same document. Generic checklist items like “move content” and “check SEO” are not enough.

Use this sequence for a controlled Drupal to WordPress migration.

1. Crawl and export the current Drupal site

Crawl the live Drupal site before any work starts. Save the crawl export and do not overwrite it. This becomes your baseline.

Export these items at minimum:

URL

Status code

Indexability

Title tag

Meta description

H1

Canonical URL

Word count

Inlinks

Outlinks

Images

PDF links

Structured data

Redirect chains

Then export content directly from Drupal where possible. For custom content types, include field names, field values, taxonomy terms, author IDs, publish dates, and media references.

2. Decide the WordPress content model

Do not import Drupal content until WordPress has a clean content model.

A common mapping might look like this:

Drupal Article → WordPress Post

Drupal Basic Page → WordPress Page

Drupal Staff Profile → Custom Post Type: Team

Drupal Resource → Custom Post Type: Resources

Drupal Location → Custom Post Type: Locations

Drupal Category Vocabulary → WordPress Categories

Drupal Audience Vocabulary → Custom Taxonomy: Audience

WordPress can expose and manage posts, pages, taxonomies, media, and other content types through REST endpoints, which is helpful when building custom import workflows or validating migrated data. The WordPress REST API handbook explains how WordPress represents content through endpoints that can be queried, created, or updated.

3. Build the WordPress staging site

Build everything on staging first. The staging site should be blocked from indexing using appropriate controls, such as password protection or server-level restrictions. Do not rely only on a noindex setting if the staging site contains sensitive content.

Install and configure the theme, required plugins, custom post types, fields, forms, menus, SEO plugin, caching setup, and security tools before importing final content.

4. Import content in batches

Do not import everything at once unless the site is small. Start with one content type, such as blog posts, then verify the output before importing the next type.

Check:

• Are titles and body content correct?
• Did images attach properly?
• Are publish dates preserved?
• Are authors mapped correctly?
• Are categories and tags clean?
• Did special characters, tables, embeds, and buttons survive the import?
• Are internal links still pointing to Drupal URLs?
• Are custom fields showing in the right templates?

For large imports, use batch logs. A simple import log should include content ID, old URL, new URL, import status, media status, and errors. This makes it easier to fix failures without guessing.

5. Rebuild forms, menus, and interactive elements

Forms need manual quality assurance. Submit every important form on staging and confirm the result.

Test:

• Admin notification emails.
• User confirmation emails.
• Required fields.
• Conditional logic.
• Spam protection.
• CRM or email marketing integrations.
• Thank-you pages.
• Conversion tracking.

Menus should also be rebuilt, not blindly copied. A migration is a chance to remove dead navigation items and make the new WordPress site easier to use.

6. Add redirects and crawl staging

Upload the redirect map and test it before launch. On staging, redirects may need temporary host-file testing or launch simulation depending on the server setup.

Run a staging crawl and compare it against the Drupal baseline. Look for missing pages, accidental noindex tags, broken links, redirect chains, 404 errors, missing titles, duplicated H1s, and thin pages that should not be indexed.

7. Launch during a low-risk window

Launch when the right people are available to fix issues. Avoid launching late on a Friday unless your team is prepared to monitor the site over the weekend.

At launch, confirm:

• DNS points to the correct server.
• SSL is active.
• WordPress is no longer blocked from indexing.
• Redirects work on the live domain.
• The XML sitemap is live.
• Analytics and conversion tracking are active.
• Forms send correctly.
• Caching and performance settings are enabled.
• Backups are running.

If you are also moving hosting after the CMS migration, treat that as a separate risk layer. A host move has its own DNS, backup, and server checks. This guide to moving a WordPress site to another host is a better fit when the CMS is already WordPress and the main concern is hosting infrastructure.

What to Test After Launch

Post-launch testing should happen in the first hour, first day, first week, and first month. Search engines and users will not find every issue immediately, so you need a monitoring window.

In the first hour, test core user paths. Visit the homepage, top service pages, top traffic pages, contact forms, search, navigation menus, and high-value landing pages. Confirm that important Drupal URLs redirect to the right WordPress pages.

In the first day, crawl the live WordPress site. Compare the crawl with the staging crawl and the original Drupal crawl. Watch for accidental differences caused by launch settings, caching, plugin conflicts, or server rules.

In the first week, monitor Google Search Console. Look at indexing, crawl errors, sitemap processing, and page experience signals. Expect some fluctuation, especially if URLs changed. The goal is not to avoid every movement. The goal is to catch preventable problems early.

In the first month, review organic landing pages and conversions. Compare traffic by page group, not just total traffic. For example, blog posts may behave differently from service pages, resource pages, or location pages.

A good post-launch migration report should include:

Check	Tool	What to look for
Redirect validation	Screaming Frog, redirect checker, server logs	Old URLs return 301 and land on relevant new URLs.
Indexing	Google Search Console	New WordPress URLs are discovered and submitted sitemap is processed.
Broken links	Screaming Frog, Ahrefs, Sitebulb	Internal 404s, missing images, broken PDFs, and old Drupal links are fixed.
Metadata	SEO plugin crawl export	Titles, descriptions, canonicals, and robots directives are correct.
Performance	PageSpeed Insights, GTmetrix, WebPageTest	Templates, images, scripts, and caching are not slowing key pages.
Forms	Manual testing, CRM logs	Leads reach the right inbox, CRM, or automation tool.
Backups and updates	Hosting panel, backup plugin, maintenance logs	The new WordPress site can be restored if something breaks.

Post-launch maintenance matters because the migration does not end when the new site appears online. WordPress needs updates, backups, monitoring, security checks, and performance reviews. If your team does not want to manage that internally, a managed website maintenance service can keep the new site stable after the Drupal system is retired.

Conclusion

The safest Drupal to WordPress migration is the one that starts with decisions, not imports. Audit the Drupal site, map what each page becomes, rebuild the right structures in WordPress, protect valuable URLs with redirects, and test the new site before and after launch.

A clean migration should leave you with more than a WordPress version of the old site. It should leave you with a simpler, faster, easier-to-manage website that keeps the content and search value worth protecting.

FAQs