How to Change WP URL Without Breaking It

Published on May 12, 2026

If you need to change WP URL, do it in a controlled order: back up first, update WordPress Address and Site Address, then fix redirects, SSL, and any hard-coded links. Most breakages happen not from the URL change itself, but from the pieces around it still pointing to the old location. The website usually is not angry - it is just following stale settings.

This task comes up during domain changes, moving from HTTP to HTTPS, shifting WordPress into a subdirectory, or migrating from staging to production. For store owners, agencies, and SaaS teams, a bad URL change can mean login loops, mixed content warnings, broken admin access, or forms posting to the wrong place. So the goal is not only to edit two fields. The goal is to keep the whole application calm.

What changing the WP URL actually affects

In WordPress, there are two core settings: WordPress Address and Site Address. They sound similar because, frankly, they are. But they do different jobs.

WordPress Address is where the core WordPress files live. Site Address is the public URL visitors use to reach the site. In many setups these are identical. In others, WordPress might live in a subdirectory while the site loads from the root domain.

If you change one incorrectly, WordPress may redirect you away from wp-admin, send assets to the wrong domain, or create an infinite redirect loop. Plugins, themes, the database, the web server, and CDN rules may also still reference the previous URL. That is why a proper change is partly WordPress work and partly infrastructure hygiene.

Before you change WP URL

Take a fresh backup of both files and database. If this is an e-commerce site or a busy content site, do the work in a low-traffic window. A URL change can touch cached pages, session cookies, and payment callbacks, so timing matters.

You should also confirm four things before making edits. First, the new domain or protocol already resolves to the correct server. Second, the SSL certificate is active if you are moving to HTTPS. Third, your web server virtual host or Nginx server block is ready for the new host name. Fourth, you know whether WordPress is behind a proxy, load balancer, or CDN that may force redirects.

If any of those are not in place, WordPress may be configured correctly and still fail in public. The logs are telling the same story then.

The safest ways to change the URL

Change it in the WordPress admin

If you still have admin access, this is the cleanest method. Go to Settings, then General. Update WordPress Address and Site Address to the new URL. Save changes.

This works well when the move is simple and the new domain already points correctly to the site. Right after saving, log in again if needed and test the homepage, admin area, media library, and a few internal pages.

The risk is obvious: if you enter the wrong URL, or the new host is not fully ready, you can lock yourself out of the dashboard.

Change it in wp-config.php

If the dashboard is not accessible or you want more control, define the values directly in wp-config.php. Add these lines above the stop editing line:

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

This forces WordPress to use the values from the config file. It is often the fastest recovery method for login loops or broken admin redirects.

It is also a good temporary stabilizer during migrations. Once everything is working, you can keep these constants in place or remove them and manage the values from the admin again.

Change it in the database

If neither admin nor config editing is available, you can update the values in the database, usually in the wp_options table. The option names are home and siteurl.

This works, but it is more manual and easier to do badly if you are in a hurry. On sites with custom table prefixes, do not assume the table is wp_options. Check first.

HTTP to HTTPS is where people get surprised

A lot of requests to change wp url are really HTTPS migrations in disguise. The visible change looks small, but browsers, cookies, and asset loading disagree.

After switching from HTTP to HTTPS in WordPress settings, confirm that the SSL certificate is valid and installed for the correct hostname. Then update your server redirects so HTTP requests permanently redirect to HTTPS. If your site sits behind a reverse proxy or CDN, make sure WordPress can detect HTTPS properly, otherwise it may keep redirecting forever.

Mixed content is the next usual visitor. Pages load over HTTPS, but images, scripts, fonts, or CSS still call HTTP URLs. This can break layouts or trigger browser warnings. You may need a database search-and-replace for old absolute URLs, especially if the site was built with a page builder or custom fields storing full links.

Search and replace old URLs carefully

Changing the two core settings does not rewrite old links stored inside posts, metadata, widget content, or plugin settings. If the old domain appears hard-coded in the database, users will still hit it.

This is where a proper serialized-data-safe search-and-replace matters. Do not run a careless plain text replacement on an exported SQL file and hope for the best. Some plugin and option data is serialized, and a bad replace can corrupt lengths and break settings.

If you are using a professional migration workflow, run a tool that understands WordPress serialization. Then check page builder layouts, menus, image URLs, canonical tags, Open Graph settings, and any plugin that stores callback or API URLs.

Common problems after a URL change

Login page keeps redirecting

This usually means WordPress, the web server, or a proxy is disagreeing about the correct scheme or hostname. Check WP_HOME and WP_SITEURL, then inspect server redirect rules. If SSL termination happens upstream, WordPress may need the forwarded HTTPS header handled correctly.

Cookies can also be tied to the old domain. Clear browser cookies and test in a private window before assuming the site is cursed.

wp-admin is inaccessible

If the admin URL sends you to the wrong location, force the correct values in wp-config.php. This often gets the dashboard back immediately. Also review .htaccess or Nginx rules for old rewrite behavior.

Images or CSS are broken

That points to hard-coded URLs or mixed content. Search the database for the old domain and inspect browser developer tools to see which assets still call the previous URL.

Redirect chains or loops

These usually happen when WordPress redirects one way and the web server or CDN redirects another. Reduce the logic to one clear rule set. If possible, handle canonical host and HTTPS redirects in one place only.

Forms, webhooks, or checkout callbacks fail

External services may still post to the old domain. Check payment gateway URLs, SMTP return paths, webhook endpoints, and third-party integrations. On membership or e-commerce sites, this is where silent revenue damage happens.

When WordPress Address and Site Address should be different

Most sites should keep them the same. But there are valid exceptions. If WordPress is installed in a subdirectory like /wordpress while the public site loads from the domain root, then Site Address may be the root URL and WordPress Address the subdirectory URL.

This setup can be useful for file organization, but it adds complexity. If you are not doing it intentionally, do not invent it mid-migration. Simple configurations fail less often.

A practical order that avoids downtime

Use a short maintenance window, confirm DNS, SSL, and server config first, then change the WordPress URLs. After that, run the database search-and-replace, flush caches, and test key paths: homepage, admin, forms, checkout, media, API endpoints, and cron behavior.

If the site uses object caching, full-page caching, or a CDN, purge everything after the change. Old cached redirects can make a healthy site look broken for another 20 minutes, which is not the most beautiful DNS situation, but it is under control.

For business-critical sites, stage the change first. At Kodu.cloud, this is exactly the kind of task where managed infrastructure support pays for itself - not because changing a URL is impossible, but because the small surrounding checks are what prevent the ugly surprises.

Final checks after you change WP URL

Open the site in a fresh browser session and test both with and without www if relevant. Confirm the SSL padlock, inspect a few source URLs, and make sure the admin, login, media uploads, and contact forms all behave normally. If search engines have already indexed the old domain, keep proper redirects in place long enough for traffic and ranking signals to move cleanly.

A WP URL change is usually a short job when the environment is ready. It becomes a long evening only when DNS, SSL, server rules, cache, and database references are allowed to argue with each other. Keep them in the same direction, and the service is calm again.

Andres Saar Customer Care Engineer