SharePoint site URLs in Microsoft 365: changing /sites/<sitename>, understanding redirects, and cleaning them up</sitename>

If you’ve been in Microsoft 365 long enough, you’ve seen it: someone creates a new Team, or someone spins up a SharePoint site, and a URL appears that looks something like: https://contoso.sharepoint.com/sites/Accounting

That /sites/<sitename> portion becomes part of the site’s identity. It shows up in browser favorites, Teams file tabs, OneDrive sync relationships, sharing links, Power Automate flows, and sometimes even third-party apps.

And then reality hits: the name wasn’t final, the department got rebranded, a merger happened, or the original site name included “-test” and nobody wants to admit it.

So the question becomes: Can you change the SharePoint site URL?

Yes. And you should understand the ripple effects—especially the redirect site Microsoft creates to keep old links working (and how to remove it when you need that URL back).

Why SharePoint sites default to /sites/<sitename>

In most Microsoft 365 tenants, modern SharePoint sites (including Microsoft 365 group-connected team sites created by Teams) use the managed path /sites/ by default. That’s why you typically see /sites/<sitename> when:

• A Team is created (which also creates a connected SharePoint team site)
• A SharePoint site is created directly in SharePoint

In day-to-day operations, the important part is: that URL becomes “sticky.” People bookmark it, sync it, share it, and embed it. So when it’s wrong, you want a clean way to fix it without breaking everything.

The good news: you can change the SharePoint site address (URL)

Microsoft supports changing the site address for common site types such as:

• Microsoft 365 group-connected team sites
• Modern team sites not connected to a group
• Communication sites
• Classic team sites

But Microsoft also calls out several situations where changing the site address is not supported, including scenarios like:

• Publishing feature is/was enabled
• Very large sites (document-count threshold)

Also important: you’re not “moving” the site between managed paths. For example, Microsoft notes you can’t rename a site from /sites/ to /teams/ using this feature—you’re changing the address within the URL, not the whole structure.

How to change a site URL in the SharePoint admin center

Craig-style disclaimer up front: do this during low usage. When the rename is in progress, SharePoint sets the site to read-only and the process can take time depending on site size. Microsoft notes it can take about 10 minutes (size dependent) and recommends doing this when usage is low.

Step-by-step (SharePoint admin center)

• Go to the SharePoint admin center
• Navigate to Active sites
• Select the site to open the details panel
• On the General tab, under Site address, select Edit
• Enter the new site address and select Save

Microsoft also notes there are limitations (for example: hub sites, sites on hold, locked sites, PWA sites, and some BCS-related scenarios). The “why can’t I edit this one?” questions usually land here.

What happens next: the redirect site (and why you should care)

When you change a site address, Microsoft automatically creates a redirect at the old URL. That redirect is not just a “rule”—it is effectively a special site at the previous address using a redirect site template (Microsoft identifies it as REDIRECTSITE#0).

Why that’s useful

Redirects are how Microsoft avoids “instant chaos.” If users click an old favorite, or they have an older sharing link, or they typed the old URL from memory, they’ll still be routed to the new location. Microsoft explains that redirects ensure prior URLs continue to work and route browser requests to the new site.

Why that’s also a problem (sometimes)

If you renamed …/sites/Accounting to …/sites/Finance, and later you want to create a brand-new site called Accounting, you can’t reuse the old URL cleanly while the redirect exists. Microsoft explicitly calls out that if you want to reuse the previous address, you need to delete the redirect.

How long does the redirect last?

In practical terms: the redirect remains until you remove it. Microsoft’s guidance focuses on how redirects are created automatically and how to delete them when you need to free up the old URL; it does not describe an automatic expiration timeframe for these redirects.

So if you’re asking “does it go away on its own after 30 days?”, the safe operational answer is: assume it stays indefinitely unless an admin removes it. That’s why it’s common to see tenants with years’ worth of redirect sites sitting around, quietly doing their job—until someone tries to reuse an old URL.

Effects and “gotchas” you should communicate to users

Before changing a site address, Microsoft recommends communicating the change to users and highlights that users should close files and avoid edits during the rename window.

A few practical impacts to keep in mind:

• Read-only during rename: Users will be blocked from editing while the change is in progress.
• Some URL dependencies don’t update automatically: Embedded links in web parts, customizations, and some app references may need manual updates after the rename.
• Workflows / integrations can require attention: Microsoft notes scenarios where items like SharePoint Workflow 2013 may need republishing, and apps referencing the URL might require updates.
• Teams / SharePoint integration typically survives, but with quirks: Microsoft documents some limitations around Teams files and how users may need to access channel Files tabs to refresh certain behaviors.

The quick consultant takeaway: renaming is supported and common—but treat it like a change window. Communicate it, do it off-hours if possible, and plan on a short post-change validation checklist.

Removing the redirect site (freeing up the old URL)

If you want to reuse the old URL, you need to delete the redirect site. Microsoft’s process is PowerShell-based and uses the SharePoint Online Management Shell.

How to remove a redirect (PowerShell)

Microsoft’s documented command to remove a redirect is:

Remove-SPOSite -Identity https://contoso.sharepoint.com/sites/OldSiteName

You run this against the old URL (the one that is now the redirect), and it deletes the redirect site.

Important notes Microsoft calls out:

• If you receive “The operation is not supported for the site,” check whether a retention policy is applied to the old or new URL. You may need to remove the retention policy to delete the redirect.
• After deletion, browsing to the old URL should return a 404 (because the redirect is gone).
• You may need to clear browser cache/history before you see the change reflected.

How to list all redirect sites

If you’re trying to assess redirect sprawl in a tenant, Microsoft provides a way to list redirect sites by filtering on the template:

Get-SPOSite -Template REDIRECTSITE

That will show you redirect sites currently present.

A simple “rename checklist” (the consultant version)

Here’s the short list I like to keep in mind when doing a site rename:

• Communicate the planned change window and expected new URL.
• Do it during low usage (site is read-only during the change).
• Validate core functions after rename: site access, key libraries, sharing, and any known integrations.
• Decide if you need the old URL later. If yes, plan to remove the redirect.
• If removing the redirect, verify retention policies won’t block deletion.

Wrapping up

SharePoint site URLs are one of those “set it and forget it” things—right up until they’re wrong. The good news is Microsoft supports changing site addresses in Microsoft 365, and it automatically creates a redirect site at the old address to keep users moving.

The more subtle part is lifecycle management: those redirects don’t magically disappear, and if you want to reuse an old /sites/<sitename> later, you’ll need to delete the redirect using SharePoint Online PowerShell.