| Element | Site name change | Site URL (address) change |
|---|---|---|
| Files and folders | Unaffected | Unaffected |
| Permissions | Unaffected | Unaffected |
| Existing sharing links | Continue working | Old links redirect automatically for a period, then may stop; see below |
| Bookmarked / hardcoded URLs | Unaffected | Rely on Microsoft's automatic redirect window |
| Search index | Re-indexes display name; no downtime | Full re-crawl required; search may lag for hours |
| Power Automate flows referencing the site | Unaffected | Flows referencing the old URL directly will fail |
| Custom scripts / SPFx referencing absolute URLs | Unaffected | Break unless updated |
| Site collection ID (GUID) | Unchanged | Unchanged |
What is the difference between a name change and a URL change?
A SharePoint site has a display name (what users see in navigation and the site header) and a URL, which is set once at creation and derived from that name by default but can diverge from it. Changing the display name alone, through site settings, is low-risk and near-instant. Changing the URL is a separate, heavier operation that Microsoft treats more like a relocation than a rename, even though the content itself never moves.
Renaming the display name only
A site owner can change the display name from Site Settings without any admin involvement, and without touching the URL. This is safe to do at any time. Files, permissions, sharing links, and any URL-based automation are untouched, because the address a browser resolves is unaffected. The only visible change is the name shown in navigation, the site header, and search result titles.
Changing the site URL
Changing a site's URL is a SharePoint admin-level operation, run from the SharePoint admin center or via PowerShell. Unlike a display name change, this alters the actual address every link, bookmark, and integration depends on.
Microsoft creates an automatic redirect from the old URL to the new one when a URL change is performed through the supported admin tooling. That redirect is not permanent. Plan to update hardcoded references rather than relying on the redirect indefinitely, since Microsoft's own guidance treats it as a transition aid, not a long-term URL alias.
Set-SPOSite -Identity "https://tenant.sharepoint.com/sites/OldName" -Url "https://tenant.sharepoint.com/sites/NewName"
The rename operation runs asynchronously. Large sites with substantial content take longer to complete, and the site is placed in a read-only state for the duration. Check progress with Get-SPOSite against the new URL before communicating the change to users.
What breaks that people do not expect
- Power Automate flows and Power Apps that reference the site by its literal URL will fail once the URL changes, even though the redirect keeps browser navigation working. Update the connection reference, not just the trigger.
- Search relevance temporarily degrades after a URL change because SharePoint needs to re-crawl and re-index content under the new address. Users may notice recently changed files not surfacing in search for several hours.
- Custom branding, SPFx web parts, or scripts that hardcode the site's absolute URL rather than using relative references will point at the old address until manually updated.
- Embedded links inside documents (a link from one Word document to another file on the same site, typed manually rather than inserted) do not update automatically and depend entirely on the temporary redirect.
When should you rename versus recreate a site?
- Choose a display name change when only the visible label needs to change and no external system references the URL.
- Choose a URL change when the address itself is wrong (a department renamed, a project code retired) and existing permissions, files, and version history must be preserved exactly as they are.
- Choose a new site plus migration when the underlying structure also needs to change, such as splitting one site into several, or when the destination needs a different template or hub association than the source.
For the migration path, see the guide to migrating a SharePoint site, which covers preserving permissions and metadata when content needs to move rather than simply be re-addressed.
Auditing embedded links after a URL change
Because the automatic redirect is temporary, any absolute links embedded in documents, wikis, or custom pages need to be found and corrected before the redirect window closes. Manually reviewing every document is not practical past a handful of files. ShareMaster's Replace Master finds and updates hardcoded URLs across libraries, lists, and Site Pages in bulk, which is the more reliable path once a site's address has changed and the temporary redirect can no longer be counted on.