Why Local Sites Break When They Go Live
Building a WordPress site on your computer is a sensible habit. It is fast, safe for experiments, and costs nothing while you learn. But a local site is written to a different address than the live one, and that address is stored in hundreds of places: the database, settings, media URLs, widget content and plugin configuration.
Copy the files to a live server without handling those references, and you get a site where the homepage loads but the images are broken, the links point back to your computer, and the admin area redirects to a folder that does not exist online. This guide shows two ways to move the site correctly: a migration plugin method for most people, and a manual method for when plugins are not available or you want full control.
What Must Change in a Migration
| Item | What changes |
|---|---|
| Site address and WordPress address | From your local address to your live domain |
| Database records | Every stored URL referencing the old address |
| Configuration file | Database name, user, password and host for the live server |
| Files | Uploaded to the live host, with correct folder permissions |
| Permalinks | Regenerated so post URLs resolve on the new server |
| Environment settings | Debug mode off, caching on, local tools removed |
Before You Move: Preparation Checklist
- Finish your content and design locally. Migrating a half-built site means doing it again later.
- Take a full backup of the local site, both files and database, and store the copies somewhere other than the local folder.
- Set up hosting, and create an empty database with a user that has full privileges on it.
- Point your domain’s DNS to the new host, or use a temporary hosts-file entry if you want to build the live site before switching the live domain.
- Have the database credentials ready: name, user, password and host. On shared hosting, the name and user are usually prefixed with your account name.
- Download a copy of your local uploads folder so large media files can be re-uploaded if the archive fails.
Method 1: Migration Plugin (Recommended)
This approach handles the URL rewriting for you and takes about thirty minutes for a typical site.
- Install a migration plugin on the local site. Common options create a single package containing your files and database, and can also push the site directly to a remote destination if your credentials are supplied.
- Create the export. Choose the full-site option, including the database, and let it finish. Large sites produce large archives, so check for a completion message rather than assuming.
- Install a fresh WordPress on the live server. You only need the installer finished, with no content. This gives you a working environment to restore into.
- Upload the migration plugin to the live site, and use its import or restore function to upload your archive from step two.
- Enter the new URL when prompted. The plugin rewrites the database references as it restores.
- Run the save-permalinks step after restore, which regenerates rewrite rules on the new server.
- Log in and test. Check the homepage, an article, an image-heavy page, the menu, and the admin dashboard.
- Delete the migration plugin on both sites once the move is verified. Leaving backup archives in the web root is a security and storage problem.
Method 2: Manual Migration
Manual migration is more work but leaves nothing to chance and works on hosts where plugins are restricted.
Step 1: Export the local database
- Open your local database tool, such as phpMyAdmin through your local stack’s control panel.
- Select your WordPress database.
- Export it in SQL format and save the file.
Step 2: Rewrite the URLs in the database file
Never open a large SQL file in a text editor and use a global find and replace on the word “http”. A correctly built search-and-replace tool, or a command-line tool if you have one, changes only the specific local address to the specific live address and handles serialised data correctly.
The safest sequence is to import the database first and then run a proper search-and-replace inside WordPress using a dedicated tool, or to use the command-line method below if you have access.
Step 3: Upload the files
- Compress the entire local WordPress folder into a single archive.
- Upload it to the live server through the file manager, or via FTP if the archive is large.
- Extract it into the correct directory: the web root for your domain, or the folder for the addon domain or subdomain you are using.
- Check that index.php, wp-admin and wp-content now sit directly in the correct directory.
- Set folder permissions to 755 and file permissions to 644.
Step 4: Configure the connection
Edit wp-config.php so the database name, user, password and host match the live database you created. Keep the authentication keys from your local file, or generate new ones.
Step 5: Import the database
- Open phpMyAdmin on the live host and select the live database.
- Import the SQL file you exported earlier.
- If the file is large, import it in parts or ask your host to restore it from a compressed copy.
Step 6: Fix the URLs
If you have not already replaced the local address, do it now using a dedicated search-and-replace tool that handles serialised data. Replace your old local address, including the port if there was one, with the new live address. Then open the site and check that the header image, logo and internal links resolve to the live domain.
Step 7: Regenerate permalinks
Open Settings, then Permalinks, and click Save without changing anything. This rewrites the rules and fixes most “404 on posts” problems on a fresh migration.
Post-Migration Checklist
- Site address and WordPress address both show the live domain in Settings, then General.
- Homepage, three articles, a category page and a contact page load correctly.
- Images display, including ones inside old posts.
- Menus point to live URLs, not local ones.
- Permalinks work for posts and pages.
- SSL is installed and the site loads over HTTPS with no mixed content warnings.
- Search engine visibility is enabled, so the site is not still set to discourage indexing.
- Debug display is off and error logging is appropriate for production.
- Local-only plugins, such as debugging bars and query inspectors, are deactivated and deleted.
- Caching and backup plugins are configured for the live environment.
- Forms submit correctly and notification emails arrive.
- Sitemap loads, and the URL is submitted in Search Console.
- Users and passwords are reviewed; remove test accounts you created locally.
- Uploads directory permissions allow new uploads.
Common Problems and Their Fixes
| Problem | Cause | Fix |
|---|---|---|
| Site redirects to the local address | Address fields still hold the local URL | Update them in the database or via the configuration file |
| Broken images and links | URL replacement incomplete | Run a full search-and-replace across the database, including serialised data |
| 404 errors on posts | Rewrite rules not regenerated | Save permalinks once, without changing settings |
| White screen | PHP memory limit, plugin conflict or syntax error during editing | Rename the plugins folder, raise memory, and check the error log |
| Database connection error | Wrong credentials or wrong host name | Confirm the prefixed database name, user and host with your host |
| Mixed content warnings | Assets still referenced over http | Update URLs to https and clear caches |
| Styles missing | Theme files did not upload fully | Re-upload the theme folder and check permissions |
| Cannot log in to wp-admin | Stale cookies or a redirect loop | Clear cookies, try an incognito window, check the address fields |
Going Live Without Losing Search Visibility
- Remove any staging restrictions that block search engines, and check that no index-blocking header or password protection remains.
- Keep the same permalink structure the site had before, if it was live previously, so existing URLs continue to work.
- Set up redirects for any URL that changed, using 301s, and avoid chains.
- Submit the sitemap and confirm that Google can fetch it.
- If this is a relaunch of an existing domain, monitor Search Console for coverage errors in the first two weeks.
- Update the site address in your Analytics account, or confirm the tracking property follows the new domain.
Frequently Asked Questions
Do I need to install WordPress on the live server first?
For the plugin method, yes; a working installation gives you something to restore into. For the manual method, you can upload the files and database directly without running the installer, provided the configuration file is correct.
Can I migrate without touching the database?
No, not if the local and live addresses differ. The database stores the old address, and skipping the replacement produces exactly the broken images and redirects described earlier.
Is a migration plugin safe?
Reputable, well-maintained plugins are safe and widely used. Choose one with a strong update history, and delete the archive files and the plugin afterwards so old copies of your database are not left publicly accessible.
How long does a migration take?
A small site takes twenty to forty minutes including verification. Large sites with many images can take a few hours, mostly spent uploading and extracting files.
Will my local site still work after migrating?
Yes. Migration copies data rather than moving it, so keep the local copy as a development environment. Just remember that content added locally after migration will not appear live unless you migrate again.
What if I change the domain again later?
Repeat the same process: take a backup, then run a search-and-replace from the old domain to the new one, restore, and update the address fields. Migrations get easier each time.
Migration Questions After You Go Live
Should I test the live site before switching the domain?
Yes, if possible. A temporary hosts-file entry on your own computer lets you view the live site on the real domain before DNS changes for everyone else. Alternatively, use a temporary domain from your host, complete the migration, run the checklist, and then point the final domain at it and repeat the URL replacement. Testing in advance turns a public outage into a private one.
How do I keep developing locally now that the site is live?
Decide which environment owns the content. The common pattern is to develop locally with a copy of the database, then push only the theme or plugin changes live, rather than pushing the whole database. If you migrate the entire database back and forth, you will overwrite live content with older local versions and lose comments or posts in the process.
What should I do about the old local URL still appearing in emails or feeds?
Check your site title, tagline, email templates, form notifications, RSS feed settings and any hard-coded URL in the theme options. Automated migration tools catch database records, but hard-coded values in theme files and plugin settings sometimes survive. Sending a test email from the contact form and reading it on another device is the quickest way to catch the ones that matter.
How soon should I submit the live site to search engines?
After the checklist is complete: URLs correct, SSL working, indexing enabled, sitemap reachable. Submitting a broken site wastes a crawl, and repeated errors at launch are harder to recover from than a week’s delay. Once you are confident, submit the sitemap and request indexing for your most important pages.
What if permalinks still 404 after saving them?
Check for a stale redirect rule in the hosting configuration, confirm that the server is Apache with rewrite support or Nginx with the correct rewrite block, and make sure your hosting plan permits the .htaccess file your site needs. On managed hosts, ask support to confirm that the rewrite rules for WordPress are in place.
Do I need to reinstall plugins after migrating?
They travel with the files, but premium plugins often require you to activate a licence on the new domain, and a few detect the domain change and deactivate themselves. Expect to re-enter licence keys, reconnect API integrations, and re-save settings for caching, SEO and email delivery after any migration.
Final Thoughts
Moving a WordPress site from localhost to a live server is a three-part task: files, database and URLs. Handle all three, run a proper search-and-replace rather than a blind one, save your permalinks after the move, and work through the verification checklist before telling anyone the site is ready. Do that, and the live version will behave exactly like the one you built on your own computer.