Changing a WordPress domain is often part of a rebrand, business name change, or move to a clearer web address. Although the two main URL fields are available in the WordPress dashboard, editing them is only one part of the process. DNS, SSL, stored links, redirects, email, caching, and search visibility must also be handled carefully.
This guide explains the complete transition from olddomain.com to newdomain.com, including preparation, dashboard changes, nameservers, testing, and recovery options.
Introduction: Why Changing Your Primary Domain Matters#
Your primary domain influences how visitors find your website, how search engines index it, and how your brand appears online. A shorter or more relevant domain can make a website easier to remember, but an incomplete change can cause downtime, broken images, login failures, redirect loops, and lost search traffic.
It is important to distinguish between two separate changes:
- Hosting account primary domain: The main domain attached to your hosting account. It may also affect email accounts and hosting configuration.
- WordPress website address: The domain WordPress uses to load its files and display the website.
Changing the URL in WordPress does not automatically change your hosting account’s primary domain, DNS records, nameservers, SSL certificate, or email addresses.
For a Ruachost hosting account, prepare the new domain and point it to the correct nameservers first. If the hosting account’s primary domain must also change, submit a support ticket from the Ruachost Client Area with the old domain, new domain, and confirmation that the new domain is not already configured as an addon or parked domain.
Be aware that an account-level domain change may affect addresses such as info@olddomain.com. Plan how the equivalent info@newdomain.com mailbox will be configured before completing the transition.
Preparing for the Change: Backup Your Website#
Create a complete backup before changing any domain settings. A full backup gives you a recovery point if the new domain does not resolve, WordPress becomes inaccessible, or a database replacement damages stored settings.
Your backup should include:
- The WordPress database
- The
wp-contentdirectory - Themes and plugins
- Uploaded media
wp-config.php.htaccess, if present- Any custom server configuration
- A record of the current DNS settings
Download or store the backup somewhere separate from the website’s hosting account. A backup that exists only on the same server may be unavailable if the account develops a broader configuration problem.
Confirm that the backup can be restored—not merely that a backup file was created. At minimum, check that the archive contains your files and that the database export opens as a valid SQL file.
Before editing WordPress, also verify the following:
- The new domain is registered and active.
- It points to the hosting server.
- The hosting account recognizes the domain.
- An SSL certificate covers the new hostname.
- Both the
wwwand non-wwwversions behave as intended. - You have working access to the hosting control panel and database.
- You know how email accounts will be affected.
Do not change the WordPress URLs while the new domain still leads to a parking page or an unrelated server. DNS changes can take time to propagate because resolvers may retain cached records until their time to live expires.
It is also sensible to perform the change during a low-traffic period. Avoid publishing new content between the final backup and the migration, as those changes may be lost if you need to restore the backup.
Accessing the WordPress Dashboard: A Step-by-Step Guide#
While the old domain is still working, open the WordPress administration area at a URL such as https://olddomain.com/wp-admin.
Then:
- Enter an administrator username or email address.
- Enter the corresponding password.
- Complete two-factor authentication if enabled.
- Confirm that the account has administrator permissions.
- Keep the dashboard open while checking the new domain in a separate browser tab.
If the administration page redirects unexpectedly, clear the browser cache or try a private browsing window. Security, redirection, and caching plugins can also interfere with access, so record their current settings before making changes.
This guide primarily applies to a self-hosted, single-site WordPress installation. WordPress Multisite requires changes to additional database tables and possibly constants in wp-config.php; every subsite must then be tested. On WordPress.com, the primary domain is managed through the platform’s Domains area rather than only through Settings → General, as explained in the official WordPress.com domain guide.
Navigating to the Settings Menu#
From the WordPress dashboard sidebar, select Settings, followed by General. Locate these two fields:
- WordPress Address (URL)
- Site Address (URL)
Their names sound similar, but they have different functions.
Setting | Database option | Purpose | Typical value |
|---|---|---|---|
WordPress Address |
| Location of WordPress core files |
|
Site Address |
| Public address visitors open |
|
Most standard installations use the same value in both fields. Different values are appropriate only when WordPress core files intentionally reside in a separate directory.
If either field is unavailable or greyed out, the URL may have been defined in wp-config.php. In that situation, WordPress is overriding the database value, and the dashboard cannot edit it.
Before proceeding, copy the existing values into a text file. Pay close attention to:
http://versushttps://wwwversus non-www- Any subdirectory such as
/wordpress - Spelling and domain extension
Even a small mismatch can create repeated redirects or load the site from the wrong location.
Changing the Site Address (URL) and WordPress Address (URL)#
Enter the complete new URL in both fields. For a typical HTTPS installation, the values would be https://newdomain.com. Do not include a trailing slash unless the existing configuration specifically requires one.
Click Save Changes. WordPress may immediately log you out because the administration cookies are associated with the old domain. This is expected. Open https://newdomain.com/wp-admin and sign in again.
Changing these fields updates the home and siteurl options, but it does not replace every old URL stored in the database. Posts, image references, menus, widgets, page-builder data, and plugin settings may still contain olddomain.com.
The official WordPress migration documentation warns that broad database replacements can damage serialized data. Use a migration tool or search-and-replace method that understands WordPress serialization.
If WP-CLI is available, first run a dry test that reports proposed replacements without changing the database:
wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables-with-prefix --skip-columns=guid --dry-runAfter reviewing the output and confirming your backup, run the replacement:
wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables-with-prefix --skip-columns=guidIf the dashboard becomes inaccessible, you can temporarily define the URLs in wp-config.php. Add these lines above the comment that says to stop editing:
define('WP_HOME', 'https://newdomain.com');
define('WP_SITEURL', 'https://newdomain.com');These constants override the dashboard fields. Remove them later if you want the URLs to be editable under Settings → General again. Another recovery option is to update the home and siteurl rows in the applicable options table through phpMyAdmin. The table is commonly named wp_options, although the prefix may differ.
Updating Domain Nameservers#
Nameservers are not normally changed from the WordPress dashboard. They are managed wherever the domain’s DNS is hosted. Their job is to direct DNS queries to the service responsible for the domain’s records.
Before switching the WordPress URLs, make sure the new domain uses the nameservers or DNS records required by your Ruachost hosting account. If you manage individual DNS records instead, confirm that the root domain and intended www hostname point to the correct server.
Changing nameservers and changing WordPress URLs accomplish different tasks:
Change | Managed in | What it controls |
|---|---|---|
WordPress URLs | WordPress dashboard | URLs generated by WordPress |
Nameservers | Domain or DNS control panel | Where DNS records are managed |
Hosting primary domain | Hosting account or support | Main domain assigned to the account |
SSL certificate | Hosting control panel | HTTPS coverage for the new domain |
All four components must agree for a reliable transition. Editing only the WordPress fields cannot make an unconfigured domain reach the correct server.
After updating DNS, check that the new domain resolves to the expected hosting server. Also confirm that loading https://newdomain.com does not produce a certificate warning. If HTTPS is not ready, install or issue the certificate before sending visitors to the new address.
Keep the old domain active. It must continue resolving to a server that can redirect visitors and search engines to the corresponding URLs on the new domain.
Clearing Cache and Rebuilding Permalinks#
Old domain references may remain in several cache layers even after the database has been updated. Clear any WordPress caching plugin, server-level cache, content delivery network cache, and browser cache.
Next, go to Settings → Permalinks. Confirm that the desired permalink structure is still selected, then click Save Changes without changing it. This asks WordPress to rebuild its rewrite rules and often resolves post or page 404 errors.
Review .htaccess if the server uses Apache, especially if it contains custom rules referencing the old hostname. To preserve traffic and search signals, configure a permanent 301 redirect from each old URL to its equivalent new URL. For an Apache-hosted site, a basic domain-wide rule could look like this:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?olddomain\.com$ [NC]
RewriteRule ^(.*)$ https://newdomain.com/$1 [R=301,L]Add redirect rules only after confirming the new domain works. Back up .htaccess first, and ensure the old domain remains attached to the hosting account so requests can reach the redirect.
Avoid redirecting every old URL to the new homepage. A request for olddomain.com/contact/ should lead to newdomain.com/contact/ whenever that page still exists.
Finally, update the XML sitemap and any canonical URL settings. Submit the new sitemap in Google Search Console and use its Change of Address process where applicable. Keep redirects in place for the long term so old bookmarks, backlinks, and indexed URLs continue to work.
Testing and Troubleshooting Your New Domain Setup#
Test the website in a private browser window and on a device that has not recently visited it. This reduces the chance that cached DNS or cookies will hide a problem.
Check the homepage, several posts and pages, media files, menus, forms, search feature, checkout or membership functions, and the WordPress login page. View the browser console for missing assets and mixed-content warnings.
Also open several old-domain URLs. Each should return a permanent redirect to the matching page on the new domain.
Problem | Likely cause | Recommended action |
|---|---|---|
Cannot access | Incorrect | Use |
Redirect loop | Conflicting HTTPS or | Align WordPress, SSL, proxy, and redirect settings |
Posts return | Rewrite rules were not refreshed | Resave Settings → Permalinks |
Images are broken | Old URLs remain in content | Run a serialization-safe search and replace |
Browser shows “Not secure” | SSL missing or invalid | Issue a certificate for the new hostname |
Mixed-content warning | Assets still use | Replace old HTTP references with HTTPS |
Email stops working | DNS or account domain changed | Restore the required MX records and mailboxes |
Search traffic declines | Redirects or sitemap missing | Add |
Test response behavior rather than relying only on visual appearance. The new pages should return successful responses, while the old URLs should redirect once—not through a long chain.
Monitor error logs, analytics, form submissions, email delivery, and Search Console reports during the following days. Contact important websites that link to the old domain and request an update, especially for high-value links, even though the redirects remain in place.
Conclusion: Ensuring a Seamless Transition#
A successful domain change requires more than editing two WordPress fields. Back up the site, prepare DNS and SSL, coordinate the hosting-level domain, update home and siteurl, replace stored references safely, rebuild permalinks, and redirect the old domain. Thorough testing then confirms that visitors, search engines, email, and WordPress administration all continue to work.
If you need help coordinating your WordPress domain change or updating the primary domain on your hosting account, visit Ruachost and contact the support team before starting the transition.



