Changing your WordPress site URL is safe, but only with a strict 301 redirect plan behind it. The address bar is where your rankings live: each URL holds the search history of that page, so if you change the address and do not redirect the old one, Google sees a 404, decides the page is gone, and drops it along with its position. Do it properly, with a complete map of old addresses to new ones, and the rankings transfer cleanly. The change involves more than the domain, too: WordPress stores its own address settings and your content is full of internal links, all of which have to move with you. WPBuildAI scans the live site and builds the old-to-new map before you change anything, so the switch is planned rather than improvised.
Changing the site URL is a host change in Google’s eyes, and since June 2026 its guidance asks for Change of Address requests covering all subdomains and both the www and non-www variants of the old domain, not just the address you were using day to day.
What “changing the site URL” actually changes
“Changing the site URL” can mean several different things, and they carry different risk. Moving to a new domain changes every address on the site. Switching from http to https, or from non-www to www, changes the address of every page even though the path stays the same. Changing the permalink structure changes the path of every post, which is its own project covered in changing permalink structure without losing SEO. What they share is that the public address of your pages moves, and search engines have indexed the old ones. Whenever the address a page is reachable at changes, that change has to be communicated with a redirect, or the equity tied to the old address is stranded.
The address bar versus the WordPress setting
There are two separate things called the URL, and confusing them is a common way to break a site. The public address is what visitors and Google use. Inside WordPress, the Settings, General screen has a WordPress Address and a Site Address (stored as siteurl and home), which tell WordPress where its files live and where the site loads from. If you change the domain at the host or DNS level but not these settings, WordPress keeps trying to load from the old address and the site breaks. If you change the settings without redirects, visitors and search engines hitting the old URLs get errors. Both layers have to be updated together, which is why a checklist beats doing it by memory.
Why internal links break if you only flip the setting
Changing the address setting does not rewrite the links inside your content. WordPress content often contains absolute links, full addresses pointing at the old domain, embedded in posts, menus, and theme options. After a domain change, those links still point at the old address, causing broken internal links and, on an https switch, mixed-content warnings where a secure page loads insecure resources. So part of any URL change is updating the internal references to the new address, carefully, so you do not corrupt serialized data in the database. Capturing the internal link graph in the inventory is what tells you how many references exist and where, before you start changing them.
The 301 redirect plan that protects rankings
The redirect plan is the part that actually protects rankings, and it has one rule: every old URL points to its exact new counterpart, in a single hop. Google’s site move guidance describes this map of old to new as the core of a safe move. Pointing everything at the homepage does not work, because Google reads a bulk redirect to an unrelated page as a soft 404 and passes no equity. Chained redirects, where one redirect lands on another, waste crawl budget and can trip a too many redirects error. Use permanent 301s, not temporary 302s, so the signal that the move is permanent reaches Google, following its redirects guidance.
Same content, new address: tell Google directly
If you are moving to a new domain but keeping the same paths, Google has a specific procedure for it. Its guidance on a site move without URL changes covers using the Change of Address tool in Search Console, which tells Google the whole site has moved from one domain to another. That speeds up the transfer and reduces the window where rankings wobble. It does not replace the redirects, it works alongside them: the 301s handle individual requests, and the Change of Address signal handles the site-level move. Keep the old domain registered and serving redirects for months afterwards, because Google revisits old URLs for a long time.
The deployment side: DNS, HTTPS, and staging
A URL change is also a deployment, and a few deployment details cause outsized problems. Confirm the canonical domain is consistent, www or non-www and https, so you are not splitting signals across variants. Make sure the staging copy you built the new site on is not indexable: it should carry a noindex tag while in progress, the mechanism in Google’s block indexing guidance, and the live site must not accidentally keep that noindex after launch. The single most damaging launch mistake is shipping the live site with the staging noindex still on, which deindexes everything. Plan the DNS switch for a low-traffic window, and keep the ability to roll back if something is wrong.
A step-by-step site URL change
- Inventory every URL from the sitemap, internal links, and Search Console.
- Map each old URL to its exact new address.
- Set up the new site and update the WordPress address settings.
- Update internal links and hardcoded references to the new address.
- Confirm staging is noindex and the live canonical is correct.
- Apply single-hop 301s for every changed URL.
- Switch DNS, resubmit the sitemap, and file a Change of Address if the domain moved.
- Verify the redirects resolve and watch Search Console for 404s.
A worked example: moving to a new domain
A site moving from an old domain to a new one, keeping the same page paths, crawled first and found 320 URLs, including a set of old PDFs and a few campaign pages still ranking. They built the new site on staging with noindex on, updated the WordPress address settings, and rewrote the internal links to the new domain. They set a 301 for every one of the 320 URLs, each pointing to the same path on the new domain. At cutover they switched DNS, removed the staging noindex, confirmed the live canonical, resubmitted the sitemap, and filed a Change of Address. Over the next fortnight Google moved the rankings to the new domain with only minor, temporary movement, because every old URL had a direct destination and Google had been told the site had moved.
Common mistakes changing a site URL
- Changing the domain at the host but not the WordPress address settings, which breaks the site.
- Redirecting every old URL to the homepage instead of its true counterpart.
- Leaving internal links and hardcoded references pointing at the old domain.
- Launching with the staging noindex still applied, which deindexes the new site.
- Dropping the old domain too soon, before Google has finished moving the rankings.
Key points to remember
Changing your WordPress site URL is safe with a strict 301 plan and risky without one, because rankings live on the old addresses and a missing redirect turns a ranked page into a 404. Update both layers, the public address and WordPress’s own address settings, fix the internal links, and point every old URL to its exact new counterpart in a single hop. If the domain moves, file a Change of Address and keep the old domain redirecting for months. Confirm staging stays noindex and the live site does not. Do that and the rankings transfer; skip the inventory and they leak. WPBuildAI scans the live site and builds the old-to-new map first, so the switch is planned. Send your site URL for a free migration assessment.
Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.