Drupal redirects and SEO during migrations

How Drupal redirects protect rankings during a migration

Search engines keep the old URLs of a site in their index until they receive clear signals that those pages have moved. When a site with years of indexed pages is rebuilt as a new Drupal site, often with new themes, URL aliases and content structure, the redirect map, the canonical tags and the launch checks decide whether those rankings carry over to the new addresses or are lost in a wave of 404 errors. Teams usually need this work in two situations: moving a Drupal 6 or 7 site to a current Drupal version, or changing platform altogether. Drupal 6 and 7 sites cannot simply be updated in place. The Drupal.org upgrade documentation describes migrating them into a new site with the core Migrate modules or Drush, and themes must be rebuilt because they cannot be migrated. That means every URL pattern changes hands during the project, so the redirect plan is part of the migration scope from the start.

The redirect map is built from the old site's real traffic and link data, not from the sitemap alone. Export the URLs that receive organic visits, backlinks and internal hits from server logs and analytics, then match each one to a destination on the new site. Confirm how the old site generated its paths, since legacy Drupal 7 aliases and node-based paths often differ from what Pathauto produces on the new site. Decide how the Redirect module will store and serve these entries, how imported entries will be validated for loops and chains, and who signs off on pages with no equivalent, which should return a deliberate 404 or 410 rather than a blanket redirect to the homepage. Canonical tags on the new pages should point to the final URL so that duplicate paths do not compete with it.

Launch checks are where most redirect plans fail, so schedule them before cutover. Crawl the old URL list against the staging environment and confirm each entry returns a single 301 to a live page with a 200 response. Check that the new site's robots.txt, sitemaps and noindex settings have not been carried over from staging. After go-live, monitor 404 logs daily for several weeks and add redirects for any high-value paths that appear. Ask your partner to define these checks, the owner of each one and the rollback decision in writing, since the effort depends on the number of URLs, the number of languages and how much content changes shape during the rebuild.

Why Drupal 7 migrations lose traffic when URLs change

Most ranking loss during a Drupal 7 migration comes from URLs that change without a planned replacement. The usual causes are paths that were restructured during the rebuild, URL aliases generated by a different pattern in the new site, duplicate paths left live alongside the new ones, redirects that chain through two or three hops or loop back on themselves, and old pages removed with no target. Each of these leaves search engines with a dead end, a slow path or two competing copies of the same page. Before the build is finalized, export every indexed and linked path from the old site, compare it with the new alias patterns in Pathauto, and decide for each one whether it keeps its path, moves to a named target, or is retired on purpose. The redirect map is the deliverable that protects rankings, so it should be reviewed by someone who owns the content, not only by the developer who wrote the migration.

The timeline matters because it sets how much room the team has. Drupal 7 security support ended on January 5, 2025, according to Drupal.org's Drupal 7 end of life page, and that page lists HeroDevs and Tag1 Consulting as certified Extended Security Support providers for sites that cannot migrate yet. Organizations that rely on extended support may keep the old site running longer, which changes when the URL changes happen and how long the old and new sites overlap. Confirm the current support status, the terms and the end dates directly with your own hosting, security and extended support vendors, and do not rely on this page for compliance decisions. Ask each vendor in writing what they cover for the Drupal 7 site, and plan the cutover around the date you can actually guarantee, not the date the project would prefer.

Treat the old site as a source to be retired, not a permanent neighbor. Keep it reachable, but only long enough to crawl it, export the redirect source paths and confirm that search engines are being sent to the right targets. Run a crawl of the new site after launch to catch broken internal links, and watch the 404 report for paths that were missed in the map. Decide in advance who owns the 404 queue, how often it is reviewed, and what triggers a new redirect entry. These decisions, along with the redirect map, canonical URL rules and launch checks, are what keep a migration from becoming a slow traffic loss that only shows up in analytics months later.

Drupal redirects options and when each fits

This table compares four places redirects can live during a Drupal migration: inside Drupal, in the web server, at the edge, or split between edge and Drupal. Read each column for ownership, pattern handling, auditing and the performance and editorial trade-offs, then match the option to your URL volume and how often editors change content. Confirm the current Redirect module release and its compatibility with your Drupal version before choosing.

Option	Who maintains it	Pattern rules and imports	Auditing	Performance and editorial control
Redirect module in Drupal	Your Drupal team, with the module maintained on Drupal.org	Per-path entries, editor-created redirects and CSV or Drush imports for bulk maps	Redirect admin lists and 404 reports inside the CMS	Requests reach PHP, so load rises at volume; editors can change redirects without a deployment
Apache rewrite rules	Platform or infrastructure team	Regex and pattern rules in .htaccess or the virtual host, loaded from versioned files	Access and error logs, reviewed through deployment history	Fast because it runs before Drupal; editors have no direct control and changes need a release
Nginx map or rewrite rules	Platform or infrastructure team	Map blocks and return rules, often generated from a versioned CSV at build time	Access logs and config in source control; reloads must be tested	Fast and scalable for large maps; editorial changes require engineering work
CDN or reverse proxy edge rules	Platform, network or security team, depending on the provider	Edge rule sets or bulk redirect lists managed in the provider console or by API	Provider analytics and logs; confirm retention and export options	Serves redirects closest to users and offloads origin; policy sits outside the CMS, so ownership must be clear
Hybrid: legacy map at the edge, content changes in Drupal	Shared between platform team and Drupal team	Frozen Drud 7 URL map at the edge; new slug changes handled by the Redirect module	Two audit trails, so reconcile them at each launch check	Good balance of speed and editorial control; needs a written rule on which layer owns each URL pattern

How to build Drupal redirects maps before cutover

The sequence turns every legacy URL that search engines index or users reach into a single-hop redirect to a live canonical page, so rankings and inbound links carry over at launch. Each step produces an artifact that the next step checks.

Inventory every legacy URL
Export the full set of URLs the current site exposes from three sources: a crawl of the live site, server access logs covering a representative period, and analytics landing-page reports. Add the URLs listed in the search console indexing reports and the sitemaps the old site publishes. Merge and de-duplicate the lists into one source file, keeping the status code and referring source for each row. You know this step is done when the file accounts for every URL found in the logs and the crawl, and the team has signed off on the scope of what the logs covered.
Map each URL to a canonical target
For each legacy URL, record the new canonical address on the Drupal site that replaces it, usually from a content ID, a migrated node or a taxonomy term. Flag URLs with no equivalent so an editor decides between a closest-match page and a 410 response. Review the mapping with content owners for high-traffic and high-link sections first. You know this step is done when every row has one target or a documented decision, and no target is a redirect or a 404 page.
Import the map into the redirect layer
Load the mapping into the Redirect module, or into the web server or CDN layer if the platform handles redirects there, using a scripted import rather than manual entry. Keep the source file under version control so changes after cutover are traceable. Record the language and query-string handling for each rule. You know this step is done when the rule count in the redirect table matches the mapping file, with no rows rejected by the import.
Test a sample for single-hop 301 responses
On a staging copy of the new site, request a sample of old URLs across every section, including those with trailing slashes, query strings and translated paths. Confirm each returns a 301 status code and that the Location header points directly to the mapped target. Check that the target returns a 200 response. You know this step is done when the sample passes with no unexpected status codes, and failures have been logged and fixed in the source map.
Detect redirect chains and loops
Run a full crawl of the old URL list against staging and flag any response that takes more than one hop, any loop, and any target that is itself redirected. Chains often appear when a Drupal path alias changes after the map was written or when a legacy URL already redirected on the old site. Collapse each chain so the original URL points straight to the final target. You know this step is done when the crawl reports zero chains, zero loops and zero redirected targets.
Reflect theme and template URL changes
Because Drupal 6 and 7 themes cannot be migrated and must be rebuilt, template changes can alter generated URLs, pagination, facet parameters or canonical paths. Compare the rendered URLs on the old and new templates for each content type, and update the map wherever the new site produces a different canonical form. Re-run the chain check after each change. You know this step is done when a rendered-URL comparison for each content type matches the map.
Repeat until the map is clean
Repeat the test, chain check and template comparison until a full pass produces no exceptions, then freeze the mapping file and record its version. Confirm with the client's SEO and engineering leads which exceptions, such as intentionally removed pages returning 410, are accepted. Keep the frozen map as the input for launch checks and for post-launch 404 monitoring. You know this step is done when a complete pass has no open exceptions and the frozen map is signed off.

Canonical URL risks to fix before launch

A migration often leaves the old and new site reachable at once, and Drupal can generate several URLs for the same content. Search engines then have to choose which version to index, and they often choose the wrong one. The cards below cover the duplicate and conflicting URL patterns to find in a crawl and resolve before cutover.

Old and new paths both serve content

During a Drupal 7 migration, the legacy site may stay live on its old host while the new Drupal site serves the same articles at new paths. If both return a 200 status, search engines index two copies and split link signals between them. Confirm in your crawl output whether any legacy hostname or path still returns content after the planned cutover, and make sure every legacy URL either redirects with a 301 or returns a 404 or 410 once retired.

Trailing slash and protocol variants

Drupal treats /about and /about/ as separate requests unless the web server or a redirect rule normalizes them, and HTTP and HTTPS versions of the same page can both respond. Each variant can be indexed and can carry its own copy of the canonical tag. Check your crawl for paired variants that return 200 status, and set one rule at the web server or reverse proxy that sends every variant to the single preferred form with a 301 redirect.

Pathauto aliases alongside node paths

When Pathauto generates aliases for content, the node path such as /node/123 often keeps responding alongside the alias. Search engines can then index both, and internal links may point to whichever form the editor pasted. Confirm that every migrated node has an alias, that the node path redirects to the alias through the Redirect module or a similar rule, and that internal links and canonical tags point to the alias. Also check for aliases that changed after launch without a redirect from the previous alias.

Parameterized listing pages

Listing pages built with views filters, sorting or pagers create URLs such as ?page=2, ?sort=date or ?type=news. Each parameter combination can be crawled as a separate page with near-duplicate content. Review the crawl for query-string variants of category, tag and search pages, decide which parameters change the content enough to index, and set canonical tags on the others so they point to the clean listing URL.

Canonical tags pointing to removed URLs

Metatag or a theme template can output a canonical link that points to a path the migration removed, a staging host, or a node path that now redirects. Search engines then ignore the page's own URL in favor of a target that returns a redirect or 404. Confirm in the crawl that each canonical URL returns a 200 status on the production hostname, and that no canonical points to a staging or development domain.

Launch checks before, during and after cutover

Most ranking losses after a migration trace back to work finished before launch. Before cutover, the goal is to prove that the new site produces the same URLs, the same status codes and the same indexing signals that the live site already earns. Start by crawling the staging site with a crawler that can follow redirects and report status codes, titles, canonical tags and robots directives for every URL it finds.

Crawl the staging site: Record every response code, redirect chain and canonical target. Flag any internal link that returns a 404 or passes through more than one redirect.
Compare the redirect map against the live URL inventory: Export the live URLs from analytics, server logs and the existing sitemap, then confirm each one either exists on the new site or maps to a documented destination.
Confirm robots and noindex settings: Check that staging is blocked from indexing, and that the production build does not carry over a site-wide noindex or a Disallow rule that would hide content.
Verify canonical URLs: Each indexable page should declare one canonical URL that matches the URL the redirect map sends traffic to.
Confirm the sitemap contents: The sitemap should list only final, indexable URLs with 200 responses.

Confirm with your team how many redirect hops and which URL classes are acceptable to sign off, because that threshold should reflect your own risk tolerance and the size of your inventory.

The cutover window is when infrastructure changes can break URLs that worked a minute earlier. Treat each change as a separate check with its own owner and rollback step, so that a failure in one layer does not hide a failure in another. Run the checks against the production hostname as soon as each change lands, and again after DNS caches have had time to settle.

Confirm DNS changes: Verify that the production hostname resolves to the new target from more than one resolver, and that any old hostnames still resolve for redirects.
Confirm certificate changes: Check that the certificate covers every hostname in use, including www variants and any legacy domains, and that the chain is complete.
Confirm the redirect layer: Test representative old URLs for each redirect type, including the 301 rules from the redirect map, and confirm that the Redirect module or the web server rules return the expected target.
Sample key templates: Load the homepage, a landing page, a long article, a taxonomy listing, a search results page and a node with media. Check titles, meta descriptions, canonical tags and structured data against the staging crawl.
Record the outcome: Keep a dated log of each check and its result so that auditors and the SEO team can trace what changed and when.

Keep a tested rollback path for DNS and the redirect layer ready for the whole window, and confirm who has authority to invoke it.

Security and operational considerations for redirect layers

A redirect layer sits in front of the whole site, so mistakes in it affect every visitor, crawler and legacy link at once. The cards below cover the risks that tend to appear during a Drupal 7 migration or replatform and the control that addresses each one.

Open redirects from loose target rules

A redirect map that accepts any target can send visitors from your domain to an external site, which phishing campaigns and search spam both exploit. Restrict redirect targets to internal paths or an approved list of hostnames, and reject entries that begin with a scheme or a protocol-relative prefix. Review imported maps for targets that point off-site before they go live, since legacy spreadsheets often contain them.

Who can edit redirect maps

The Redirect module lets any user with the right permission create or change a rule, and a single edit can break a high-traffic URL or open a loop. Limit editing to a named group, separate it from content editing, and keep an audit trail of who changed which rule. Confirm which roles your site grants this permission to during the build, not after launch.

Logging and retention of 404 and redirect hits

404 and redirect logs reveal legacy URLs that still receive traffic, but they also store visitor IP addresses and referrers that may fall under your privacy policy. Decide which fields are kept, how long they are retained, and who can read them. Check the retention period against your data protection obligations and confirm what your hosting platform and log pipeline store by default.

Redirect map kept in version control

If the redirect map exists only in the database, a restore or a clean deployment can silently remove it, and the team loses the history of why each rule exists. Export the map to a file in the same repository as the site code, and deploy changes through the same review process as code. Verify that a fresh environment built from the repository reproduces the live map.

Legacy hostnames and TLS for old domains

Old domains often keep receiving links long after launch, and a redirect only works if the certificate for that hostname is valid and the request reaches the new site. Inventory every legacy hostname, plan certificate renewal for each one, and route them through the same redirect logic at the edge or web server. Confirm DNS ownership and renewal dates for domains that are not used for mail or other services.

Review of post-launch redirect changes

After launch, teams often add or edit rules to fix a single broken page without checking the wider effect on canonical URLs or other rules. Require a review step for every change that checks for chains, loops and conflicts with existing aliases. Keep a short runbook for who approves changes and how a bad rule is rolled back quickly.

What buyers ask about Drupal redirects and migration SEO

What does a Drupal 7 redirect and SEO migration cost?

No fixed price applies, because cost follows the written scope. The main drivers are the number of URLs that need a redirect decision, how many templates change on the new site, how many languages and translated aliases must map, how clean the legacy data is, and how many legacy hosts, domains or subdomains feed traffic to the site. One-time work includes URL inventory, the redirect map, template and metadata mapping, and launch checks. Recurring work includes 404 monitoring and redirect cleanup after launch. Ask any provider for a quote that itemizes each of these, names who does each task, and states what the client must supply. Drupal itself is licensed under GPL-2.0-or-later with no paid edition, so the cost sits in people and infrastructure, not licenses.

How long does redirect mapping take during a migration?

Duration depends on scope, mainly URL volume, the number of content types and templates, and how much of the old URL structure the new site keeps. A site with a stable URL pattern and few legacy hosts moves faster than one with years of inconsistent paths, several domains and multilingual content. Timing also depends on Drupal 7 end of life. Drupal 7 security support ended on January 5, 2025, and the Drupal Association lists certified Extended Security Support providers for sites that cannot migrate yet, so the migration deadline is driven by risk rather than by a vendor date. Ask for a timeline with milestones for inventory, mapping, staging crawl comparison, and launch checks, and confirm which steps depend on your sign-off.

What must our team provide before the work starts?

Most redirect projects stall on access and decisions, not on tooling. Prepare these inputs before work starts:

A full crawl export of the live site, including status codes, titles, canonicals and internal links
Search console and analytics access, so high-traffic and high-link URLs can be ranked for priority
Legacy web server logs or CDN logs covering a long enough period to show requests for old paths
The current URL list from the sitemap and any existing redirect tables
A named editorial owner who signs off on content that is merged, retired or renamed
Access to DNS, the staging environment and the production web server or CDN configuration

Ask the provider to confirm in writing which of these they need and in what format.

Can our in-house team handle redirects and SEO for the migration?

Often yes, if the team has someone who understands Drupal URL aliases, the Redirect module, crawl tools and search console data, and if there is time for a full crawl comparison before launch. An in-house team usually has the advantage of knowing the content owners and the legacy system. The risks are capacity during launch, lack of experience with legacy logs and multilingual alias mapping, and the absence of an independent launch check. A useful test is whether your team can produce a redirect map that covers every indexed URL with a single hop to its final destination, and can explain how it will catch 404s after go-live. DeployOpen provides planning, implementation, testing and documentation for self-hosted platforms in your own infrastructure, so the split of work can be agreed in the written scope.

What breaks most often during a Drupal redirect migration?

The most common failures are redirect chains where one old URL points to another redirect rather than the final page, redirect loops after alias changes, missing mappings for taxonomy term pages, paginated lists, and translated aliases, and canonical tags that still point to the old domain or to staging. Legacy hosts, file paths and query string parameters are often forgotten, which leaves inbound links unmapped. Another frequent problem is a launch that goes live with the staging noindex setting still in place. Verification should compare a pre-launch crawl with the redirect map, test sample URLs in each language, and watch 404 logs for at least the first weeks after launch, then review the remaining unmapped paths.

What should a fixed-scope quote for redirects and SEO include?

A fixed-scope quote should list the scope in terms you can check:

The URL sources in scope, such as the sitemap, crawl export, analytics and legacy logs, with the counts agreed in writing
The content types, templates, languages and legacy hosts covered
The redirect map format, the rules for chains and loops, and the Redirect module configuration or other method used
The canonical, metadata and sitemap checks run on the new site
The staging comparison, launch checklist and post-launch 404 monitoring period
The client inputs and sign-offs, with dates
Exclusions, such as content rewriting, paid search or link building
Deliverables, including the redirect map, test results and a handover document
The commercial terms, payment milestones and change request process

Ask the provider to confirm which items are one-time and which recur, and whether post-launch monitoring is a separate retainer.

Do we need Drupal 7 extended support while we migrate?

Possibly, depending on how long the migration will take and how exposed the site is. Drupal 7 security support ended on January 5, 2025, according to Drupal.org. The Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites that cannot migrate yet. Extended support is a separate commercial arrangement with those vendors, not part of a redirect project, and it does not change the need to rebuild themes, since Drupal 6 and 7 sites are migrated into a new site and themes must be rebuilt. Ask your provider how the SEO workstream will hold URL structures steady while the legacy site is still live and whether a temporary security arrangement is needed during the cutover window.

Limits to confirm in your environment

A redirect map is only as reliable as the platform that serves it. The items below are the points where Drupal redirect work tends to break during a migration, and each is a question to settle with the module maintainers, your hosting or CDN provider, or your own team before the redirect plan is final.

Redirect module release and Drupal compatibility

Confirm which release of the contributed Redirect module you will install and that it supports the exact Drupal version and PHP version of the target site. Check its project page on Drupal.org for the supported core range, then test the module on a staging copy of the new site. Ask whether it handles the redirect volume you expect and how it behaves with the Migrate-generated redirect records. Record the version in your build so later upgrades do not change redirect behavior silently.

Rule volume at the hosting or CDN layer

Ask your hosting provider or CDN whether its edge or load balancer can hold and evaluate the number of redirect rules in your map. Some platforms limit rule counts, regex complexity or rule file size, and others apply redirects only after a request reaches the origin. Each option changes where the 301 is issued and how much load a long map adds to every request. Confirm the limit in writing and test the largest map you plan to use before launch.

Log retention on legacy servers

Your redirect map is usually built from the old site's access logs and crawl exports, so confirm how long the legacy servers keep those logs and whether they are rotated or compressed. Many default retention settings are short, and once logs are gone, URLs that were linked but never crawled are hard to recover. Ask the current hosting team to export and archive logs before decommissioning, and confirm who holds the copies and for how long.

Old URLs indexed under retired hostnames

Check whether search engines still index old URLs under hostnames you plan to retire, such as legacy subdomains, staging hosts or alternate domains. Redirects only pass signals from URLs that receive requests, so an old hostname that stops responding can lose its indexed pages. Ask your DNS and certificate owners to keep those hostnames live with permanent redirects to the matching new URLs for as long as they are indexed. Confirm who owns each hostname and its certificate renewal.

Target Drupal and PHP requirements

Confirm the Drupal version the new site will run and the PHP version its hosting provides. Drupal 7 sites are migrated into a new site rather than upgraded in place, so the target version determines both the migration path and the redirect module you install. Ask whether the target version is near end of life, since a site that launches close to a support deadline will need an upgrade plan soon after cutover. Verify PHP support on the same page before you fix the stack.

Third-party tools that alter redirects or canonicals

Ask every tool in the stack what it does with redirects and canonical tags, including the CDN, WAF, analytics and consent tools, SEO plugins, and any reverse proxy. Two systems issuing redirects for the same path can produce chains, loops or conflicting canonical targets. Make a single owner for each rule and confirm the order in which layers evaluate requests. Test the final behavior with a crawler against a staging copy that matches production.

How DeployOpen scopes and delivers redirect and SEO migration work

DeployOpen plans, implements, tests and documents the redirect and SEO side of a Drupal migration inside your own infrastructure, as part of the same written scope as the content and build work. Engagements are fixed-scope, so the redirect map, metadata, sitemaps and launch checks are agreed before the work starts.

How we scope

Inventory the current URLs, indexed pages and top-traffic landing pages from the existing Drupal 7 or other source site.
Agree which URL patterns change, which keep their paths, and which content is retired, merged or redirected.
Write the scope and deliverables in writing, including the redirect map, canonical rules and launch checklist, before work starts.

How we build

Build the redirect map and configure the Redirect module so old paths resolve to their new equivalents in a single hop.
Set canonical URLs, metadata defaults and URL aliases so each page has one preferred address on the new site.
Test redirects, 404 responses and sitemaps on a staging copy of your environment before any production cutover.

How we hand over

Deliver the redirect map as a versioned file with owners, dates of change and the reasoning behind each rule.
Document the 404 monitoring setup, alert routing and the steps for adding redirects after launch.
Provide a launch checklist and post-launch verification record so your team can repeat the checks.

How we support

Review crawl errors, 404 logs and redirect chains during an agreed period after launch.
Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
Confirm with your team which search console and analytics accounts, and which owners, will receive ongoing reports.