How to bullet-proof your next WordPress migration in Europe

Moving a WordPress site to a new host, domain, or folder structure is a bit like moving house in a foreign city: one forgotten forwarding address and your mail—traffic, rankings, revenue—never arrives. The good news? Most disasters are caused by tiny, preventable oversights, not by arcane server magic. Below is a field-tested checklist used by the engineers who support WP in EU, the free hosting initiative for European non-profits and start-ups. Follow it and you will catch 90 % of problems before users (or Google) ever notice them.

Why migrations go sideways—and why they don’t have to

Over the past three years WP in EU has helped 1,400+ sites relocate inside Europe. Roughly 62 % of support tickets filed after go-live track back to three classic mistakes:

• Staging left crawlable and later competing with the production site for rankings.
• Database URLs hard-coded in widgets or page-builder blocks that never got updated.
• Mixed-content warnings triggered when only the main domain gets an SSL certificate, not the CDN or subdomain where images are stored.

Notice that none of these require a computer-science degree to fix; they simply need a repeatable process. That process can be broken into three phases: staging checks, launch-day checks, and the two-week post-launch watch.

Phase 1: Lock down staging before anyone else sees it

Your staging environment is a rehearsal stage, not a preview for the public. Treat it like one.

Block search engines—yes, even the “good” ones

Add HTTP basic authentication or an IP allow-list, then drop a disallow rule in robots.txt. Google will sometimes ignore robots.txt if an external link points to the staging domain, so authentication is the only bullet-proof route. While you are at it, deactivate XML sitemap generation on staging; you do not want a rogue plugin pinging search engines with unfinished URLs.

Snapshot everything twice

Take a file-level backup and a database dump before you change a single character. Store one copy off-site (S3, Wasabi, or your preferred EU provider) and one on the new host. WP in EU users can click “Create Checkpoint” in the dashboard; the snapshot is encrypted at rest and kept for 30 days at zero cost.

Run a dry-run search-replace

WP-CLI’s search-replace command is brilliant, but it is also case-sensitive and will skip certain meta-keys unless you add the --all-tables flag. After the dry run, export a CSV of proposed changes and eyeball at least 50 rows for odd serialised data. When you see something like s:7:"http:// you know the length integer is about to break; fix the source data first.

Phase 2: Launch day—15 minutes that decide the next six months

Pick a low-traffic window (for European sites 03:00–05:00 CET works well) and have at least two people on call: one handling DNS, the other watching real-time logs. The following sequence keeps surprises to a minimum.

1. Put the old site in read-only mode. A simple wp maintenance-mode activate prevents new comments or orders during the switch-over.
2. Export the final database, import it on the new host, and run the search-replace for the new domain.
3. Raise the PHP memory limit to 256 MB temporarily; migration scripts often bump against the default 128 MB.
4. Update DNS with a 300-second TTL that you lowered 24 h earlier. Cloudflare or any EU registrar such as INWX lets you do this instantly.
5. Within five minutes hit the site from an external location (GTmetrix has test nodes in London and Frankfurt). If the homepage loads, you are 80 % home.

Keep a browser tab open on the new Search Console property. If the coverage graph spikes red, you still have time to roll DNS back before the indexes shuffle.

Phase 3: The 14-day vigil that protects your SEO

Google’s index is a living cache; it does not forget old URLs overnight. During the first two weeks your crawl budget is re-allocated, and small errors can snowball into ranking loss. Do the following every 48 hours:

• Run Screaming Frog or Sitebulb with the “response time” metric enabled. Any URL above 1.2 s needs optimisation; EU visitors expect sub-second mobile speeds.
• Check Search Console for 404 spikes. Export the list, then bulk-redirect in Nginx or use the free Redirection plugin. Avoid wild-card redirects if your slugs changed; precise regex keeps link equity intact.
• Audit hreflang tags if you operate in multiple EU languages. A common pitfall is forgetting to update the paths after the domain swap.