To move wordpress from localhost to live server, copy your local WordPress files and database, connect them to a new live database, and change the old localhost URLs. This guide uses XAMPP as the local example and DirectAdmin for hosting, but the same order works with WAMP, MAMP and most shared hosting panels.
Keep the local copy untouched until the live site passes every test. WordPress’s official migration handbook also treats the files and database as separate parts of the move.
Step 1: Prepare the local site and live hosting
Why this matters: migration is easier to recover when you have a complete local backup and a ready destination before changing anything.
You need:
- A domain connected to your hosting account, or a clear plan for connecting it after the upload.
- DirectAdmin login details and access to the domain’s document root, usually its
public_htmlfolder. - Your local WordPress folder, such as
C:\xampp\htdocs\wordpress. - The local database name, username and table prefix from the local
wp-config.phpfile. - A new live MySQL database, database user and password. Do not use your local password unless you intentionally set the same one.
- A folder on your computer with two backups: a copy of the complete WordPress folder and an exported
.sqldatabase file.
Before exporting, open the local site and note its exact address. It may be http://localhost/wordpress, http://localhost/my-shop or another path. You must use that exact old URL during the replacement step.
If you want a hosting provider to handle the move, HostKarle includes free migration with its WordPress hosting plans. For a manual move, continue with the steps below.
What success looks like: you can open the local website, you know its old URL and database name, and you have both the files and database saved outside the XAMPP folder.
Step 2: Export the WordPress database from localhost
Why this matters: posts, pages, settings, users, menus and plugin data live in the database, not only in the WordPress files.
- Start Apache and MySQL in the XAMPP Control Panel.
- Open
http://localhost/phpmyadminin your browser. - Read the
DB_NAMEvalue in your localwp-config.php, then select that database in phpMyAdmin. Do not select a similarly named database by guesswork. - Choose Export, keep the export method as Quick, select SQL as the format, and start the export.
- Save the downloaded file with a clear name such as
my-site-local-2026-10-18.sql.
Open the first few lines of the SQL file in a text editor only to confirm that it is not empty. Do not run a global find-and-replace on the SQL file: WordPress themes and plugins can store URLs in serialized data, and changing string lengths manually can corrupt those values.
What success looks like: the SQL file has a sensible size for your site and your local database remains available in phpMyAdmin as an additional safety copy.
Step 3: Upload the local WordPress files to DirectAdmin
Why this matters: the database contains the content and settings, while the files contain WordPress core, themes, plugins, media and configuration.
First connect the domain in DirectAdmin if you have not already done so. Open the domain’s document root in File Manager. For a primary domain this is commonly public_html; an addon domain normally has its own document-root folder. Use the path shown by your account rather than assuming it.
On your computer, open the local WordPress folder. Select everything inside it, including wp-admin, wp-includes, wp-content, index.php, wp-config.php and the hidden .htaccess file if one exists. Create a ZIP archive of those contents, upload the ZIP through DirectAdmin File Manager, and extract it in the document root. Uploading one archive is usually more reliable than uploading thousands of small files one by one.
Check the extracted layout before continuing. If your local path was C:\xampp\htdocs\wordpress and you uploaded the wordpress folder itself, the site may end up at example.com/wordpress. For a site that should open at the domain root, the contents of that folder must be directly inside the live document root.
Keep the original local wp-config.php for reference, but expect to edit its database values in the next step. If File Manager does not show hidden files, enable its hidden-file option and confirm that .htaccess was uploaded. Do not upload the XAMPP installation itself; only upload the WordPress site folder.
What success looks like: the live document root contains wp-admin, wp-content and wp-includes at the expected level, and the uploaded archive is kept until the site works.
Step 4: Create and import the live database
Why this matters: the imported database must be owned by a live database user that WordPress can authenticate with.
In DirectAdmin, open MySQL Management or MySQL Databases under the account tools. The exact label can vary with the DirectAdmin skin.
- Create a database for the site.
- Create a database user with a strong, unique password.
- Add the user to the database and grant the required permissions, normally the full permissions offered for that database.
- Write down the final database name, username, password and database host. DirectAdmin may add an account prefix to the first two values.
- Open phpMyAdmin from DirectAdmin, select the new empty database and choose Import.
- Upload the local
.sqlfile, leave its format as SQL, and start the import.
The database name in the import screen must match the database you created. DirectAdmin documents phpMyAdmin access and the option for making it available through the control panel in its phpMyAdmin documentation.
If phpMyAdmin refuses the upload because the file is too large, ask your host which database-import method is available for your account. Do not split SQL statements randomly in a text editor. A command-line import, when SSH and the correct credentials are available, follows this pattern:
mysql -h DATABASE_HOST -u DATABASE_USER -p DATABASE_NAME < my-site-local-2026-10-18.sql
Replace every capitalised placeholder with the real value. The -p option prompts for the password instead of putting it in your shell history.
What success looks like: phpMyAdmin shows the imported tables, including a table ending in options, and the table prefix matches the $table_prefix value in the local wp-config.php.
Step 5: Edit wp-config.php for the live database
Why this matters: WordPress cannot use the imported content until its configuration points to the live database.
In DirectAdmin File Manager, make a backup copy of the uploaded wp-config.php, then open the original for editing. Change only the database connection values so they match the live database you just created:
define( 'DB_NAME', 'LIVE_DATABASE_NAME' );
define( 'DB_USER', 'LIVE_DATABASE_USER' );
define( 'DB_PASSWORD', 'LIVE_DATABASE_PASSWORD' );
define( 'DB_HOST', 'LIVE_DATABASE_HOST' );
Use the host value supplied by your hosting account. localhost is common on shared hosting, but it is not a value to assume when your provider gives you another database host. Preserve the existing $table_prefix, salts and other settings unless you have a specific reason to change them.
Save the file, then open the live domain. A database connection error at this point usually means one of four values is wrong: database name, username, password or host. If that happens, compare wp-config.php character by character with the values shown in DirectAdmin.
What success looks like: the live domain reaches WordPress rather than showing a PHP parse error, and the page is either your migrated site or a clear URL-related error ready for the next step.
Step 6: Replace localhost URLs with the live URL
Why this matters: links, image paths, stylesheets and WordPress’s own home address can still point to the local XAMPP URL after the files and database are online.
Write down both values before replacing anything:
- Old URL: the exact local address, for example
http://localhost/wordpress. - New URL: the exact public address, for example
https://example.com.
The safest bulk method is a serialization-aware tool. If WP-CLI is available in the live WordPress folder, run a dry run first:
wp search-replace 'http://localhost/wordpress' 'https://example.com' --skip-columns=guid --dry-run
Review the reported tables and replacement count. If the old URL is correct, run the same command without --dry-run:
wp search-replace 'http://localhost/wordpress' 'https://example.com' --skip-columns=guid
Run the command from the live WordPress directory, or add the appropriate --path=/path/to/wordpress option. The official WP-CLI search-replace documentation explains the dry-run option and why the command handles serialized data. Do not include a trailing slash in one URL and omit it in the other unless that is how the original value was stored.
If WP-CLI is not available but you can access the Dashboard, use a reputable search-and-replace tool that explicitly supports serialized WordPress data. If you cannot log in, you can first check the home and siteurl rows in the options table in phpMyAdmin. Use your actual table prefix, not necessarily wp_, and change only those two values to the new URL. Then log in and complete the full serialized-safe replacement.
What success looks like: opening the live URL no longer redirects to localhost, the login page uses the live domain, and the page source loads CSS and images from the live domain.
Step 7: Enable SSL and refresh permalinks
Why this matters: a domain change can leave rewrite rules and HTTP URLs out of sync even after WordPress loads.
Before forcing HTTPS, make sure the domain resolves to the hosting account and that its SSL certificate is active. In DirectAdmin, use the domain’s SSL tools to enable the certificate supplied with your hosting plan. Open the site using the final https:// URL and check that the browser does not show a certificate warning.
Then sign in at https://example.com/wp-admin and check Settings > General. Confirm that WordPress Address (URL) and Site Address (URL) both contain the correct live URL. Save only if a value is wrong.
Next open Settings > Permalinks. Do not change the structure unless you intend to; simply click Save Changes once. This refreshes the rewrite rules and often fixes page links that show 404 errors after a move. WordPress’s migration guidance also recommends refreshing permalinks when rewrites or .htaccess rules are involved.
What success looks like: the home page, a normal page, a blog post and the /wp-admin page all open over HTTPS with the expected permalink structure.
Step 8: Verify the live site before closing localhost
Why this matters: a site can display its home page while images, forms, menus or plugin settings still point to the development environment.
Use this final checklist:
- Open the home page in a private browser window and test the main navigation.
- Open at least one page, one post, one category and one media-heavy page.
- Confirm that images, CSS, JavaScript and fonts load from the live domain.
- Submit a contact or enquiry form without using real customer data.
- Log in and out of WordPress, then check the user profile and admin email address.
- Open Tools > Site Health and resolve migration-related critical errors.
- Search the page content and database for
localhostor the old local folder name. - Check the site on a phone and in a second browser.
- Keep the local folder and SQL export until you have completed a fresh live backup.
For a larger or business site, make the DNS change during a quiet period and record the old DNS values before editing them. Once the public domain opens the new hosting account and the checklist passes, you can archive the local project safely.
Troubleshooting after moving WordPress
“Error establishing a database connection”
Recheck DB_NAME, DB_USER, DB_PASSWORD and DB_HOST in wp-config.php. Also confirm that the database user was added to the database in DirectAdmin. The WordPress database-connection troubleshooting guide covers the same checks in more detail.
The site redirects back to localhost
The old URL is still present in home, siteurl or other serialized settings. Correct the two options if you are locked out, then run a serialization-aware search and replace for the complete old URL, including its local folder path.
Images are broken or the design is unstyled
Inspect one broken image in the browser and compare its URL with the live domain. Replace remaining old URLs, confirm that the wp-content/uploads folder was uploaded, and check that the theme and required plugins are active. If an image URL contains the wrong subdirectory, confirm that the WordPress files are in the intended document root.
Pages show 404 but the home page works
Go to Settings > Permalinks and click Save Changes. If that does not help, confirm that .htaccess exists in the WordPress root and that the site is using the same permalink structure as the local copy.
The browser shows a redirect loop after enabling HTTPS
Check that both WordPress URLs use the same https:// address and that your hosting SSL is active. Remove conflicting forced-HTTPS rules added by a plugin or custom .htaccess change, then test in a private window after clearing the browser cache.
If you prefer a provider-assisted route, HostKarle’s manual WordPress migration guide is a useful companion for moving an existing site to hosting.
FAQ
Can I move WordPress from localhost without reinstalling it?
Yes. Copy the existing WordPress files, export and import the existing database, update the database credentials, and replace the local URL. You do not need to create every page and plugin again.
What should I upload from XAMPP to live hosting?
Upload the contents of the local WordPress site folder, including wp-content, the WordPress core folders, wp-config.php and .htaccess when present. Do not upload the whole XAMPP program folder or unrelated local projects.
Do I need to change the WordPress database name during migration?
No. The live database can have a different name; update DB_NAME, DB_USER, DB_PASSWORD and DB_HOST in wp-config.php to match the new database. Keep the table prefix unchanged unless you are deliberately changing it and understand the database implications.
Why are my WordPress images still pointing to localhost?
The image URLs are stored in the database and may also appear inside serialized theme or plugin settings. Run a dry-run first, then use WP-CLI search-replace or another tool that understands serialized WordPress data instead of editing the SQL file with a plain text replacement.
Should I delete my localhost WordPress site after it goes live?
No. Keep the local files and exported database until the live site has passed your checks and you have a current live backup. After that, archive or remove the local project only when you no longer need it for development.
DONE move-wordpress-from-localhost-to-live-server words=2366
{“@context”: “https://schema.org”, “@type”: “FAQPage”, “mainEntity”: [{“@type”: “Question”, “name”: “Can I move WordPress from localhost without reinstalling it?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Yes. Copy the existing WordPress files, export and import the existing database, update the database credentials, and replace the local URL. You do not need to create every page and plugin again.”}}, {“@type”: “Question”, “name”: “What should I upload from XAMPP to live hosting?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Upload the contents of the local WordPress site folder, including wp-content, the WordPress core folders, wp-config.php and .htaccess when present. Do not upload the whole XAMPP program folder or unrelated local projects.”}}, {“@type”: “Question”, “name”: “Do I need to change the WordPress database name during migration?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “No. The live database can have a different name; update DB_NAME, DB_USER, DB_PASSWORD and DB_HOST in wp-config.php to match the new database. Keep the table prefix unchanged unless you are deliberately changing it and understand the database implications.”}}, {“@type”: “Question”, “name”: “Why are my WordPress images still pointing to localhost?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “The image URLs are stored in the database and may also appear inside serialized theme or plugin settings. Run a dry-run first, then use WP-CLI search-replace or another tool that understands serialized WordPress data instead of editing the SQL file with a plain text replacement.”}}, {“@type”: “Question”, “name”: “Should I delete my localhost WordPress site after it goes live?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “No. Keep the local files and exported database until the live site has passed your checks and you have a current live backup. After that, archive or remove the local project only when you no longer need it for development. DONE move-wordpress-from-localhost-to-live-server words=2366”}}]}Want to partner with us, suggest a resource or advertise on this blog? Email partnerships@hostkarle.in



