Skip to main content

SharePoint Online: Disable Top Navigation on a Teams Connected Site Using PnP PowerShell

If you've tried to disable the top navigation bar on a modern Teams-connected SharePoint site, you've probably noticed there's no obvious setting to do it. The UI doesn't give you a toggle. Site settings don't have the option. And the PowerShell properties you'd expect to work simply don't.

This post covers exactly that scenario - what I tried, why each approach failed, and the single PnP PowerShell command that actually works.

The Problem

On a modern Teams-connected SharePoint site (template GROUP#0), the top navigation bar is visible by default. Unlike classic SharePoint publishing sites, there is no built-in UI option in site settings or site collection settings to disable it. If you want to hide the top navigation bar - for example because the site is associated to a hub that already provides navigation, making the site's own top nav redundant - you need to do it programmatically.

What Didn't Work for Me

1. Site Settings and Site Collection Settings

The first place anyone looks. On modern Teams-connected SharePoint sites there is no toggle to disable the top navigation bar in either site settings or site collection settings. Classic publishing sites had this option under Navigation Elements; modern sites simply don't expose it in the UI.

2. Change the Look → Navigation

Settings gear → Change the look → Navigation provides some visibility options on certain modern sites. On Teams-connected sites this either doesn't appear or only controls the left navigation, not the top navigation bar.

3. QuickLaunchEnabled

A commonly referenced property for hiding navigation:

$web = Get-PnPWeb -Includes QuickLaunchEnabled -Connection $conn
Write-Host "QuickLaunchEnabled: $($web.QuickLaunchEnabled)"

This controls the left navigation panel (Quick Launch), not the top navigation bar. Setting it to $false has no effect on the top nav. Not the right property.

4. IsVisible on TopNavigationBar Nodes

Enumerating the TopNavigationBar navigation nodes and setting IsVisible = $false on each:

$nodes = Get-PnPNavigationNode -Location TopNavigationBar -Connection $conn
foreach ($node in $nodes) {
    $node.IsVisible = $false
    $node.Update()
}
Invoke-PnPQuery -Connection $conn

This appears to work - reading $node.IsVisible back returns False - but the navigation remains fully visible in the browser. Modern SharePoint's rendering engine does not honour this classic CSOM property. It reads from a different configuration layer entirely.

5. Navigation.UseShared

The idea here is to make the site inherit navigation from a parent or hub, which would suppress its own top nav. This hits two walls:

$web = Get-PnPWeb -Includes Navigation -Connection $conn
$web.Navigation.UseShared = $true   # throws error on root web
$web.Navigation.Update()            # method does not exist

Setting UseShared = $true on a root web throws: "A root web site cannot use shared navigation from another web site." And Navigation.Update() doesn't exist as a method on the Navigation object anyway - another dead end.

What Actually Works

The correct lever for modern SharePoint Online is the header layout. Setting it to Minimal hides the top navigation bar entirely while leaving all navigation nodes intact - nothing is deleted, so it can be re-enabled at any time:

$conn = Connect-PnPOnline -Url "https://<tenant>.sharepoint.com/sites/<teamsite>" `
            -ClientId $clientId -Tenant $tenantId `
            -Thumbprint $thumbprint -ReturnConnection

Set-PnPWebHeader -HeaderLayout Minimal -Connection $conn

To re-enable the top navigation later:

Set-PnPWebHeader -HeaderLayout Standard -Connection $conn

All four HeaderLayout values and their effect on the top navigation:

HeaderLayout Top Navigation
Standard Visible (default)
Compact Visible, smaller header
Minimal Hidden
Extended Visible, large header with background image support

Why the Other Approaches Failed

The classic CSOM properties - IsVisible, UseShared, QuickLaunchEnabled - predate modern SharePoint's rendering pipeline. They are still readable and writable via the API, but the modern header component doesn't consult them. It reads header configuration from a separate modern layer. Set-PnPWebHeader targets that modern layer directly, which is why it is the only approach that actually works.

This is a recurring pattern in SharePoint Online administration: properties that worked in classic SharePoint are still present in the API but silently ignored by modern rendering. Always check whether a more recent cmdlet exists before assuming a classic CSOM property is the right tool.

Key Takeaway

To hide the top navigation bar on a modern Teams-connected SharePoint Online site, use:

Set-PnPWebHeader -HeaderLayout Minimal -Connection $conn

Classic CSOM navigation properties (IsVisible, UseShared, QuickLaunchEnabled) are ignored by the modern rendering engine. Set-PnPWebHeader is the correct cmdlet for modern SharePoint header and navigation control.

Frequently Asked Questions

Can I hide the top navigation bar on a SharePoint Online modern site without PowerShell?

Not reliably on a Teams-connected site. The UI does not expose a toggle for the top navigation bar on modern GROUP#0 sites. The only supported method is via PnP PowerShell using Set-PnPWebHeader -HeaderLayout Minimal.

Does Set-PnPWebHeader -HeaderLayout Minimal delete my navigation nodes?

No. Setting the header layout to Minimal hides the navigation bar visually but leaves all navigation nodes intact. You can restore them at any time by running Set-PnPWebHeader -HeaderLayout Standard.

Why does IsVisible = $false not work on SharePoint navigation nodes?

The IsVisible property is a classic CSOM property that predates modern SharePoint's rendering pipeline. The modern header component does not read this property - it uses a separate configuration layer. Use Set-PnPWebHeader instead.

Why does Navigation.UseShared not work on a Teams-connected site?

Setting $web.Navigation.UseShared = $true throws an error on root web sites: "A root web site cannot use shared navigation from another web site." Additionally, Navigation.Update() does not exist as a method on the Navigation object in modern PnP PowerShell versions.

Does this work on communication sites as well as team sites?

Yes. Set-PnPWebHeader -HeaderLayout Minimal works on any modern SharePoint Online site regardless of template, including communication sites (SITEPAGEPUBLISHING#0) and Teams-connected team sites (GROUP#0).

Can I apply this to multiple sites at once?

Yes. Use Get-PnPTenantSite to retrieve all sites of a given template and loop through them applying Set-PnPWebHeader -HeaderLayout Minimal to each.

Further Reading

Labels:
Location: United Kingdom

Comments

Post a Comment

Popular posts from this blog

Difference between the architectures of SSPs and SharePoint Service Application

SharePoint 2010 has some new features and components, which help to overcome difficulties such as redundancy and service-sharing that we faced while using SharePoint 2007.  Services in MOSS 2007 were implemented with the help of Shared Service Providers or SSPs. But we cannot use the services of one SSP for another SSP. So each SSP has to have its own set of services and applications, which increases redundant data in the farm.  For example, different managers in the same organization use a SharePoint site to maintain official data associated with an SSP. This SSP is associated with different services, such as Search service, BDC service, and a user profile service. A project manager in this organization requests an exclusive user profile service to maintain project data security. To provide this, we first need to create a separate SSP for the project manager and then a separate service called user profile service - project name. Next, we need to associate the SSP with ...
5 comments
Read more

SharePoint Designer Workflow Failed to Start - Cancelled by System Account

I was working on a List workflow the other day in SharePoint Designer 2010. This list already had a workflow which was working perfectly fine and I needed another manual workflow in it. No matter what I tried the workflow would fail and would log a message in the history list that Workflow failed to start and it was cancelled by System Account . I observed that the same happened with new workflows in that list, new workflows in other lists and I even tried creating new subsites and workflows were behaving the same way. I googled for a while and there were many suggestions to clear SPD cache which did not help me. I played with SPD 2010 for a while and observed that the workflow xml and xoml files were checked out. I read in some blogs that this could cause this issue as well. I tried to check those files in but then I was greeted with a new error! " Cannot perform this operation. The file is no longer checked out or has been deleted ." I had no clue what was happening...
10 comments
Read more

"Cannot impersonate user for data source" - SSRS reports

We were getting this strange error while viewing our reports in SharePoint that was deployed using BIDS 2005: An error has occurred during report processing. Cannot impersonate user for data source 'datasource' Logon failed I tried many things but nothing worked. I did some research and found many blog posts which suggested me to reapply the password on the datasource file specified in the error message and save it again. That didn't work for me. I saw some check boxes in the data source file that read "Use as Windows Credentials" and "Set Execution Context to this report" and I didn't know what they meant. I unchecked those in my data source and then when the refreshed the page the report started displaying.
2 comments
Read more