Step-by-Step Guide to Migrating Websites to WordPress from Other Platforms

Key Takeaways

• A WordPress migration moves four things, not one: your content, your media, your URLs, and the search and AI visibility attached to those URLs. Most migrations that fail move the first two and forget the last two.
• The risk is real and measurable. Across 892 domain migrations, organic traffic took an average of 523 days to return to pre-move levels, and 17% never got back after 1,000 days (Search Engine Journal). Well-planned moves recover in 30 to 90 days.
• A URL map built before you touch anything is the single highest-value hour of the project. Every old URL needs one named destination, page by page, including images and PDFs.
• Use server-side 301 or 308 redirects and keep them live for at least one year, which is Google’s own stated guidance (Google Search Central, 2026).
• You can now lose AI visibility separately from rankings. Redirects protect your URLs, but ChatGPT, Gemini, and Google AI Overviews cite passages. Rewrite your headings and answers during the move and the citation breaks even when the redirect works.
• Wix and Squarespace have very different exits. Squarespace gives you a real WordPress export file. Wix does not, and its images stop loading the moment you cancel the plan, so budget for manual work.
• Expect a dip. A 10% to 30% drop that stabilizes within two to six weeks is normal. A drop past 30% that has not moved after four weeks is a technical fault, not patience.

WordPress is where most sites end up. It powers 40.8% of all websites and 59.0% of every site built on a known content management system, and a large share of those sites started somewhere else. A business outgrows a page builder, hits a wall on what it can publish, or gets a quote to add one feature and decides it is time to own the platform instead of renting it.

The move itself is not the hard part. Exporting content and installing WordPress is a weekend. The hard part is arriving with your search rankings, your backlinks, and your AI citations still attached, because those live on URLs, and a migration changes URLs. Get that wrong and you keep every page you ever wrote while losing most of the traffic that found them.

In this, we cover the full process: what to prepare before you start, how to move from Wix, Squarespace, Joomla, Drupal, or static HTML, how to handle redirects the way Google actually asks for, and what to watch in the 30 days after launch. It is written for the person who owns the site, not the person writing the code.

What Does a Website Migration Actually Move?

A website migration moves four separate assets, and each one can fail on its own. Naming them upfront is what keeps a migration from turning into a rebuild with a traffic hole in it.

What moves	What it contains	What breaks if you skip it
Content	Posts, pages, products, categories, tags, authors	Missing pages, lost formatting, orphaned drafts
Media	Images, PDFs, video, audio, downloads	Broken images, dead resource links, lost image search traffic
URLs	Every address a person or search engine can reach	404 errors, lost rankings, lost backlink value
Visibility	Rankings, backlink equity, AI Overview and assistant citations	Traffic drop that outlasts the technical fix by months

The first two are what migration plugins handle. The last two are what people hire someone to fix six months later, after the damage shows up in revenue.

There is a useful distinction here. Platform migration means the software changes but the domain stays the same, for example Squarespace to WordPress on yoursite.com. Domain migration means the address changes too. Domain migrations carry noticeably more risk because every single link on the internet pointing at you now needs a redirect to follow. If you can avoid changing the platform and the domain in the same week, do that. Two smaller moves are far easier to debug than one large one.

A website migration moves four assets: content (posts, pages, products), media (images, PDFs, downloads), URLs (every reachable address), and visibility (rankings, backlink equity, and AI citations attached to those URLs). Migration plugins handle content and media. URL mapping and redirects are what protect visibility, and they are the most commonly skipped step.

What the Migration Data Actually Says

Most migrations lose traffic, and the recovery window is longer than people expect. This is the part that should set your timeline and your care level.

The largest public dataset on this comes from a study of 892 domain migrations collated in October 2024 by Dan Taylor and published through Search Engine Journal. On average, it took 523 days for the new domain to show the same organic traffic as the old one. 17% of the migrations had still not recovered after 1,000 days. The fastest recoveries in the sample landed at 19, 22, 23, and 33 days.

How Long Does Organic Traffic Take to Come Back After a Migration

Scenario	Days to return to pre-migration traffic
Fastest recorded in the study	19 days
Well-planned migration	30 to 90 days
Average across all 892 moves	523 days
17% of sites	Never recovered after 1,000 days

Read that average correctly, though. It is not a law of physics. Rather, it is what happens when migrations get treated as an IT task instead of a search task. The 19-day recoveries in the same dataset were not lucky; they were prepared. Similarly, an August 2026 analysis of e-commerce replatforming put typical loss from poor execution at 20% to 40% of organic traffic (Optimum7 via GlobeNewswire), which is a preventable number, not an unavoidable one.

Use this as your reading guide once you are live:

• 10% to 30% dip, recovering within two to six weeks. Normal. Google is re-crawling and re-assigning signals. Do nothing except keep monitoring.
• Over 30%, or flat after four weeks. Something is broken. Almost always redirects, canonical tags, a blocked robots.txt, or a noindex left on from staging.
• Over 50% in week one. Stop and check whether the staging site’s search engine blocking is still switched on. This is the most common single cause and it takes two minutes to rule out.

What Changed for Migrations in 2026

Two things have shifted, and both change what a migration puts at risk.

Google now judges the site, not just the page

Google’s latest confirmed core update rolled out from May 21 to June 2, 2026, following a March 2026 core update and a June 2026 spam update. The pattern across the December 2025 and 2026 updates is consistent: quality gets assessed across a whole site, not one URL at a time.

For a migration, that has a practical consequence. If you carry over 200 thin pages from the old platform because they were easy to export, you are not just carrying dead weight, you are handing Google a site-wide quality signal at the exact moment it is re-evaluating you. A migration is the cheapest opportunity you will ever get to delete or merge weak pages. Redirect them to the strongest relevant page and cut them.

Author identity matters more too. If your old platform published everything under “admin” or a generic account, set up real author profiles with real credentials on the new site. Anonymous content has been losing ground since the December 2025 update.

AI assistants are a second index, and you can lose it separately

People do not only search on Google anymore. ChatGPT reached roughly 900 million weekly active users in early 2026, more than double the 400 million a year earlier (DemandSage). Business owners now ask ChatGPT, Claude, and Gemini the same questions they used to type into a search box, and those tools answer with a handful of cited sources instead of ten blue links. Earning those citations is what generative engine optimization, or GEO, refers to.

On Google itself the click math has changed. Pew Research tracked the browsing of 900 US adults and found that when an AI Overview appeared, users clicked a traditional search result 8% of the time, compared with 15% when no AI Overview was present. They were also more likely to end the session entirely, 26% versus 16%.

Clicks Drop When an AI Overview Appears

Search result type	Share of searches where a user clicked a result
No AI Overview shown	15%
AI Overview present	8%

[Our Insights] Here is the part almost no migration checklist covers. A working redirect protects your URL. It does not protect your citation. AI systems do not cite pages the way Google ranks them, they cite passages. A model that learned to quote your sentence “a full WordPress backup includes both files and database” is matching that specific wording under that specific heading. If your migration is also a content refresh, and the writer retitles the section, splits the paragraph, and rephrases the answer, the redirect resolves perfectly and the quotable passage is gone. The citation quietly stops appearing and nothing in Search Console tells you why.

Two rules follow from that:

1. Do not redesign the words during the technical move. Migrate the content as-is. Refresh it a month later, once the new URLs are indexed and stable. Separating the two also means that if traffic drops, you know which change caused it.
2. Confirm you are indexed in Bing, not just Google. ChatGPT Search pulls its live results from Bing’s index. A site that is perfectly migrated for Google and invisible in Bing Webmaster Tools has lost the largest AI referral source there is.

Agencies that track this are reporting real numbers. One reports clients losing as much as 60% of their AI visibility in the three months after a migration when nobody planned for it. Where redirects and entity wording were preserved, recovery took 4 to 8 weeks instead (Edge45).

The Pre-Migration Checklist

Everything that decides whether a migration succeeds happens before you move a single file. Work through this list in order and do not start the move until all of it is done.

1. Crawl and record the old site. Run Screaming Frog or a similar crawler over the current site and export every URL, title, meta description, heading, and status code. This is your before picture. Without it you cannot prove what was lost or find what is missing.

2. Benchmark your numbers. Export the last 12 months from Google Search Console and Google Analytics: top landing pages by clicks, top queries, and top converting pages. Save it outside the site. After launch you will compare against this, and you cannot get it later if the property changes.

3. Build the URL map. A two-column spreadsheet, old URL on the left, new URL on the right, one row per page. Include images, PDFs, and any downloadable files that earn links or traffic. This is the document the whole migration runs on. Your top 100 pages by traffic and backlinks get mapped by hand, not by rule.

4. Take a verified backup. Not just a copy, a backup you have confirmed you can restore. Our WordPress backup guide covers the 3-2-1 approach and how to test a restore properly.

5. Build on staging first. Never assemble the new site on the live domain. A staging environment lets you test the whole thing under real conditions, and it is where you catch the problems that would otherwise be public.

6. Block staging from search engines, then write yourself a note to unblock it. Put staging behind a password or a noindex, and add a launch-day step to remove it. Forgetting this step is the number one cause of a catastrophic week-one drop.

7. Choose your timing. Move during your lowest-traffic window, and never in your busiest revenue month. Avoid launching on a Friday. If something breaks, you want a full working week to fix it.

8. Keep both environments running. Keep the old site or platform accessible and paid for through the transition. You will need it to check original content, and cutting it early removes your fallback.

Pre-launch item	Why it matters	Time to do it
Full crawl export of old site	Your only record of what existed	30 to 60 minutes
Search Console + Analytics export	Proves impact, guides priorities	30 minutes
URL map spreadsheet	Drives every redirect you write	2 to 6 hours
Verified restorable backup	Your undo button	1 hour
Staging build	Catches faults before the public does	Ongoing
Staging noindex removal note	Prevents the worst single failure	2 minutes

The Core Migration Process

The platform-specific steps differ, but the shape of the job is the same every time.

1. Set up hosting and install WordPress on your new environment. Pick hosting sized for your actual traffic, not the cheapest tier.
2. Set permalinks first. Go to Settings > Permalinks and choose your structure before importing anything. Changing it after import means re-doing every redirect. Post name is the usual choice.
3. Import the content using the platform’s export file and the matching importer, covered per platform below.
4. Move the media into your own library. Imported posts often still point at images hosted on the old platform. Those must be pulled into WordPress uploads. The Auto Upload Images plugin does this in bulk.
5. Rebuild the design. Themes do not transfer between platforms. Choose a WordPress theme close to your existing look, or commission a build. Our guide on choosing a WordPress theme helps if you are weighing options.
6. Recreate menus, forms, and widgets. Navigation, contact forms, and sidebars are always manual.
7. Update internal links. Run a search and replace across the database to point old-domain internal links at the new ones. Do not rely on your own redirects for internal navigation, that wastes crawl budget and slows every page.
8. Write the redirects from your URL map before the switch, not after.
9. Test everything on staging: links, forms, checkout, search, mobile layout, and page speed.
10. Go live, remove the noindex, submit the new sitemap, and start monitoring.

Step 7 deserves a note. Google follows internal links to understand your site structure, and a page reachable only through a redirect chain takes longer to be re-indexed. Fix the links themselves, and keep the redirects as a safety net for external traffic.

Migrating from Wix to WordPress

Wix is the hardest common migration because Wix has no real export. Plan for manual work and budget time accordingly. There is no plugin that moves a Wix site cleanly, and any tool promising otherwise is doing a page-by-page scrape.

What you can move semi-automatically: blog posts through the RSS feed.

1. Download your Wix RSS file, usually at yoursite.com/blog-feed.xml, and save it to your desktop.
2. In WordPress go to Tools > Import, find RSS, and select Install Now.
3. Select Run Importer, choose the feed.xml file, and upload.

The RSS feed often contains only recent posts rather than your full archive. Check the count against your Wix dashboard before you assume it worked.

What you have to move by hand: every static page. Home, About, Services, Contact, landing pages. Copy the text across, then re-upload the images. Wix images are served from Wix’s own domain, so even where they appear to carry over, they are not yours.

The redirect problem. If you used a custom domain with Wix, you can point the DNS at your new host and set up redirects on the WordPress side normally. If you were on a free Wix subdomain, you cannot redirect at all. In that case, leave a visible notice with a link on the old Wix homepage and keep the plan active for a few months while people find you.

Because so much is retyped, Wix is the migration where the passage-preservation rule matters most. Copy your existing wording exactly rather than “improving it while you are in there.” You can rewrite later, deliberately, once the new URLs are settled.

Migrating from Squarespace to WordPress

Squarespace gives you a proper WordPress export file, which makes this the smoothest of the site-builder migrations. It also has one trap that catches people months later.

Exporting:

1. In Squarespace go to Settings > Website > Import and Export Content.
2. Select Export, then choose the WordPress option.
3. Download the .xml file.

Importing:

1. In WordPress go to Tools > Import, find WordPress, and select Install Now.
2. Select Run Importer, upload the file, assign an author, and import.
3. Tick the option to download and import file attachments.

What comes across: your standard pages, one blog page with its posts, gallery pages, text and embed blocks.

What does not come across: product pages, album pages, event pages, audio and video blocks, product blocks, custom CSS and style changes, folders and index pages. If you have more than one blog page, only one exports. Store owners need to export product data separately as a CSV.

The trap. Imported posts frequently keep pointing at images still hosted on Squarespace’s servers. As long as your Squarespace subscription is active, everything looks fine. The day you cancel it, images across the site go blank.

Fix this before you cancel:

1. Install Auto Upload Images.
2. Go to Posts > All Posts, open Screen Options, set items per page to 999, and apply.
3. Select all posts, choose Edit from the bulk actions, select Apply, then select Update.

That forces WordPress to pull every remote image into your own media library. Verify with a spot check on a few old posts, then cancel the Squarespace plan. If you are still weighing the move at all, our WordPress vs Wix vs Squarespace comparison covers the trade-offs before you commit.

One more detail: Squarespace blog URLs typically sit under a /blog/ path. Match that structure in WordPress permalinks where you can, because URLs you do not have to change are URLs you cannot break.

Migrating from Joomla or Drupal to WordPress

Both have mature importers from the same developer, and both can usually reuse your existing domain and hosting account.

Joomla:

1. Install and set up WordPress, then set your permalink structure.
2. Install and activate the FG Joomla to WordPress plugin.
3. Go to Tools > Import and select Run Importer under the Joomla tool.
4. Enter your Joomla site URL and database details.
5. Choose what to import, then select Start / Resume Importer.

Drupal:

1. Install WordPress and set permalinks.
2. Install FG Drupal to WordPress.
3. Go to Tools > Import, select Run Importer, then Remove all WordPress Content for a clean slate.
4. Enter your Drupal FTP credentials and run the connection test.
5. Enter the Drupal database parameters and test that connection.
6. Configure how pages and posts should map, then select Start / Resume.

Both platforms use URL structures that WordPress will not reproduce, so every imported page needs a redirect. The Redirection plugin handles this at the WordPress level and lets you import redirects in bulk from a CSV, which is exactly what your URL map should produce.

Drupal migrations in particular, tend to have custom content types and fields that do not map onto posts and pages neatly. If your Drupal site is more application than website, get the mapping reviewed before you import, because untangling it afterwards costs more than planning it did.

Migrating from Static HTML to WordPress

Static HTML is the lowest-risk migration on this list. Your URLs are usually simple, there is no database, and the content is right there in the files.

You have three routes:

• Manual theme conversion. A developer turns your existing HTML and CSS into a WordPress theme, preserving the design exactly. Right when the current design is a business asset you do not want to lose.
• Child theme approach. Start with a clean, lightweight WordPress theme and build a child theme that matches the old look. Faster than a full conversion, and you keep the parent theme’s updates.
• Import the content, replace the design. Use a plugin such as HTML Import 2 or paste content into new pages, then pick a modern theme. The right call when the old design was tired anyway.

Whichever route you take, the URL rule is the same. Old HTML sites usually have addresses like /services.html. WordPress will serve /services/. Every one of those needs a 301. Keep the path structure identical wherever possible so the redirect is a one-to-one match rather than a guess.

Moving a WordPress Site to New Hosting

If you are already on WordPress and only changing hosts, this is a different job with better tools. Most quality hosts include free migration as part of onboarding, and it is worth asking before you pay for anything else.

If you are doing it yourself, these are the current options:

Tool	Free version	Paid from (2026)	Best for
All-in-One WP Migration	Yes, with an upload size limit	Unlimited extension from $69; Pro from $99/year for unlimited sites	Straightforward one-off moves
Duplicator	Yes, manual process	Basic $79/year for 2 sites; Plus $199/year for 5	Recovery features and cloud storage
WP Migrate	Database only	Paid tiers for full site	Developers running repeat migrations
Host migration service	Usually free with a plan	Included	Almost everyone moving hosts

Two notes on cost. All-in-One WP Migration’s free version has an upload size cap that most real sites exceed, so budget for the extension. And Duplicator’s advertised price is typically an introductory discount that renews at full rate, with users reporting a plan moving from $69 to around $160 over several years. Check the renewal price, not the first-year price.

Host-to-host WordPress moves rarely change URLs, which means the whole redirect problem mostly disappears. Your risks shift to PHP version mismatches, plugin conflicts on the new stack, and email deliverability. If a move like this leaves you staring at a blank page, our guides to the WordPress critical error and PHP fatal errors will get you back in.

Redirects: The Part That Decides Everything

Use server-side 301 or 308 redirects, map them one-to-one, and keep them live for at least a year. That sentence is most of what separates a 30-day recovery from a 523-day one.

Google’s own site move documentation is direct about it: use HTTP permanent redirects such as 301 and 308, implemented server-side, and “keep the redirects for as long as possible, generally at least 1 year” (Google Search Central, 2026). If your domain is changing, also submit the Change of Address tool in Search Console. That tool speeds up crawling and helps signals transfer, but it does not replace the redirects. It is an announcement, not a mechanism.

The mistakes that cause real damage:

• Redirecting everything to the homepage. If a page has no equivalent, redirect it to the closest relevant page. If nothing is relevant, let it return a 404. A mass homepage redirect gets treated as a soft 404 and passes nothing, while also dumping visitors somewhere they did not ask to be.
• Redirect chains. Old URL to interim URL to final URL wastes crawl budget and dilutes signals. Point every old URL directly at its final destination.
• Leaning on JavaScript redirects. Google can process them, but they are slower to be discovered, unreliable across crawlers, and other bots including AI crawlers often will not follow them at all. Server-side or nothing.
• Forgetting media. Images and PDFs earn traffic and links of their own. Check Search Console’s image search data before you move, and map those URLs like any other page.
• Testing after launch instead of before. Run your full redirect list through a bulk status checker on staging. Every row should return a single 301 and land on a 200.

A last detail people miss on domain moves: keep paying for the old domain for at least a year, ideally longer. If it expires and someone else registers it, your redirects die and your backlink history now points at whatever they build there.

Media, Images, and Multilingual Content

Media is the most commonly forgotten asset in a migration, because nothing obviously breaks in the page editor when it goes wrong.

Before you move, open Google Search Console and look at your image search performance. If images bring meaningful traffic, those file URLs are assets and belong in the URL map. Where you can, keep the original filenames so the URLs do not change at all. Where you cannot, redirect them like any other page.

Also check for hotlinked media. Any image still served from your old platform’s domain is on borrowed time, and it disappears the moment that account closes. Pull everything into the WordPress media library and confirm it with a crawl that reports external image sources.

Multilingual sites need one extra layer. If the site runs on WPML, the WPML Export and Import add-on moves posts, pages, taxonomies, and WooCommerce products while keeping each item assigned to the correct language. The part that needs checking by hand afterwards is your hreflang tags. Every language version must point at every other version, including itself, using the new URLs. Broken hreflang after a migration causes the wrong country’s page to rank, which looks like a ranking loss and is actually a mapping error.

The First 30 Days After Launch

Launch day is the start of the work, not the end of it. Here is the monitoring schedule that catches problems while they are still cheap.

When	What to check
Launch day	Staging noindex removed. Robots.txt allows crawling. New sitemap submitted in Search Console. Change of Address submitted if the domain changed. Spot-check 20 redirects from your map. Test every form and the full checkout.
Days 1 to 3	Search Console Coverage report for new errors. Crawl the live site for 404s and redirect chains. Confirm analytics is recording. Run PageSpeed Insights on your top templates.
Week 1	Compare Search Console clicks against your pre-launch export. Check indexed page count is climbing. Verify Bing Webmaster Tools has picked up the new site. Fix every 404 that has traffic.
Weeks 2 to 4	Track rankings for your top 20 queries. Expect movement, look for patterns rather than reacting daily. Confirm the traffic dip is closing rather than deepening.
Months 2 to 6	Monitor rankings, organic traffic, and backlinks monthly. Keep redirects live. Reclaim any broken backlinks by contacting the linking site.

Two additions for 2026. First, run your top questions through ChatGPT, Gemini, and Perplexity in week one and again at week six, and note whether your site still appears as a cited source. That is the AI half of your visibility and no dashboard reports it for you yet. Second, check Core Web Vitals on the new hosting. A migration often changes server response times in both directions, and our performance audit checklist covers what to measure.

The Migration Mistakes We See Most in Audits

[PERSONAL EXPERIENCE] When a site comes to us after a migration that went wrong, it is almost never an exotic problem. In our experience auditing these, the same four causes account for nearly all of it.

The staging noindex is still live. Weeks after launch, the new site carries a noindex tag or a robots.txt block left over from staging. Traffic looks catastrophic because Google has been told not to index anything. Two-minute fix, months of lost revenue.

There was no URL map, so redirects were written from memory. Someone redirected the pages they remembered and let the rest 404. The pages that get forgotten are usually old blog posts, which are also the pages carrying the backlinks.

The content was rewritten during the move. The migration and the redesign happened together, so when traffic dropped nobody could tell whether it was the redirects, the new template, or the new copy. Diagnosis takes weeks that a staged approach would have avoided.

Nobody checked the old platform was still paid for. The Squarespace or Wix plan lapsed, and every image the new site was quietly still borrowing went blank at once.

None of these need advanced skills to prevent. They need somebody to own the checklist and go through it before launch instead of after. If you would rather not be that person, our WordPress migration service handles the mapping, the redirects, and the monitoring window, and a site audit will tell you what state a migration already done has left you in.

Ready to Move Without Losing What You Built

A migration is a routine job with an unforgiving detail: the URLs. Move the content and forget the mapping and you land on a better platform with a fraction of the traffic, which is the worst possible trade. Do the crawl, build the map, write the redirects, and separate the move from the redesign, and you land with everything intact.

If you want the mapping, redirects, and post-launch monitoring handled by people who do this regularly, our WordPress migration service covers the whole process. If a migration has already happened and the numbers are not recovering, book a site audit and we will tell you exactly where the traffic is leaking and what it takes to get it back.