
Treat it as a migration
Changing your WordPress domain is not one setting change. It is a coordinated website migration.
The safest approach is to prepare the new domain, protect the database, map old URLs to new URLs, update WordPress carefully, and keep permanent redirects in place while search engines transfer signals.
Quick answer
To change a WordPress domain safely, back up the site, prepare the new domain and hosting, point DNS correctly, update WordPress URLs, replace old-domain references in the database, map every important old URL to its new equivalent with permanent redirects, submit the new sitemap, use Search Console Change of Address for a full domain move, and monitor both domains after launch.
Three migration facts worth remembering
Before you change the domain, understand what is actually moving
A domain move touches several layers at once. Your registrar controls the domain registration. DNS tells browsers and services where the domain should go. WordPress stores its own site URLs and often stores absolute URLs inside the database. Search engines know the old URLs and need clear redirect and sitemap signals to understand the move.
The four layers of a WordPress domain migration
- 1Domain and DNS
The new domain must be registered and its DNS must point to the correct hosting or infrastructure.
- 2WordPress configuration
WordPress Address, Site Address and any hard-coded URL constants must agree with the new domain.
- 3Database and assets
Old-domain references in posts, widgets, metadata and serialized settings may need a safe search-and-replace process.
- 4Search and referrals
Old URLs need direct permanent redirects to their matching new URLs so users and search engines reach the right destination.
First decide which migration you are actually doing
- IfOnly the hosting provider changes and public URLs stay identical→Then
Do not use a domain-move workflow. Follow a hosting migration process and change DNS only after the new environment is tested.
- IfThe entire site moves from olddomain.com to newdomain.com→Then
Use this guide, including one-to-one permanent redirects and Search Console Change of Address.
- IfOnly HTTP changes to HTTPS on the same hostname→Then
Use HTTPS migration guidance and redirects, but do not use the Search Console Change of Address tool.
- IfOnly some paths or pages change→Then
Redirect those individual URLs and update sitemaps. A full-domain Change of Address is not appropriate.
Migration checklist before touching the live site
Pre-migration safety checklist
- Own and verify the new domain before cutover.
- Create a complete backup of files and database.
- Keep a tested rollback route.
- Record the current DNS values and nameservers.
- Create a map from important old URLs to matching new URLs.
- Verify both old and new Search Console properties.
- Test the new site before changing public DNS when possible.
- Do not cancel the old domain after the move.

Step 1: Prepare the new domain and protect the old one
Register the new domain and make sure you control its DNS. If the change is part of a rebrand, check trademark and brand conflicts before migration. A new domain does not need keywords simply to be SEO friendly. The more important SEO requirement is preserving URL relationships and avoiding unnecessary content or architecture changes during the move.
Do not let the old domain expire after launch
The old domain is the source of your redirects and may still receive bookmarks, referrals and search traffic. Google recommends keeping redirects for at least one year. For users, keeping the old domain and redirects longer can be sensible.
Step 2: Back up WordPress and prepare a rollback path
A domain change can affect the WordPress database, login URL, media references, plugin settings, caches and external integrations. Create a full backup that includes both files and database, then verify that you know how to restore it. If your host provides staging, rehearse the process there first.
| Backup layer | What it protects | Why it matters during a domain move |
|---|---|---|
| Database | Posts, options, metadata, plugin settings | URL replacement can alter many database rows at once. |
| wp-content files | Themes, plugins and uploads | Images and plugin assets must remain available after the move. |
| Configuration | wp-config.php, server rules, environment settings | Hard-coded URLs or redirect rules can override dashboard settings. |
| DNS snapshot | Nameservers and key DNS records | A saved baseline makes rollback and troubleshooting much faster. |
Step 3: Connect the new domain to the correct hosting and DNS

How you connect the new domain depends on your hosting setup. Some hosts ask you to change nameservers. Others ask you to keep DNS where it is and update A, AAAA or CNAME records. Follow the hosting provider's documented values rather than copying records from another site.
Report analysis
Diagnose the layer before changing another setting
Many failed domain migrations happen because DNS, WordPress configuration and redirects are changed at the same time. Separate the layers so each test tells you something useful.
- If the new domain does not resolve, WordPress settings cannot fix that problem.
- If the homepage works but media or internal links still use the old domain, inspect database references and caches.
- If old URLs reach the new homepage instead of their equivalent pages, the redirect mapping is too broad.
Step 4: Update WordPress Address and Site Address carefully

In a typical single-site installation, go to Settings > General and update the WordPress Address (URL) and Site Address (URL) to the new HTTPS domain when the new domain is ready to serve the site. WordPress documents these fields as the application location and the address visitors use to reach the site.
If those URL fields are locked
Check whether WP_HOME or WP_SITEURL is defined in wp-config.php or whether your host manages the values. WordPress notes that a defined WP_HOME value prevents the Site Address field from being changed in the dashboard.
Step 5: Replace old-domain references without corrupting serialized data

WordPress content and plugin settings may contain absolute URLs. A safe replacement must handle serialized data correctly. WP-CLI's official search-replace command is designed for database replacements and supports a dry-run option. Better Search Replace is another widely used WordPress plugin for this task. Whichever method you use, test before committing changes.
| Method | Best for | Safety habit |
|---|---|---|
| WP-CLI search-replace | Administrators comfortable with command line access | Run with –dry-run first and review the replacement report. |
| Better Search Replace | Dashboard-driven database replacement | Back up first and use its dry-run workflow before writing changes. |
| Manual SQL replacement | Specialist cases only | Avoid naive replacements on serialized data unless you fully understand the storage format. |
wp search-replace 'https://oldsite.example' 'https://newsite.example' --all-tables-with-prefix --skip-columns=guid --dry-runDo not blindly replace every occurrence of the old domain
Review email addresses, API endpoints, licensed services and third-party URLs separately. A domain string can appear in places that should not be rewritten.
Step 6: Create direct permanent redirects from old URLs to matching new URLs
For a permanent domain move, Google recommends permanent server-side redirects such as HTTP 301 or 308 when possible. Redirect each old URL directly to its corresponding new URL. Avoid sending every old page to the new homepage and avoid unnecessary redirect chains.
What a clean redirect migration looks like
- 1Old page
https://olddomain.example/services/wordpress-migration/
- 2Permanent redirect
The server returns a 301 or 308 response with the exact new destination.
- 3Matching new page
https://newdomain.example/services/wordpress-migration/
Redirect QA before announcing the move
- Old homepage redirects to new homepage.
- Important old articles redirect to their matching new articles.
- Redirects go directly to final URLs without avoidable chains.
- HTTP variants and www/non-www variants follow the intended canonical host.
- Removed content is handled intentionally instead of redirecting everything to the homepage.
Step 7: Tell Google about the domain move
After the new domain is serving the site and redirects are active, verify both domains in Google Search Console. For a full move from one domain or subdomain to another, use the Change of Address tool. Google's current help documentation says the tool is for domain or subdomain moves and should be used after the move and redirects are in place.
When to use Search Console Change of Address
- Ifoldsite.com moves completely to newsite.com→Then
Use Change of Address after redirects are working and both properties are verified.
- Ifhttp://example.com becomes https://example.com→Then
Do not use Change of Address. Follow HTTPS and site-move guidance and redirects.
- Ifexample.com/old-section moves to example.com/new-section→Then
Do not use Change of Address. Use URL redirects and update the sitemap.
Submit the new sitemap in Search Console and update internal links to the new URLs. Google also recommends updating important external and profile links where practical. A small or medium-sized site may take a few weeks for most URLs to move in Google's systems, and temporary search visibility fluctuations can occur during processing.
Step 8: Verify the migration instead of assuming it worked
Post-migration verification
- Key new URLs return HTTP 200.
- Key old URLs return a permanent redirect to the correct new URL.
- No important page redirects to an unrelated homepage.
- Navigation and internal links use the new domain.
- Images, CSS, JavaScript and downloads load without mixed old-domain references.
- The XML sitemap lists new-domain URLs.
- Search Console can fetch and inspect important new URLs.
- Analytics and conversion tracking still record expected activity.
- Email, forms, webhooks, payment callbacks and third-party integrations are tested separately.
Report analysis
How to read the first few weeks after a domain move
Short-term volatility does not automatically mean the migration failed. Focus on crawlability, redirect quality, indexing and user-facing errors rather than reacting to every daily ranking movement.
- A rise in 404s often means the redirect map missed real old URLs.
- A large number of redirect chains usually means old rules were layered instead of consolidated.
- If new URLs are crawlable and redirects are correct, allow time for search systems to process the move.
Common domain-migration mistakes that create avoidable SEO damage
| Mistake | Why it hurts | Better approach |
|---|---|---|
| Changing domain, theme, content and URL structure together | Too many variables change at once, making diagnosis difficult | Keep the migration focused. Make unrelated redesign changes separately when possible. |
| Redirecting all old URLs to the new homepage | Destroys page-to-page relevance and frustrates users | Map old URLs to the closest matching new URLs. |
| Cancelling the old domain quickly | Breaks redirects, bookmarks and old backlinks | Keep the old domain registered and redirects active. |
| Updating WordPress before the new domain can serve the site | Can lock administrators out or create downtime | Prepare DNS, hosting and rollback first. |
| Skipping database checks | Leaves old media, links or plugin settings behind | Use a serialized-data-aware replacement tool and verify results. |
| Treating a temporary ranking fluctuation as failure | Encourages unnecessary changes during processing | Monitor crawl, redirects and indexing before making new structural changes. |
Pros
- A necessary rebrand can align the site with the business name.
- A shorter, clearer domain can improve memorability and communication.
- A legally safer domain may remove trademark or brand-confusion risk.
Cons
- A domain move adds technical and SEO migration risk.
- Backlinks and bookmarks depend on long-lived redirects.
- Search visibility can fluctuate while the move is processed.
- Email, forms and third-party integrations may need separate reconfiguration.
Practical verdict
Change the domain only when the business reason is stronger than the migration cost
A domain change can be done safely, but it is not a routine SEO optimization. If you have a real rebrand, legal, ownership or usability reason, use a controlled migration plan. If the goal is simply to add keywords to the domain, improving the existing site is usually the lower-risk path.
Frequently asked questions
Will changing my WordPress domain name hurt SEO?
It can cause temporary search fluctuations, but a well-planned migration with direct permanent redirects, updated internal links, a new sitemap and Search Console migration signals gives search engines a clear path to transfer signals.
How long should I keep 301 redirects after changing domains?
Google currently recommends keeping redirects for at least one year. From a user and referral perspective, keeping the old domain and redirects longer can be useful.
Do I need the Search Console Change of Address tool?
Use it for a full move from one domain or subdomain to another after the redirects are working. Do not use it merely for HTTP-to-HTTPS changes or for moving individual paths within the same site.
Should I use Better Search Replace when changing a WordPress domain?
It is one option for replacing old-domain references in the database. Back up first and use a dry-run or equivalent preview. WP-CLI search-replace is another option and is designed to handle serialized WordPress data.
Can I change only the WordPress Address and Site Address fields?
Those fields are important, but a full domain migration usually also requires DNS changes, database URL checks, permanent redirects, sitemap updates and verification of external services.
Should I change my domain just to get a more SEO-friendly name?
Usually not. A domain move introduces migration risk, and keywords in the domain are not a substitute for useful content, strong site architecture, relevant links and a good user experience.
Sources and references
Planning a domain or hosting change?
Use Bloggingfy's migration and DNS guides before changing the live site.
Start with a backup, confirm which infrastructure layer is changing, and keep a tested rollback route before touching production.



