From localhost to live: putting your WordPress site online

Moving a WordPress site from localhost to a live server means copying three things, repairing one of them, and deliberately leaving a fourth behind. You copy the theme and plugin files, the uploads folder, and the database. You repair the thousands of localhost URLs stored inside that database, using a search-and-replace tool built for WordPress, because a plain text find-and-replace corrupts the data. You leave wp-config.php behind, since the live site needs its own database credentials and fresh security keys. DNS switches last, after the live copy has been tested. Most disasters in this migration come from skipping one of those sentences.

What makes the trip

Three things travel. The wp-content directory carries your theme, your plugins, and every image in the uploads folder. The database carries the posts, pages, users, plugin settings and widget configurations, and those two together are the entire site. The third is smaller: the decisions in wp-config.php, table prefix, debug mode, and the values you will rewrite for production. The local file itself does not travel, and neither do the credentials in it, which belong to a database on your own machine that the live server cannot reach.

What stays behind

Developer plugins stay on localhost. Query Monitor and friends get deactivated and deleted before you export anything, because debugging tools shipped to production are noise at best and a leak of server internals at worst.

Media is the sneaky one, because it lives in two places at once. The files sit in wp-content/uploads, while the references to those files sit in the database, embedded in post content and attachment records as full URLs that begin with localhost. Copy the folder without fixing the references and the live site fills with images pointing at a computer in your house. Fix the references without copying the folder and the same images break from the other direction.

Why find-and-replace breaks the database

Much of what WordPress stores is serialized PHP, a format that records the length of every string next to the string itself. Your local URL is usually shorter than your live domain, so a straight text replacement changes the text while the recorded lengths still describe the old one, and the value becomes invalid. WordPress reads the corrupted entry, shrugs, and treats it as missing. The damage lands where you look last: widget settings, theme options, siteurl itself.

The URL swap therefore needs a tool that recalculates those lengths. WP-CLI does it with wp search-replace, which understands serialized values and can target individual tables. The interconnect/it Search Replace DB script does the same job in a browser. Migration plugins such as Duplicator and All-in-One WP Migration bundle the fix into the move itself. Any of those is correct. A plain SQL update over an exported dump is the one route that is not.

wp-config.php, written fresh

The live file needs four things from you. The database name, user and password the host provides. The same table prefix as your local install, so the imported tables match. WP_DEBUG set to false. And freshly generated security keys and salts: the old keys signed the cookies you created while building locally, and new keys invalidate every existing session, which is what you want on day one. Check the PHP version while you are nearby, because a site built on a newer PHP release than the server runs fails in ways that look like plugin bugs.

The order that avoids rework

Set up the destination first: a server and a fresh WordPress application, or an empty application if a migration plugin will populate it. Move the files, by SFTP for small sites or as part of a migration plugin's package. Import the database if you took the manual route, then run the URL replacement, then write the live wp-config.php. Test before anyone else can arrive: reach the site through the host's preview URL or a hosts-file entry on your own machine and click it through like a visitor. Front page, one inner page, the admin login, one form submission, one image at full size. When those five pass, change the DNS record. The launches that get into trouble are the ones that flipped DNS first and tested afterwards.

First-day breakages

Three breakages cover most launch-day requests. Inner pages returning 404s mean the rewrite rules need a flush: open Settings, Permalinks, and save, which rebuilds them. A white screen on some pages usually means a PHP version or missing extension mismatch between your machine and the server. Images still pointing at localhost mean the uploads folder and the URL replacement got out of step, so rerun the search-replace and check that the uploads tree arrived whole. None of these is an emergency, and all of them are cheaper to fix before the announcement goes out.

When the site moves again

The localhost-to-live move happens once in a site's life. Everything after it is a live-to-live migration, a working site with an audience moving between hosts, which needs its own cutover discipline and a rollback window. That process, including the option of having your host's engineers do the first move (Cloudways does the first site free), is covered in migrating a WordPress site to a new host.