How do you redirect Drupal URLs after moving to WordPress?

Last updated: 28 October 2026

Drupal answers a page at its system path (/node/<id>) and at its alias, and WordPress serves only the permalink it generates. After the move, the system paths and every alias that is not recreated answer 404. Export the alias table, use it as the left column of the redirect map, then request every old URL on the new site to confirm the redirects land.

Related guides: the website migration testing checklist, finding broken pages after a migration, and the platform guides for WordPress to Webflow and moving into Shopify.

What changes in the URLs

These are default path shapes. The site owner may have changed any of them, so confirm each pattern against the old site’s sitemap and a crawl.

• Drupal system paths: /node/<id> for content, /taxonomy/term/<id> for terms and /user/<id> for accounts.
• Drupal aliases: the readable paths a site assigns to those items, such as /about or /blog/my-post. The system path and the alias can both answer 200 on the old site, so links and search results may use either.
• Drupal media: /sites/default/files/<file>.
• WordPress permalinks: /<slug>/ for pages and posts, /category/<slug>/, /tag/<slug>/, /author/<name>/ and /wp-content/uploads/<year>/<month>/<file> for media, with a trailing slash.

WordPress does not serve /node/<id>, /taxonomy/term/<id> or /user/<id>, and every alias moves to whatever permalink the new site generates for it. Two differences hide in plain sight: Drupal aliases carry no trailing slash while WordPress permalinks do, and an old alias may contain upper-case letters that the new slug does not. Check both against your own paths.

Build the redirect map

1. Export the alias table. Drupal keeps the mapping from each alias to its system path. Export it and use the aliases as the left column of the redirect map, so the map starts from every path the old site actually served.
2. Add what the table does not list. Take the sitemap URLs, the Sitemap: lines in robots.txt and a crawl, and add the system paths that appear in links, so /node/<id> redirects to the same destination as its alias. The website migration testing checklist covers this inventory.
3. Write the new permalink next to each old path. Match items by title or by the imported record, one old path to one new path.
4. Decide what has no equivalent. Term pages and user pages often have no WordPress counterpart. Redirect each to the closest category, tag or author page, or retire it on purpose with a 410.
5. Enter the redirects as permanent (301) with a redirect plugin or the web server’s rules. Check whether your tool accepts patterns before you rely on one for a whole family of paths.
6. Request every old URL on the new site. Read the final status of each and check that it lands on the matching page and not on the homepage. The guide finding broken pages after a migration shows how to read each result.

What usually goes missing

• System paths, which no alias or sitemap lists but which links and search results still use.
• Taxonomy term pages and user pages, which WordPress does not serve at those paths.
• Files linked at /sites/default/files/ by old pages and by other sites.
• Paginated listings, whose page numbering differs between the platforms.
• Trailing-slash and upper-case variants of the same path.
• Query-string variants, such as tracking parameters on shared links.

What DiffiCat automates

DiffiCat compares each page at the same path on both sites. Enter the site you are moving from as Site A and the site you are moving to as Site B. It requests each old URL on the new site and follows redirects hop by hop: a correct redirect passes “Exists”, a missing redirect fails it, and a redirect that lands on the wrong page fails “Content”, because the title and body text no longer match.

• The URL list. DiffiCat reads the old site’s sitemap.xml and the Sitemap: lines in its robots.txt, and falls back to a crawl of the homepage. You can also supply a sitemap URL.
• Three checks on every page. “Exists” compares the HTTP status of both versions. “Content” compares the title, H1, meta description, canonical, robots meta, hreflang and body text, with a 90% word-overlap threshold for the body. “Visual” compares screenshots pixel by pixel at 375 px, 768 px or 1440 px, or any width from 320 px to 2560 px.
• A report you can act on. Pages are listed worst first, and each failure names the site at fault, such as A: 200 → B: 404.

Building the redirect map stays yours: DiffiCat shows which old URLs fail and why, and you add the redirects.

What this does not catch

• Behaviour: forms, search, checkout, sign-up flows and other interactive features need their own functional tests.
• Speed and server load: a page can match exactly and still be slower.
• Pages nobody listed: if a URL is missing from the inventory, no tool checks it.

DiffiCat has its own limits. Both sites must resolve on the public internet: localhost, loopback and private-network addresses are refused, so deploy staging to a public URL (password protection is fine). Pages are rendered in headless Chromium only. Sign-in with a username and password is supported, but sign-ins that need a code (MFA), a CAPTCHA or single sign-on are not.

Run the check on your sites

Enter your old and new site in the try-it form, or open app.difficat.com and start the free trial: 500 captured pages once when signed in, 100 without signing in, with every check and viewport width and no card needed.