How to Migrate a Website to WordPress Without Losing SEO

The WordPress Specific Version of This Problem

The general discipline of a safe migration, benchmarking, URL mapping, redirects, staging QA, launch sequencing, and the recovery window, applies regardless of where you are going. That process is written out in full in the SEO migration checklist, and it is the right starting point.

This article covers something narrower: the failures that happen specifically because the destination is WordPress.

They are worth separating because they are not judgement errors. They are defaults. WordPress ships with behaviours that quietly restructure a site during import, and a team following a perfectly good general migration process can still lose traffic because a permalink setting rewrote every URL while nobody was looking.

Six of them cause most of the damage.

Failure One: The Permalink Structure Rewrites Everything

The largest single cause, and the most avoidable.

WordPress generates URLs from a permalink setting. Change that setting and every URL on the site changes with it. Import content before configuring it and you get whatever the default produced, which frequently inserts dates, categories, or a base segment that did not exist on your old platform.

A page that lived at /services/migration can end up at /2026/09/services-migration without anyone deciding that.

Three rules:

Set the permalink structure before importing anything. Changing it afterwards regenerates every URL and invalidates work already done.

Choose the structure that reproduces your existing URLs, not the one a general guide recommends. If your blog lived at /blog/post-title, configure exactly that, base segment included.

Check custom post types separately. A custom post type registered by a theme or plugin brings its own slug, so a page that was at /case-studies/name can silently become /portfolio/name because that is what the theme called its post type. This is not visible in the permalink settings screen and it catches people repeatedly.

Failure Two: Archives Mint URLs That Never Existed

WordPress automatically generates archive pages for every category, tag, author, and date period.

On a fresh site that is unremarkable. On an import it can be destructive, because importers frequently create tags liberally from the source data. A blog arriving with four hundred tags produces four hundred archive URLs, none of which have backlinks, most of which contain a handful of posts, and all of which compete for crawl attention.

You also inherit author archives for every user the import created, and date archives for every month you have ever published.

The fix is a decision rather than a default. Keep the archives that serve a genuine navigational purpose, usually a small number of categories. Noindex or disable the rest. And crucially, look at what the import actually created before launch rather than finding it in a crawl report six weeks later.

Failure Three: Metadata Does Not Come With the Content

Title tags and meta descriptions do not transfer automatically, and this surprises people every time.

On your old platform they live in that platform's own fields. In WordPress they live in an SEO plugin, usually Yoast or Rank Math, and there is no automatic connection between the two. Unless someone explicitly maps them, the plugin falls back to a template pattern and every page gets a generic title derived from the post name and the site name.

A site can migrate with perfect URLs, perfect redirects, and perfect content, and still lose rankings because every title tag now reads "Page Name | Company Name".

The sequence that works: export old titles and descriptions before migrating, map them to the destination URLs, import them into the plugin fields, then spot check a sample in the rendered HTML rather than trusting the plugin interface.

The same applies to canonical tags, Open Graph data, and any structured data that was hand placed on the old platform.

Failure Four: The Theme Changes What Is On the Page

A subtler one, and it is why content parity checks matter.

WordPress themes make decisions about rendering. A theme might truncate excerpts, hide the H1 on certain templates, render headings at different levels from the source, lazy load content in a way that affects how it is parsed, or wrap content in markup that changes its emphasis.

The content is technically all there. What the page communicates to a crawler is not the same.

Check a representative sample of migrated pages by comparing the rendered output against the original: H1 present and correct, heading hierarchy intact, body content complete rather than excerpted, image alt text preserved, and internal links present in the content rather than stripped.

The pages worth checking most closely are the ones earning the most traffic, which the URL inventory already identified.

Failure Five: Media Paths Break Quietly

WordPress stores uploads in a dated directory structure under wp-content/uploads. Your old platform did not.

Two consequences. Image URLs change, so any hard coded references in imported content point at files that no longer exist, and images that ranked in image search lose their addresses. Second, imports frequently bring images in without alt text even when the source had it, because the alt attribute lived in the old platform's markup rather than in a field the importer read.

Check after import: images render on a sample of pages across templates, no content references the old domain or CDN, alt text survived, and the media library does not contain hundreds of duplicates from a rerun import.

That last one is common and it inflates both storage and the sitemap.

Failure Six: Staging Directives Reach Production

The most embarrassing failure and one of the most common.

WordPress has a "Discourage search engines from indexing this site" setting, and staging plugins and hosting staging environments often set it automatically. If the site is cloned from staging to production, or the setting is simply never unticked, the live site ships with a sitewide noindex.

Related failures in the same family: a robots.txt carrying staging rules, canonical tags still pointing at the staging domain or the old platform, and internal links pointing at staging URLs that are unreachable publicly.

Check all four on production, after launch, in the rendered output. Not on staging, and not by asking whether someone remembered.

The Order to Work In

The WordPress specific items sit inside the general process rather than replacing it.

Before the build: crawl and inventory every URL with its traffic, rankings, links, and conversion value. Export metadata. Decide the permalink structure and the content model, including what each custom post type's slug will be.

During the build: configure permalinks before importing. Register post types with the slugs you want. Decide the archive policy. Map metadata into the SEO plugin.

Before launch: crawl staging and compare against the inventory. Verify redirects resolve in one hop to a 200. Check content parity on your top pages. Confirm images render and alt text survived. Check canonicals, robots directives, and the indexing setting. Regenerate the sitemap and confirm it contains only canonical, indexable, non redirected URLs.

At launch: confirm DNS and SSL, crawl production immediately, check the indexing setting again on production, and verify the highest value pages first.

Afterwards: monitor indexing, 404s, redirect errors, rankings, organic traffic, and form submissions. The general monitoring window and what to watch is covered in the migration checklist.

If Rankings Drop, Diagnose in This Order

Work top down. Each step rules out a category before you spend time on the next.

1. Status codes. Do your important URLs return 200? A surprising share of incidents end here.
2. Indexability. Check the WordPress indexing setting, robots.txt, and page level noindex directives from the SEO plugin.
3. Redirects. Does each old URL resolve in a single hop to the correct new URL? Look for chains and loops.
4. Canonicals. Are they pointing at the new URLs, or still at staging or the old platform?
5. Content parity. Compare rendered output against the original for your top pages. Check for the theme level truncation described above.
6. Internal links. Are they updated, or still pointing at old or staging URLs? Are important pages orphaned?
7. Sitemap. Does it contain only canonical, indexable, live URLs?
8. Rendering and server. Is content dependent on JavaScript that a crawler cannot see? Is the server returning errors under crawl load?
9. Missing pages. Did anything get dropped in the import that used to earn traffic?
10. Compare by page type. If one template lost traffic and the rest held, the problem is in that template rather than sitewide.

Most incidents resolve in the first four steps.

Platform Notes

The origin platform changes what you have to watch for on the way out.

HubSpot templates and modules do not convert, forms need a decision, and canonicals often still point back at HubSpot after import. Covered in HubSpot to WordPress migration.

Webflow exports markup rather than a working site, leaving CMS collections and form handling behind. See Webflow to WordPress.

Squarespace has an export that misses pages, galleries, and product data, and its URL structure rarely survives a default WordPress permalink setting. See Squarespace to WordPress.

Wix has no meaningful export, so everything is rebuilt and the URL map becomes the entire project. See Wix to WordPress.

Frequently Asked Questions

Why do websites lose rankings after moving to WordPress?

Most often because the permalink structure silently rewrote every URL on the site. WordPress ships with a default permalink setting, and themes and plugins add their own slugs for custom post types, so a page that lived at one address on the old platform can land at a completely different one without anyone choosing that. Combine that with category and tag archives creating URLs that never existed before, metadata that did not survive the import, and internal links still pointing at the old structure, and a technically successful migration produces a measurable traffic loss.

What WordPress permalink structure is best for a migration?

Whichever one reproduces your existing URLs most closely. That is the whole answer, and it overrides every general recommendation about post name structures. If your old blog lived at /blog/post-title then configure WordPress to serve exactly that, including the base segment, rather than accepting a default that inserts dates or categories. Changing permalink structure during a migration means every URL needs a redirect, which is avoidable work and avoidable risk. Set the permalink structure before importing anything, because changing it afterwards regenerates every URL on the site.

Do WordPress category and tag archives hurt SEO after a migration?

They can, because WordPress generates archive URLs automatically for every category, tag, author, and date, and an import that creates tags liberally can mint hundreds of thin pages that never existed on the old site. None of them have backlinks, most have little unique content, and collectively they can dilute crawl attention and create duplication. The fix is a deliberate decision rather than a default: keep the archives that serve a real navigational purpose, noindex or disable the rest, and check what the import actually created before launch rather than discovering it in a crawl report later.

Does metadata transfer automatically when importing into WordPress?

No, and assuming it does is one of the most common causes of post migration traffic loss. Title tags and meta descriptions on the old platform live in that platform structure, while in WordPress they live in an SEO plugin such as Yoast or Rank Math, and nothing connects the two automatically. Unless the migration explicitly maps old titles and descriptions into the plugin fields, WordPress falls back to a template pattern and every page gets a generic title. Export the old metadata before migrating, map it, import it, then spot check a sample in the rendered HTML.

How long do rankings take to recover after a WordPress migration?

Expect movement for two to four weeks while search engines recrawl and reassess, with larger sites taking longer because the recrawl itself takes longer. A well executed migration typically returns to its baseline within four to eight weeks, and sometimes exceeds it if the rebuild also fixed speed or structural problems. Decline that is still deepening after a month is not a recovery curve, it is an unresolved problem, and the diagnostic order is status codes, indexability, redirects, canonicals, content parity, then internal links.

Get the Risk Review Before Launch, Not After

Every failure in this article is cheap to prevent and expensive to diagnose once the site is live and the traffic has already moved.

Get a WordPress migration SEO risk review and we will check the permalink and content model decisions, the URL map, the metadata plan, and the staging configuration before launch rather than after. Start with the SEO migration checklist for the full process, and website migration cost if you are still budgeting. Book a strategy call or call us at 321-401-7016.