WordPress Change Website URL Safely in 2026

You changed the domain. Or you forced HTTPS. Or you moved a staging site into production and now the login redirects somewhere strange, product images are broken, and Divi layouts look half alive.

That’s the moment it becomes apparent that wordpress change website url is not a one-field update. It touches your WordPress options, your database content, your builder data, your redirects, and every plugin that stores absolute URLs. On a simple brochure site, you can sometimes get away with a quick settings edit. On a Divi and WooCommerce build, that shortcut is where trouble starts.

The safest path is boring on purpose. Back up everything. Change the address using a method that won’t lock you out. Then run a serialization-aware search and replace across the database. After that, test the site like a user would, not like a developer hopes it works.

Why Changing Your WordPress URL Is a High-Stakes Task

Changing your WordPress URL looks harmless because the interface makes it look harmless. Two fields in Settings > General, save changes, done. That assumption breaks a lot of sites.

WordPress is everywhere. As of 2023, WordPress powers 43.4% of all websites globally, and over 80% of sites undergo domain transfers or HTTPS upgrades yearly, which makes URL changes a routine task. It also means mistakes happen at scale, including the 404 errors that plague an estimated 30% of unoptimized changes, according to the WordPress migration documentation.

What actually breaks

A URL change can hit more than the homepage address. It can affect:

• Divi Builder layouts because modules often store settings in structured data that doesn't survive a sloppy find-and-replace.
• WooCommerce product content because image URLs, checkout-related pages, account links, and plugin settings may still point to the old domain.
• Popup and targeting rules because tools that depend on page paths or exact URL conditions can stop firing correctly.
• Media and internal links because old absolute URLs remain buried in posts, theme options, widgets, and custom fields.

Practical rule: Changing the site URL is the easy part. Updating everything that depends on that URL is the real job.

Why Divi sites need extra care

Divi stores a lot of page-builder data in ways that punish blunt tools. If you export a site, change the address in one place, and skip the database cleanup, pages may load but render incorrectly. A broken builder layout is often worse than an obvious error because you don't catch it until a client opens a sales page, a popup, or a product template.

That’s why the safest method always starts with control. You want a URL change process that keeps admin access available, avoids accidental reversions, and respects serialized data. Anything less is gambling with a live site.

Your Pre-Migration Safety Checklist

Before touching the URL, build a rollback path. This part isn't glamorous, but it decides whether a mistake becomes a minor detour or a full outage.

Back up files and database separately

You need two things before any change:

1. A full file backup
2. A full database backup

If your host offers snapshot backups in the control panel, use that first. Then make a separate export if possible. I don't like relying on a single restore point when the task involves database-wide replacements.

For many sites, the practical options are:

• Hosting backups through cPanel, managed hosting snapshots, or server control panel tools
• A backup plugin such as UpdraftPlus if that’s already part of your workflow
• Manual exports of the database through phpMyAdmin plus a copy of the WordPress files over SFTP

Gather access before you need it

The worst time to look for credentials is after you've locked yourself out.

Keep these ready in a text file or password manager:

• WordPress admin login
• SFTP or FTP access
• Hosting control panel access
• Database access
• File manager access, if your host provides it

If the login URL starts redirecting to the wrong place after the change, you need another way in immediately.

Keep one recovery path outside WordPress itself. If the dashboard fails, your fix has to come from the server or database.

Stage first if the site is valuable

If the site is tied to leads, sales, bookings, or active campaigns, test the process on staging. A staging copy lets you confirm how Divi templates, WooCommerce pages, and plugin settings behave after the switch.

If you don't have the time or the tolerance for trial and error, it’s worth using a team that handles professional web migration as an operational process rather than a one-click guess. That matters most when the site includes custom code, dynamic templates, multilingual layers, or ecommerce flows that must stay intact.

Freeze changes during the move

A URL change shouldn't happen while people are editing products, updating landing pages, or changing navigation. Lock down the workflow for a short window so your backup, database state, and content state all match.

A simple checklist helps:

• Pause content edits so no one changes posts or products mid-migration
• Delay plugin updates until after the URL change is complete
• Hold design edits in Divi to avoid conflicting database writes
• Avoid marketing sends that point users to URLs while redirects are still unsettled

Record what matters before you start

You don't need a giant migration workbook for a small site, but you should document a few specifics:

Item	Why it matters
Current site URL	Confirms the exact string to replace
New site URL	Prevents typos across config and database
Checkout, cart, account, and thank-you pages	WooCommerce pages break quietly when links go stale
Popup target URLs and conditional display rules	Divi-related triggers often depend on path accuracy
Custom scripts or hardcoded theme settings	These won't update themselves

Pick the right time

Run the change during a quiet traffic window. That gives you room to test forms, login flows, and checkout without active users colliding with cached redirects or half-updated URLs.

If you skip this prep, every method that follows becomes riskier than it needs to be.

Comparing the 5 Methods for Changing Your URL

Not every method deserves equal trust. Some are convenient. Some are recovery tools. Some are what I use on production because they reduce lockout risk and behave predictably on complex sites.

Over 75% of WordPress URL changes are driven by HTTPS migrations, the dashboard works for simple sites, but many professionals prefer wp-config.php, and WP-CLI achieves over a 98% success rate on enterprise-scale migrations, according to this IONOS guide on changing a WordPress URL. That matches what I see in practice. The more moving parts a site has, the less I want the dashboard to be my primary tool.

Comparison of WordPress URL Change Methods

Method	Best For	Risk Level	Divi/WooCommerce Safe?
WordPress Admin	Small, simple sites	Medium	Limited
wp-config.php	Production changes, lockout prevention	Low	Yes, when followed by database replacement
functions.php	Temporary recovery	Medium to high	Only as a short-term fix
phpMyAdmin (Database)	Emergency admin lockout recovery	Medium	Yes, but incomplete by itself
WP-CLI	Agencies, large sites, scripted workflows	Low	Yes, when search-replace is handled properly

WordPress Admin method

This is the familiar route. Go to Settings > General, update WordPress Address (URL) and Site Address (URL), then save.

It works when the site is simple and the URL change is straightforward. The problem is that it only changes the core address values. It does not clean up every old URL inside posts, custom fields, theme options, or builder content.

Use it when:

• the site is small
• you already have a staging copy
• you know you can still access the dashboard after the change

Avoid relying on it when:

• Divi layouts are heavily used
• WooCommerce is active
• you expect old absolute URLs inside the database
• the domain move may break login access

wp-config.php method

This is the method I trust most for production. It overrides the site URL before WordPress fully loads, which means it can prevent the classic redirect loop or admin lockout after a domain switch.

Add these lines to wp-config.php above the line that says That's all, stop editing!:

define('WP_HOME', 'https://newdomain.com');
define('WP_SITEURL', 'https://newdomain.com');

This does two useful things. First, it forces WordPress to use the new address immediately. Second, it grays out the URL fields in the dashboard, which prevents accidental reversion from an admin click.

If I’m changing a live Divi or WooCommerce site URL, this is the default starting point unless there’s a strong reason not to use it.

It still doesn't replace old URLs across the database. You must do that separately.

functions.php method

This method is often shown in quick tutorials because it’s easy to paste in temporarily:

update_option('siteurl', 'https://newdomain.com');
update_option('home', 'https://newdomain.com');

You place it in functions.php, load the site once, and then remove it.

I only use this as a temporary recovery trick when someone already broke the site and I need a quick way to get WordPress pointed somewhere usable again. It’s not my preferred path for planned changes because theme-level edits are easier to forget, easier to duplicate, and awkward on sites with child themes or deployment workflows.

phpMyAdmin database method

If the dashboard is inaccessible, editing the values directly in the database is often the fastest rescue.

Open phpMyAdmin and find the wp_options table. Update the siteurl and home rows to the new full URL.

Typical SQL looks like this:

UPDATE wp_options SET option_value = 'https://newdomain.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://newdomain.com' WHERE option_name = 'home';

This is effective for emergency recovery, but it’s incomplete as a full migration method. It only updates those core options unless you also run a proper search-replace elsewhere.

If you’re comparing migration workflows for larger projects, this review of WP Migrate DB Pro vs Shipper Pro is useful context because the key difference between tools usually shows up in how they handle database state, serialized values, and operational safety.

WP-CLI method

For agencies and server-side workflows, WP-CLI is the cleanest option. It’s fast, scriptable, and less error-prone than clicking through a live admin area.

Core option updates look like this:

wp option update home 'https://newdomain.com'
wp option update siteurl 'https://newdomain.com'

And a broader database replacement can be handled with WP-CLI search-replace commands if you know exactly what you're doing and how your stack stores data.

Use WP-CLI when:

• you manage many sites
• you work in staging-to-production pipelines
• you want repeatable commands in deployment notes
• you’re comfortable validating the result from the command line

What works and what doesn't

Here’s the practical version.

• Works well: wp-config.php plus a serialization-aware database replacement
• Works well: WP-CLI in skilled hands with proper search-replace handling
• Works in a pinch: phpMyAdmin for lockout recovery
• Works only for basic sites: dashboard settings alone
• Doesn’t hold up on complex builds: changing the address and assuming the rest will sort itself out

For Divi and WooCommerce, the method matters less than the sequence. Stable URL override first. Database cleanup second. Verification last.

Updating All Internal Links and Serialized Data

Most failed URL changes happen after the first step, not during it. The site address gets updated, the homepage loads, and someone assumes the work is finished. It isn't.

The old URL is still sitting inside content, theme settings, media references, and plugin data. On Divi sites, that usually includes builder content. On WooCommerce sites, it often includes product-related references and settings. If you don't clean those up properly, you'll get a site that looks partially migrated.

What serialized data means in plain English

Some WordPress data isn't stored as plain text. It’s stored as structured values that include length information and nested settings. Divi uses that kind of structure in many places because the builder needs to remember module settings, design options, and content relationships.

That’s why a raw database search-and-replace can damage layouts. It changes the text but not the structure around it.

A safer route is a serialization-aware plugin such as Better Search Replace.

How to run Better Search Replace safely

The goal is simple. Replace the old domain with the new one across the database without corrupting structured data.

Use this order:

1. Install Better Search Replace
2. Search for the exact old URL
3. Replace with the exact new URL
4. Select all relevant tables
5. Run a dry run first
6. Leave GUID replacement unchecked
7. Run the final replacement
8. Review the frontend and builder output

The plugin is useful because it handles many of the replacements that a manual process misses. It’s especially important after a wp-config.php override, where WordPress itself knows the new URL but the content database still remembers the old one.

Key check: If a Divi page loads but sections are missing styles, modules look blank, or saved layouts behave oddly, suspect incomplete or corrupted database replacements first.

Which tables to include

For most sites, scan broadly. Don’t only scan posts.

Typical tables to include:

• wp_posts for content and builder data
• wp_postmeta for custom fields and plugin-linked content
• wp_options for settings stored outside core URL values
• WooCommerce-related tables if your install includes them
• Custom plugin tables when plugins store absolute URLs there

The common mistake is narrowing the scan too much because someone is afraid to touch the database. That caution is understandable, but partial replacements are what create weird, scattered breakage.

For a broader SEO reason, clean internal references matter too. If you want a non-technical explanation of why site architecture and direct internal paths matter, this guide on how internal links improve organic traffic is a useful companion.

One checkbox you should not casually touch

Most migration tools include an option to replace GUIDs. Leave that unchecked unless you have a very specific reason and know the implications.

GUIDs are not the place for casual URL cleanup. Changing them can create problems you don't need, while doing little to improve the migration itself.

A quick visual walkthrough can help if you prefer to see the process before running it on a live database.

Divi and permalink cleanup

After the replacement, save permalinks again inside WordPress. That refreshes rewrite rules and fixes a surprising number of odd URL issues.

If you need a refresher on the settings involved, Divimode has a clear walkthrough on configuring your permalink settings. That’s useful after the main migration because permalink refresh and URL replacement are related tasks, but they solve different problems.

What to test immediately after replacement

Check the areas that hide old URLs best:

• Homepage hero modules with buttons and background images
• Global headers and footers built in Divi Theme Builder
• Popup triggers and path-based conditions
• Product galleries and category pages
• Account, cart, checkout, and thank-you flows
• Menus, widgets, and reusable layouts

If one area still points to the old domain, assume there are more. Keep searching until the old URL is gone from the site’s real user paths.

The Essential Post-Change Go-Live Checklist

A successful URL change isn't finished when the new homepage loads. It's finished when users, search engines, and third-party tools all reach the right destination cleanly.

Put redirects in place

If the old domain or old HTTP version is still reachable, redirect it to the new canonical URL with 301 redirects. This preserves continuity for bookmarked pages, old backlinks, and search engine crawlers.

A simple Apache example in .htaccess for an HTTPS move looks like this:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

For a domain change, server rules vary by environment, so use the redirect method your host supports best. A plugin can work for smaller redirect maps, but server-level redirects are cleaner for whole-site moves.

Clear every layer of cache

You can fix the site perfectly and still think it's broken because cached responses keep serving the old URLs.

Clear these in order:

• WordPress cache plugin
• Hosting or server cache
• CDN cache
• Browser cache

If the site uses image optimization or CSS/JS aggregation plugins, purge those too. Divi-generated CSS can hang onto old paths longer than expected.

A stale cache can make a correct migration look wrong. Always assume caching is part of the diagnosis.

Update services outside WordPress

A lot of site owners remember the domain but forget the connected services.

Review and update:

• Google Analytics property settings
• Google Search Console property if needed
• XML sitemap submission
• Payment gateway callback or webhook settings
• Email templates that include hardcoded URLs
• Social profile links and ad destination URLs

If you need the search-engine side of the launch sequence, this guide on how to submit your website to Google is a useful follow-up after the URL change is stable.

Run a human QA pass

Don't just click the homepage and call it done. Walk the site like a user.

Test these flows:

Area	What to verify
Navigation	Menus reach the new URLs directly
Forms	Submissions work and thank-you pages resolve correctly
WooCommerce	Cart, checkout, account, and order emails use the right domain
Media	Images, downloads, and background assets load without mixed content warnings
Divi features	Popups, fly-ins, conditional sections, and template-driven pages behave correctly

Look for mixed content

If you moved from HTTP to HTTPS, mixed content is one of the most common leftovers. The browser will often warn you that some assets are still loading over the old protocol.

This usually points back to one of three places:

• old URLs still in the database
• hardcoded theme or plugin settings
• third-party embeds calling insecure assets

When you see mixed content, don't patch it page by page unless you have to. Find the source of the old URL and remove it centrally.

Troubleshooting Divi, WooCommerce, and Multisite Issues

Even when the main migration goes well, edge cases show up fast on complex sites. Divi, WooCommerce, and Multisite each add their own failure modes.

For Divi users, skipping serialization handling during a URL change causes an estimated 70% of layout corruptions, and the recommended production-safe method is a wp-config.php override combined with a tool like Better Search Replace, which achieves a 95% success rate and avoids dashboard lockouts, based on this Divi-focused migration walkthrough.

When Divi layouts look broken

Divi failures after a URL change usually show up as:

• missing background images
• modules that render without expected styling
• saved layouts that don't load correctly
• Theme Builder templates acting inconsistently
• path-based triggers failing on popup and conditional content tools

If you use a plugin such as Divi Areas Pro for popups, fly-ins, mega menus, or content injection, check any conditions tied to page paths, URL matching, or visitor behavior. Those rules may still refer to the old site structure even after the core URL is changed.

The fix is usually one of these:

1. rerun the database replacement carefully
2. clear all generated CSS and caches
3. resave affected templates or layouts
4. verify the path conditions inside your Divi-related plugins

When WooCommerce behaves strangely

WooCommerce doesn't always fail loudly. Sometimes the catalog looks fine while transactional parts break.

Look closely at:

• product image URLs
• cart and checkout page assignments
• my account links
• email template links
• gateway return or callback URLs
• cached fragments from optimization plugins

If checkout redirects to an old domain, don’t only inspect WooCommerce settings. Check the site-wide URL settings, permalink state, and any gateway configuration that stores full callback URLs.

If a store works until payment or login, the issue is often outside the visible page content.

Admin lockout and redirect loops

This is the classic post-change panic. You log in, and WordPress keeps bouncing you to the old domain or a broken path.

Start with the least destructive fix:

• Set WP_HOME and WP_SITEURL in wp-config.php
• Clear browser cookies for the site
• Purge caches
• Verify siteurl and home in the database
• Temporarily disable redirect plugins if needed

If the dashboard becomes reachable after the config override, leave those definitions in place until the rest of the migration is confirmed stable.

Multisite needs a different mindset

A Multisite URL change is not a normal single-site swap. There are network-level settings, individual site settings, possible subdirectory or subdomain relationships, and extra places where the old address may still live.

The risky mistake is applying single-site habits to a network. On Multisite, check:

• the main network address
• each site’s stored URLs
• domain mapping logic if used
• network-wide plugins with site-specific paths
• media references across subsites

If you're dealing with Multisite and WooCommerce together, slow down. That combination deserves staging and a tested rollback plan every time.

Mixed content and false positives

Sometimes the site is mostly correct, but the browser still flags insecure content. That doesn’t always mean the whole migration failed.

Common causes include:

• old image URLs inside theme options
• external scripts still loading over HTTP
• cached CSS generated before the move
• embedded content from third parties

Use the browser inspector to identify the exact asset. Fix the source, not just the symptom.

Finalizing Your Website URL Change

A safe wordpress change website url process comes down to discipline, not shortcuts. The method I trust most on live Divi and WooCommerce projects is simple. Set the new URL with wp-config.php, keep server access available, run a serialization-aware search and replace, then test the site like a customer would.

That sequence avoids the most common disasters. It reduces the chance of admin lockout, protects Divi layout data, and gives WooCommerce a better chance of surviving the move without hidden failures in checkout or account flows.

If your site is already live on the new address, take one last pass through redirects, caches, forms, and transactional pages. The migration isn’t complete until old URLs stop appearing anywhere that matters. Once that’s done, the site has a stable base again, and you can get back to building instead of repairing.

---

If you build with Divi regularly, Divimode is worth keeping in your toolkit for tutorials, plugin documentation, and practical guidance around interactive Divi features like popups, fly-ins, mega menus, and WooCommerce-aware behavior. It’s a useful resource when URL changes affect page targeting, conditional display, or other builder-driven functionality.