Moving a Localhost WordPress Site (XAMPP/Local) to a Live Server

Moving a localhost WordPress site from XAMPP or Local to a live server comes down to three things: copying the files, importing the database, and rewriting every http://localhost URL that got baked into your content. Most small sites go live in 30 to 60 minutes. The parts that trip people up are serialized data in the database and file permissions, and both have fixes that take a couple of minutes once you know where to look.

Below is the process we walk customers through, in the order we’d do it ourselves, with the manual route and the plugin route side by side.

What Actually Needs to Travel

A WordPress install is only two moving parts. Everything else on your machine (Apache, MySQL, the PHP binary) stays behind because your host already runs its own copies.

• The file tree: wp-content (themes, plugins, uploads), plus wp-config.php, .htaccess and core files if you want an exact match.
• The database: one .sql dump containing your posts, pages, options, users and every plugin setting.
• The URLs: stored in wp_options, in post content, in widget data, and often inside serialized arrays from page builders.

That last item is why a plain find-and-replace in a text editor breaks sites. Serialized strings record their own character length, so swapping localhost/mysite (16 characters) for yoursite.com (12) corrupts the array unless the tool recounts it.

Before You Touch Anything: A Five-Minute Pre-Flight

1. Update WordPress core, themes and plugins on localhost so you aren’t debugging version drift later.
2. Delete the junk: unused themes, half-built plugins, the three demo imports you forgot about. Smaller archive, faster upload.
3. Check your local PHP version against your host’s. Local defaults to PHP 8.1 or 8.2 in recent releases; a mismatch causes fatal errors on activation.
4. Note your local database name, user and password from wp-config.php. You’ll replace all three.
5. Take a copy of the whole folder and the SQL dump, and keep it untouched as your rollback.

If you develop with version control, push the repo first. Our notes on Git-based WordPress hosting cover deploying wp-content from a branch instead of dragging folders around, which is worth setting up if this won’t be your only migration.

The Plugin Route (Easiest for Sites Under 1 GB)

Duplicator, All-in-One WP Migration and WP Migrate all do the same job: package files plus database into a single archive, then rebuild it on the destination. The free tiers usually cap imports around 256 MB to 512 MB, which covers a typical brochure site.

1. Install the plugin on your localhost site and run the export. Duplicator produces an installer.php and an archive; All-in-One produces a .wpress file.
2. On the live server, install WordPress fresh (one click in most control panels), then install the same plugin.
3. Upload the archive and run the import. The plugin handles the search-replace, including serialized data.
4. Log in with your local credentials, since the imported database overwrites the new install’s user table.

If the upload fails at 90 percent, the cause is nearly always upload_max_filesize or max_execution_time. Ask support to raise them, or use the plugin’s FTP-drop method instead of the browser uploader.

The Manual Route (Better for Large or Fussy Sites)

1. Export the database

In XAMPP, open phpMyAdmin at http://localhost/phpmyadmin, select your database, then Export with the Quick method and SQL format. In Local, right-click the site and choose Open Site Shell, then run wp db export site.sql. Local also ships Adminer under its Database tab.

2. Upload the files

Zip the site folder, upload it by SFTP or the host’s file manager into public_html, then extract server-side. Uploading a single 400 MB zip takes minutes; uploading 40,000 loose files over FTP can take hours.

For a closer look at this topic, see our guide: WP-CLI: The Command Line Guide for WordPress Server Management.

Related reading: Integrating Autonomous AI Agents into Your WordPress Site.

Related reading: How to Handle Email Hosting When Migrating Your WordPress Site.

3. Create the live database and edit wp-config.php

Make a new MySQL database and user in your control panel, grant all privileges, then update DB_NAME, DB_USER, DB_PASSWORD and usually DB_HOST (localhost works on most shared hosts). Import the .sql file through phpMyAdmin.

4. Rewrite the URLs properly

With WP-CLI installed, one command does it safely:

wp search-replace 'http://localhost/mysite' 'https://yoursite.com' --all-tables --precise --skip-columns=guid

Run it with --dry-run first to see the replacement count. The official WP-CLI search-replace documentation explains why the GUID column should be left alone: changing it makes feed readers re-deliver every old post as new. Without shell access, the Better Search Replace plugin does the same job through the admin screen.

WordPress publishes a general reference for relocating an installation in its Moving WordPress article, which is worth skimming if your domain structure is changing too.

Post-Launch Checklist

• Permalinks: Settings, Permalinks, Save Changes. This regenerates .htaccess and clears most 404s on inner pages.
• Search visibility: uncheck “Discourage search engines” under Settings, Reading. Local and XAMPP setups often have it enabled.
• SSL: issue the certificate, then hunt mixed-content warnings in the browser console. Hard-coded http:// image paths are the usual culprit.
• File permissions: 644 for files, 755 for directories, 600 for wp-config.php where the host allows it.
• Email: localhost never sent mail, so contact forms are untested. Configure SMTP and send a real test.
• Caching and CDN: turn them on after you’ve confirmed the site renders correctly, not before.
• Analytics: connect tracking and confirm hits arrive. Server-level reporting like WordPress hosting analytics catches traffic that ad blockers hide from JavaScript tags.

Give the site a crawl too, then submit a fresh XML sitemap to Search Console so the live URLs get indexed rather than any staging address you tested on.

Errors You’ll Probably Hit, and the Fix

• Error establishing a database connection: credentials in wp-config.php don’t match the live database, or the user wasn’t granted privileges.
• Endless redirect to localhost: siteurl and home in wp_options still point at your machine. Fix those two rows in phpMyAdmin first.
• White screen after import: usually a PHP version gap or a plugin fatal. Set WP_DEBUG to true temporarily and read the line number.
• Broken layouts in a page builder: serialized data wasn’t handled. Re-run a proper search-replace, then regenerate the builder’s CSS cache.
• Missing images with working media library entries: the uploads folder didn’t transfer completely. Compare file counts.

If you manage sites for clients, standardise the plugin stack before you migrate rather than after. Our guide to bulk managing plugins across many client sites shows how that pays off at volume, and the walkthrough on moving from Medium to WordPress covers content-side cleanup if you’re also importing from elsewhere.

Frequently Asked Questions

How long does it take to move a localhost WordPress site live?

Between 30 and 90 minutes for a site under 1 GB, with DNS propagation adding up to 24 hours on top. Large media libraries and WooCommerce databases push that toward half a day, mostly because of upload time rather than configuration.

Can I move the site without a migration plugin?

Yes, and for sites over about 2 GB the manual method is usually faster and more reliable. You need SFTP access, phpMyAdmin or command-line MySQL, and a tool that handles serialized search-replace correctly.

Why does my live site keep redirecting to localhost?

Because the siteurl and home values in the wp_options table still hold the local address. Edit both rows directly in phpMyAdmin, or add WP_HOME and WP_SITEURL constants to wp-config.php as a temporary override.

Do I need the same PHP version on the live server?

Not identical, but stay within one major version. Running PHP 8.2 locally and 7.4 in production is the most common source of fatal errors right after an import, since modern themes drop support for older branches.

What happens to my localhost login details?

They carry over, because the user table travels with the database and replaces whatever the fresh install created. Change the password after launch, and browse the full site index if you want our hardening guides next.

Ready to Put That Local Build on a Real Server?

Our team migrates localhost and staging sites free of charge, including the database search-replace and SSL setup, usually the same day you send credentials. Tell us where the site lives now and we’ll handle the move from there.