What happens to my WordPress plugins on the new site?

Plugin functionality gets rebuilt directly into the custom site as native code, so there is nothing to keep renewing, updating, or patching. A contact form becomes PHP form handling with CSRF protection and rate limiting baked in. An SEO plugin's settings become proper JSON-LD schema markup and meta tag output written for the page's specific type. A caching plugin becomes unnecessary because a hand-coded PHP page has no plugin overhead to cache away in the first place. The exception is a plugin doing something specialized: a complex booking engine, a membership access control system, or a multi-currency WooCommerce configuration with custom tax logic. In those cases the scope gets evaluated specifically and you will hear a direct answer about what is and is not worth rebuilding.

What is a 301 redirect and why does it matter for SEO?

A 301 redirect is an HTTP response code that tells browsers and search engines a URL has permanently moved to a new location. When Google follows a 301, it transfers the link equity — the ranking authority accumulated by the old URL — to the new destination. This is the mechanism that makes a migration SEO-safe. Without it, every URL change creates a dead end: Google hits a 404 (not found), drops the page from its index, and the ranking disappears. The equity that page built up does not automatically move anywhere — it is lost until the new page earns it back from scratch, which takes months. With a proper 301 in place, the transition is almost seamless from Google's perspective. The technical implementation depends on the server: Apache sites use .htaccess rewrite rules, Nginx sites use server-block rewrite directives. Both accomplish the same thing — every old path returns a 301 pointing to the correct new URL.

Should I keep the same URL structure when I migrate?

Wherever possible, yes — keeping the same URL paths is the path of least resistance for SEO. If your WordPress site uses /services/web-design/ and the new site can use the same path, do it. No redirect needed, no risk of the redirect chain affecting crawl behavior, and no transition period where Google is resolving the old path to the new one. The URL structure on a WordPress site is controlled by the permalink setting (Settings > Permalinks). Common patterns are /%postname%/ for flat URLs and /%category%/%postname%/ for hierarchical ones. Custom PHP sites can match either. The situations where URLs need to change are when the old structure is technically problematic (dynamic query strings like ?page_id=47 instead of readable paths) or when you are reorganizing the information architecture deliberately. In those cases, every changed URL gets a 301 — no exceptions, including pages you think nobody visits. Automated scanners and old links in the wild will surface those paths.

What about my WordPress blog posts? Can I migrate those too?

Yes, and how you migrate them depends on volume and what you plan to do with them going forward. A blog with twenty to fifty posts is worth migrating in full: extract the content from the WordPress XML export, clean up shortcodes and WordPress-specific formatting, and rebuild each post as a PHP page or flat HTML file with the same URL. A blog with hundreds of posts requires a decision about content quality before doing the work: migrating three hundred posts where sixty of them drive 80% of the traffic is not the same value proposition as migrating all three hundred equally. The right call is usually to migrate the high-traffic posts, audit and improve the middle tier, and 301-redirect the low-value posts to relevant category pages rather than porting content that has never ranked and is unlikely to. Google Search Console's Performance report shows you exactly which posts are driving impressions and clicks — use that data to prioritize.

What does it cost to migrate off WordPress?

For a typical service business site of five to fifteen pages with no large blog archive, migration cost is comparable to a new multi-page build — in the $2,800–$5,000 range — because the work involved is similar: rebuilding each page in clean PHP, setting up hosting, writing the redirect map, and handling the DNS cutover. The content already exists, which reduces some work; URL mapping and redirect testing adds some back. Sites with a large blog archive, WooCommerce data, user accounts, or complex custom post types require a scope assessment based on what is involved. If the migration is straightforward, you hear a fixed number before anything starts, not an open-ended hourly estimate with a surprise total at the end.

How to Migrate Off WordPress

Q: Will I lose my Google rankings if I migrate off WordPress?

No — not if the migration is executed correctly. The two things that protect your rankings are a complete 301 redirect map (every old URL forwarding to its new equivalent) and content preservation (the same text, headings, and meta descriptions on the new page). Search engines follow 301 redirects and pass the accumulated ranking authority from the old URL to the new one. Sites that drop traffic after a migration almost always skipped the redirect step or changed URL patterns without mapping the old paths. That is a planning failure, not an inevitable consequence of leaving WordPress. After the new site goes live, resubmit the sitemap in Google Search Console and monitor the Coverage and Performance reports daily for the first two weeks to catch any 404s before they cost you ranking.

Q: Do I need to rebuild my content from scratch?

No. Your pages, posts, and images are all portable. WordPress has a built-in XML exporter (Tools > Export) that packages your content into a structured file. From there, content gets extracted, cleaned up to remove WordPress-specific formatting artifacts and shortcodes, and rebuilt into the new site's PHP templates. For a service business site of five to fifteen pages, this is a few hours of copy-paste and review work. For a site with a large blog archive, the content volume scales but the process does not change fundamentally. You may want to take the migration as an opportunity to audit and improve weak pages rather than porting them unchanged — that is optional, not required.

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 the most urgent. WordPress's add-on model is powerful, but each add-on is an independent piece of software maintained by a third party on their own schedule. Automated hacking tools constantly scan the internet looking for the standard WordPress login page and known weak add-ons on every site they can reach. When a security hole is discovered in a popular add-on, working break-in tools spread publicly within days. Sites that have not installed the fix by then are wide open. For a business owner who is not tracking security bulletins every week, the risk piles up silently until something breaks.

Performance problems are slower to manifest but just as damaging to a business. A WordPress site built with a drag-and-drop page builder like Elementor or Divi loads a big chunk of the builder's own behind-the-scenes code before any of your actual design even starts to appear. That weight is baked into the builder: you cannot remove it without switching builders entirely. On phones, where Google grades how fast your main photo or headline shows up on screen, a default WordPress build typically takes two to four seconds to paint that first big element. That is not a hosting problem. It is a foundation problem, and it costs you ranking in competitive local search, where even half a second faster translates to visible position gains.

Maintenance fatigue is the quietest reason and the one most site owners undercount when they are deciding whether to move. WordPress itself, your theme, and every active add-on update on their own separate schedules that do not line up with each other. An add-on update that breaks your page layout, a behind-the-scenes software upgrade that suddenly throws errors in an older add-on, or a theme update that wipes out a tweak you made: each of these is a maintenance headache that takes time to track down and fix. Over three to four years, all that lost time adds up to a cost that rarely shows up in any upfront comparison. Full breakdown: 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.

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 real 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 is the single most important deliverable in a WordPress move. It is the document that decides whether your Google rankings survive the switch. Every web address that changes needs a row in this map. Every address that stays the same still needs to be on the list so you can confirm it exists on the new site before you flip the switch.

The map has three columns: the old web address, the new web address (or a note if the page is being removed), and a priority flag showing whether this address gets meaningful search traffic. A spreadsheet works fine. Moves that keep the exact same web addresses shrink the map to a one-line confirmation for most pages: old address equals new address. That is the recommended approach for any page that currently ranks.

WordPress sometimes forces address changes. The most common case is a WordPress site whose addresses look like a string of gibberish (a number or code instead of plain words) because the setting that controls readable addresses was never turned on. Those ugly addresses are not worth keeping. A clean address like "yoursite.com/about" beats a cryptic one for both visitors and Google. Since the cryptic ones rarely rank anyway, automatically forwarding them to the clean version is low risk. The higher-risk cases are pages that do rank, where changing the address means leaning entirely on the automatic forward to carry the ranking authority over. Avoid changing those unless you have a strong reason that outweighs the risk.

For pages being removed entirely (old blog posts that never ranked and are not worth keeping, or a service page for something you no longer offer), the forward should point at the most relevant remaining page, not the home page. A removed service page should forward to your services list or to the nearest remaining service. Forwarding everything to the home page is a common shortcut that Google penalizes: it can tell the home page has nothing to do with the removed page, so it refuses to pass the old page's ranking authority through.

Once the map is complete, the automatic forwards get set up on the new server before you flip the switch. Test every forward in the map against a private preview copy of the site before you go live, not after.

Porting your content

WordPress keeps all your pages, posts, images, and settings tucked away behind the scenes. You do not need any special access to get them out. In the WordPress dashboard, go to Tools, then Export, and choose "All content." WordPress hands you a single file containing every piece of content on the site. That file is the starting point for your move.

For a service business site of five to fifteen pages, the cleanest approach is to open that export file, find each page and post by its title, and drop the content into the new site. WordPress sprinkles little placeholder codes through your content (the things that pull in a contact form or a photo gallery). Those placeholders get replaced with the real working feature on the new site. Clear them out as you copy, not after the fact.

Your images sit in WordPress's uploads folder, sorted by year and month. The whole folder gets copied over to the new server. The links pointing at those images inside your content get pointed at their new home. If the images keep the same folder layout on the new server, the links do not change at all and this step is just a straight folder copy.

For sites with a large blog archive, copying post by post by hand does not scale. The export file can be processed automatically instead. A small program reads each post, pulls out the title, web address, content, and main photo, and writes them all into the new site in one pass. It runs once and the whole archive is live, with no manual work per post.

One thing worth doing while you move content over, no matter the size of the site: a quick writing cleanup. The move is the easiest moment to improve pages that have weak headlines, thin content, or wording that no longer describes what your business actually does. Pages you bring over unchanged keep ranking exactly the same after the move: no better, no worse. Pages you improve along the way can start climbing within weeks of launch as Google re-reads them on the faster new site.

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.

Each add-on's job gets built straight into the new site. A contact form add-on becomes a built-in form with spam blocking, junk-filtering, and reliable email delivery baked right in. The form does everything the add-on did: it takes the message, emails it to you, and handles mistakes gracefully, all with no third-party software involved and nothing to keep updating. The weak spot that made the add-on a security risk disappears because the add-on itself disappears.

An SEO add-on's settings (your search headlines, the summaries under your links, the map of your pages you hand to Google, and the behind-the-scenes labels that tell Google what your business is) get written by hand into the new site instead. Those labels are not churned out by an add-on reading a settings panel: they are written precisely for each kind of page. A service page gets service labels, a question-and-answer section gets FAQ labels, an about page gets business-identity labels. None of this needs an add-on that plants its own tracking, bogs down your dashboard, and pushes extra code at every visitor.

Gallery add-ons, slideshow add-ons, testimonial add-ons, and most visual display add-ons get replaced with clean, lightweight page code. The add-on existed in the first place because WordPress builds pages out of stacked blocks: you drop a gallery block or a slideshow block onto a page in the editor. On a custom-built site, a gallery is simply a tidy grid of images. It needs no add-on because the page is built properly from the start.

The exception is an add-on doing something genuinely complex: a booking engine that syncs with Google Calendar and takes payments, an online store with hundreds of products, custom shipping rules, and an active order history, or a membership system managing different access levels with paid subscriptions. These get a scope assessment specific to the feature involved. Some are worth rebuilding as custom code, while others point toward the conclusion that WordPress is the right platform for that particular site. If that is the answer, you hear it directly. WordPress-to-custom 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.

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 real people do: filling out the contact form and confirming the message actually 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 real 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 actually 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, not just the new site's numbers alone. 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 the planned switch, you tell the system that points your domain at your website to start checking for updates every five minutes instead of once a day. By default, the internet remembers where your domain lives for hours at a time, which means after a switch some visitors could keep landing on the old server for up to a full day. Tightening that window to five minutes means the switch reaches everyone 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.

The security padlock is worth planning for specifically. The new server needs its security certificate (the thing that puts the padlock in the browser bar and keeps the connection encrypted) in place before you switch the domain, or visitors will see a scary "not secure" warning during the changeover. These certificates are free and issue in seconds to minutes, so set it up ahead of time rather than leaving it as a last step.

After the switch, do a full walkthrough of the live site: every page, every form, every forward. Then confirm the forwarding map is working on the real live site, not just the preview copy. Small differences between the preview and the live server occasionally surface something the preview did not catch. If a forward is wrong, fix it immediately. Every hour a high-traffic page shows a "page not found" instead of forwarding properly is an hour of lost ranking.

Watching the site after launch

The move is not finished when the new site goes live. The two weeks after launch are when Google re-reads the changed site, follows all the forwards, and updates its records. What happens during that window decides whether your rankings hold, improve, or dip briefly before recovering. Keeping an eye on things during this period catches problems before they snowball.

On launch day, hand Google an updated map of your pages through its free Search Console tool. Go in, find the Sitemaps area, remove the old map if it is still listed, and submit the new one. This tells Google there is fresh information to look at and speeds up how fast your new pages get picked up. Do not wait for Google to stumble onto it on its own: that can take days.

Check Search Console daily for the first two weeks. It flags any pages Google could not load, dead ends, and forwarding problems. A new dead end after launch means a web address slipped through the cracks in your forwarding map: something Google still knows about is no longer being forwarded on the new server. Fix each one as it appears by forwarding it to the right page. A dead end left alone for a week will fall out of Google entirely; fix it within a day and the forward keeps the ranking intact.

Search Console also shows how often you appear in search results and how often people click. Expect a little wobble in the first week as Google digests the change. Rankings sometimes drift a few spots either way while Google re-reads the site. This is normal and not a sign of trouble unless it drags on past two weeks or hits specific pages hard. If one page drops sharply and stays down, check that its forward is working and that the new page matches the old one on the things that matter for ranking: the headline, the main heading, and the body text.

Google's page-speed health scores in Search Console run about a month behind, so you will not see the full speed improvement reflected there right away. But you can check live speed numbers immediately with a free speed test. Run it on your busiest pages after launch and compare against the before numbers you recorded. Confirm the improvement is there. If the live site is slower than the preview suggested, the cause is almost always one image that did not get shrunk down properly or an outside service (a chat widget, a tracking tag) that loads 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

Will I lose my Google rankings if I migrate off WordPress?

No, not if the move is done correctly. The two things that protect your rankings are a complete forwarding map (every old web address automatically forwards to its new equivalent) and keeping your content intact (the same text, headings, and search summaries on the new page). Google follows those automatic forwards and passes the built-up ranking authority from the old web address to the new one. Sites that lose traffic after a move almost always skipped the forwarding step or changed their web addresses without mapping the old ones. That is a planning failure, not an unavoidable cost of leaving WordPress. After the new site goes live, hand Google an updated map of your pages and keep an eye on its free Search Console tool daily for the first two weeks to catch any dead ends before they cost you ranking.

Do I need to rebuild my content from scratch?

No. Your pages, posts, and images all come with you. WordPress has a built-in export tool (under Tools, then Export) that packages all your content into a single file. From there, the content gets pulled out, cleaned up to strip out WordPress's little placeholder codes and leftover formatting, and rebuilt on the new site. For a service business site of five to fifteen pages, this is a few hours of copy-and-review work. For a site with a large blog archive, there is more content to move but the process is the same. You can choose to clean up and improve weak pages while you are at it rather than moving them as-is. That is an option, not a requirement. Nothing is lost in the move.

What happens to my add-ons?

Each add-on's job gets built straight into the new site, so there is nothing left to renew, update, or patch. A contact form becomes a built-in form with spam blocking and junk-filtering baked in. An SEO add-on's settings become hand-written search listings and behind-the-scenes labels tailored to each kind of page. A speed-booster add-on becomes unnecessary, because a properly built page has no add-on bloat to speed up in the first place. The exception is an add-on handling something complex: a booking engine that takes payments, an online store with hundreds of products and an active order history, or a membership system with different paid access levels. Those cases get scoped specifically and you hear a direct answer about what is and is not worth rebuilding.

What is an automatic forward and why does it matter?

An automatic forward is a signal that tells browsers and Google a web address has permanently moved to a new home. When Google follows one, it carries the built-up ranking authority from the old web address over to the new one. Without it, every address change creates a dead end. Google hits a "page not found," drops the page from search, and the ranking disappears. The authority that page built up does not move anywhere on its own, so it is lost until the new page earns it back from scratch over months. With proper forwarding in place, the move is nearly invisible to Google. Every forward gets tested against a private preview copy of the site before you go live, not after.

How long does a WordPress migration take?

For a standard service business site of five to fifteen pages with no blog archive, two to four weeks from kickoff to launch. That's roughly the same as a new multi-page build, because the work involves rebuilding the site on a new foundation rather than starting from zero design decisions. Content already exists, which saves time; mapping your web addresses and testing the forwards adds some back. There is no downtime during development: the new site is built and tested on a private preview copy while your WordPress site stays live. The switch itself (pointing your domain at the new server) takes minutes, with the forwards going live at the same time. Sites with a large blog archive or a complex online store need a scope assessment based on what is involved.

Should I keep the same URL structure?

Wherever possible, yes. Keeping the same web addresses means no forwarding is needed on those pages and removes the risk entirely. If your WordPress site uses "yoursite.com/services/web-design" and the new site uses the exact same address, nothing needs to forward and Google sees no change. The cases where addresses need to change are when the old ones are a string of gibberish (WordPress's default look-up codes instead of readable words) or when you are deliberately reorganizing how the site is laid out. In either case, every changed address gets an automatic forward to its new home, no exceptions, including pages you think nobody visits. Automated scanners and old links floating around out there will surface those addresses, and a dead end where a forward should be costs ranking for no reason.

What about my blog posts? Can I migrate those too?

Yes, and the approach depends on how many you have. A blog with twenty to fifty posts is worth moving in full. Pull the content from the WordPress export, clean up the leftover placeholder codes, and rebuild each post on the new site with the same web address. A blog with hundreds of posts calls for a content review first: Google's free Search Console tool shows exactly which posts are showing up in search and getting clicked. The right call is usually to move the high-traffic posts carefully, clean up and improve the middle tier as you go, and forward the dead-weight posts to relevant category pages rather than dragging along content that has never ranked and probably never will. Forwarding everything to the home page is a common mistake: Google penalizes it because the home page has nothing to do with the old post.

What does a WordPress migration cost?

For a typical service business site of five to fifteen pages with no large blog archive, the cost is comparable to a new multi-page build (in the $2,800–$5,000 range) because the work is similar: rebuilding each page cleanly, setting up hosting and the security padlock, writing and testing the forwarding map, pointing your domain at the new site, and watching it for the first couple of weeks. The content already existing saves some work; mapping your web addresses and setting up the forwards adds some back. Sites with a large blog archive, an online store with order history, customer logins, or other complex features need a scope assessment based on what is involved. If the move is straightforward, you get a fixed number before any work starts, not an open-ended hourly estimate.

See all web design FAQs →

How to migrate off WordPress without losing your rankings