The fear that keeps businesses on a site they have outgrown is simple: "we will lose our Google rankings". That fear is rational, because botched migrations do lose rankings. It is also avoidable. Rankings attach to URLs and the signals those URLs carry, not to WordPress. This is the runbook we use.
Inventory: Export Everything Before You Touch Anything
The migration fails or succeeds here. You cannot preserve what you never listed. Before a single line of new code is written, build one authoritative list of every URL that exists, has ever existed, or has ever been linked. Five sources, merged and deduplicated, because no single source is complete.
- ▸The sitemap and a full crawl. Start with the XML sitemap index, then crawl the live site properly (Screaming Frog, Sitebulb or equivalent) to catch pages the sitemap omits.
- ▸Search Console. Export the Pages report, indexed and not indexed, plus Performance by page over the last 16 months. That tells you which URLs actually earn clicks.
- ▸Analytics. Landing pages over 12 months, including the long tail nobody remembers publishing.
- ▸Server access logs. The only source showing what crawlers actually request, including old URLs your own crawl will never discover.
- ▸Links and the database. Export top linked pages from Search Console, then posts, pages, attachments, categories, tags and authors from the WordPress database.
One more source everyone forgets: the existing redirect table. If the site runs a redirect plugin, it holds years of legacy rules. Carry them into the new stack or flatten them into it, otherwise you silently break URLs that worked fine yesterday.
The URL Map Is the Whole Project
Everything else is execution. The URL map is a spreadsheet where every source URL gets a decision, an owner and a verification tick. If a URL is not on the map, it will 404 on cutover, and you will find out from a traffic graph rather than from a test.
Columns that earn their place: source URL, status code, current canonical, indexed yes or no, clicks in the last 12 months, referring domains, destination, redirect type, decision, verified.
- ▸301 for anything with traffic, links or index presence. Permanent redirects pass ranking signals. Use them by default.
- ▸410 only for content you want gone forever. A clean signal, but irreversible in practice.
- ▸Never mass-redirect to the homepage. Search engines commonly treat an irrelevant bulk redirect as a soft 404, and the equity evaporates. Map to the closest equivalent, or let it 410.
- ▸Flatten every chain. If an old URL already redirects through two hops, point it at the final destination. Chains waste crawl budget and leak signal, and long chains may not be followed at all.
- ▸Decide the awkward categories deliberately. Paginated archives, category and tag archives, author archives, feed endpoints, attachment pages (WordPress creates one per uploaded file by default), and query-string URLs such as the numeric post ID form.
Pick one trailing-slash convention and one case convention, then enforce both at the edge. Mixed conventions double your redirect hops on every URL.
Preserve the Signals, Not Just the Words
Rankings rest on more than body copy. Port the title tag, meta description, self-referencing canonical, H1, publish and modified dates, author, hreflang and robots directives for every mapped page. Diff them field by field against the old site before you go live. A missing canonical or an inherited noindex is a silent catastrophe.
- ▸The single most common disaster is shipping a staging robots.txt that disallows everything, or a global noindex tag. Add a deploy gate that fails the build if robots.txt disallows the root or any production page emits noindex.
- ▸Change one variable at a time. Do not redesign, rewrite copy and change URLs in one release. Migrate at content parity first, then iterate. When rankings move you need to know which change caused it.
- ▸Rewrite internal links in body content to point at final destinations. Relying on redirects for your own internal linking is sloppy and slow.
- ▸Keep the content complete. Pages trimmed "because nobody reads them" are frequently the ones ranking for long-tail queries that convert.
This is the same discipline we apply to data migrations off closed platforms, described in Leaving Salesforce: The Engineering Migration Runbook.
Media, Images and the Files Everyone Forgets
WordPress stores uploads under a dated directory structure and generates multiple resized variants referenced through srcset. If your new stack changes those paths, every image reference inside every post body breaks at once, along with your Google Images traffic and any images other sites have hotlinked.
- ▸Cheapest safe option: keep the same upload paths. Serve the existing media directory from the new origin unchanged. No body rewriting, no image redirects, no risk.
- ▸If paths must change, rewrite body content and add redirects for image URLs too. Images are indexed resources, not decoration.
- ▸Preserve filenames and alt text. Do not rename files to content hashes mid-migration. Both carry real signal.
- ▸Beware serialized data. WordPress stores PHP-serialized strings in options and page-builder fields, and those strings encode their own byte length. A naive SQL find-and-replace corrupts them. Use a serialization-aware tool such as the WP-CLI search-replace command.
- ▸Do not import bloat. Migrate the media you actually use, in modern formats and correct dimensions.
Structured Data and Feed Parity
Inventory the machine-readable layer before cutover and rebuild it deliberately. Most WordPress sites emit schema from an SEO plugin without anyone knowing which types. Losing Article, BreadcrumbList, Product, LocalBusiness or FAQPage markup can quietly remove your rich results and your review stars.
- ▸Enumerate first. Crawl the old site and extract every schema type in use, per template. That list is your acceptance criteria.
- ▸Rebuild as JSON-LD and validate with the Rich Results Test and a schema validator. Diff type by type, not site-wide.
- ▸Carry the social layer. Open Graph and Twitter card tags, the default share image, and the favicon.
- ▸Keep the feed. RSS at the same path, or redirected. Subscribers and syndication partners are real traffic.
- ▸Preserve verification and analytics tags. A migration that loses the analytics tag looks exactly like a traffic collapse and wastes a week of panic.
Test Redirects Before Cutover, Not After
Treat the URL map as data and test it automatically against the staging origin. For every source URL assert three things: exactly one hop, a final 200 status, and the expected destination. Fail the build on any 404, loop or chain. Manual spot-checking finds a fraction of the breakage.
- ▸Test every variant of each URL: with and without the trailing slash, with and without www, http and https, and uppercase forms.
- ▸Confirm real 404 status codes for missing URLs. A pretty "not found" page returning 200 is a soft 404 and pollutes your index.
- ▸Check response headers, not just rendered pages: canonical, robots and hreflang are often right in the template and wrong in the header.
- ▸Run the suite twice: on staging, then against production within minutes of cutover.
Staged Cutover With a Rollback You Have Rehearsed
Cutover is a sequence, not a moment. Freeze content, lower DNS TTL to about five minutes 48 hours ahead, snapshot the old stack in full, deploy the new one, flip DNS or the CDN origin, then re-run the redirect suite against production before you tell anyone it is done.
- ▸Keep the old stack alive on an internal hostname for at least 90 days. It is your rollback and your reference for anything you missed.
- ▸Rollback is a flip back, which is why the TTL matters. Rehearse it once so nobody improvises under pressure.
- ▸Pick a low-traffic window on a day your team is present. Never a Friday evening.
- ▸Immediately after: submit the new XML sitemap, inspect ten representative URLs with the URL Inspection tool, confirm indexability and rendering, and verify analytics is firing.
The same rollback thinking applies to infrastructure moves, as we covered in Cloud Migration Pitfalls: Lessons From Projects That Went Wrong.
The First 30 Days: What to Measure and What to Ignore
Expect a short dip while search engines reprocess and recrawl. That is normal. What is not normal is a decline that keeps going after four weeks. Measure by page-type cohort, never by site total, because a site-wide average hides the one broken template that is actually bleeding.
- ▸Weekly in Search Console: indexed page count, impressions and clicks by template cohort, average position for your top 50 queries, coverage errors, and crawl stats.
- ▸In server logs: crawler hits on old URLs trending down, 404 volume trending to zero. Any recurring 404 is a missing row in your URL map. Add it and redeploy the same day.
- ▸Core Web Vitals. The new stack should be faster. If it is not, you traded rankings for a design refresh, the argument in Performance Budgets: Treat Speed as a Requirement, Not a Wish.
- ▸Ignore day-to-day rank noise. Set a decision gate at day 30 against a per-cohort threshold you agreed in advance.
- ▸If a cohort is genuinely down, the cause is almost always findable: a broken redirect, an unmapped URL pattern, a shipped noindex, dropped content, or a slower page. Fix the cause, do not add content.
Leaving WordPress is one instance of a broader pattern, covered in Escaping SaaS: The Complete Guide to Migrating Your Business to Custom Software and Low-Code vs Custom Code: When Cheap Tools Cost You More Later.
How TuniCyberLabs Helps
We run WordPress exits as engineering projects with SEO acceptance criteria baked in: a merged URL inventory from crawl, logs and Search Console, a reviewed redirect map, automated redirect and metadata tests in CI, structured data parity checks, a rehearsed cutover with rollback, and 30 days of cohort monitoring. You get a faster site you own outright, without the traffic scare. See how we scope this on our services page, and the security case for leaving in The WordPress Security Reality Check Every Business Owner Avoids.
Talk to TuniCyberLabs about a migration plan that protects your rankings before a single URL changes.