A Drupal migration is a rebuild<\/a>, 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.<\/p>\n\n\n\n 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<\/a> shows.<\/p>\n\n\n\n Learn Squared<\/a>, the e-learning platform Pagepro moved off Drupal 7 to Next.js, described what the move did for its team.<\/p>\n\n\n\n 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\u2026 the turnaround time from ideation to feature launch has been a marked improvement upon our previous development solution.<\/p>\nAndrew Hawryluk, Co-founder, Learn Squared<\/cite><\/blockquote>\n\n\n\n A Drupal SEO migration checklist<\/strong> 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<\/a>; this article covers how to keep your rankings through that move.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Don\u2019t let your migration tank your rankings.<\/p> 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.<\/p>\n\n\n\n Without these benchmarks, diagnosing a post-migration traffic drop turns into guesswork.<\/p>\n\n\n\n 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 The aliases sit in the database. On Drupal 8.8 and later they are in the This inventory is the reference for every later step: the content mapping, the redirect spreadsheet and the staging crawl all check against it.<\/p>\n\n\n\n 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<\/a>; here the focus is the SEO fields.<\/p>\n\n\n\n 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<\/a> that Metatag used to render, and reference fields<\/a> for taxonomy terms and related content.<\/p>\n\n\n\n Search engines use internal links to understand page hierarchy and spread link equity across your domain. Drupal body content often contains absolute URLs and Upgrade your tech without losing a single keyword position.<\/p> When URLs change, permanent redirects are your main defense against lost traffic. Google treats 301 and 308 redirects<\/a> 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n On a Next.js frontend, the map becomes entries in next.config.js redirects<\/a>, 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<\/a>, and longer is better for pages with backlinks.<\/p>\n\n\n\n Scale decides where the redirects live. On Vercel, 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.<\/p>\n\n\n\n On a Next.js frontend, the migrated SEO fields feed the page head through generateMetadata<\/a>, where \n
SEO migration from Drupal checklist<\/h2>\n\n\n\n
\n
Benchmark traffic and rankings<\/h2>\n\n\n\n
\n
Collect URLs, aliases and metadata from Drupal<\/h2>\n\n\n\n
\/node\/<\/code> system paths, old redirects or pages nothing links to anymore.<\/p>\n\n\n\n\n
\/node\/123<\/code> path is paired with the address visitors and search engines actually use.<\/li>\n\n\n\npath_alias<\/code> table, so a query such as drush sql:query \"SELECT path, alias, langcode FROM path_alias\"<\/code> lists every alias with its system path and language; on Drupal 7 the table is url_alias<\/code>, with source<\/code>, alias<\/code> and language<\/code> 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.<\/p>\n\n\n\nHow to map Drupal content architecture<\/h2>\n\n\n\n
Map content types and SEO fields<\/span><\/h3>\n\n\n\n
\n
article.title<\/code>, body.summary<\/code> to article.excerpt<\/code>, field_image<\/code> to article.featuredImage<\/code>, and field_tags<\/code> to references to tag documents.<\/li>\n\n\n\nPreserve taxonomy and internal links<\/span><\/h3>\n\n\n\n
\/node\/123<\/code> paths that point straight at the old site, and those links break or route through redirects after the move.<\/p>\n\n\n\n\n
\/node\/<\/code> links in body content with their final URLs during the migration, so internal navigation never depends on redirects.<\/li>\n\n\n\nSEO migration from Drupal and redirects<\/h2>\n\n\n\n
Build a redirect spreadsheet<\/span><\/h3>\n\n\n\n
\n
next.config.js<\/code> holds up to 1,024 redirects, enough for many smaller sites. For a Drupal site with thousands of aliases, Vercel’s bulk redirects<\/a> load many thousands of simple redirects from a CSV or JSON file, and the Next.js redirecting guide<\/a> 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<\/a>, before any page renders.<\/p>\n\n\n\nCarry SEO data through the content migration<\/h2>\n\n\n\n
\n
alternates.canonical<\/code> sets the canonical URL and alternates.languages<\/code> outputs the hreflang tags for each language version. For the structured data side, see structured data in CMS migration<\/a>.<\/p>\n\n\n\n