The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →The safest way to move a WordPress site to a new domain is to work in sequence: back up the files and database, build the destination, update both WordPress URL settings, replace old-domain references with a serialization-aware tool, then keep the old domain online with one-to-one 301 redirects while you test the new site.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Do not change the URL first and try to repair the site afterward. That order can lock you out of the dashboard, create broken links, and leave serialized plugin or widget data corrupted.
As an Amazon Associate I earn from qualifying purchases.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteWhat changes when you move a WordPress site
A domain move changes more than the address visitors type. WordPress stores the site URL in core settings, while themes, widgets, menus, media records, plugin options, canonical tags, feeds, forms, and content can contain the old domain in their own fields. Search engines and external sites may still request the old URLs for months or years.
A complete migration therefore has four separate jobs:
#1 Best Overall
- easy to use
- Free app
- Compatible with all devices
- It gives the best comparison between ten different hosts
- Move the WordPress files and database to the destination hosting location.
- Tell WordPress that both its installation URL and public site URL have changed.
- Update embedded old-domain values without damaging PHP-serialized data.
- Leave the old domain available and redirect each old address to its matching new address.
The exact screens differ by host and control panel, but the order below applies to a normal single-site installation. A multisite network, a host change with different PHP or database versions, or a site using custom server rules may require additional network-level and infrastructure work.
Choose an implementation that matches your access
There are three practical ways to perform the file, database, and URL work. The important distinction is not the brand of tool; it is whether the method can preserve serialized data, provide a dry run or rollback, and cover every URL.
| Method | Best fit | Strengths | Risks and checks |
|---|---|---|---|
| Migration plugin | Dashboard access and limited database administration | Guided export/import, search and replace that is designed for WordPress data, and often a rollback or staging workflow | Confirm that the plugin handles serialized values, supports your WordPress size and multisite status, and does not omit files or database tables |
| WP-CLI | SSH access and an administrator comfortable with commands | Repeatable operations, a dry-run search and replace, and documented handling of PHP-serialized data | Run commands against the correct installation and database; take an untouched backup before changing anything |
| Database administration plus file copy | Direct control of the server and database | Works without dashboard access and gives you direct control over imports and configuration | A plain SQL text replacement can break serialized values when the URL length changes; use a serialization-aware procedure instead |
For a small site, a migration plugin may be the least error-prone route. For a repeatable deployment or a large site, WP-CLI gives better visibility. Direct database work is a recovery option, not permission to run an unqualified replacement across every table.
1. Create recoverable backups before changing the domain
Make two independent backups while the old site still works: a complete copy of the WordPress files and an export of the database. Keep an untouched copy separate from any working copy you might edit during the migration. A database-only backup cannot restore uploads, themes, or plugins, and a files-only copy cannot restore posts, users, settings, or orders stored in the database.
Files to include
- The entire WordPress directory, including
wp-content/uploads, active and inactive plugins, themes, and the root files. wp-config.php, but store it securely because it contains database credentials and authentication keys.- Any server configuration or rewrite rules that your host requires for permalinks.
Database checks
- Export every WordPress table, including custom tables created by plugins. Preserve the table prefix and character set.
- Record the database name, user, password, host, and table prefix used by the current
wp-config.php. - Verify that the export can be opened or restored in a test database before you edit URLs.
Do not overwrite this original backup with a post-migration export. If a URL replacement or redirect change causes a problem, the untouched copy is your clean rollback point.
2. Prepare the new hosting location
Create the destination site before changing DNS. Provision a database and a document root, then confirm that the destination supports the WordPress version, PHP runtime, database engine, HTTPS, and required extensions used by the existing installation. If the database name, user, password, host, or table prefix will differ, note the new values.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Copy the WordPress files to the destination document root, preserving permissions and the directory structure.
- Import the database export into the new database. Do not import it into a production database that contains unrelated applications.
- Open
wp-config.phpon the destination and change only the connection values that actually changed:DB_NAME,DB_USER,DB_PASSWORD,DB_HOST, and, when applicable,$table_prefix. - Keep the destination private or use a temporary host-level access control while you work. Avoid letting search engines index an unfinished copy.
- Check that the destination can connect to the imported database before editing the canonical URLs.
If you are moving hosts and domains at the same time, complete the copy and database import first. Separating the two changes makes it easier to identify whether a failure comes from hosting, configuration, or URL replacement.
3. Change both WordPress URL settings
With the files and database in place, sign in to the destination dashboard and go to Settings → General. Replace both fields with the new HTTPS address:
- WordPress Address (URL) — the address where the WordPress core files reside.
- Site Address (URL) — the public address visitors use.
Enter the complete address without a trailing slash, such as https://new.example. In a conventional installation the two values are identical, but they are separate settings; changing only one can leave the dashboard, front end, login links, or generated URLs pointing at the old domain. Save the settings once, then expect to be redirected to the new address.
If the dashboard becomes inaccessible
You can temporarily force the values in wp-config.php. Add these definitions above the line that says WordPress has stopped editing, replacing the example with your real address:
define('WP_HOME', 'https://new.example');
define('WP_SITEURL', 'https://new.example');Use this as a recovery measure while you regain access and complete the migration. Remove the temporary definitions after the database settings are correct if you want the values to remain editable from Settings → General. If a hard-coded value is required by your deployment, leave both definitions in place deliberately and document that choice.
4. Replace old-domain references safely
Changing the two General settings does not rewrite every old URL stored elsewhere. Search the database and the files for the old domain after the new site loads. Common locations include image and attachment URLs, navigation menus, widget text, theme options, serialized plugin settings, custom fields, canonical tags, and form actions.
Why a raw SQL replacement is dangerous
PHP-serialized values store string lengths alongside their text. If an old domain is replaced by a domain with a different length, a simple text replacement can leave the length metadata wrong. The affected option may then fail to unserialize, causing missing widgets, broken theme settings, or plugin errors. The WordPress handbook specifically warns against an unqualified replacement across the entire database for this reason.
Use a serialization-aware tool
Use a WordPress migration plugin that explicitly supports serialized data, or use WP-CLI’s search-replace command. WP-CLI documents that the command intelligently handles PHP-serialized data and does not change primary-key values.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11From the destination WordPress directory, a cautious WP-CLI sequence is:
- Run a dry run against the old and new HTTPS values, including the protocol exactly as stored. A typical form is
wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --dry-run. - Review the reported table and row counts. Unexpected tables may contain legitimate references that need a separate decision; missing
wp_-prefixed tables can indicate that you are in the wrong directory or using the wrong database. - Run the same command without
--dry-runonly after confirming the destination and backup. - Repeat the search without replacement to find remaining old-domain values, including HTTP variants if the old site used both HTTP and HTTPS.
Do not replace a bare word that happens to be part of an email address, a third-party URL, or an unrelated text value. Match the old scheme and hostname as precisely as possible, then inspect the results. If your site is a multisite network, stop before running a single-site command: network tables, mapped domains, and per-site options need a network-aware migration plan.
5. Preserve the old domain with one-to-one 301 redirects
Keep control of the old domain and its hosting or redirect layer. Configure permanent 301 redirects from each old URL to the corresponding new URL. A 301 tells search engines that a page has moved permanently; it is not the same as sending every request to the new homepage.
Preserve paths and query behavior
If the old page was https://old.example/guides/controller, the preferred destination is the matching path on the new domain, such as https://new.example/guides/controller. Preserve paths, filenames, and meaningful query parameters when the application depends on them. Create explicit exceptions for pages that were intentionally renamed, and map those to their new equivalents.
- Use server-level redirect rules when you control the old host and need coverage before WordPress runs.
- Use a redirect plugin when the old site still runs WordPress and you need a manageable list, logging, or 404 monitoring.
- Learn WordPress lists Redirection, Simple 301 Redirects, and All-in-One SEO as examples of tools that can create redirects.
Avoid chains such as old URL → temporary URL → new URL. Redirect directly from the old address to the final HTTPS address. Do not let the old domain expire immediately: expiration removes the redirect path and can break inbound links, bookmarks, feeds, and visitors using cached results.
6. Cut over DNS and HTTPS
After the destination responds correctly on a temporary hostname or controlled test, point the new domain’s DNS records to the destination host. The exact record names depend on your provider, but the result should be that the new hostname resolves to the server containing the migrated files.
- Issue and install a certificate that covers the new domain, including the hostname visitors actually use.
- Verify that the site loads over HTTPS without certificate warnings before making it public.
- Keep the old domain’s DNS and web service active so its 301 rules continue to work.
- Once the new domain is live, set the preferred hostname consistently. Do not alternate between the www and non-www forms unless you intentionally redirect one to the other.
DNS changes can appear inconsistent while caches update. During that period, test from more than one network or use a host-file or staging method rather than assuming a single result represents every visitor.
7. Test the migrated site before declaring it complete
Test both the new site and representative old URLs. The checklist below targets the failures that most often survive a basic homepage check.
Recommended Free Tools
| Area | What to test | Failure sign |
|---|---|---|
| Homepage and navigation | Open the homepage, primary menus, category archives, pagination, and a selection of posts and pages. | 404 responses, links still using the old hostname, or loops between www and non-www addresses |
| Login and permissions | Sign in, sign out, reset a password, and open an editor screen with an administrator and a normal user where applicable. | Redirect loops, rejected cookies, missing capabilities, or a login form posting to the old domain |
| Media | Load images, responsive sizes, downloadable files, galleries, and featured images from older posts. | Mixed-content warnings, missing files, broken attachment URLs, or uploads still requested from the old domain |
| Forms and interactive features | Submit contact, comment, search, and other important forms; check email notifications and payment or membership callbacks if the site uses them. | Submissions posted to the old host, blocked cross-origin requests, or notifications not delivered |
| SEO signals | Inspect canonical tags, robots directives, XML feeds, sitemaps, pagination links, and structured URLs. | Canonical tags naming the old domain, a noindex directive left from staging, or feeds that still advertise old links |
| Redirects | Request the old homepage and several old deep URLs, including a post, page, media file, and a URL that was intentionally renamed. | 404 responses, homepage-only redirects, redirect chains, or an old domain that no longer responds |
| Code and database | Crawl the new site for old-domain strings, HTTP resources, and server error logs. | Mixed content, stale JavaScript or CSS URLs, plugin warnings, or database errors |
Re-save Settings → Permalinks once if normal post or page URLs return 404s after the move. Saving the existing structure regenerates rewrite rules; it does not replace the need for correct server configuration.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common failure modes and recovery paths
The dashboard redirects to the old domain
Check that both General settings were changed and that no old value remains in wp-config.php, a cache layer, or a reverse proxy. Temporarily define WP_HOME and WP_SITEURL as shown earlier, clear application and browser caches, then correct the underlying setting.
Best Value
- Free WordPress Hosting Guide Android Application. It Contains: A Brief Overview of WordPress Hosting, 9 Major Benefits of Managed WordPress Hosting.
- 5 Simple Steps to Choose WordPress Hosting, How to Maximize Your WordPress Hosting and Blogging Success, How to Choose the Best WordPress Hosting Provider, Optimize Your Blog with VIP Word.
- Press Hosting, What You Should Know to Choose the Best WordPress Hosting and Much More.
Widgets, menus, or theme options disappeared
This usually indicates damaged serialized data or an incomplete database import. Restore the untouched database backup or a verified pre-replacement copy, then repeat the replacement with a serialization-aware tool. Do not attempt to repair serialized length fields by hand in production.
Images are broken or browsers report mixed content
Search for both the old hostname and any http:// version of the new hostname in content, theme settings, and plugin options. Confirm that the files exist in the destination uploads directory, that the new certificate is valid, and that generated image URLs use HTTPS.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Old URLs return 404 or all redirect to the homepage
Compare the old request path with the destination path. Add one-to-one rules for renamed content, preserve paths where the content did not move, and check that the old host is actually serving the redirect configuration. A blanket homepage redirect hides missing mappings and discards the visitor’s intended destination.
Permalinks fail while the homepage works
Save the current permalink structure, then inspect the destination server’s rewrite support and document root. If only some paths fail, compare the generated URL with the file or route that should handle it and check for case differences or a missing redirect exception.
Search engines still show the old domain
That is expected during a transition. Keep the old domain and direct 301 mappings available, ensure the new pages expose self-consistent canonical URLs and feeds, and monitor crawl errors. A redirect preserves a destination signal, but it cannot compensate for missing pages or inconsistent canonical tags.
After launch: monitor, document, and retire carefully
Keep the old redirect layer active while users, bookmarks, external links, and search crawlers transition. Review web-server and redirect logs for requests that do not map cleanly, then add targeted redirects for valuable missing paths rather than sending them all to the homepage. Crawl the new site periodically for 404s, old-domain references, mixed content, and accidental noindex directives.
Document the final DNS records, certificate coverage, database credentials location, redirect rules, WordPress URL values, and the date of the last verified backup. Record which domain is canonical and which hostname redirects to it. This information shortens recovery time if a plugin update, host migration, or certificate renewal later exposes a hidden dependency on the old address.
Do not delete the old hosting account or release the old domain merely because the new homepage works. First verify that representative deep links, media URLs, feeds, and inbound links have a functioning one-to-one redirect, and retain a restorable copy of the old files and database.
Quick Recap
A concise migration runbook
- Download all WordPress files and export the complete database; preserve an untouched copy.
- Build the new hosting location, database, HTTPS certificate, and private test access.
- Copy files, import the database, and update changed connection values in
wp-config.php. - Set both WordPress Address (URL) and Site Address (URL) under Settings → General to the new HTTPS address without a trailing slash.
- Use a serialization-aware plugin or WP-CLI search and replace with a dry run to update embedded old-domain references.
- Configure direct 301 redirects from old URLs to matching new URLs and keep the old domain online.
- Point DNS to the destination, verify HTTPS, and test navigation, login, media, forms, feeds, canonicals, robots directives, and old deep links.
- Save permalinks if rewrite rules need regeneration, crawl for 404s and mixed content, and monitor redirects before retiring any old infrastructure.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
