You know the feeling. The old domain has to go live, the client wants the new brand in search, the staging site looks fine, and somebody in the room says, “It's just a domain change, right?” That's usually the moment a clean launch turns into a migration.
A WordPress domain change is never only a URL swap. WordPress's own migration handbook makes it clear that the process has to happen in sequence, starting with a full backup, then changing the WordPress Address and Site Address, then updating files and, if needed, moving the database and files too. Until the rest of the migration is done, the site can briefly show a 404 after the URL change, which is exactly why the old domain and the new domain have to be planned together, not treated like separate chores. WordPress migration handbook
For Elementor-heavy sites, that gap is where the damage becomes apparent. The homepage may load, but old template links, WooCommerce product paths, forms, analytics tags, and CDN assets can still point at the wrong domain. If you need a broader migration reference while you map out the cutover, the AI Search Optimization Platform from Nuwtonic is one useful resource to keep nearby, especially if you're trying to understand how a domain move affects visibility beyond the site itself.
When a move is urgent, it usually falls into one of four buckets. A rebrand changes the public face of the business. A domain swap consolidates or replaces a temporary address. An HTTPS migration changes the trust layer as much as the URL. A multisite split pulls one network into separate properties, which is where people discover that a “simple” rename is really several site moves at once.
The safest way to think about it is this, the domain change is the visible moment, but the dependencies are what decide whether the launch survives. WordPress settings only affect how the CMS resolves URLs at runtime. They don't rewrite old links inside Elementor templates, they don't refresh WooCommerce slugs, and they don't fix a form webhook that still posts to the retired domain. That's why a proper checklist needs to start with the messy stuff you can still control before DNS changes.
Prepare the site before anything moves
Start with a full backup, files plus database, and store it off-site. Then set up staging and do a dry run there first, because the worst time to discover a broken redirect is after search engines have already found it. Keep an inventory of admin logins, registrar access, hosting credentials, analytics access, payment gateway keys, and email-sending settings, because the handoff always stalls on one missing password.
Practical rule: if you can't restore the old site in minutes, you're not ready to move it.
The other thing that gets skipped is the baseline. Save current traffic, top landing pages, indexed URLs, and Search Console status before you touch the live domain, so you can tell the difference between a real recovery problem and normal post-move noise. I also like to inventory every integration that touches the domain, especially CRM forms, CDNs, checkout flows, and automation tools, because those are the places that break without warning.
If the domain change is tied to content strategy or search visibility, pair your technical plan with editorial cleanup. A change like this is a good time to review templates, internal linking, and title patterns, but only after the migration path is stable. For the migration mechanics themselves, the WordPress site migration guide is a reasonable companion reference if your team wants a second checklist alongside the core WordPress workflow.
DNS, Nameservers, and SSL for the New Domain
The domain becomes visible to the public at the DNS layer, not in WordPress. If you're moving the entire zone to a new provider, nameserver changes hand delegation over to the new host. If you're keeping the zone where it is and only pointing the site somewhere else, updating A and CNAME records is enough. That distinction matters because the wrong choice can create a propagation mess that looks like a site outage when it's really just an incomplete DNS handoff.
A lower TTL before the cutover shortens the waiting window, which is why experienced teams reduce it ahead of time rather than on the morning of launch. Then issue and validate an SSL certificate for the new domain before traffic arrives, because nothing looks more broken than a site that resolves cleanly but throws certificate warnings on first load. WordPress.com's 2025 guidance puts the DNS change first, then URL updates, then Google Search Console's Change of Address step, and WP Engine also treats 301 redirects as paramount in the handoff process. WordPress.com domain change guide WP Engine domain move guidance
What actually needs to change
The registrar side usually handles the nameserver or record edits. The hosting side handles certificate issuance, so don't waste time digging through wp-admin for a problem that lives outside WordPress. If you want a clean practical walk-through of SSL plus DNS setup that stays close to the server side, the Wistec SSL DNS setup reference is a useful one to compare against your own hosting workflow.
A domain can resolve before it's actually safe for users, which is why certificate validation comes before the public switch.
That separation also explains why propagation can feel inconsistent. Some visitors will reach the new destination quickly, while others keep seeing the old server until cached DNS records expire. In practice, that window can be short or annoyingly long, so the cleanest move is to keep both the DNS target and the certificate ready before telling WordPress the domain has changed.
For HTTP to HTTPS situations, or any move where insecure assets would cause trust problems, the article on HTTP to HTTPS SEO is worth keeping open while you test browser behavior and mixed-content warnings.
Changing WordPress Address and Site Address
Once DNS is live and SSL is trusted, the WordPress-side swap is straightforward, but only if the new domain already resolves correctly. In Settings → General, the WordPress Address (URL) tells WordPress where core files live, while the Site Address (URL) is the public-facing address visitors see. In many normal installs they match, but they are not the same thing, and mixing them up is a classic way to lock yourself out.
If the admin area is still reachable, update those fields there first. If the site is already unreachable, switch to editing wp-config.php or the database directly rather than waiting on wp-admin access that may not come back on its own. In multisite or subdomain setups, be careful not to treat each site as an isolated single install, because the network structure can keep old-domain references in places that are easy to miss.
The part people get wrong
The common mistake is changing the URL fields before SSL is valid. That can create a login loop, or it can push the site into a state where the browser refuses to trust the admin session. If that happens, go back to the server-side configuration and restore access there, then revisit the WordPress URL fields only after the certificate and DNS state are stable.
WordPress's migration handbook is explicit that the move has to be done in sequence, not all at once, which is why this step is about runtime behavior, not content rewriting. It changes how WordPress interprets the domain, but it does not rewrite hard-coded references stored inside posts, widgets, or templates. Elementor sites usually expose that difference fast, because the editor and the front end can still hold old URLs even after the general settings look correct.
If you are dealing with a network install, take a slower approach and verify each site's URL handling separately. A bulk change in a multisite can look successful while hidden mappings, uploaded media paths, or domain-specific plugin settings still point to the old address. That is one of those situations where the admin screen says “done” long before the site is.
Database Search-and-Replace the Safe Way
This is the risky part. URLs live all over the database, and some of them are stored in serialized structures, which means a careless find-and-replace can corrupt widget settings, option arrays, and template data. WordPress.com and Jetpack both recommend database-wide replacement or WP-CLI after the swap, and hosting guidance commonly shows wp search-replace 'old.example.com' 'new.example.com' as the safer bulk method for replacing hard-coded URLs across the database. WordPress.com domain change support
The rule is simple, don't do a naive replace on the live database if you can avoid it. Export the database first, run the replacement on staging, and validate that the homepage, media library, and admin screens still behave. If you have access to WP-CLI, a dry run first is the cleanest way to see what will change before you commit it.
Safe methods that don't corrupt data
A plugin such as Better Search Replace or Search & Replace can work if the scope is limited and you know exactly what tables you're touching. WP-CLI is better when you need repeatability and lower risk, because it's explicit about the search string and the target string. Either way, the point is the same, update old-domain references without flattening the structure that WordPress expects to read back later.
Practical rule: the right search-and-replace leaves the site looking untouched except for the domain itself.
After the rewrite, run a quick validation pass. Check a few pages with curl, inspect media URLs in the library, and click through a sample of saved template content. If the domain appears in the database in plain text, in widgets, menus, or custom fields, that's not a problem. The problem is when the data structure itself gets mangled and the page editor starts showing blank panels or broken blocks.
This is also the moment to decide whether to leave the old domain as a historical reference inside logs, exports, or internal notes. For production content, old references need to be replaced. For audits and backups, keep the original backup untouched so you've got a clean recovery point if a later step exposes a bad row.
Elementor, WooCommerce, and Dependent Systems
A lot of migrations look finished but still fail in user-facing ways. Elementor stores more than visible content, it also carries CSS output, template data, asset references, and embedded links that can survive the URL swap long after the homepage looks fine. WooCommerce adds product permalinks, cart flows, checkout pages, and catalog paths, which means a successful domain move still needs a second pass through the commerce layer.
For Elementor, regenerate CSS and re-save templates after the search-and-replace, because stale stylesheet output can keep old paths alive. For WooCommerce, re-save permalinks and confirm product pages, shop archives, cart, checkout, and account pages all resolve on the new domain. If a site uses contact forms, webhook endpoints, or SMTP plugins, verify those integrations explicitly, because forms often fail without any obvious front-end error.
The same logic applies to analytics and CDN settings. Old tracking IDs may still fire, but they can point at the wrong property or keep recording the retired domain in reports. CDN caches can also hold onto old asset URLs until you purge them, which is why image files and background assets sometimes still load from the old host even after the site has moved.
If you're working inside Elementor and WooCommerce together, the Elementor WooCommerce tutorial is a useful companion reference for understanding how templates and shop components interact when URLs change.
The hidden breakpoints
The failures that matter most aren't usually on the homepage. They're in product images, form submissions, checkout redirects, and template-linked media. A page can render perfectly and still send customers into a broken flow the moment they click Add to Cart or submit a lead form.
Practical rule: if the site's HTML loads but the business workflow fails, treat it as a migration error, not a plugin bug.
That's why I always test login, checkout, media loading, and analytics after the URL swap. Elementor-based builds are especially prone to this because the site often looks polished while still depending on a web of saved links, global widgets, and embedded integrations that no visual QA step will catch. The fix is boring but effective, open the templates, save them again, clear caches, and verify every path that touches revenue or lead capture.
301 Redirects and Google Search Console
The SEO layer is where the move gets formalized. A 301 redirect is the permanent signal that tells search engines the old URL has moved, and migration guidance from WordPress and hosting providers treats redirects as required if you want to preserve visibility. The practical order is simple, add the new domain in Google Search Console, verify the old property, then submit the move after the domain and DNS changes are stable.
The old domain should redirect page by page to the new one, not dump everything onto the homepage. That matters because each page carries its own search history, internal references, and backlinks. Server-level redirects are easier to audit than plugin rules, and they hold up better once you start checking a larger site with hundreds of URLs.
Quick reference for redirect and Search Console steps
| Step | Where | Why it matters |
|---|---|---|
| Add the new domain as a property | Google Search Console | Needed before Google accepts the move |
| Verify the old domain too | Google Search Console | The old property is where the change is submitted |
| Implement 301 redirects | Server or edge layer | Preserves users, backlinks, and indexing signals |
| Submit the sitemap on the new domain | Search Console | Helps discovery of the new URLs |
| Use Change of Address | Search Console old property | Tells Google the move is intentional |
Once the redirects are live, submit the new sitemap and check that internal links point straight to the new domain instead of bouncing through redirects. Internal redirect chains waste crawl budget and slow down index updates, which is the kind of problem that lingers after the URL change itself.
If you want the migration path in one place, the clean DNS, SSL, and database work from earlier steps is what makes this section effective. Without those pieces in place, redirects only cover up a deeper configuration problem.
Troubleshooting the Most Common Breakages
The site can be “migrated” and still be wrong in a dozen small ways. Redirect loops usually mean the old and new rules are fighting each other, or a cache layer is serving stale headers. Mixed-content warnings usually mean some hard-coded HTTP assets survived the search-and-replace, which is why browsers trust the page but distrust part of what it loads.
Locked-out wp-admin almost always traces back to a bad domain setting or an SSL mismatch. Broken Elementor styling often points to stale generated CSS or template assets that haven't been regenerated after the swap. Images returning 404 can come from old media URLs in custom fields, theme options, or page builder storage, while lost WooCommerce carts are usually tied to cookie scope, cached checkout pages, or a redirect that interrupts the session flow.
Fast triage that saves time
Open the browser console first when styling looks wrong. It will often tell you whether a script, stylesheet, or image is still loading from the old domain. Then check the server error log and the redirect response headers, because those two places usually tell you whether the break is in WordPress, the server, or the cache layer.
Practical rule: fix the layer that owns the break, not the layer that shows the symptom.
For redirected assets, look for patterns instead of isolated misses. If a whole folder of images still points at the old host, that's a search-and-replace miss, not a random cache problem. If only logged-in users see the issue, the session or cookie path is probably the culprit. If checkout breaks but product pages work, focus on the cart and account endpoints before you blame the theme.
A clean monitoring routine helps the site settle. Check Search Console coverage on day 2, compare traffic against your baseline on day 4, and run a fuller crawl on day 7. Keep the old domain renewed for as long as you own the new one, and update anything public that still references the retired address, including social profiles, email signatures, and business listings.
If you want Elementor tools that help with layouts, widgets, and the maintenance work around migrations, Exclusive Addons is built for that kind of WordPress workflow. Visit Exclusive Addons if you want a plugin stack that can support the rebuild, cleanup, and post-migration fixes around a domain change.