How to migrate off WordPress without losing your rankings

Why businesses migrate off WordPress

Before spending weeks on a migration, you should be clear on what you're solving. The most common reasons businesses leave WordPress fall into three buckets: security overhead, performance problems, and maintenance fatigue. Any one of them is a valid trigger. Understanding which one is yours shapes every decision that follows.

Security is most urgent. WordPress add-ons follow independent third-party maintenance schedules. Automated scanners target standard logins and known weaknesses; public attack tools follow popular add-on vulnerabilities within days. Unpatched sites remain exposed. Owners not reading weekly security bulletins accumulate risk silently.

Elementor and Divi load substantial builder code before your design; removing that weight requires switching builders. Default WordPress builds commonly take two to four mobile seconds to display the main element Google measures. This foundation problem costs competitive local rankings, where even half a second yields visible gains.

WordPress, themes, and add-ons update on different schedules. Broken layouts, software upgrades incompatible with older add-ons, and theme updates erasing tweaks all take troubleshooting time. Over three to four years, this hidden maintenance cost accumulates beyond upfront comparisons. WordPress vs. custom →

What to check before you start

A migration that starts without an audit is a migration that will discover surprises at the worst possible time: after the new site is live, when fixing them requires either rolling back to WordPress or shipping a broken site. The audit happens before a single line of new code is written.

Pre-migration audit

• Start with a complete list of every web address on your site. A scanning tool can map the whole site automatically, or your SEO add-on can hand you a full list. The goal is a list of every working page on the site: your main pages, blog posts, category pages, tag pages, author pages, everything. This list becomes the master reference for making sure no old web address gets left behind in the move.
• Next, pull your traffic data. Google's free Search Console tool shows which pages are showing up in search results and getting clicked. Your analytics show which pages turn visitors into customers. Together, these tell you which pages drive value and need extra care during the move. A page that ranks for a competitive search term and drives 40% of your contact form submissions is not the same risk as a category page that has never attracted a single click.
• Document your current search listings. Export the clickable headlines and the short summaries that Google shows under each of your links. Your SEO add-on can save these to a spreadsheet. They need to be carried over exactly on the new site, not rewritten during the move unless there is a specific reason to improve them. Changing your headlines and summaries during a move adds one more thing that makes it harder to tell what caused any ranking wobble after launch.
• Finally, list out your add-ons and what each one does. For each add-on, the question is: what feature does this provide, and how will that feature be handled on the new site? Contact form: what are the fields, where do messages go, is there any spam filtering? Photo gallery: how are images organized, what sizes do they display at? Booking tool: what is the booking flow, does it take payments, does it connect to any outside services? This list drives the scope of the new build and surfaces any feature that needs more than a standard rebuild.

Building your forwarding map so no web address gets lost

The forwarding map determines whether Google rankings survive. List every changed address and every unchanged one, verifying each exists on the replacement before switching.

Use three spreadsheet columns: old address, new address/removal note, and search-traffic priority. For ranking pages, preserve addresses where possible; each row then simply confirms old equals new.

WordPress sites without readable addresses enabled may use cryptic numbers/codes. Replace those rarely-ranking addresses with readable paths like "yoursite.com/about" and forward automatically: low risk and better for visitors/Google. Changing ranking addresses relies entirely on forwards to preserve authority; require a compelling reason.

Forward retired, unranked posts or discontinued services to the most relevant remaining page, services list, or nearest service. Sending everything home loses authority: Google recognizes unrelated destinations and refuses to pass ranking credit.

Porting your content

No special access is needed: in WordPress, choose Tools → Export → "All content." The single file packages site content as your migration starting point.

For five-to-fifteen-page service sites, locate each page/post by title in the export and copy it into the replacement. Replace WordPress's contact-form/gallery placeholder codes with working features during copying, not afterward.

Copy WordPress's uploads folder, organized by year/month, to the new server. Update content's image links if locations change; preserving the folder structure needs only the copy.

For large blog archives, automate extraction: a small program reads each post's title, address, content, and main photo, then writes the archive into the new site in one pass without per-post copying.

Migration is an ideal opportunity to improve weak headlines, thin content, and outdated business descriptions. Unchanged pages retain rankings; improved pages can climb within weeks as Google rereads them on the faster replacement.

What happens to your add-ons

This is the question that comes up most often from business owners considering a move. They ask: "I have an add-on that does this thing. Can I keep it?" In almost every case, the answer is no, and that is a feature of the move, not a limitation.

Build add-on functions directly. A native contact form receives messages, emails you, handles errors, and includes spam blocking, junk filtering, and reliable delivery. Removing the third-party add-on removes its update burden and security weakness.

Hand-write former SEO add-on settings: search headlines/summaries, Google's page map, and business labels. Tailor labels to each page: services, FAQs, or business identity for About. This avoids add-on tracking, dashboard slowdowns, and extra visitor code.

Replace gallery, slideshow, testimonial, and most display add-ons with lightweight code. WordPress needs these for its stacked editor blocks; a properly built custom gallery is simply an image grid without add-ons.

Scope complex exceptions individually: Google Calendar/payment bookings; stores with hundreds of products, custom shipping, and order history; paid memberships with access tiers. Some merit custom rebuilding; others favor retaining WordPress. You'll hear directly when it does. WordPress migration service →

Building and testing the new site

The new site is built and tested in full before anything touches production. Your WordPress site stays live throughout the development period; there is no interim state where visitors land on a broken or under-construction page. The new site runs on a staging environment until it passes every check.

Pre-launch test pass

• Anything WordPress used to handle needs to be checked by hand on the new build. Every feature that used to run off one of those placeholder codes (contact forms, galleries, slideshows, call-to-action blocks) has to be confirmed as replaced and working, not just gone. A feature that quietly shows nothing on the new site is harder to catch than an outright error. Walk each page next to its WordPress version and confirm they match. Also confirm the old WordPress login and admin pages lead nowhere on the new server: they should not exist, and any leftover WordPress files sitting on the new server are a security hole even on a site that no longer runs WordPress.
• Visitor testing covers the things visitors do: filling out the contact form and confirming the message arrives, clicking through every page and confirming all the links work, loading the site on a phone and confirming it looks and works right on common screen sizes, and checking that every image loads at the right size with a proper description attached.
• Search testing covers the things Google looks at: every page has its own clear clickable headline and short summary for search results, each page tells Google which version is the authoritative one so it never sees duplicates, the page map you hand Google lists every live page with accurate dates, the behind-the-scenes labels that tell Google what your business is are valid, and nothing is accidentally telling Google to skip pages that should show up in search. A common slip-up is leaving a "do not list this site" instruction switched on from the private preview stage. Confirm the live site invites Google in everywhere it should. Also compare the new site's Google labels against what WordPress was producing: the new ones should be at least as complete, covering the same kinds of pages with the same or better information.
• Speed testing confirms the move delivers on being faster than WordPress. Run a free speed test on both the current WordPress site and the new one before launch. You want the difference written down alongside the new site's numbers. A WordPress site on a fast host with speed tricks turned on can score decently, so the side-by-side matters. Note how fast the main image and headline appear, how steady the page is as it loads, and how quickly it responds to taps. After launch, you have hard numbers to point to as Google's page-speed health checks improve over the following weeks.
• Forwarding testing is the last check before going live. Test every row in the forwarding map against the private preview copy. A misconfigured forward that sends visitors in a loop or points to the wrong page should be caught here, not discovered by Google after launch. Simple tools let you confirm each old web address forwards to the right new one without even loading the full page.

Pointing your domain at the new site

This is the moment your domain name stops pointing at your WordPress hosting and starts pointing at the new server. It is the most visible step in the move and, when everything before it has been done right, also the least risky. Most of the work is already finished by the time you make this change.

A day or two before switching, tell the domain-address system to check for updates every five minutes instead of daily. Internet systems normally remember your old server for hours, potentially sending visitors there for a full day after the move. A five-minute window spreads the switch within minutes instead of hours.

Then you make the switch: update the setting so your domain points at the new server's address, and immediately confirm the new site is answering correctly. Within a few minutes, most visitors are hitting the new server. The forwards are already live because they were built into the new server from the start.

Install the new server's encryption certificate before switching domains to avoid "not secure" warnings. Browser-padlock certificates are free and issue in seconds to minutes; don't leave installation until last.

After switching, test every live page, form, and forward, including the full map. Preview/live server differences can reveal missed errors. Fix incorrect forwards immediately: each hour a high-traffic page returns "not found" loses ranking.

Watching the site after launch

During the two weeks after launch, Google rereads pages, follows forwards, and updates records. Monitor this ranking-critical window to catch problems before they grow or prolong dips.

On launch day, open free Google Search Console's Sitemaps area, remove any old map, and submit the updated one. This accelerates discovery instead of waiting days for Google to notice.

Check Search Console daily for two weeks for unloadable pages, dead ends, or faulty forwards. New dead ends expose unmapped addresses Google remembers. Forward them promptly: fixing within a day preserves rankings; leaving them a week drops pages from Google.

Search Console tracks appearances and clicks. First-week position fluctuations are normal while Google rereads; changes lasting past two weeks or severe page-specific drops aren't. For sustained drops, verify forwarding and compare the original headline, main heading, and body text.

Search Console speed scores lag about a month. Immediately test busy live pages with a free speed tool and compare recorded baselines. If live performance trails preview results, suspect an undersized-image optimization failure or external chat/tracking service loading slower on the live domain.

After 30 days, set the domain back to checking for updates on the normal once-a-day schedule. The fast five-minute setting exists for one reason: a quick undo if something went badly wrong during the switch. Once the site has been steady for a month, that safety net is no longer needed.

Key takeaways

• The forwarding map is the single most critical piece of work. Every web address that changes or disappears needs to automatically forward somewhere relevant before you point your domain at the new site.
• Do your homework before any new code is written. You need a full list of your web addresses, your traffic data from Google's free Search Console tool, your current search listings, and a list of what every add-on does, so the work can be scoped accurately.
• Content does not have to be rebuilt from scratch. WordPress hands you a single file with all your pages and posts. The content gets pulled out, cleaned up, and rebuilt on the new site.
• Each add-on's job gets built straight into the new site as code you own, with nothing to renew, nothing to update, and no extra weak spot for hackers to target.
• A day or two before the switch, set your domain to check for updates every five minutes instead of once a day, so the change reaches everyone in minutes rather than hours.
• Hand Google an updated map of your pages on launch day and check Search Console daily for the first two weeks. Any new dead end needs a same-day forward to the right page.
• Ranking wobble in the first week is normal. A lasting drop on specific pages after the two-week window points to a broken forward or a content problem on that page.

Common questions

See all web design FAQs →