A website is ever evolving. It needs to change and adapt as the business grows and online demands change. This is why it is so critical to build sites so they can be extended and why bespoke, custom built themes are preferable over a premium theme. But, those are topics for other articles.
But, what if what you want to do add to your site could happily be its own website? What if the design of the main site doesn’t fit the message of the content you want to promote? Perhaps you only need the content online for a finite amount of time? Introducing the microsite!
In this article, we will answer two important questions. What is a microsite and why use a microsite? So, without further ado…
A microsite is a website that serves a dedicated purpose and doesn’t fit as part of a brand’s main website. They are typically very targeted sites with just one or a few pages designed purely for the singular purpose for which they’re created. A great example of a microsite is the Houston Zoo Lights site. It’s dedicated to selling tickets and providing information for the seasonal Houston Zoo Lights event that happens each Christmas.
A microsite is often best identified through the usage of a hard sub-domain (subdomain.domain.com) or altogether separate URL from the main site. However, it may still reside at a soft sub-domain (domain.com/sub-domain) which is for microsites wanting to retain a sense of continuity. We’ll look at which option is better a little later.
Whatever the identifying factor, the microsite will be a completely separate website to the main site. The site will engage its own data structure, design and code base. It is for this reason they’re a very powerful tool and why we like microsites. So…let’s explore some examples of when to deploy a microsite and understand more why we do so.
At the start of this article, we asked a few questions to which the answer is, a microsite. Now, we will break it down into some examples to demonstrate why to use a microsite.
We touched on Houston Zoo Lights earlier and it’s a great example of when to go with a microsite because of design control. It’s obvious to see that the Houston Zoo Lights microsite is never going to fit into the main Houston Zoo website design.
By separating the site into its own entity, it can be designed exactly for the purpose it serves. Furthermore, the site’s design wouldn’t share any code from the main site. By utilising a microsite, neither the main site nor the microsite are being bloated by one another. It would be very difficult to write clean code for both designs in one theme. There would be mass duplication and redundant code. This in turn builds in technical debt as maintaining the code base becomes harder.
If you need a site for only a limited period of time, then building out new templates and adding code to an existing site isn’t an efficient solution. Any code that’s added should really be removed when the microsite ceases to be required.
By using a microsite, once the need for the pages passes the site can simply be switched off. No time is required cleaning up and should the site be required again, it sits ready to go.
A site which gathers data, such as a visitor or customer feedback dashboard, is likely to have a lot of functionality attached to it. Furthermore, the data is going to need to be processed and stored.
Jumbling all of this into the main site is less than ideal. It risks slowing down the main site and it makes extracting data that much harder. By utilising a microsite, it keeps everything nicely separated.
Customer service or support platforms are a perfect example of this. Replacing the main site would involve hours of work extracting the support or feedback data and files associated with submitting and processing said data.
The question that should be asked to determine if a microsite is the appropriate tool is this. Does the code to run the microsite differ greatly from the main site? This can be markup, functionality or styling. If the answer is yes, then a microsite is probably the correct route to take.