Preserving Your SEO During a Drupal to WordPress Migration

04 November 2025

SEO is consistently the number one concern for site owners considering a Drupal to WordPress migration, and rightly so. Years of ranking authority, backlinks, and organic traffic are at stake. The good news is that with proper planning, your search rankings can survive the transition intact. The key is understanding exactly where the risks are and addressing each one systematically before launch.

Why Migration Puts Your SEO at Risk

Search engines index your site based on URLs, content structure, and metadata. A platform migration touches all three. When Google crawls your site after launch and finds different URLs, missing pages, or changed metadata, it needs to re-evaluate your content. That re-evaluation doesn't always go in your favour.

The specific risks fall into four categories:

URL changes. Drupal and WordPress generate URLs differently. Without proper redirect mapping, every changed URL becomes a dead link in Google's index.
Missing metadata. Meta titles, descriptions, and Open Graph data stored in Drupal modules don't transfer automatically.
Taxonomy page loss. Drupal's vocabulary listing pages may drive significant traffic. If those pages disappear after migration, that traffic goes with them.
Broken internal links. Links embedded in content that point to old URL structures will return 404 errors.

URL Structure: The Critical Difference

This is where most SEO damage occurs in Drupal to WordPress migrations. The two platforms handle URLs in fundamentally different ways.

How Drupal Handles URLs

Drupal stores URL aliases in the url_alias (Drupal 7) database table, separate from the content itself. Each node can have multiple aliases: /about-us, /about, and /node/28 can all point to the same page. Aliases support forward slashes, allowing deep path structures like /services/migration/drupal-to-wordpress. The character limit is 255.

How WordPress Handles URLs

WordPress stores a single slug in the post_name field within wp_posts. URLs are generated dynamically using rewrite rules based on your permalink settings. Slugs cannot contain forward slashes or quotation marks, and WordPress converts accented characters to their ASCII equivalents. The character limit is 200. Unlike Drupal, WordPress has no mechanism for storing multiple URL variations per page.

What This Means for Your Migration

Any Drupal alias that contains forward slashes, exceeds 200 characters, or includes special characters can't be replicated directly in WordPress. Each of these cases needs a 301 redirect from the old URL to the new one. For sites with hundreds or thousands of URL aliases, this mapping exercise is a significant piece of work, but it's non-negotiable if you want to preserve your rankings.

Building Your Redirect Map

The redirect map is the single most important SEO deliverable in any migration. It's a complete list that pairs every old Drupal URL with its new WordPress equivalent.

Export all Drupal URL aliases: pull the complete URL alias table, including any /node/NID paths that may be indexed
Map each alias to its WordPress URL: based on your chosen permalink structure and any slug changes
Include taxonomy pages: Drupal vocabulary listing pages (/categories/topic-name) need redirects to their WordPress equivalents
Handle user pages and views: if your Drupal site has indexed user profiles or Views-generated pages, these need redirects too
Implement as server-level redirects: .htaccess rules (Apache) or nginx rewrite rules are faster and more reliable than plugin-based redirects

I implement redirects at the server level rather than through WordPress plugins. Server-level redirects execute before WordPress even loads, which means faster response times and no dependency on a plugin that might be deactivated or conflict with an update.

Meta Data Migration

Drupal sites typically store meta titles, descriptions, and Open Graph data through the Metatag module. This data lives in dedicated database tables, separate from node content. WordPress SEO plugins (Yoast, Rank Math, SEOPress) store equivalent data as key-value pairs in the wp_postmeta table.

The migration involves exporting Drupal's metatag records and converting them into the format expected by your chosen WordPress SEO plugin. This isn't something automated migration tools handle, because each SEO plugin uses its own meta key naming convention.

For high-value pages, I recommend a manual review of meta titles and descriptions during migration. A platform change is a good opportunity to tighten up metadata that's been neglected. However, wholesale rewrites should wait until after migration, once you've confirmed your baseline rankings are stable.

Taxonomy Pages and Listing Pages

Drupal's taxonomy system is more flexible than WordPress's default categories and tags. Drupal supports multiple vocabularies with custom fields, and each vocabulary can generate listing pages that rank independently in search results.

Before migration, audit your analytics for taxonomy pages that drive meaningful traffic. These need explicit handling:

Vocabulary-to-taxonomy mapping. Decide which Drupal vocabularies become WordPress categories, tags, or custom taxonomies.
Listing page URLs. Drupal's /taxonomy/term/NID and friendly alias paths need redirects to the equivalent WordPress archive pages.
Custom taxonomy templates. If your Drupal taxonomy pages have custom layouts or additional content, you may need custom WordPress archive templates to replicate them.

What Gets Preserved Automatically

Not everything requires special handling. Several SEO elements transfer naturally because they're embedded in your content:

Heading structure. H1, H2, H3 tags within your content body come across as-is.
Image filenames and alt text. These are stored within the content HTML and transfer with the content.
Internal link structure. Links within content bodies migrate with the text, though the target URLs may need updating to match the new structure.
Content freshness signals. Publication dates can be preserved during migration, maintaining your content's age signals.

Common SEO Pitfalls

These are the issues I see most often in migrations that weren't properly planned:

Forgetting the "Discourage search engines" checkbox. WordPress has a setting under Settings > Reading that tells search engines not to index the site. It's often enabled during development and forgotten at launch. One checkbox can undo all your SEO work.
Changing permalink structure after launch. Pick your WordPress permalink structure before migration and don't change it afterwards. Every change invalidates your redirect map.
Ignoring pagination. If your Drupal site has paginated listing pages that are indexed, those ?page=2 URLs need handling too.
Skipping the XML sitemap. Submit a new sitemap to Google Search Console immediately after launch. This accelerates re-crawling and helps Google discover your new URL structure.
Not monitoring post-launch. The first 4-6 weeks after migration are critical. Monitor Google Search Console for crawl errors, indexing drops, and 404 spikes. Address issues immediately. Delays compound the damage.

When to Invest in SEO Preservation

The level of SEO work depends on your site's organic traffic value. A brochure site with minimal search traffic needs basic redirect mapping and not much more. A content-heavy site with thousands of indexed pages and significant organic traffic justifies a thorough audit, complete redirect map, and post-launch monitoring programme.

I assess this during the initial content audit and provide a recommendation based on your site's actual traffic profile. There's no point over-investing in SEO preservation for pages that don't drive business value, and equally, no point cutting corners on pages that do.

Related reading:

Concerned About Losing Your Search Rankings?

I build SEO preservation into every migration: URL mapping, 301 redirects, metadata transfer, and post-launch monitoring. Get a free consultation to discuss your site's SEO requirements.

Get a Free Quote