· 4 min read

Implementing 404 custom page on Communication Site

Want a better looking 404 page for modern communication sites, I have found a way to set a modern page to be the 404 page at the site collection level. We have known for a while now, that classic SharePoint sites support custom 404 pages and redirects to the PageNotFoundError.aspx page - so lets apply this to modern sites.

Ah classic, my old friend…

Screenshot of classic pages library with an error pointing to the 404 page

I’ve seen this working using classic SharePoint, so I started to dig around a Classic publishing portal site to further understand how this works. I used an awesome tool - SharePoint Online Client Browser.  Shout out and thanks to Bram De Jager - for an fantastic tool for diving into SharePoint under the hood.

Typically, settings for a site collection are stored in the property bag, so that was the first place I looked and immediately found a reference in the key “vti_filenotfoundpage” to “/sites/ClassicPublishingSite/Pages/PageNotFoundError.aspx”.

SharePoint Online client browser with arrows pointing at the vti_filenotfound in the property bag

Although this may not be news to some, its useful to know that a simple value in the property bag that SharePoint uses in classic sites to achieve this functionality.

So lets apply this to a Communication Site

An immediate challenge you may find, is that you cannot edit the property bag in a Communication Site because this is a NoScript site. This prevents custom script running on your site as a security measure and includes changing values in the property bag.

I am going to disable this, apply the change and re-enable, to see what happens if this key/value pair gives us the feature to specify a 404 page.

Note: please read this article around the security implications of doing this, if you open this up, at: Security Considerations of allowing custom script| Microsoft Docs

To apply this, we utilise the PnP PowerShell library to write a short script to disable the NoScript setting, make the change to the property bad and re-enable the NoScript setting:

$tenant = "<tenant>"
$site = "<site>"

$siteUrl = "https://$($tenant).sharepoint.com/sites/$($site)"

Write-Host "Setting 404 page at $($siteUrl)..."

# Connect to SharePoint Online with PnP PowerShell library
Connect-PnPOnline $siteUrl -UseWebLogin

# Disable NoScript
Write-Host "  Disabling NoScript" -ForegroundColor Cyan
Set-PnPTenantSite -Url $siteUrl -NoScriptSite:$false

# Sets the value in the property bag, 
# note: ensure you have disabled NoScript
Write-Host "  Adding Property Bag Key" -ForegroundColor Cyan
Set-PnPPropertyBagValue -Key "vti_filenotfoundpage" `
    -Value "/sites/$($site)/SitePages/Page-not-found.aspx"

# Enable NoScript
Write-Host "  Enabling NoScript" -ForegroundColor Cyan
Set-PnPTenantSite -Url $siteUrl -NoScriptSite

Write-Host "Script Complete! :)" -ForegroundColor Green

What happened?

To test this, within the site collection page, enter a bad URL e.g. https://yourtenant.sharepoint.com/sites/yoursite/pages/pagewithbrokenlink.aspx.

This simple entry into the property bag has enabled this feature with minimal effort. I’ve created a little video below to show a demo of what happens when we apply the setting:

A few observations to note:

  • This is scoped at this site collection, you will find that 404s generated will only be redirected to the custom modern page when the 404 occurs under the URL (in bold) **https://yourtenant.sharepoint.com/sites/yoursite**/pages/somebadpage.aspx
  • In my developer tenant, on the root site, I have the publishing features enabled, any hit to the URL
    https://yourtenant.sharepoint.com/ will use that 404 page instead.
  • In Hub Sites, you will need to apply this setting on all the associated sites within the Hub - this setting is not replicated.
  • When redirecting to the 404 page, in the URL, SharePoint adds an additional query string parameter “requestUrl”. This can be very useful to log what the URL was when the user tried to navigate. If there is a cluster of same URLs from multiple users, this could indicate a broken link in the site.



Back to Blog