How to Change the Name of a SharePoint Site: A Practical Business Guide

What does changing a SharePoint site name actually change?

A request to “rename SharePoint” can describe several different jobs. Someone may want the heading at the top of a department site to reflect a new team name. Another person may be asking for a different web address. A company rebrand could also involve the Microsoft 365 group, a Teams team, email addresses and the organisation’s SharePoint domain. These are connected identities, but they are not interchangeable settings.

Start by asking what a colleague should see differently after the work is complete. If the answer is simply “Customer Operations instead of Customer Service”, a display-name update may be sufficient. If an old project code appears in the address copied into client instructions, an address change might be justified. A display-name edit does not automatically deliver that outcome.

Write the current value and proposed value in the change request. Include a screenshot or an example link, without sensitive document details. This removes ambiguity before an administrator starts work. It also gives the business owner a clear result to approve and the support team a straightforward way to verify completion.

For help with information architecture, site ownership and implementation, explore our SharePoint consultancy.

Which SharePoint names should you distinguish before making changes?

Why might a business need to rename a SharePoint site?

Useful reasons include a department restructure, a project becoming an ongoing service, or a confusing abbreviation being replaced with plain language. A name should help people decide whether they are in the right place. “People and Culture” tells a new starter more than an unexplained internal code, especially when several sites appear in search results.

Avoid making the name carry too much information. Putting an owner’s name, an expiry date and a long departmental hierarchy into every title creates maintenance work. A site description can explain purpose and audience. Metadata, navigation and ownership records can hold other details. The visible name should remain understandable when someone sees it in isolation.

A rename is less useful when the real problem is obsolete content or overlapping workspaces. Calling three duplicated sales sites by clearer names still leaves three places to look. In that situation, decide which site is authoritative, what should be archived and who owns the information. Settle the information architecture before spending time polishing labels.

If the issue spans identity, Outlook, Teams and document access, our Microsoft 365 support can help you assess the wider environment.

Who can change a SharePoint site’s display name?

The person making the change needs appropriate permissions on that site. If Site information or the expected controls are missing, ask the site owner or SharePoint administrator to check the permission model. Do not try to solve a missing control by obtaining broad tenant access for an otherwise routine content task.

Ownership should also be a business responsibility. An administrator can perform the edit, but the department should confirm the wording, affected audience and effective date. This is particularly useful for HR, finance or client-facing collaboration sites, where a misleading title could cause information to be filed in the wrong place.

Use a named change owner and a named technical owner when more than one team is involved. The business owner confirms the intended identity; the technical owner checks connected services. For a small display-name edit these may be the same person. A larger rename should still have one person accountable for confirming that all requested work has actually finished.

Treat access decisions as part of your modern workplace security, including accounts, devices and sharing settings.

How do you change the display name of a modern SharePoint site?

Open the correct site in a browser and check its current address before editing. Select the Settings gear and choose Site information. Update the Site name field, review the description for wording that should also change, and save. Microsoft’s site information guidance describes this route; available options vary by site type and permissions.

Keep the edit focused. A panel may also expose privacy, classification or hub-related settings. A naming request does not authorise changing those controls. Record the fields that were deliberately changed, then reopen the site in a fresh view to confirm that the saved name is displayed as expected.

Next, look at the site homepage and important menu entries. A heading in a Text web part may have been typed manually and may still contain the old wording. A menu label may also be independent of the site name. Update those items only where they form part of the agreed rename, and use the page publishing process where required.

Finally, ask a normal site member to confirm what they see. An administrator’s view is useful for configuration checks, but a member can spot a confusing menu or inconsistent title that the technical change alone does not reveal.

Does changing a site name also change its URL?

Treat the display name and URL as separate changes. Before making any address change, decide whether the old URL creates a real operational problem. An address can remain technically serviceable even when the display name changes. Keeping it may be a sensible choice if many business systems already depend on it.

Consider a project site originally called “Warehouse Phase One”. The department now wants “Warehouse Operations” on the homepage because the facility is live. That does not automatically mean the underlying address must change that afternoon. A proportionate approach could update the visible identity first and schedule a separate URL review once system dependencies are known.

If the URL does need changing, document the business reason and expected benefit. Cleaner addresses can improve clarity, but they do not justify an unplanned interruption to a purchasing workflow or a supplier portal. The wider the dependency, the more carefully the change should be scheduled and tested.

For a wider move between platforms, review our cloud migration services alongside the individual SharePoint task.

How does an administrator change a SharePoint site address?

Microsoft provides a site-address change process for supported SharePoint Online sites. An authorised SharePoint administrator can review the selected site in the SharePoint admin centre and use its address-editing controls where available. The administrator should first read Microsoft’s current site address change documentation, including exclusions and effects on connected services.

Check eligibility before promising a date. Not every site configuration supports the same operation. An organisation-wide domain rename is a different procedure, and changing between the /sites and /teams managed paths is not achieved by an ordinary site-address edit. A blocked operation needs diagnosis, not an improvised workaround.

Microsoft states that a site is read-only during an address change and that a redirect is created at the old location. Plan a quiet window and tell colleagues to close files beforehand. Do not interpret an approximate processing time as a guaranteed maintenance window for every site.

After the operation completes, capture the new address from the site itself. Use that exact value in documentation and tests. Avoid circulating an address copied from a planning spreadsheet until the live site confirms it is correct.

Where approvals or notifications form part of the process, discuss the workflow through our Power Automate consulting.

What should you check before renaming a site address?

Create a short dependency register. List the site’s business owner, important libraries, connected Teams usage, workflows, forms, embedded reports and applications that read or write data. Ask departments how they reach the site, rather than relying solely on what the administrator can see in a menu.

Include material outside Microsoft 365. A customer onboarding PDF may contain a link to the site. A line-of-business application may hold a stored destination. A managed browser bookmark may send hundreds of staff to the old address each morning. These dependencies matter even when they are simple to update.

Classify each dependency by consequence. A forgotten shortcut may cause inconvenience; a scheduled document-processing job can fail silently and affect operations. Give the latter an explicit test and an owner who understands its expected output. Record whether the dependency uses a stable identifier or a literal URL, but confirm behaviour rather than relying on that distinction alone.

Also agree what will happen if a problem appears. Keep the previous values, the support contact and a sensible decision point. A rollback is itself a technical change with consequences, so it should not be the first unplanned reaction to one stale menu label.

How should you handle Teams, groups and email addresses?

A connected Teams team, Microsoft 365 group and SharePoint site can present several names to the same employee. Make a small identity checklist before a restructure: site title, Teams name, group display name, relevant email aliases and visible navigation. Confirm which values the business actually wants to change.

Do not promise that editing one label will automatically produce the desired result across every workload. Behaviour depends on the connection and the operation used. Review each affected surface after the change. Email addressing is especially important because a familiar display name can conceal an unchanged underlying address.

Ask a member to open shared files through Teams as well as directly in the browser. Test the specific channels and tabs people use. A successful browser visit proves the site is reachable, but it does not prove that every embedded tab or saved shortcut still guides users to the correct content.

Keep historical messages in perspective. Old conversations may legitimately contain the previous department name. The objective is a clear current identity and working access, not rewriting every historical reference. Focus on active entry points and records that people rely on today.

Make support ownership clear after the change; our managed IT support explains the ongoing service options.

What could a rename affect in Power Automate and business applications?

A site can be a destination for invoice approvals, document generation, forms or reporting. Before an address change, identify the processes that depend on it and describe a representative successful run. A workflow owner should be able to show which library receives the file, who receives the task and what completion looks like.

Use controlled tests after the change. Submit a clearly labelled test item through the normal route, check the resulting record and confirm that notifications reach the expected people. If the process creates a financial transaction or sends an external message, use an approved test method that avoids creating a real commitment.

Do not stop at a green status in one run history screen. Check the business result. An automation may complete while writing to an unintended folder, using an outdated link in a message, or generating a document with the old department title. Functional verification should include both technical completion and the recipient’s experience.

Where a dependency requires reconfiguration, record the actual change and retest it. This creates a useful handover for future administrators and prevents the next rename from starting with the same discovery exercise.

For ongoing governance and administration, see our guide to SharePoint managed services.

How do you communicate the change without confusing staff?

Use a concise notice that says what is changing, why, when and what colleagues need to do. Distinguish a new display name from a new address. If only the label changes, say so plainly. If work may be temporarily read-only, specify the window and the support contact.

Give people a recognisable example. “The site currently shown as Service Desk Knowledge will appear as IT Knowledge from Monday” is clearer than “SharePoint branding alignment”. Include the final verified link after the change, particularly in onboarding material or department instructions.

Tell champions and helpdesk staff before the wider announcement. They are likely to receive questions and can identify instructions that need updating. For a site used by external guests, check whether a separate message is needed and who is responsible for sending it.

Keep the announcement proportionate. A minor name correction should not generate a week of communications. A business-critical address change deserves more notice and a short completion update once testing has passed.

How should you test and sign off the rename?

Build a test sheet around real activities. Open the homepage as an ordinary member, locate a familiar document, edit a permitted test file and follow the main navigation. Ask a visitor to verify read access where the site has a separate reader audience. Test a guest route if external collaboration forms part of normal use.

For an address change, test bookmarked links and the specific applications listed in the dependency register. Confirm important workflows, embedded content and Teams file access. Record any issue with its owner and impact; do not hide an unresolved problem behind a general statement that the rename succeeded.

Sign-off should distinguish configuration completion from business acceptance. The administrator confirms that the intended values are saved. The site owner confirms that staff can still complete the important tasks. This separation is valuable even when both checks take only a few minutes.

Retain the change record with the site’s ownership information. Include the date, previous and current names, addresses where applicable, tests performed and any follow-up work. It becomes a practical reference when someone later asks why an old shortcut looks different.

If existing information is being reorganised or transferred, use our SharePoint data migration guide to plan the wider move.

What naming rules prevent the same problem returning?

Agree a short naming standard that people can apply without specialist help. Use recognisable business terms, distinguish permanent departments from temporary projects and avoid unexplained acronyms. Decide where a year or client identifier is useful and where it would simply make a permanent site look obsolete next January.

Keep a register of active sites with their purpose and business owner. The register should help someone determine whether an appropriate workspace already exists before creating another one. It does not need to become an elaborate catalogue; a maintained list of the information needed for decisions is more valuable than a comprehensive spreadsheet nobody trusts.

Set a trigger for reviewing identity, such as a department restructure, merger or project closure. Ask whether the site should be renamed, archived or consolidated. This prevents repeated cosmetic changes from concealing a growing collection of abandoned sites.

For example, a company could reserve customer names for active customer collaboration sites and use a stable internal department label for shared procedures. That is a design choice, not a Microsoft requirement. The important point is that colleagues understand the convention and know who can approve exceptions.

For colleagues who need help with everyday document collaboration, share our practical guide to using SharePoint.

What should the final handover contain?

Give the business owner a brief completion note rather than a collection of administration screenshots. State the final display name, the live address, the checks completed and any actions remaining. If a workflow or navigation entry needed adjustment, include the owner responsible for maintaining it.

Update support documentation where the old name would lead someone astray. A helpdesk article that tells staff to open a retired department label can create avoidable tickets even when every technical link works. Check onboarding instructions and training material alongside the site itself.

Close the work only when the agreed outcome is reviewable. For a simple title edit, that may be a verified heading and owner confirmation. For an address change, retain the dependency tests and communicate the new entry point. Clear evidence makes the next support conversation much easier.

When is renaming the wrong solution?

If the site has the wrong audience, inappropriate permissions or a confused purpose, changing its title will not resolve the underlying design. A shared workspace containing both confidential HR documents and general announcements needs an access and information-architecture review before a cosmetic tidy-up.

Similarly, repeated annual renames may indicate that temporary projects and permanent departmental knowledge are mixed together. A stable operational site with separate project spaces may reduce future disruption. Choose the structure around how information is owned, used and retired.

NetMonkeys can help assess a rename within the wider Microsoft 365 environment, including navigation, permissions and connected processes. A useful scope is specific: identify the values to change, check dependencies, perform the agreed work and verify the business outcome. That gives the organisation a clear improvement without turning a simple request into an unnecessary rebuild.