What are microsites?

“Microsites” refers to the various offshoot websites that can run alongside your main website.  For example, a UK council will always have a primary public facing site (e.g. https://www.plymouth.gov.uk/), but will typically also have other online real estate such as "Visit ...", "Invest In ..." type sites, or many other smaller sites with a dedicated purpose. 

Microsites sometimes run under their own standalone domain name (e.g. https://www.visitplymouth.co.uk) or sometimes they run as sub-sections of another domain (e.g. https://www.visitplymouth.co.uk/invest).  Microsites typically run on a disparate array of platforms (i.e. WordPress, Drupal, Umbraco, Wix etc).  Some sites may be managed by the same team, others may be managed independently.  For those responsible for an organisation’s online presence, keeping on top of all of these sites, to make sure that they remain secure, legislation compliant and up-to-date quickly becomes mind boggling!

Given how complex microsites arrangements can be, it’s no surprise that supporting them in Public Platform is like playing a four-dimensional game of chess!

Microsites in Public Platform

When we built Public Platform, we wanted to offer a solution for microsites, so that a single Public Platform instance could run multiple sites, which for all intents and purposes appear as independent sites to outside visitors.  This brings the following benefits:

• All sites remain secure.
• All sites remain legislation compliant.
• The content management experience becomes consistent across all sites.
• All sites receive a steady stream of improvements and new features as part of your Public Platform subscription.
• Costs are reduced by re-using your existing Public Platform subscription.

As such, microsites functionality has been in Public Platform since its earliest days, as it was a requirement of a project we delivered for Warrington Borough Council in 2021 where we produced a series of microsites running off a single Public Platform instance. 

We’ve also been using this functionality to run the https://councilplatform.com site, (which was built using Public Platform), as well as the marketing site of our sibling product https://publicplatform.com.

To that end, we have developed two methods of running and maintaining multiple microsites, Multi Sites and Domain Access.

The "Multi Sites" microsites proposition

The existing microsites functionality is built using Multi Sites.  The key points of “Multi Sites” based microsites functionality is:

• Sites are run from a single codebase.
• Sites have a separate database and uploaded files folder.
• Sites have a separate admin system.
• Sites can either re-use the same theme or have totally separate themes.
• Sites have totally separate user accounts and content.

This works well for most use cases, but there are a few downsides:

1. User accounts aren’t shared between the microsites, so it leads to staff having to setup a user account per site.  It would be preferable to have a single user account that works across all sites, and permissions controlled on a per-site basis.
2. It’s not possible to share content or configuration between sites.
3. It takes about a half day of development time to setup a new micro-site.

However, to strengthen the "Multi Sites" based microsites proposition, we’ve added in Single Sign On functionality. This allows you to make one site a primary site (most likely your main public website), and all other microsites are configured as subordinate sites. The login process on subordinate sites routes authentication via the primary site. This means that the primary site is the single source of user accounts for all microsites. The user role for a user is set on each individual micro-site. This means that if a user account is blocked on the primary site, then access is rescinded on all subordinate sites. The default user role on subordinate sites is no role, so users can login but cannot do anything until they have a role allocated to them.

The "Domain Access" microsites proposition

In our own use case of running https://councilplatform.com/ and https://publicplatform.com/ from a single Public Platform instance, the sites are managed by the same team and we wanted to be able to share content between the two sites.  This is because Public Platform is essentially Public Platform minus the council specific third-party integrations, so the content of the two websites has a high degree of overlap.

To solve this use case, we’ve implemented a new microsites solution using something called “Domain Access”.  With Domain Access, microsites are created by creating a “Domain Record” in Public Platform’s admin system and then pointing a corresponding domain name (e.g. publicplatform.com)  to the existing Public Platform website’s server.  Using the platform's admin system, you can then edit the settings for each micro-site and:

• Set each site’s theme.
• Allocate users to each site.
• Allocate content to each site.

This all sounds perfect as it solves the previously mentioned downsides.  But there are some drawbacks to the Domain Access microsites approach:

1. Domain Access only “walls off” sites to a certain extent.  Things such as overall site configuration and uploaded files will be visible to users of all Domain Access based microsites provided their user role has sufficient permission.  You need to tightly control allocated user roles to ensure that inexperienced users of a micro-site don’t adversely affect another site.
2. Running multiple sites from a single admin system makes content management more complicated.  Modern site building puts a lot of focus on ensuring the frontend of sites places minimal “cognitive load” on visitors, but sadly, content editors don’t often get the same level of consideration!  Running multiple large sites from a single admin system will make site management harder.

When to use "Multi Sites" or "Domain Access" microsites approach

We feel that this enhanced “Multi Site” functionality is generally the better option for running microsites, especially so if:

• The micro-site is large (i.e. more than a handful of basic CMS pages).
• The micro-site is run by a separate team from your primary Public Platform site.

An example always helps, so please take a look at https://safeguarding.councilplatform.com. This is a “Multi Sites” based microsite, with https://demo.councilplatform.com being the primary site and Safeguarding being the subordinate. We’ve chosen this arrangement as the hypothetical Parminster Safeguarding team would manage the site independently of the primary Parminster website. The site is also substantial with its own News and Events feeds, as well as containing custom forms and site-specific functionality such as a ‘Quick Exit’ button.

In short, Council and Public Platform clients now have two options for the running of multisites:

• "Multi Sites", where sites are mainly separate and siloed, with staff access being controlled from the primary site.
• "Domain Access", where sites are run from a single backend, and which site content appears on being decided at the point of publishing.