If the SharePoint admin centre shows both Members and Site members, you are looking at two permission systems—not two labels for the same list.
On a Microsoft 365 group-connected team site:
- Members are members of the connected Microsoft 365 Group. That membership is shared with the wider workspace, including its SharePoint site and, where present, its Team.
- Site members belong to a SharePoint permission group for that site. They can have site access without becoming members of the Microsoft 365 Group.
Microsoft recommends managing a group-connected team site's normal membership through its Microsoft 365 Group or Team. Use SharePoint-only access deliberately—for example, the Visitors group is how you give view-only site access because Microsoft 365 Groups do not have a view-only role.
That is the short answer. The full answer depends on the type of SharePoint site you are checking.
Members and Site members compared
| Question | Members | Site members |
|---|---|---|
| What is it? | The membership of the connected Microsoft 365 Group | A SharePoint group with permissions on one site |
| Where does it apply? | The group-connected workspace and its services | The SharePoint site and any content that inherits the group's permissions |
| Normal permission on the site | Group members become site members | The site's Members group normally has edit permission |
| Where should it be managed? | Microsoft 365 Group or Teams membership | SharePoint site permissions |
| Does it grant access to Teams conversations? | Yes, when the group has a Team and the user is a member of it | No; site-only access does not make somebody a member of the Team |
| Can it provide view-only site access? | No Microsoft 365 Group view-only role | Yes, but use the SharePoint Visitors group rather than Members |
| Can the lists differ? | Yes | Yes—SharePoint-only users, security groups, visitors, direct shares and unique item permissions can all produce differences |
Microsoft's current SharePoint permissions guidance says Group owners become site owners and Group members become site members. It also says that people added directly to the SharePoint site do not gain access to the Group's other services.
The important word is directly. SharePoint can grant access outside the Microsoft 365 Group. That flexibility is useful, but it is also why checking only the Group membership is not a complete access review.
First identify the type of site
Do this before trying to “fix” a difference. The right membership authority changes with the site type.
| Site type | Normal membership authority | What to know |
|---|---|---|
| Microsoft 365 group-connected team site | Microsoft 365 Group, or Teams when a Team exists | Group owners and members receive corresponding SharePoint access. SharePoint-only permissions are possible, but Microsoft recommends the Group or Team for the simplest management model. |
| Communication site | SharePoint Owners, Members and Visitors groups | Communication sites are not connected to Microsoft 365 Groups. A small number of Members normally create content; a much larger Visitors audience reads it. |
| Non-group-connected site | SharePoint groups and site permissions | There is no connected Microsoft 365 Group membership to compare. Manage access in SharePoint. |
| Standard Teams channel | The parent Team's Microsoft 365 Group | Standard channels store files in folders in the Team's parent SharePoint site. Team owners and members have access to that site. |
| Private or shared Teams channel | The channel membership in Teams | Each private or shared channel has a separate SharePoint site. Its site permissions are read-only in SharePoint and must be managed through Teams. |
| Hub site | Depends on whether the hub itself is a team site or communication site | Being associated with a hub is an information-architecture relationship; inspect the underlying site type before managing its membership. |
The Microsoft overview of Teams and SharePoint integration is particularly important for channel sites. A private or shared channel is not just a locked folder in the parent site. It has its own SharePoint site and its membership follows the channel.
What the admin centre is showing
In the SharePoint admin centre, go to Sites > Active sites, select a site, then open Membership. Microsoft documents this panel as a place to view site admins, owners, members and visitors. Group-connected team sites can also expose the connected Group's owners and members.
Those entries represent different roles:
- Group owners and members control membership of the Microsoft 365 Group-backed workspace.
- Site owners, members and visitors are SharePoint permission groups scoped to the site.
- Site admins have site collection administrator rights. This is a privileged SharePoint role and should not be confused with routine Group or site membership.
The wording and layout can change as Microsoft updates the admin centre. The durable distinction is the authority behind each entry: Microsoft 365 Group, SharePoint group, Teams channel or site-administrator assignment.
Microsoft's current Active sites documentation explains where to view the Membership panel. It does not describe a separate “sync” command that makes SharePoint-only membership flow back into the Microsoft 365 Group.
Why the two membership lists differ
A difference is not automatically an error. It is evidence that you need to identify the access route.
1. Somebody was given access to the SharePoint site only
A site owner can grant a person or group permission in SharePoint without adding them to the connected Microsoft 365 Group.
That person may be able to edit the site or its files, but they do not become a member of the Team, group mailbox, calendar or other Group-connected services.
This can be intentional. A contractor might need a project document library without access to every Team conversation. The problem begins when nobody records the exception or reviews it later.
2. Somebody needs view-only access
Microsoft 365 Groups have owners and members, but no view-only membership role. Microsoft recommends adding read-only users directly to the SharePoint Visitors group.
This is a normal reason for the SharePoint permission view to contain people who are not Microsoft 365 Group members.
Do not add a large read-only audience to the Members group simply to make the lists look consistent. That would give them more permission than the job requires.
3. A communication site has no Microsoft 365 Group
Communication sites use SharePoint Owners, Members and Visitors groups. There is no connected Group membership that should match them.
Microsoft's communication-site permission guidance recommends a small authoring group and a larger visitor audience. Security groups are often useful for that visitor population.
4. The site belongs to a private or shared Teams channel
Private and shared channels have separate SharePoint sites. Channel owners become site owners and channel members become site members, but Microsoft requires you to manage that membership in Teams. The SharePoint permissions view is read-only.
Trying to repair the channel site from SharePoint is the wrong route.
5. A file, folder, list or library has been shared separately
The site-level Members and Site members lists are not a complete inventory of every way somebody can reach content.
A sharing link can grant access to an individual item. A library, folder or file can also stop inheriting permissions from its parent. These permissions may exist without putting the recipient into the site's default Members group.
This is why “the two member counts match” is not proof that the site's access is tidy.
6. A site admin has powerful access outside normal membership
Site collection administrators can manage and access the site even when they do not appear as routine Group members or Site members. Review site admins separately, keep the number small and use the least-privileged admin role that will do the job.
The access model in one diagram
Microsoft 365 Group
├── Owners ───────────────► SharePoint site owners
└── Members ───────────────► SharePoint site members
│
└──► Other connected Group services
SharePoint site only
├── Owners ───────────────► Full control of the site
├── Members ───────────────► Usually edit the site
└── Visitors ──────────────► Read the site
Separate access paths
├── Site collection administrators
├── Direct sharing
├── Security groups
├── Sharing links
└── Unique library, folder or item permissions
The arrows go from the Microsoft 365 Group into SharePoint. Adding somebody to a SharePoint group does not add them back to the Microsoft 365 Group.
A safe audit checklist
Do not start by deleting the names that look different. First work out whether each route is intentional.
1. Record the site's purpose and type
Confirm whether it is a group-connected team site, communication site, ordinary non-group site, parent Teams site or channel site.
Also record the business owner and the sensitivity of the content. The same access pattern can be reasonable on a public internal news site and unacceptable on a restricted finance site.
2. Check the normal membership authority
For a Teams-connected parent site, review Team ownership and membership. For a group-connected site without Teams, review the Microsoft 365 Group. For communication and non-group sites, review the SharePoint groups.
Use the source of authority that matches the site type rather than editing every membership surface until the counts happen to match.
3. Review SharePoint groups separately
Inspect the site's Owners, Members and Visitors groups.
For every user or group that sits outside the normal Microsoft 365 Group membership, record:
- who needs the access;
- why site-only access is required;
- whether the permission level is appropriate;
- who approved it; and
- when it should be reviewed.
Microsoft advises using the built-in groups for normal scenarios and managing group-connected team sites through the associated Group. Custom permission structures should have a clear reason and an owner.
4. Review site admins
Check primary and additional site admins independently from owners, members and visitors. Site-admin access is not a substitute for an accountable business owner.
5. Look below the site level
Review direct shares, sharing links and content with unique permissions. Pay particular attention to:
- broad organisation-wide links;
- external recipients and guests;
- folders used as informal security boundaries;
- old project exceptions; and
- content whose permission inheritance has been broken.
Do not assume that removing somebody from the Site members group removes every link or unique permission they hold.
6. Check what changed, not only the current state
The current membership view tells you who appears to have access now. It does not tell you who granted it or when.
Microsoft Purview records SharePoint sharing activity, including events such as AddedToGroup, SharingSet, SecureLinkCreated and AddedToSecureLink. Microsoft's sharing-audit documentation explains how the acting user, target user or group, operation and object can be used to investigate a change.
Audit availability, retention and the activities you can search depend on your Microsoft 365 and Purview configuration. Do not promise a historical answer until you have confirmed the relevant period is retained.
7. Use estate-wide reporting when the problem is bigger than one site
For a large tenant, opening every Membership panel does not scale. Microsoft offers Data access governance reports for broader permission and sharing analysis, with licensing and feature availability that must be checked for your tenant.
These reports can help you find sites with broad exposure. They do not decide whether a named person's access is legitimate; that still needs an accountable owner and business context.
How to repair an unintended mismatch
Use this order:
- Confirm the access is genuinely wrong. Ask the site or Team owner before removing it.
- Choose the intended authority. For routine collaboration on a group-connected site, that is normally the Microsoft 365 Group or Team.
- Preserve legitimate view-only access. Keep readers in Visitors rather than promoting them to Members.
- Move legitimate collaborators to the Group or Team. Only if they should also participate in the wider workspace.
- Remove redundant site-only membership. Do this after the correct access route is working, not before.
- Review links and unique permissions. Group cleanup does not automatically prove that item-level access is gone.
- Record the decision. Capture owner, reason, approver and review date for any remaining exception.
- Test with the affected account. Confirm both the access that should work and the access that should not.
For a private or shared channel site, stop at step one and make the membership change in Teams. SharePoint deliberately presents those site permissions as read-only.
Common mistakes
“Members and Site members should always be identical”
No. View-only visitors, communication-site audiences and approved site-only access are valid reasons for differences.
The goal is an understandable access model, not matching numbers.
“Site members are just a cached copy of the Group”
No. The connected Microsoft 365 Group can be granted access through SharePoint, but the SharePoint Members group is still a site-level permission container. SharePoint-only access can exist alongside Group-derived access.
Do not diagnose a mismatch as a cache or sync delay without evidence from the affected tenant.
“If the Membership panel looks right, every file is secure”
No. Sharing links, unique permissions and site admins are separate access paths.
“Adding someone to Site members should make them appear in Teams”
No. SharePoint permissions do not flow back into Team or Microsoft 365 Group membership.
“Every team site is managed the same way”
No. A group-connected parent site and a private or shared channel site have different permission-management rules.
The practical rule to remember
Use the Microsoft 365 Group or Team for the people who belong to the whole collaboration workspace.
Use SharePoint groups for SharePoint-specific roles—especially Visitors—or for a documented exception. Use Teams for private and shared channel membership. Then audit direct sharing and unique permissions separately.
That produces a permission model an administrator can explain, instead of two lists that merely happen to contain the same names.
Keep SharePoint and Teams access understandable
If you are untangling Teams-connected sites, direct permissions, external sharing or abandoned owners, join SharePoint & Teams Admins. It is built for the small Microsoft 365 teams that have to keep the estate usable without turning governance into a full-time department.