WordPress migrations — hosting changes, domain moves, theme rebuilds, or permalink structure shifts — often resemble urgent turnarounds: fixed deadlines, revenue pressure, and organic risk. Better hosting alone does not “save rankings”; you protect them with consistent URLs, a disciplined redirect map, and parity on money templates so internal links and commercial copy still tell the same story after launch.
If Google sees a different URL set or the same content duplicated across hosts without controls, you lose continuity. Migration is documentation and testing — not only dumping the database.
Before migration: inventory and baseline
- Full or sampled crawl plus CMS exports and Google Search Console URL lists.
- Flag priority landings: revenue, leads, and queries you cannot afford to slip.
- Capture duplicates: HTTP/HTTPS, www/non-www, trailing slashes, query parameters — decide canonical winners.
- Baseline renders (title, meta description, H1, above-the-fold marketing copy) for money templates for post-launch diffing.
- Document legacy `.htaccess`, nginx, or edge rules — migrations often silently drop forgotten redirects.
Redirect spreadsheet: legacy URL → target URL → status strategy
Keep mapping in a sheet or redirect manager — not tribal knowledge. Every legacy URL needs an explicit decision: permanent redirect (301), consolidation into a stronger page, deliberate 404/410, or no change when paths stay identical.
- 301: durable moves or merging weaker URLs into one stronger destination.
- 410: intentional removals — only when there is no substitute and external equity should not be preserved via 301.
- Avoid “we will add redirects later after indexing” — soft 404 risk rises quickly.
301 redirects — single hop, avoid chains and loops
Prefer one stable 301 from legacy to final destination rather than chains A→B→C or long-lived 302s. Chains slow crawling, complicate debugging, and hide mapping mistakes.
Common redirect deployment mistakes
- Over-broad regex rules catching APIs, previews, or admin paths.
- Wrong evaluation order — first match wins; document ordering explicitly.
- HTTPS migrations missing hard redirects from HTTP — duplicate hosts linger in the index.
Canonical tags, HTTPS, www, and trailing slashes
Pick one preferred host and path format; enforce the rest at the server edge. Canonical tags complement redirect policy — they cannot substitute for chaotic routing, especially after IA changes.
robots.txt, XML sitemaps, and Search Console
- Refresh XML sitemaps with canonical, indexable URLs; split large archives when needed.
- Ensure robots.txt does not accidentally block crawl-critical paths or assets Google needs for rendering.
- In Search Console: correct property, sitemap submission, coverage monitoring, and URL Inspection sampling after launch.
Content and template parity
A “same” page post-migration must keep transactional messaging, heading hierarchy, and trust signals — not only a similar theme skin. Cutting FAQs, shrinking body copy, or removing schema blocks risks snippet drift and SERP CTR drops.
Structured data and WooCommerce templates
Theme or SEO plugin swaps can quietly break JSON-LD and Product/Breadcrumb markup — minor template bugs may duplicate errors in Rich Results or distort price/stock presentation.
Database serialization and URL replacements
Naive global search-replace on serialized PHP strings corrupts theme options and widgets. Use tooling that respects serialization (WP-CLI with dry runs, dedicated scripts), always from backups tested on a clone.
Staging without index leakage
Protect staging with auth/VPN, meta or header-level noindex, and avoid publicly linking a full production duplicate. Open staging mirrors are a duplicate-content invitation.
DNS, TTL, and cut-over windows
- Lower TTL ahead of A/AAAA changes to shorten propagation.
- Maintain a cut-over checklist: sequencing, rollback plan, uptime/TLS monitoring.
- Verify MX and transactional mail paths — hosting moves sometimes break forms and SMTP unexpectedly.
Post-launch technical validation
- Spot-check redirects via HTTP headers — expect one 301 to a 200 on priority URLs.
- Watch server logs for 404 spikes on top landings during the first days and weeks.
- Refresh internal links and navigation where feasible instead of relying solely on redirects.
- For multilingual stacks keep hreflang pairs aligned after path changes.
Performance and Core Web Vitals after the move
New hosting, CDN tiers, or PHP stacks can improve or regress LCP/TTFB — compare lab/field baselines before and after and budget hotfixes if templates emit heavier HTML or cache behaves differently.
Migration finishes when SERPs and users still recognise the same intent — ideally faster or more stable, not accidentally worse.
Related — rescue audits and pillars
- WordPress programming services — pillar landing
- Core Web Vitals — validate performance after migration
- Rescuing stalled web projects — entry audit
- WordPress programming services — detailed scope
- WordPress vs custom — migration to another stack
FAQ
Frequently Asked Questions
- Not by itself — continuity of URLs/content, stable rendering, and avoiding new 5xx or duplicate-host chaos drive outcomes. Pain usually comes from missing redirects, coverage drops, or slower origin responses.
- Keep locale pairs consistent and refresh annotations plus XML sitemaps — a single mismatched PL/EN pair can skew geographic targeting.
- When migration locks to a campaign cut-over or a single maintenance window — time becomes a business constraint.
- Short volatility while crawl budgets reshuffle is common; sustained coverage loss or query drops weeks later usually mean redirect gaps or template regressions — revisit the URL map and logs.
- Plugins help manage lists but do not replace server-level routing discipline — large stacks often combine nginx/Apache rules for critical paths with audited plugin-managed rows.
- Update goals, campaign parameters, and reporting views — migrations without analytics hygiene silently break period comparisons and decision-making.