Categoría: English

A quiet but real trend right now: people are moving back to WordPress from Wix, Shopify, and even headless CMS setups, chasing more control and lower long-term costs. What they’re not chasing — and what they usually get anyway — is a migration that quietly wipes out months or years of SEO equity. Failing to plan the redirect layer alone can cause organic traffic to collapse — documented cases show 50-70% losses within two weeks of launch. That’s not a rare worst-case; it’s what happens by default when URLs simply don’t match up.
None of this is exotic. It’s a checklist problem, not a technical mystery. Here’s how to do it properly.

Step 1: Inventory everything before you touch anything

Before you export a single file, crawl your current site and get a full list of every URL that exists. Screaming Frog SEO Spider (free for up to 500 URLs) will generate this for you in minutes. Save it as a spreadsheet — this becomes your master checklist for the entire migration.

While you’re at it, pull two more reports from your current analytics:

• Top landing pages by organic traffic (last 3-6 months) from Google Search Console
• Pages with backlinks from whatever SEO tool you use

These are the URLs that matter most. If you’re moving off a platform that restricts exports — Wix in particular blocks direct database access, which routinely adds hours to a migration — this inventory is the only reliable map you’ll have of what needs to survive the move.

Step 2: Know what actually transfers and what doesn’t

This is where most DIY migrations go wrong: people assume more comes over automatically than actually does.

• Blog posts usually export via RSS feed reasonably well.
• Static pages, navigation, forms, and galleries almost never transfer cleanly — expect to rebuild these manually in WordPress.
• Images often stay hosted on the old platform’s servers even after «migration» unless you specifically download and re-upload them. A plugin like Auto Upload Images can force WordPress to pull and save hotlinked images locally.
• Meta titles and descriptions set in Wix or Shopify do not export. You’ll need to re-enter these in WordPress using an SEO plugin (RankMath or Yoast).

Budget for this rebuild work upfront rather than discovering it mid-migration.

Step 3: Build the redirect map before launch, not after

This is the single highest-leverage step in the entire process. For every URL in your Step 1 inventory, map where it will live on the new WordPress site — even if the new URL structure is identical, confirm it explicitly rather than assuming.

Install a redirect plugin (Redirection or RankMath’s redirect manager) and set up 301 redirects for every URL on your list before you point your domain at the new site. A 301 tells Google and every visitor’s browser «this moved permanently,» preserving both link equity and user experience. Skipping this step is the single most common cause of the traffic collapse mentioned above.

Step 4: Never migrate directly on your live domain

Set up the new WordPress site on a staging subdomain (staging.yoursite.com) first. Import content, rebuild pages, configure redirects, and test everything there — while your current site keeps running and keeps ranking. Only point your actual domain at the new site once staging has passed a full review.

Before going live, confirm:

• PHP 8.3 or higher on your new hosting (older versions cause timeout errors on large imports)
• Every page and post from your Step 1 inventory has a live counterpart
• Every redirect actually resolves to the correct destination (test a sample manually, don’t just trust the plugin)
• Forms, payment gateways, and any third-party integrations (CRM, email) work end to end

Step 5: The first 30 days after launch

Migration risk doesn’t end at launch — it front-loads into the following month:

• Submit your new XML sitemap to Google Search Console and Bing Webmaster Tools immediately
• Monitor Search Console daily for crawl errors and 404s in the first two weeks
• Compare organic traffic week-over-week against your pre-migration baseline
• Fix any 404s you find by adding the missing redirect — don’t wait for a batch cleanup later

The bottom line

Nearly every migration horror story traces back to one of two things: no complete URL inventory before starting, or no redirect map before going live. Both are fully preventable with an afternoon of preparation. The technical rebuild is the easy part — protecting the SEO equity you already earned is where the real work is.

Every AXRGlobal hosting plan includes staging environments and migration support — so your next move is backed by a team that’s done it before.

Plan your migration

For years, the standard WordPress security advice was simple: keep everything updated, and you’re mostly safe. That advice broke down in 2026.
A run of supply chain attacks has shown that a plugin can be fully updated, from a fully trusted source, with a fully clean install history — and still be the thing that compromises your site. This isn’t a scare story. It’s a specific, documented shift in how WordPress sites are actually getting breached, and it changes what “trustworthy plugin” needs to mean.

What actually happened

In early 2026, an attacker bought a portfolio of more than 30 established WordPress plugins — with a combined 400,000+ installations — through the marketplace Flippa. The first code commit after the sale was a backdoor. It sat dormant for eight months, doing nothing, before activating and injecting spam into every site running those plugins. Because the plugins came from WordPress.org with a long, clean commit history, none of the standard trust signals — install count, years active, “verified” repository status — caught it.
A separate incident hit ShapedPlugin, a vendor with 400,000+ free-plugin installs. Attackers compromised the company’s build pipeline rather than any individual plugin file, so premium updates pushed through the official system carried a backdoor capable of stealing credentials, two factor codes, and WooCommerce order data — while hiding itself from the plugin list to avoid detection.
Gravity Forms, running on roughly a million sites including major organizations, was hit by a similar attack on its distribution infrastructure. Notably, sites using automatic updates were unaffected — the compromise only reached people who manually downloaded installers directly from the vendor’s site during the breach window.
The common thread: these weren’t code vulnerabilities. They were trust-model failures. The attacker didn’t break in — they bought their way into a position of legitimate access.

What this means for how you vet plugins

The old checklist — active installs, star rating, “last updated recently” — still matters, but it’s no longer sufficient on its own. Add these:
Check for ownership changes. If a plugin you rely on has recently changed maintainers, or was acquired by a new company, that’s now a legitimate reason to pause and re-evaluate, even if the code looks identical. The WordPress.org changelog and support forum threads will usually mention a transition if one happened.
Prefer automatic updates from the official repository over manual installers. The Gravity Forms incident specifically shows why: automatic updates through WordPress.org’s infrastructure were untouched, while manually downloaded installers during the compromise window were not. This is one case where the “less convenient, more careful” instinct is backwards — automation through the trusted channel was actually the safer path.
Reduce your total plugin count. Every additional plugin is an additional vendor relationship you’re implicitly trusting, and an additional codebase that could change ownership without you noticing. If two plugins do overlapping jobs, consolidate.
Watch for unexpected new files or directories after an update. Recent attacks specifically relied on this going unnoticed. If you have the technical means, a basic file-integrity monitor (many security plugins include one) flags new files appearing outside a normal update.
Consider a managed security service for anything business-critical. Services like Patchstack or Wordfence Premium track disclosed vulnerabilities and known supply-chain incidents faster than most site owners can monitor manually — over 250 new plugin and theme vulnerabilities are being disclosed weekly in 2026, and a meaningful share are exploitable without authentication.

What to do if you’re running an affected plugin

If you discover you’re running a plugin caught in a supply-chain incident:
1. Deactivate and remove it immediately — don’t just wait for a “clean” update
2. Rotate all admin passwords and API keys, since some of these attacks specifically harvested credentials
3. Check for unfamiliar admin users or unexpected files added around the time of the compromise window
4. Scan with a security plugin capable of detecting known indicators of compromise for that specific incident
5. If the plugin handled payments, forms, or customer data, treat it as a data exposure and follow your own breach-notification obligations

The bottom line

This shift doesn’t mean plugins are unsafe to use — WordPress’s entire ecosystem depends on them, and most plugins never experience anything like this. It means “trusted” needs to include “who currently owns this, and how do they distribute updates,” not just “how long has this existed.”
Fewer plugins, verified through official update channels, monitored by a service that tracks these incidents in real time, is the realistic version of plugin trust in 2026.
We track WordPress plugin discussions across different sources daily — surfacing plugin vulnerability reports as they emerge in real community conversations. If you want someone watching your plugin stack so you don’t have to, get in touch. We’ll alert you the same day a new signal appears on our radar.

Write us in Contact