SEO Migration from Drupal

What this means for your team

A Drupal migration is a rebuild, and every rebuild carries SEO risk. The risk concentrates in three places: missing redirects, metadata lost in the content scripts, and staging settings left on at launch. Plan the SEO steps into the project from the start: the inventory and redirect map belong in the first sprint, and someone on your team should own Search Console for the first month after launch.

On Pagepro’s Nexity process, the first four weeks deliver a production-ready foundation, with content migrated, redirects in place and editors trained; Drupal estates with many languages and integrations take longer, as the timeline section of the Drupal to headless CMS guide shows.

Learn Squared, the e-learning platform Pagepro moved off Drupal 7 to Next.js, described what the move did for its team.

We’ve absolutely seen an increase in development velocity with the Pagepro team, through initial development and even into the initial weeks of our first SLA… the turnaround time from ideation to feature launch has been a marked improvement upon our previous development solution.

Andrew Hawryluk, Co-founder, Learn Squared

SEO migration from Drupal checklist

A Drupal SEO migration checklist keeps the SEO work in the right order while developers rebuild the site. Each step below has its own section. For choosing the target platform, the frontend stack and the project timeline, see the guide to migration from Drupal to a headless CMS; this article covers how to keep your rankings through that move.

1. Benchmark: Record traffic, rankings, indexed pages and Core Web Vitals before anything changes.
2. Inventory: Export every URL, path alias, existing redirect, Metatag value and hreflang tag from Drupal.
3. Map content: Decide where each content type, field and taxonomy term lives on the new platform, including its SEO fields.
4. Map redirects: Pair every old URL with its new address in a redirect spreadsheet.
5. Migrate SEO data: Make the migration scripts carry titles, descriptions, canonicals, alt text and structured data.
6. Test staging: Crawl the staging site, test every redirect and check performance and accessibility.
7. Launch: Switch over, run smoke tests in the first 24 hours and submit the new sitemap.
8. Monitor: Review Search Console daily and fix errors as they appear.

Pagepro runs this checklist on Nexity, its own Next.js and Sanity framework for migrations, built from 20+ real projects with zero drops in Google rankings across all of them.

Benchmark traffic and rankings

Before you move away from Drupal, record a baseline of organic traffic and keyword positions. You need to know exactly where your organic traffic comes from if you want to protect it, and with a pre-launch snapshot your team can spot a dip in days rather than months.

• Top-performing pages: List every URL that drives high session volume and note its conversion rate, so you can review these pages first on staging and at launch.
• High-ranking keywords: Log your current positions in a rank tracker, which makes it easier to trace visibility changes after the move.
• Inbound backlinks: Document which Drupal URLs attract external links, so the redirect map protects that authority.
• Indexed pages and Core Web Vitals: Note the number of indexed pages in Search Console and the current Core Web Vitals, so you can compare like for like after launch.

Without these benchmarks, diagnosing a post-migration traffic drop turns into guesswork.

Collect URLs, aliases and metadata from Drupal

Crawl the existing Drupal site to list every indexable URL with its status code, canonical tag and metadata, then export the data Drupal holds behind those pages. A crawl alone misses part of the picture: it finds the aliases that are still linked, but not the /node/ system paths, old redirects or pages nothing links to anymore.

• Path aliases: Export every alias, including those Pathauto generated from patterns, so each /node/123 path is paired with the address visitors and search engines actually use.
• Existing redirects: Export the entries stored by the Redirect module. Old redirects have to point to the new final addresses too, or they turn into chains after launch.
• Metatag output: Record the titles, descriptions, canonical tags and Open Graph values the Metatag module renders for each content type, including the default patterns, not only the values editors typed.
• Hreflang and language versions: On multilingual sites, export the language of every node and its translations, so the new platform can reproduce the same hreflang annotations.
• Structured data and image alt text: Extract schema.org markup and alt attributes, so rich results and image search traffic survive.
• Canonical conflicts: Flag pages with missing canonicals or canonicals pointing to other URLs, and fix them on the new site rather than carrying the conflict over.

The aliases sit in the database. On Drupal 8.8 and later they are in the path_alias table, so a query such as drush sql:query "SELECT path, alias, langcode FROM path_alias" lists every alias with its system path and language; on Drupal 7 the table is url_alias, with source, alias and language columns. Export the Redirect module’s entries the same way from its own table, or with a Views data export if you prefer a CSV.

This inventory is the reference for every later step: the content mapping, the redirect spreadsheet and the staging crawl all check against it.

How to map Drupal content architecture

For SEO, content mapping has one job: every page keeps its address or gets a redirect, keeps its metadata, and keeps its place in the internal link structure. Planning the content model itself is covered in the Drupal to headless CMS guide; here the focus is the SEO fields.

Map content types and SEO fields

Map each Drupal content type and field to its place on the new platform, and give every content type explicit SEO fields. On a headless CMS such as Sanity, that means a slug field that holds the old path alias, a group of SEO fields for the title, description and canonical that Metatag used to render, and reference fields for taxonomy terms and related content.

• Field-level translation: Standardize legacy inputs so metadata translates cleanly; for example, the node title maps to article.title, body.summary to article.excerpt, field_image to article.featuredImage, and field_tags to references to tag documents.
• Taxonomy terms: Keep each term as its own document or record with its own URL, so category pages that rank keep their address and their internal links.
• Multilingual content: Keep one record per language version with its own URL, so hreflang pairs can be rebuilt one to one.

Preserve taxonomy and internal links

Search engines use internal links to understand page hierarchy and spread link equity across your domain. Drupal body content often contains absolute URLs and /node/123 paths that point straight at the old site, and those links break or route through redirects after the move.

• Update contextual links: Replace old absolute and /node/ links in body content with their final URLs during the migration, so internal navigation never depends on redirects.
• Replicate structural navigation: Keep the header, footer and sidebar link structure close to the Drupal layout, so the site hierarchy search engines know stays intact.
• Eliminate orphan pages: Make sure every migrated page gets at least one internal link, or it cannot be crawled efficiently.

SEO migration from Drupal and redirects

When URLs change, permanent redirects are your main defense against lost traffic. Google treats 301 and 308 redirects the same way, as a signal that the new address should become the canonical one, so either status works as long as every old URL points straight to its final destination.

Build a redirect spreadsheet

A redirect spreadsheet shows where each current page will live on the new site. Combine the crawl, the exported path aliases and Redirect module entries, Search Console and analytics data, so every URL with traffic or inbound links is accounted for.

• Legacy Drupal URL: The exact old path, from the alias export, the crawl and analytics.
• New destination URL: The most relevant new page for that content, never a blanket redirect to the homepage.
• Redirect type: A permanent redirect, 301 or 308, with no intermediate hops.

On a Next.js frontend, the map becomes entries in next.config.js redirects, which answer permanent redirects with a 308, or a redirect list managed in the CMS for large sites. Google recommends that you keep redirects for at least a year, and longer is better for pages with backlinks.

Scale decides where the redirects live. On Vercel, next.config.js holds up to 1,024 redirects, enough for many smaller sites. For a Drupal site with thousands of aliases, Vercel’s bulk redirects load many thousands of simple redirects from a CSV or JSON file, and the Next.js redirecting guide describes a redirect map checked in Proxy with a Bloom filter for dynamic cases. Either way, Vercel processes redirects at the edge across all regions, before any page renders.

Carry SEO data through the content migration

The content migration is where SEO data most often gets lost, because scripts move the visible text and skip the fields around it. Whatever the destination, the scripts have to carry titles, descriptions, canonicals, alt text, structured data and language versions alongside the content.

• Drupal to a current Drupal version: The core Migrate API with the Migrate Drupal module moves content, taxonomy and configuration from Drupal 7 into Drupal 11, and Metatag values can be mapped in the same run.
• Drupal to a headless CMS: Content usually leaves through JSON:API or straight from the database, as the Drupal to headless guide describes; the SEO addition is to map Metatag values, aliases and alt text into the new SEO fields in the same script.
• Rich text and media: Strip unrecognized HTML from body fields, keep image file names and alt text, and update file paths, so images keep their image search traffic.

On a Next.js frontend, the migrated SEO fields feed the page head through generateMetadata, where alternates.canonical sets the canonical URL and alternates.languages outputs the hreflang tags for each language version. For the structured data side, see structured data in CMS migration.

What to test before launch

Test the staging site against the inventory before it goes live. Search engines process structural changes quickly, so an error exposed in the first post-launch crawl can cost rankings right away.

Run crawl and redirect tests

Run a full crawl of staging with a tool like Screaming Frog or Sitebulb and compare it with the pre-migration inventory.

• Redirect validation: Request every old URL and confirm it returns a single permanent redirect to the right destination, with no loops or chains.
• Metadata parity: Compare titles, descriptions, canonicals and hreflang on staging with the Metatag export, page by page for the top pages.
• Internal links: Find any links still pointing to old Drupal paths and update them to their final URLs.
• URL variants: Request mixed-case, trailing-slash, language-prefixed and query-string versions of your top URLs, plus their /node/ and /taxonomy/term/ system paths, and confirm each one lands on the right page in one hop.
• Indexing directives: Confirm which noindex tags and robots.txt rules are for staging only, so they are removed at launch.

Check performance and accessibility

Page speed is a ranking factor, and a new frontend can make it better or worse. Measure the new templates with PageSpeed Insights and Lighthouse during development, on staging and right after launch, and compress images, lazy-load media and test mobile layouts before the switch.

SEO migration from Drupal launch risks

Watch for these launch mistakes in the first days. The first five come from how Drupal builds and resolves URLs, which the new platform may handle differently.

• Letter case: The Redirect module matches paths case-insensitively, so links with different capitalization may have worked for years, while Vercel’s CDN treats paths as case-sensitive; any variant the new site does not resolve becomes a 404.
• Trailing slashes: Next.js by default redirects /about/ to /about, so a redirect that targets the slash version adds a second hop; pick one convention and map to it.
• Language prefixes: Drupal’s /en/ and /de/ prefixes have to survive in the new routes, or every hreflang pair breaks at once.
• Query-string URLs: Paginated views such as ?page=2 and filtered listings are indexed URLs too; redirect or canonicalize them deliberately.
• System paths: /node/123 and /taxonomy/term/45 paths that search engines or other sites still use need redirects of their own.
• Redirect chains: An old Redirect module entry that now points to a redirected URL adds a hop, slows the page and wastes crawl requests; point every old URL straight to its final address.
• Staging directives left on: A noindex tag or a blocking robots.txt rule copied from staging can remove the new site from search.
• Lost metadata and hreflang: Pages that lose their titles, canonicals or hreflang pairs can drop even when their redirects are correct.
• Orphaned pages: Pages that lost their internal links during the rebuild are crawled less and rank worse.

Plan first 24-hour smoke tests

Write smoke tests as code so they run the moment the new site is live.

• Run full post-launch crawls: Crawl the live site to confirm it is accessible to search engines and that no legacy pages were missed.
• Validate priority URLs automatically: A script that requests every priority URL can confirm 200 responses, canonical tags and structured data.
• Audit robots.txt: Check that the live robots.txt does not block pages, JavaScript or CSS and that it references the new XML sitemap.

To compare the new platform with your Drupal site on your own content before committing, Pagepro offers to rebuild part of your website with your real content in 48 hours, with no cost and no commitment.

Post-launch monitoring and recovery

Google warns that rankings fluctuate during a move: for a medium-sized site it can take a few weeks or more before the new URLs show up, and rankings settle over time. Monitoring tells you whether a dip is that normal fluctuation or a fault you need to fix.

Track rankings and traffic trends

• Daily Search Console reviews: Check coverage, crawl errors and 404s every day for the first weeks, and compare indexed pages with the benchmark.
• Rank tracking by URL: Watch the pages and keywords from your benchmark, and look for consistent patterns rather than single-day swings.
• Server logs: Check that Googlebot is crawling the new URLs and that no unexpected error codes appear.

Recover pages that lose rankings

When a page from your benchmark drops and stays down for more than a few days, check it in this order before changing any content.

1. Compare with the benchmark: Confirm the drop is real for that URL and its keywords, not site-wide fluctuation.
2. Check the redirect: Request the old URL and confirm one permanent redirect to the right new page, with no chain.
3. Check the page head: Compare title, description, canonical and hreflang with the Metatag export, and look for a stray noindex.
4. Check internal links: Make sure the page still receives the internal links it had on Drupal.
5. Fix and request indexing: Correct what you found, then request indexing through the URL Inspection tool in Search Console.

Resubmit sitemaps and recrawl

Submit the new XML sitemap in Search Console as soon as the site is live. Google’s site-move guidance also suggests keeping a sitemap of the old URLs for a while: its indexed count should fall to zero as the redirects are processed, which confirms the move is working. Submit your most valuable pages through the URL Inspection tool to have them recrawled sooner.

For the headless side of the same move, from Core Web Vitals to getting cited by AI search, see the headless CMS SEO migration guide.

FAQ