How do you migrate from Drupal or Bitrix to WordPress without losing rankings?

Everything below follows Google's own site-move documentation, checked as of September 30, 2026. Links go to the primary pages, so you can verify each rule yourself.

Short answer

The whole job fits in three phases, and each has a short list of checks. The full checklist with a "how to verify" column sits in the launch section below.

1. Before the move: collect every URL the old site has ever exposed, then map each one to a new URL.
2. Launch day: switch redirects on in the same release as the new site, remove staging blocks, submit the new sitemap.
3. First 30 days: read the Page indexing and Crawl stats reports daily, fix every 404 that had traffic or links, keep the old sitemap submitted.

Expect some movement anyway. Google's site move guide warns of ranking fluctuations while pages are recrawled. For a medium-sized site, it says the switch to new URLs can take a few weeks or more (as of September 30, 2026). Fluctuation is normal, while a steady slide for weeks is a sign that something in the map is wrong.

What actually loses rankings in a CMS migration

Five mistakes cause most of the damage. None of them is specific to WordPress.

Missing redirects. An old URL that returns 404 loses whatever links and history it carried. The usual culprits are pages nobody remembered: Drupal node paths, old paginated archives, PDF files, image URLs that other sites hotlink. A crawl of the old navigation will not find them, but server logs will.

Redirect chains. Old sites carry old redirects. Drupal may send /node/123 to an alias, and the alias then points to the new WordPress page. That is two hops. Google recommends redirecting straight to the final destination and, if a chain is unavoidable, keeping it ideally to no more than 3 hops and fewer than 5 (Google Search Central, as of September 30, 2026). Flatten the chain in your map.

Redirects to the home page. Sending hundreds of dead URLs to / feels tidy. Google says this can confuse users and might be treated as a soft 404. Redirect to the closest equivalent. If there is none, return 410 on purpose.

Changed titles, headings and content on launch day. A migration already changes templates, internal links and page weight. Rewriting titles and H1s at the same time mixes two experiments. When traffic drops, you cannot tell which change caused it. Keep them identical for launch. Rewrite later, in batches.

Staging settings left on. Development sites are usually blocked with noindex or a robots.txt disallow rule. Google's guide lists forgotten noindex and robots.txt blocks as a common site-move mistake. The same goes for canonical tags that still point at the staging host.

Lost internal links belong on this list too. Menus get rebuilt by hand. Footer links and related-content blocks from Drupal Views simply vanish. Pages that lose their internal links lose crawl priority, even with a perfect redirect in place.

Before the move: inventory and redirect map

The redirect map is the most important file in the project. Build it before a single piece of content moves. Keep it in a spreadsheet, since it will be edited by several people.

Collect every URL

Google's guide suggests starting with your sitemaps, server logs, analytics and the Links report in Search Console. Use all four sources. Each one misses something.

• XML sitemap. Fast to parse, it lists what the CMS thinks is public, which is rarely everything.
• Full crawl of the live site with any desktop crawler. It finds linked pages, including parameters and pagination.
• Server access logs for as many months as the server keeps, filtered to 200 responses and to Googlebot requests. This is the source most teams skip. It surfaces old campaign pages, orphaned PDFs and URLs that only exist in someone else's backlinks.
• Search Console export from the Performance report (pages with clicks or impressions) and from the Links report (top linked pages).

Merge the lists and deduplicate. Decide the fate of each URL: kept at the same path, redirected with a 301, or retired with a 410. No fourth option.

Redirect map template

Copy these columns into your sheet. The rows below show typical Drupal and Bitrix paths.

Use 301 or 308 for permanent moves. Google treats both as permanent and as a strong signal that the target should be canonical (Redirects and Google Search, as of September 30, 2026). Implement redirects on the server or in a WordPress redirect plugin that answers with a real 3xx status. JavaScript redirects are Google's last-resort option.

Each new page needs a self-referencing rel="canonical", per the site move guide. Keep the map after launch. You will need it to update internal links and to read the Search Console reports.

Drupal specifics

Drupal 7 reached end of life on January 5, 2025, when security support ended (Drupal.org, as of September 30, 2026). That date pushes many owners toward a move. It also means the old site may already be fragile, so take a full database and file backup before the export.

Nodes and aliases. Every Drupal node has a system path like /node/123, and usually a Pathauto alias as well. Both may be indexed. Your map needs a row for each. Pull the url_alias table (Drupal 7) or path_alias (Drupal 8 and later) straight from the database. It gives you the full list in one query.

Taxonomy terms. Term pages at /taxonomy/term/45 often have aliases too. Decide whether each vocabulary becomes a WordPress category, a tag or a custom taxonomy. Paged term listings need their own rows.

Views pages. Listing pages built with Views have no node behind them. Exporters skip them. Search your logs for their paths and rebuild each one as a WordPress archive or a page with a query block.

Multilingual sites. Drupal stores translations as linked entities with language prefixes such as /de/. WordPress handles languages through a plugin, and each plugin has its own URL scheme. Pick the scheme first. Then map every language prefix. If the old site used hreflang, Google's guide says to update those annotations to the new URLs.

Content export. WordPress documentation lists third-party importers for Drupal, including FG Drupal to WordPress, compatible with Drupal 4 through 9 (WordPress Developer Resources, Importing Content, as of September 30, 2026). An importer moves content. It does not build your redirect map. Check field mapping on 20–30 sample pages before trusting the full run.

Bitrix specifics

1C-Bitrix sites put more SEO value in query strings than most platforms. That makes the inventory harder.

Element and section pages. Older Bitrix templates serve items through detail.php?ID= or ?ELEMENT_ID= and lists through index.php?SECTION_ID=. Many sites later switched on SEF (search-engine-friendly) URLs but never redirected the old parameter versions. Both may still be indexed, so map both.

Pagination. Bitrix appends PAGEN_1, PAGEN_2 and so on, one number per component on the page. Google recommends a unique URL for each page in a sequence and advises against using the first page as the canonical for the rest (Google Search Central, pagination, as of September 30, 2026). Map ?PAGEN_1=2 to /page/2/ and keep self-canonicals.

Infoblocks. Content lives in infoblocks. In WordPress, each infoblock becomes a post type or taxonomy, and each property becomes a custom field. Flatten properties into plain text and you lose filtering and structured data. That step is hard to undo later.

Smart filter. The Bitrix faceted filter has no direct equivalent in WordPress. You rebuild it with a plugin or custom code. Decide which filter combinations deserve indexable URLs. Most do not. Leave those out of the sitemap and keep them uncrawlable.

Integrations. Exchange with 1C, CRM forms and delivery modules all need a new home. They do not affect rankings directly, though they do move the launch date. Toimi's page on the subject calls the split between content, URLs and integrations "the difference between a two-week job and a three-month one," and ties it to countable inputs: infoblocks, custom components, integrations. For the detailed order of work, see a Bitrix-specific migration plan.

Launch day and the first 30 days

This is the working checklist. Run it in order; every item has a check you can do in minutes.

Before the move

Launch day

First 30 days

Two Search Console reports do most of the work. The Page indexing report shows which URLs are indexed and why others are not. The Crawl Stats report shows how Googlebot is fetching the site, broken down by response code. Google's guide adds that the sitemap of old URLs should gradually drop to zero indexed pages while the new one rises. Warnings about redirects in the old sitemap are expected.

How long do redirects stay? Google says to keep them as long as possible, generally at least one year, so it can transfer all signals to the new URLs (as of September 30, 2026). Treat that as the minimum for a CMS move as well.

The Change of Address tool applies only when the domain changes. Its help page says not to use it for URL changes within the same site; redirects and updated sitemaps handle that. If you do move to a new domain at the same time, the tool works at domain level, and Google asks you to keep redirects for at least 180 days (as of September 30, 2026). Changing the CMS and the domain together doubles the risk. Split them if the schedule allows.