Change URL on WordPress: The Complete 2026 Guide

You're usually not changing a WordPress URL for fun. You're doing it because something else is happening around the site.

Maybe the staging build is finally going live. Maybe the client rebranded and bought a new domain. Maybe SSL is turned on and you need to move from HTTP to HTTPS without breaking every image on the site. Or maybe you changed a slug and realized “change URL on WordPress” can mean anything from a one-line edit to a full migration with redirects, search-replace, and recovery planning.

That's why generic tutorials fail. They treat every URL change like the same task. It isn't. Changing a post slug is a content-level edit. Changing the site address rewires WordPress itself. Changing the domain on an established site affects configuration, internal links, media paths, cache, canonical tags, and search visibility. If you pick the wrong method, you can lock yourself out of wp-admin, trigger mixed content errors, or leave old URLs unresolved.

Why and When to Change a WordPress URL

The first thing to decide is what you're changing.

If you're updating a single page or post slug, that's low risk. WordPress handles the content edit cleanly, and your main concern is setting a proper redirect from the old slug to the new one. If you're switching the whole site from http:// to https://, that's a platform change. If you're moving from staging.example.com to example.com, that's a migration. If the business changed names, that's a domain move with SEO consequences.

A lot of bad migrations happen because someone starts with the dashboard fields before thinking through the surrounding work. That's backwards. The reason for the change determines the tool.

Common scenarios that need different handling

• Staging to live: You need to update the site address, replace internal URLs in the database, verify media paths, and usually flush every cache layer.
• Rebrand to a new domain: You need configuration changes plus one-to-one redirects from old URLs to new ones.
• HTTP to HTTPS: You need the URL update, an SSL-ready site, and cleanup for mixed content.
• Subdirectory or subdomain cleanup: You need to decide whether WordPress core files stay put or move with the public URL.

The cleanest migrations start with a precise scope. “We're changing the domain” is too vague. “We're moving production from HTTP on the old brand domain to HTTPS on the new brand domain while preserving permalink structure” is actionable.

This also tends to happen during broader rebuilds. If the URL change is part of a redesign, it helps to think through content structure, redirects, and launch sequencing together. A practical reference for that planning process is this guide on planning a site redesign.

The Core Methods for Changing Your Site Address

At the WordPress core level, this job comes down to siteurl and home. On standard installs, those values live in the wp_options table, and they're the first two rows in the database. IONOS notes that changing the WordPress URL means modifying critical configuration files or database entries, and the accepted methods are the admin dashboard, wp-config.php, direct database editing, or WP-CLI. If you get it wrong, you can trigger a white screen or lose admin access because the login URL becomes invalid immediately after saving the new domain (IONOS guide to changing the WordPress URL).

Use the dashboard when the site is healthy

If wp-admin is accessible and the fields aren't locked, go to Settings > General.

You'll see:

• WordPress Address (URL)
• Site Address (URL)

Update both in the same pass unless you intentionally run WordPress from a separate subdirectory. This is the most common way to change URL on WordPress, but it has a known failure point. Network Solutions states that this method has a high success rate, but there's a 30 to 40 percent probability of being locked out if you don't update both fields correctly or if redirects aren't already prepared, because the dashboard stops working at the old URL immediately (Network Solutions instructions for changing the WordPress URL).

A few practical rules matter here:

• Don't add a trailing slash to the URL value.
• Save only when you know the new URL resolves.
• Expect to log in at the new domain immediately after saving.

Use wp-config.php when the fields are disabled

If those General Settings fields are greyed out, someone hardcoded the values.

Add these lines to wp-config.php:

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

This is blunt, but it works. It's useful when you're locked out, when the dashboard is inaccessible, or when the site needs a temporary forced value during a migration.

There's a trade-off. Hardcoding the values gives you control, but it also overrides the UI. Junior developers often forget that and later wonder why the dashboard fields can't be edited.

Use phpMyAdmin when WordPress itself is broken

Open the site database and edit the wp_options table. Update:

• siteurl
• home

On standard installs, these are usually the first two rows. This method is reliable when the dashboard is unavailable and you don't want to force values in wp-config.php.

If you're already handling a broader move, it's worth reviewing a full WordPress migration workflow so the URL change doesn't happen in isolation from file moves, database imports, and post-migration checks.

Use WP-CLI when you want speed and repeatability

For developers, this is usually the best option.

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

WP-CLI is clean, scriptable, and easier to repeat across environments. It also keeps you out of the browser during a risky operation.

If I have shell access, I use WP-CLI first. It reduces clicking, removes UI ambiguity, and fits neatly into a migration checklist.

A Deep Dive into Database Search and Replace

Changing siteurl and home only tells WordPress where the site lives. It does not fix hardcoded URLs inside posts, Elementor data, widget settings, image references, menus, or plugin options.

That's where people get caught. The homepage loads, wp-admin works, and then half the site still points at the old domain.

Why raw SQL is risky

A simple SQL replace sounds tempting:

UPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://oldsite.com', 'https://newsite.com');

Don't treat that as a complete solution.

WordPress sites often store serialized data in the database. Elementor, widget settings, customizer options, and many plugins rely on it. A careless SQL replace can corrupt serialized strings and leave you with broken layouts or plugin settings that fail without warning.

Use a search-replace tool that understands WordPress data

If you want a GUI, Better Search Replace is a practical choice. The workflow is straightforward:

1. Back up the database first.
2. Install and activate Better Search Replace.
3. Search for the old domain.
4. Replace with the new domain.
5. Run a dry pass if the tool supports your process.
6. Target the relevant tables, or all WordPress tables if the move is complete.
7. Review the site after the replacement.

This is also the right phase to clean up mixed content after an HTTP-to-HTTPS move, because many old asset URLs live inside content and plugin settings.

WP-CLI is the stronger option for large sites

For bigger migrations, use:

wp search-replace 'http://oldsite.com' 'https://newsite.com' --all-tables --dry-run

Then run the command once the preview looks correct:

wp search-replace 'http://oldsite.com' 'https://newsite.com' --all-tables

IONOS reports that WP-CLI commands like wp search-replace run 3x faster than manual phpMyAdmin edits, and using --dry-run first produces a near-zero error rate. That matters because broken frontend links occur in 45% of cases when only siteurl and home are updated (IONOS coverage of WP-CLI search-replace).

A few things worth doing in the same pass:

• Target protocol changes carefully: Replace http://oldsite.com with https://oldsite.com if the domain stays the same.
• Check uploads and media URLs: Broken images usually come from skipped replacements.
• Review builder data: Elementor content often looks fine in the editor but fails on the front end if internal URLs weren't fully updated.

Practical rule: If the domain changed, assume the database needs a full search and replace unless you can prove every internal reference is relative.

What works and what doesn't

A useful comparison:

The mistake is thinking “site opens” means “migration complete.” It doesn't. Until internal references are updated, the site is only partially moved.

Implementing Redirects to Preserve Your SEO

The technical move isn't the end of the job. It's the beginning of the public-facing one.

When old URLs disappear without redirects, users hit dead ends and search engines lose the path from the old address to the new one. That's avoidable. A proper 301 redirect tells browsers and crawlers the move is permanent and passes authority to the replacement URL.

Reddit discussion cited in the provided data puts the risk plainly: failing to implement 301 redirects immediately can cause a traffic drop of 30% to 50%, while a proper redirect strategy can recover 80% to 95% of original visibility (discussion on URL changes and SEO impact).

Site-wide redirects for a full domain move

If the structure stayed the same and only the domain changed, a site-wide redirect in .htaccess is often enough on Apache:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldsite\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.oldsite\.com$
RewriteRule ^(.*)$ https://newsite.com/$1 [R=301,L]

Put the rule above the default WordPress block.

This works when /about/ on the old domain maps to /about/ on the new one. If the URL structure also changed, you'll need individual redirects or pattern-based rules that match the new architecture.

Redirect single slugs when content moved

For one-off permalink changes, use a redirect plugin such as Redirection or add a direct rule if you prefer code.

Example:

Redirect 301 /old-service-page/ https://example.com/new-service-page/

This is the right move after renaming a post slug, consolidating thin pages, or moving landing pages into a new section.

Don't send every old page to the homepage. Match each old URL to its closest equivalent. That's better for users, and it gives search engines a clearer replacement path.

Tell search engines what changed

After the redirects are live, finish the job in Search Console:

• Submit the updated sitemap
• Inspect important URLs
• Request indexing where needed
• Use the change-of-address process for a domain move when applicable

The provided data also notes that the sitemap should be updated and a crawl requested through the Inspect URL tool to help Google re-index the new pages. That's part of what prevents lasting ranking loss on established content.

If you want a broader refresher on crawlability, canonicals, and indexing after a move, this 2026 technical SEO guide is a useful companion.

A quick visual walkthrough can also help when you're validating redirect behavior and post-move SEO tasks:

Advanced Scenarios for Multisite SSL and Staging

The easy guides stop at single-site installs. Real projects don't.

Multisite needs network-aware changes

In WordPress Multisite, each site has its own URL context, and the network itself has another. You can't treat it like a single wp_options edit and assume the whole setup is done.

Pay attention to:

• Network settings: The main network domain and path matter.
• Per-site tables: Each site has its own options table pattern.
• Mapped domains: If domain mapping is involved, review that layer before touching redirects.
• Sunrise and custom bootstrapping: Older multisite setups sometimes include custom domain logic.

On multisite, I avoid ad hoc database edits unless I've mapped the table structure first. One wrong update can leave one site loading while another throws login or routing issues.

HTTPS moves fail when mixed content stays behind

After switching to HTTPS, the most common symptom isn't a full crash. It's a “mostly working” site with broken padlocks, missing images, blocked scripts, or layout issues.

Typical causes include:

• Old http:// asset URLs in post content
• Theme options still referencing HTTP
• Builder data with hardcoded asset paths
• CDN or plugin settings still pointing to the old protocol

The fix is usually a combination of the core URL change, a proper database search-replace, cache clearing, and a browser console check for blocked resources.

Staging-to-live should be a repeatable workflow

Good staging workflows reduce manual edits. Bad ones create launch-day panic.

A stable process looks like this:

1. Build on staging with a clearly separate URL.
2. Push files and database to production.
3. Update the core site address.
4. Run search-replace for internal references.
5. verify redirects, cache, forms, and SSL.
6. Re-save permalinks if needed.

If you do client work regularly, document the exact sequence per host and stack. URL changes become much safer when they're part of a repeatable deployment process instead of a one-off fix.

Your Post-Change Verification and Maintenance Checklist

Most URL changes fail unnoticed. The homepage loads, but a form breaks, a menu still points to staging, or the sitemap references old paths. You need a post-change checklist, not a quick homepage glance.

Frontend checks

Start where users start.

• Load the new primary URL: Test the homepage, a few core pages, a blog post, and a product or service page.
• Check internal links: Menus, buttons, footer links, related posts, and breadcrumbs should all resolve to the new domain.
• Verify media: Images, videos, PDFs, background assets, and icons should load without mixed content warnings.
• Test forms and dynamic features: Contact forms, search, login, carts, and filters are common failure points.

Backend checks

Once the frontend looks stable, validate the admin side.

• Log in through the new URL: Make sure wp-admin and the login form resolve correctly.
• Clear every cache layer: Plugin cache, server cache, browser cache, and CDN cache if one is present. If you need a cleanup process, this guide on clearing WordPress cache is a practical reference.
• Re-save permalinks: Sometimes this refreshes rewrite rules after a move.
• Review plugin settings: SEO plugins, security tools, SMTP settings, and page builders often store absolute URLs.

A migration isn't finished when the homepage loads. It's finished when the front end, wp-admin, forms, assets, and redirect paths all behave as expected.

SEO and monitoring checks

Here, long-tail issues surface.

• Update Search Console and Bing tools
• Resubmit the sitemap
• Check robots.txt
• Confirm analytics is firing on the new domain
• Test old URLs with a redirect checker

If you need to regenerate or verify the sitemap, this walkthrough on how to make a sitemap in WordPress covers the practical steps.

For ongoing care after the migration, a structured maintenance routine helps catch slower-developing issues like stale redirects, expired SSL, plugin conflicts, and performance drift. This article on WordPress maintenance for service businesses is useful if you manage client sites that need regular post-launch oversight.

Troubleshooting Common WordPress URL Change Errors

The most frustrating WordPress URL problems are usually the ones basic tutorials skip.

Why are the URL fields greyed out

If WordPress Address and Site Address are disabled in Settings > General, check wp-config.php.

Hardcoded values like these lock the fields:

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

Remove or update those lines, then refresh the dashboard. If the site depends on those constants temporarily, leave them in place until the migration is stable.

This issue isn't rare. The provided data says 35% of users run into greyed-out URL fields because values are hardcoded in wp-config.php, and it also notes that 41% of broken-site incidents stem from failed URL changes while 72% of users are unfamiliar with hosting panels (Reclaim Hosting URL fix guidance)).

How do you reverse a broken URL change

If the site is broken and wp-admin is unreachable, use phpMyAdmin to roll it back.

Follow this order:

1. Open your hosting database tool.
2. Select the WordPress database.
3. Open wp_options.
4. Find siteurl and home.
5. Replace the broken value with the previous working URL.
6. Save both entries.
7. Try logging in again at the restored address.

If the URL was also hardcoded in wp-config.php, fix that too. Database rollback won't help if the config file still forces the bad URL.

Why does the site load but links and images are wrong

That usually means the core site address changed, but the database content didn't get a full search-replace.

Symptoms include:

• old-domain image URLs
• internal links still pointing to staging
• CSS or JS loading from HTTP after an HTTPS move
• builder layouts partially broken

Run a proper database-wide search and replace, then clear cache at every layer.

Why do redirects loop or fail

Redirect loops usually come from stacked rules. For example, the server forces HTTPS, a plugin forces HTTPS again, and a domain redirect points back through the wrong host variation.

Check these in order:

• .htaccess
• redirect plugin rules
• host-level redirect settings
• canonical/domain enforcement in plugins
• cache/CDN behavior

Keep one authoritative redirect path. Multiple overlapping redirect systems create confusion fast.

If you build Elementor sites often, Exclusive Addons is worth keeping in your toolbox. It adds advanced widgets, templates, and workflow features that help you rebuild and refine pages after a domain move without fighting custom code for every layout adjustment.