Wix or Shopify to WordPress: A Migration Plan

Migrating from Wix or Shopify to Self‑Hosted WordPress

Moving from Wix or Shopify to self-hosted WordPress can provide more control over application files, data and integrations, while adding maintenance responsibilities. Start with the requirements your current platform cannot meet. A migration needs a content inventory, tested imports, URL mapping and a plan for live transactions. Better speed, lower costs and unchanged search rankings are possible goals, not automatic results.

In this guide, we’ll walk through a migration workflow from Wix or Shopify to self‑hosted WordPress. You’ll get a practical hosting checklist, a clear SEO migration plan, and concrete examples of what to do (and what to avoid). The goal: preserve content, reduce SEO disruption, and build a hosting setup you can maintain and scale.

Why Move from Wix or Shopify to Self‑Hosted WordPress?

Before talking about servers and redirects, it helps to be clear on why you are moving. That clarity will guide your hosting and architecture decisions.

1. More Control and Flexibility

On Wix or Shopify, customization is bounded by what the platform and your plan support. With self‑hosted WordPress:

• Choose a hosting environment, including shared hosting, VPS or dedicated infrastructure, with the access and resources your plan actually provides.
• Select or build a compatible WordPress theme; platform-specific Wix or Shopify themes do not become WordPress themes automatically.
• Add supported plugins or custom code, accounting for licensing, compatibility and maintenance.
• Integrate external APIs, CRM, ERP or marketing services when they provide the necessary supported access.

2. Better Technical SEO Control

Wix and Shopify have improved a lot, but they still abstract many technical details. On self‑hosted WordPress, depending on your hosting plan and server access, you can control:

• URL structures and custom taxonomies.
• Server‑level redirects (not only app‑level).
• Caching layers (PHP, full‑page cache, CDN configuration).
• Security headers, HTTP/2 / HTTP/3, and compression settings.

If you want a deeper look at how hosting decisions affect rankings, see our guide on whether server location affects SEO and speed.

3. Long‑Term Cost and Scaling

As you grow, SaaS platforms often become expensive: higher plans, app fees, and transaction percentages. With WordPress on your own hosting, you can scale resources (CPU, RAM, NVMe storage) based on actual usage. Compare total costs, including maintenance, paid themes and plugins, backups, and payment processing; self‑hosting is not automatically cheaper. You are free to move between shared hosting, VPS, dedicated servers, or even host your own hardware with colocation when you reach serious scale.

Step 1: Hosting and Domain Checklist Before You Touch Anything

A calm, clean migration starts with the right infrastructure. Use this checklist before moving a single page from Wix or Shopify.

1. Choose the Right Hosting Tier

Consider three hosting options for a new WordPress project:

• Shared hosting: Good starting point for small business sites, blogs, or low‑traffic stores. Check whether the plan includes a control panel (e.g., cPanel), a one‑click WordPress installer, managed email, and backups.
• VPS hosting: Choose CPU and RAM capacity for your workload and confirm the available administrative access. Suitable for growing WooCommerce stores or content sites needing more PHP workers, Redis, custom Nginx/Apache configs, or Docker setups, provided someone can manage the server.
• Dedicated server or colocation: Consider for high‑traffic or compliance‑sensitive projects needing dedicated hardware and custom networking. Compliance and multi‑region redundancy require separate planning; neither follows automatically from choosing this hosting tier.

If you are unsure which way to go, our comparison of different web hosting types and when each one makes sense is a good pre‑reading.

2. Confirm PHP, Database and Storage Specs

Check the requirements for the WordPress and WooCommerce versions you will install, together with the demands of your actual theme, plugins and traffic:

• A currently security-supported PHP version compatible with your WordPress release, themes, and plugins, with OPcache enabled.
• MariaDB or MySQL with sufficient RAM for buffer pools.
• Fast SSD or NVMe storage for database and file I/O.
• Enough RAM for PHP‑FPM workers, especially for WooCommerce.

Under‑sizing the server is one of the easiest ways to turn a neat migration into a slow site, even if SEO redirects are perfect.

3. Plan Your Domain and URL Strategy

Most Wix and Shopify sites use a single primary domain, but this is the moment to decide:

• Can you keep the same domain and useful URL paths to avoid unnecessary changes?
• Are you moving from a platform-owned subdomain to your own domain? Your new host cannot redirect a hostname controlled by the platform; check its supported options.
• Will the blog and store stay together, or does the proposed subdomain/subdirectory structure need new routing and URL mappings?
• Who controls registration, authoritative DNS and email? A registrar transfer is separate from changing web hosting and is not required for the move.

If you are considering a change in structure, our article on choosing between subdomain and subdirectory for SEO and hosting will help you avoid common pitfalls.

4. DNS and Nameserver Plan

Before launch day, decide where DNS will live:

• Keep existing authoritative DNS and update only the necessary web A/AAAA and www records there.
• Or prepare a complete zone with another DNS provider before changing nameservers, using the real nameserver hostnames assigned to that service.
• Preserve MX, SPF, DKIM, DMARC, CAA, SRV and verification records for services that stay in place. A website move does not move mailboxes.

Plan DNS publication and cache lifetimes separately. If DNSSEC is enabled, use a coordinated key-preserving migration supported by both providers. Otherwise remove the old DS, confirm removal at the parent and wait its previous TTL while the old zone stays signed. Then change nameservers. Before publishing the new DS, wait for the previous TTLs of the old NS/delegation records to expire, and verify the new delegation and the signed zone at the new provider. A correct response from the new authoritative server alone does not establish that old delegations have left resolver caches. This fallback temporarily removes DNSSEC protection. Changing only A/AAAA records does not itself require disabling DNSSEC. Our DNS provider comparison helps with the wider choice.

5. SSL/TLS and Security

Make sure your hosting plan supports:

• A supported issuance and renewal method for a TLS certificate covering the production names.
• Appropriate TLS configuration, with any HTTP/2 or HTTP/3 support checked against the actual server and clients.
• Defined responsibilities for server updates, access controls, backups and any included WAF or monitoring service.

We will later add WordPress‑level security, but the base must be solid.

Step 2: Pre‑Migration SEO Audit on Wix or Shopify

Before we touch WordPress, we want a complete picture of your current site: URLs, content, and performance. This becomes the blueprint for preserving content and reducing SEO disruption.

1. Crawl and Export All Existing URLs

Use a crawler (e.g., Screaming Frog or similar) to export discovered URLs from your Wix or Shopify site. Reconcile the crawl with sitemaps, platform exports, analytics, and Search Console data to find URLs the crawl missed. Include:

• All pages and posts.
• Product URLs and collections (for Shopify).
• Blog articles.
• Important landing pages, categories, tags.

Save this as old‑urls.csv. This is the base for your redirect map.

2. Document Organic Traffic and Rankings

From Google Analytics and Google Search Console, export:

• Top landing pages by organic traffic (last 3–6 months).
• Queries bringing traffic to those pages.
• Pages with backlinks (from your preferred SEO tool).

These are the URLs that must be preserved as closely as possible. If you must change their structure, you need clean 301 redirects and consistent internal linking.

3. Capture On‑Page SEO Settings

Capture these settings for all URLs where available. Prioritize manual review by business importance and traffic, then check the remaining inventory rather than treating an arbitrary sample size as complete:

• Title tags and meta descriptions.
• H1 headings.
• Canonical tags (if any).
• Structured data (product schema, article schema, etc.).

We do not want to blindly change everything at once. Keeping titles, metas, and headings stable makes it easier to spot issues after the migration.

4. Decide What Not to Migrate

Identify content that may need a separate retirement decision. Low traffic alone does not establish that a page is unnecessary:

• Thin content pages that never received traffic.
• Outdated campaigns or landing pages.
• Duplicate or near‑duplicate product variants.

For content you intentionally drop, use a 301 redirect only when there is a relevant replacement that serves the same user intent; otherwise return a proper 404 (not found) or 410 (gone). For more detail on when to use 301, 302, 404 or 410, see our guide on what HTTP status codes really mean for SEO and hosting.

Step 3: Build a Clean WordPress Environment First

Build the destination in an access-controlled staging environment, for example staging.example.com, before changing public DNS. Authentication protects access; noindex is an additional indexing instruction, not an access control. Keep real payment capture, customer notifications and stock integrations disabled or in supported test modes. Test external payment callbacks through the provider’s supported test endpoint: your local hosts override cannot redirect an external service’s requests.

1. Install WordPress and Apply Basic Hardening

After creating your hosting account or VPS:

1. Install WordPress via the control panel or manually.
2. Use a non‑generic admin username and a strong password.
3. Set proper file permissions and disable file editing from the dashboard.

Our WordPress hardening checklist walks through practical steps like configuring SALT keys, limiting XML‑RPC, and using tools such as UFW for firewall management and Fail2ban for automated bans if you are on a VPS.

2. Choose a Theme and Essential Plugins

For a migration from Wix or Shopify, keep the first setup lean:

• Theme: Lightweight, well‑coded theme optimized for performance and WooCommerce support (if you are migrating a store).
• SEO plugin: Rank Math, Yoast, or a similar SEO toolkit to manage titles, metas, sitemaps, and schema.
• Caching plugin: A full‑page caching solution compatible with your server stack (and WooCommerce, if used).
• Security plugin: To harden logins and scan for threats.
• Backup plugin: Linked to remote storage or your hosting backup system.

For a deeper look at backup strategies, see our guide to WordPress backup strategies on shared hosting and VPS.

3. Configure Core WordPress Settings

In the WordPress admin:

• Permalinks: Match your existing structure as closely as possible. For example, if Shopify products use /products/product-name, aim to preserve the full path, not just the product slug. Map any changed paths to redirects.
• Timezone and language: Set correctly for logging and scheduling.
• Search engine visibility: On staging, keep “Discourage search engines from indexing this site” enabled. Disable it on the production site at launch, not on a staging copy that remains separate.

4. Set Up WooCommerce (for Shopify Migrations)

If you are moving from Shopify to WordPress + WooCommerce:

• Configure WooCommerce currency, taxes, shipping zones and required extensions for the real business rules.
• Plan complete product and category paths; a matching product slug alone does not preserve the old URL.
• Configure payment gateways using supported test credentials and endpoints. Test the browser flow, callbacks, order status, tax, shipping and email without charging real customers or updating production stock.
• Record which settings, credentials and webhook URLs must change at launch; do not copy staging integrations blindly into production.

Step 4: Content and Data Migration Workflow

With infrastructure and WordPress ready, we can bring your content across. The exact approach depends on whether you are coming from Wix or Shopify.

1. Migrating from Wix to WordPress

A Wix site depends on Wix’s proprietary platform and cannot be downloaded as a functioning site to run on your WordPress host. Rebuild the design and functions in WordPress, then migrate the content you can access:

• Use supported content exports or RSS only after checking what they contain. Do not treat Wix blog RSS as a complete archive export; check its limited coverage, then reconcile the post count and complete text against the inventory.
• Recreate static pages, navigation, forms and other functions in WordPress.
• Download and import needed media, preserving its page association, captions and alt text; verify that the finished pages no longer rely on old platform media URLs.
• Check dates, authors, categories and tags, and fill gaps through a supported export method or controlled manual work.

For each migrated page or post:

• Reproduce headings (H1/H2), content structure, and internal links.
• Re‑set title tags and meta descriptions in your SEO plugin.
• Assign the correct featured image and categories/tags.

2. Migrating from Shopify to WooCommerce

Shopify provides separate exports for different store data. A product CSV is not a complete store backup, and a Shopify export does not automatically match a WooCommerce import schema:

• Products: Export product CSV data while preserving related variant and image rows. Product image files are not embedded in the CSV.
• Inventory: Export location-specific inventory separately when needed; do not assume the product file represents all locations.
• Customers: Export profiles and required supported fields, keeping existing communication preferences.
• Orders: Export order information and appropriate transaction records separately. Reconcile payments, refunds and fulfillment against the actual provider and business records.
• Other data: Pages, blog posts, menus, apps, subscriptions, gift cards, payment tokens and settings need a separate supported plan. Do not assume a theme download or CSV reproduces them in WordPress.

Use a repeatable import process with a preserved original export and a record of field mappings:

1. Take dated source exports and compare their scope and counts with your inventory. Record the export cutoff and what can still change afterward.
2. Map product fields to the selected WooCommerce importer, including parent–variation relationships, identifiers, attributes, categories and stock. Transfer unsupported SEO fields and image alt text separately.
3. Test a small set of representative products before the full import. Check that rerunning an update does not duplicate products or detach variations.
4. Keep source images accessible until they are downloaded and assigned in the new Media Library. If remote imports fail, upload the files directly and correct the mappings.
5. Use a compatible customer-import process and prepare account activation or password setup; do not assume existing credentials survive.
6. Import historical orders only with a tool and mapping that preserve the needed relationships and statuses. Suppress unintended charges, emails and stock deductions. Keep an access-controlled archive for history that will not be migrated, with a separate plan for open orders and refunds.

After importing, visit some representative products and categories and verify:

• Prices, variations, stock levels.
• SEO fields (titles, metas, slugs).
• Product images and galleries.

3. Create the Redirect Mapping (Old → New URLs)

Now combine your old‑urls.csv (from the crawl) with a spreadsheet of your new WordPress/WooCommerce URLs. For each old URL, assign:

• Keep a URL unchanged when its content and full address remain the same; do not redirect it to itself.
• Map changed pages to an equivalent destination, or to a genuinely relevant replacement when the original content is retired.
• Return 404 or 410 for retired content with no suitable replacement; do not send everything to the homepage.
• Mark platform-owned hostnames and CDN addresses you cannot redirect. Update references you control and evaluate the old platform’s supported options.

This mapping is the heart of your SEO‑safe migration. Implement moved‑URL mappings as server‑level 301 redirects (on Apache or Nginx) where your hosting permits; a redirect plugin is an alternative. Handle retired URLs separately.

Step 5: Reduce SEO Migration Risk: Technical Runbook

With content and mapping ready, complete the SEO‑critical tasks that reduce migration risk. Rankings and traffic can still fluctuate after launch.

1. Mirror or Carefully Improve URL Structures

Preserving your old URL structure avoids unnecessary URL changes and redirects. When that’s not possible (for example, moving from /pages/ on Shopify to / in WordPress), keep changes minimal and logically grouped. Some tips:

• Avoid adding unnecessary date prefixes if you did not have them before.
• Keep slugs readable and as close as possible to previous ones.
• Do not change URLs for your top‑performing pages unless you absolutely must.

2. Implement 301 Redirects at Server Level

The following example is for an Apache 2.4 site whose WordPress installation is in the document root, with mod_rewrite and the required .htaccess overrides enabled. Have the host confirm that the applicable directory also permits FollowSymLinks or SymLinksIfOwnerMatch. Put these custom rules before the WordPress front-controller rules and outside the block WordPress manages. Replace www.example.com and both destination paths with your real final HTTPS URLs. These are public page redirects for GET/HEAD requests, not payment or webhook endpoints:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(?:GET|HEAD)$
RewriteRule ^old-blog-post/?$ https://www.example.com/new-blog-post/ [R=301,L]

RewriteCond %{REQUEST_METHOD} ^(?:GET|HEAD)$
RewriteRule ^products/blue-shirt/?$ https://www.example.com/shop/blue-shirt/ [R=301,L]

Unlike Apache’s prefix-based Redirect directive, these patterns match only the named path, optionally with its trailing slash; they do not match deeper paths such as /products/blue-shirt/reviews. In root .htaccess the matched path has no leading slash. The fixed targets have no query string, so existing query parameters are retained by default. For a subdirectory install or different server, adapt the rules to that context. Before generating more rules from the URL map:

• Verify each destination is distinct, relevant and returns the intended page; redirects must not form loops or chains.
• Check the effective Apache configuration, then test exact paths, slash variants, unrelated prefixes, deeper paths and query parameters on the isolated destination.
• Test all mappings automatically where possible and inspect important pages manually. Confirm that source and destination HTTPS names work.
• Handle form submissions, APIs, payment callbacks and other non-GET traffic with their integration-specific migration plan; do not route them through generic page redirects.

For a deeper understanding of how Google interprets these codes, revisit our article on HTTP status codes for SEO and hosting.

3. Keep Meta Data, Headings and Canonicals Stable

For your top pages and products:

• Re‑use or minimally tweak existing title tags and meta descriptions.
• Keep H1 headings consistent with previous versions.
• Ensure canonical URLs point to the intended production URLs, not staging or retired Wix/Shopify URLs.

This makes it much easier to see whether traffic changes are from the platform move or content changes.

4. Rebuild XML Sitemaps and Robots.txt

Your SEO plugin should generate new XML sitemaps automatically. Check that:

• Only canonical, indexable URLs are listed.
• No staging or test URLs are present.
• Product, category, and post sitemaps are included where relevant.

Update robots.txt to reference these new sitemaps and ensure you are not blocking important sections accidentally.

5. Preserve International Targeting (If Any)

If you previously used multiple languages or regions, keep that structure consistent. WordPress supports this via multilingual plugins and hreflang tags. If this is part of your setup, our deep dive on doing hreflang correctly with ccTLDs, subdirectories, and subdomains is worth reviewing during planning.

6. Performance Tuning for Core Web Vitals

Compare the destination with your baseline using representative pages and sessions. Core Web Vitals are LCP, INP and CLS; TTFB is a separate diagnostic measure. Depending on the stack:

• Cache public pages with compatible layers, excluding cart, checkout, account pages and personalized sessions at every applicable cache layer. Verify with separate customer sessions.
• Serve appropriately sized images in supported formats and check fallback behavior and alt text.
• Evaluate CSS/JavaScript changes separately; combining or minifying files is not automatically faster and can break interactions.
• Use a CDN where it helps the actual audience and workload, while preserving dynamic-route and cache exclusions.

Better Core Web Vitals can improve user experience, but they do not compensate for broken redirects, missing content or indexing errors.

Step 6: DNS, Launch, and Post‑Launch Monitoring

Once content is ready, redirects are configured, and staging checks are done, plan the actual cut‑over from Wix/Shopify to your dchost.com server. For a live store, arrange a final data sync and a controlled pause in orders and edits so changes made after the initial export are not lost or duplicated.

1. Prepare DNS with Smart TTLs

A few days before launch:

• Lower TTL on the records you will change, such as A/AAAA or CNAME records (e.g., from 1–4 hours down to 300 seconds, where supported). Allow at least the previous TTL to elapse before cut‑over.
• Confirm you know where DNS is managed (domain registrar, dchost.com panel, or external DNS provider).

Lowering TTL in advance affects subsequent caching; it does not shorten answers already cached or parent NS/DS lifetimes. Negative answers and provider publication delays also matter. There is no instant or universally timed switch. Our TTL planning guide provides more detail.

2. Final Pre‑Launch Checklist

Complete ordinary staging tests first. For final checks under the production hostname, configure that name on the new server and target it using a local hosts override or an equivalent method preserving Host and TLS SNI. This changes only the testing client’s destination. Prepare a certificate for the production names separately, using supported DNS-01 validation or correctly routed CA validation requests; a local override does not affect the CA’s DNS lookups.

• Verify the certificate actually served for the production names, its chain and expiry, plus redirects and mixed content. With Let’s Encrypt HTTP-01, public port 80 and the challenge path must work; published IPv6 must also be correct.
• Back up files and the database. Preview temporary-to-production URL changes with a tool that handles serialized WordPress data, then verify links, canonicals, hreflang and sitemaps.
• Test forms, search, account access, checkout, payment callbacks, tax, shipping and email with the appropriate test configuration; local browser targeting does not redirect third-party callbacks.
• Keep staging authenticated and its indexing restrictions in place. Remove temporary restrictions only from the production site at launch; do not expose a separate staging copy.
• Confirm analytics and Search Console verification, required email DNS and delivery settings, production credentials and the rollback decision owner.

3. Switch DNS to the New Server

Choose a change window based on the business’s tolerance for paused writes, not a promise that DNS will finish within that window. Agree on stop conditions such as payment failure, inconsistent stock/orders, missing critical content or widespread HTTPS/5xx errors. At the chosen time:

1. Pause orders and content changes using supported controls. Account for other sales channels, pending payments, refunds and stock integrations; record incoming events without losing them.
2. Take the final exports and destination backup. Reconcile the data since the initial import using stable order, payment and product identifiers; avoid duplicate processing, emails or stock deductions.
3. If data, HTTPS, redirect or payment checks fail, postpone the DNS switch. Otherwise publish only the prepared web records or nameserver change, including the planned DNSSEC sequence where needed.
4. Enable production integrations and remove production-only staging restrictions. Verify the intended site and email from external networks.
5. Open writes only on the selected authoritative business system after checks pass. Keep the old platform available for transition and recovery while preventing it from taking independent orders.

Some visitors can still reach the old platform while DNS caches expire. DNS does not synchronize orders, uploads or stock, so a content freeze alone is insufficient for a store. Keep monitoring both environments and their integration queues. Preserve old media access until imports are complete. If the domain changed, maintain valid HTTPS and redirects for the old domain rather than canceling its service with the old storefront.

Rollback if Launch Checks Fail

The designated owner should stop the rollout when the agreed checks fail. Pause writes in both environments and preserve new data, logs and pending payment/integration events. If the new site has accepted orders or updates, do not merely reverse DNS or restore an old database over them. Reconcile orders, payments, refunds and stock into the chosen recovery system through supported imports or controlled manual records. If reconciliation is incomplete, keep writes paused.

After the old destination’s data, HTTPS, checkout and integrations are verified, restore the necessary web DNS values. A nameserver migration needs its own safe NS/DS rollback sequence; do not blindly republish an old DS. Continue watching both destinations through cache expiry, then reopen writes only on the verified system. Check that payment capture, fulfillment and stock changes were not repeated.

4. Post‑Launch SEO and Error Monitoring

Monitor closely from launch, then continue according to traffic, crawl frequency and the changes observed:

• Investigate unexpected 404s: restore missing content or map it to a relevant replacement; retain proper 404/410 responses for intentionally removed content.
• Check Search Console indexing, sitemap and verification status, plus impressions and important queries.
• Compare traffic and conversion data with the baseline, allowing for seasonality, tracking changes and other causes.
• Measure Core Web Vitals and TTFB separately; investigate regressions instead of assuming the platform move improved performance.
• Continue reconciling orders, refunds, stock and integration queues until the old system’s outstanding obligations are resolved.

Search visibility can fluctuate during processing, and correct redirects do not guarantee stable rankings. Investigate substantial changes by checking discovery, indexing, content, redirects and measurement before attributing everything to the new host.

Step 7: Backups, Security, and Long‑Term Maintenance

After a successful migration, your job is not done. WordPress gives you more control, but also more responsibility. A stable setup combines automated backups, regular updates, and security hardening.

1. Reliable Backup Strategy

At minimum, you want:

• Back up both application files and the database to storage separate from the production server.
• Set frequency and retention from the acceptable data-loss window and recovery needs; a busy store may need more protection than a daily snapshot.
• Test restoration in isolation and include required configuration and integration recovery instructions.
• Preserve source-platform exports and account access through the migration; those exports may not recreate a functioning store by themselves.

We covered implementation details for shared hosting and VPS in our guide on WordPress backup strategies. The key is automation and regular restore testing.

2. Keep WordPress, Themes and Plugins Updated

Schedule a regular maintenance window to:

• Back up and test WordPress, theme and plugin updates on staging before applying material changes to production.
• Remove unused components after checking dependencies; review accounts and roles.
• Check checkout, forms, email and scheduled actions after updates. A rollback involving database changes must preserve any new orders or other writes.

If you are on a VPS or dedicated server with dchost.com, also keep the OS and PHP versions updated with security patches (ideally with a staging environment to test larger upgrades).

3. Monitor Uptime and Performance

Use an uptime monitoring tool and optionally server metrics (CPU, RAM, disk, database health). This helps catch:

• Plugin conflicts causing 5xx errors.
• Unexpected traffic spikes.
• Slow queries or overloaded PHP workers.

Compare monitoring results with the contract’s measurement period, scope and exclusions. An SLA does not mean the service can never fail or that recovery is automatic. Our guide to understanding 99.9% uptime in hosting SLAs explains the distinction.

Conclusion: A Calm Path from Wix/Shopify to WordPress

A Wix or Shopify migration combines a rebuild with data transfer, DNS publication and ongoing business operations. Inventory what can be exported, test imports and URL mappings, prepare production-name HTTPS, and control writes during cutover. A documented reconciliation and rollback plan makes failures manageable; it does not guarantee unchanged rankings or uninterrupted service.

WordPress gives you more options for application and hosting management, with corresponding maintenance work. When considering DCHost or another provider, confirm resources, backup recovery, DNS/email responsibilities and the support included in the exact plan. Use the inventory, test results and rollback plan to assign responsibilities and judge when the migration is complete.