Department Microsites: When a Separate Site Is Right, and How to Stop Them Sprawling | How-to Guide

By the We.Inc editorial team · Editorial policy

A decision test for whether a department, programme or campaign gets its own microsite or a section of the main site, plus naming and domain rules, an approval form, a lifecycle with an end date, and a register template for organisations that run many sites.

Every large organisation has the same argument. Parks wants its own website because the main one is slow to change. The tourism team wants a site with its own look. A grant-funded programme needs something live in three weeks. Each request is reasonable on its own. Ten years later there are forty sites, a dozen domains nobody remembers registering, six different contact pages and no one who can say which ones are still maintained. This guide gives you a test for saying yes or no, the rules to attach to a yes, and a way to retire sites before they rot.

What we mean by a microsite

A microsite is any website that sits outside your main site's navigation and templates, with its own address. It might be a subdomain (parks.example.gov), a separate domain (visitexample.com), or a site on a third-party platform. A section of the main site (example.gov/parks) is not a microsite, even if it has its own banner. The distinction matters because a section inherits your templates, search, navigation, accessibility fixes and review process. A microsite inherits none of them unless you make it.

The decision test

Ask the requesting team to answer these seven questions in writing. A microsite is justified only if the answers to at least two of the first four are yes, and the answers to all of the last three are yes.

#QuestionWhy it matters
1Is the audience mostly people who would never visit the main site (tourists, investors, a national audience)?If residents or members are the audience, they will look on the main site first
2Does it need a brand that must look different from the parent, for a reason outside the team's preference (a partnership, a separately governed body)?"We want our own look" is not a reason; "this is a joint venture with two other counties" is
3Does it need functions the main site cannot provide (a store, bookings, a members' area)?Check first whether the main platform can add it
4Is it a time-limited campaign with a clear end date?Campaigns are the best fit, as long as they actually end
5Is there a named owner, by role, who will maintain it for its whole life?Sites without owners are where outdated and inaccessible content collects
6Will it use the organisation's approved templates or meet the same accessibility and security bar?A microsite is still your content; under ADA Title II, content provided through a contractor is still the public entity's
7Is there budget for its running costs and its retirement?Domains, hosting, testing and the work of shutting it down cost money every year

If the request fails, offer a section of the main site with a distinct landing page. Most teams asking for a microsite actually want three things: speed, a page they control and a short address. A good section with delegated editing and a short redirect gives them all three.

Section, subdomain or separate domain

Once a separate presence is justified, choose its address deliberately.

OptionUse it whenCosts and risks
Section: example.gov/parksThe default for any department or permanent programmeDepends on the main platform being easy enough for the department to edit
Subdomain: parks.example.govA distinct application or a site on a different platform, still clearly part of the organisationSearch engines may treat it as a separate site; separate analytics and certificates to manage
Separate domain: visitexample.comAudiences outside your jurisdiction, partnerships, campaigns with their own nameAnnual renewal, phishing look-alike risk, residents cannot tell it is official, link equity starts from zero
Short redirect: example.gov/fairA campaign that needs a printable addressNone worth mentioning; use these generously

For US public bodies there is an extra reason to keep things under one name. The .gov registry, run by CISA, says organisations generally cannot get more than one .gov domain, including naming variations. A department that wants its own name therefore usually ends up on a commercial domain, which residents have less reason to trust. A subdomain of your .gov keeps the official signal.

Naming rules to adopt

The microsite request form

Copy this into your intake form. Making the requester write the answers down filters out most weak requests on its own.

FieldAnswer
Name of site and proposed address
Requesting department and owner role (not a person's name only)
Backup owner role
Audience and the top three tasks they will do
Answers to the seven-question test
Why a section of the main site will not work
Platform and template to be used
Functions needed (forms, bookings, store, members' area)
Launch date and planned end or review date
Annual budget, including domain, testing and retirement
Who approves content before it goes live
Accessibility test plan before launch

Run every site from one place

The real cost of microsites is not building them. It is that each one ends up on a different platform, with a different login, a different contractor and a different idea of what "done" means. The single most effective rule is that every approved microsite is built on a platform the central web team can see and manage. That gives you:

A list of sites with search, tags and a status column showing Active and Invited
Every site under one brand in one list, with tags and status. On our demo brand the sites are sample businesses; in an organisation they would be departments and programmes.
Brand settings for colours and fonts, applied across all sites under the brand
Brand colours and fonts set once for every site. Departments start from the same look rather than inventing one.

Delegation without losing control

Departments ask for microsites mostly because they want to publish without waiting. Give them that, within limits:

Can do without askingNeeds central sign-off
Edit text, images and events on their own siteLaunching the site, and relaunching after a redesign
Add news posts and pages within the templateConnecting a new domain
Invite colleagues to editAdding a store, payments or a members' area
Request a short redirectChanging the template or brand colours
One site's settings with its site limit and switches for publishing, connecting its own domain, viewing code, blog, store, forms and SEO
Per-site switches decide what each department's site can do: publish, connect its own domain, run a blog, store or forms.

A lifecycle with an end

Microsites rarely die on purpose. Build the end into the start.

  1. Approve with an end date (campaigns) or a review date no more than two years out (programmes).
  2. Launch only after the accessibility test and content review are done.
  3. Review yearly. Is the owner still in post? Are visits worth the cost? Is the content current? Does it still pass the seven-question test?
  4. Retire by moving anything still needed into the main site, redirecting every old URL to its new home or the closest relevant page, archiving what must be kept for the record, and keeping the domain registered for a while so nobody else can buy it and pose as you.
  5. Remove the site from the register, revoke access and record the date.
An audit log listing recent actions with time, action and user columns
An audit log of organisation actions: useful at review time to see who changed what on which site.

The microsite register

Keep one sheet. ADA.gov's first steps for the Title II web rule begin with knowing how many websites you have; this register is that answer, kept current.

SiteAddressOwner rolePlatformLaunchedReview or end dateLast accessibility testStatus
Example: Summer Reading 2027example.gov/readYouth services managerMain platform2027-052027-09 end2027-04Live

Mistakes that keep repeating

Put the rules above into your website governance policy so they survive staff changes, and include the platform requirements in your RFP when you next go to market.

Where We.Inc fits

We.Inc is a white-label website platform: one brand, many sites, managed from one admin area. An organisation can put its own name on it and give each department or programme its own site. What is true today:

Sites are built with AI from templates and prompts, so every site still needs your own accessibility and content review before launch; we do not claim any site conforms to WCAG. To see a brand with several department sites set up, book a demo. The public-sector overview is on our government agencies page.

Sources

Last checked 2026-10-25.

This guide is general information, not legal advice.

Frequently asked questions

When should a department get its own microsite?

When its audience mostly would not visit the main site, it needs a distinct brand for a reason beyond preference, it needs functions the main site cannot provide, or it is a time-limited campaign, and it also has a named owner, meets the same accessibility and security bar, and has budget for running and retiring it.

Should department sites use a subdomain or a subdirectory?

A section of the main site is the default for departments and permanent programmes. Use a subdomain for a distinct application still clearly part of the organisation, and a separate domain only for outside audiences, partnerships or named campaigns.

Can a city get a separate .gov domain for each department?

Generally not. get.gov says organisations generally cannot get more than one .gov domain, including naming variations, so departments usually use sections or subdomains of the main .gov.

How do you retire a microsite safely?

Move content still needed into the main site, redirect every old URL, archive what must be kept, keep the domain registered for a period so nobody else can use it, then revoke access and update the register.

Can We.Inc run many department sites under one brand?

Yes. We.Inc runs many sites under one brand with shared branding, roles, per-site permissions, optional single-step publishing approval, an audit log, custom domains and code export. Each site still needs your own accessibility testing.

More in Guides

Website builders for the businesses in this article

Related guides and tools

Start building

We.Inc is an AI-powered website builder you can resell under your own brand. Launch a branded client dashboard, bill on Stripe Connect, and deliver AI-generated websites in minutes. White-label pricing is tailored to your volume and setup: book a 30-minute demo for a quote.

Product

Who It's For

Features

Resources

Company

View Sitemap