A new site or microsite launch is usually a race against a deadline – design sign-off, content approval, marketing calendar – and compliance is often the last box ticked before the switch flips to live. That’s exactly why a pre-launch compliance checklist matters: it catches the legal and technical gaps that get overlooked when everyone’s focused on shipping, not on cookie banners or SSL certificates.
Launch day pressure creates a predictable pattern. A team spins up a microsite for a product campaign, borrows the parent company’s template, and assumes the compliance elements carry over automatically. They often don’t. Cookie consent tools get misconfigured on new subdomains, privacy policy links point to the wrong document, and nobody checks whether the new site’s SSL certificate was actually issued and installed correctly before go-live.
Why microsites carry more compliance risk than main sites
Microsites and campaign landing pages are frequently built faster and reviewed less thoroughly than the primary domain. They’re treated as temporary or “just marketing,” which leads teams to skip steps they’d never skip on the main site.
Common gaps include:
Missing or copy-pasted privacy policies that reference the wrong company name or data practices.
Cookie consent banners that were never connected to the actual tracking scripts running on the page.
No visible business registration ID, especially on sites created for a specific market or region.
Security headers left at default (or absent) because the microsite runs on a different hosting stack than the main domain.
None of these are hypothetical. A campaign microsite launched without matching the parent domain’s cookie consent configuration will often load third-party trackers before any consent is captured – a technical failure invisible to anyone just glancing at the page.
The pre-launch checklist
Before a new site or microsite goes live, verify each of the following:
1. Legal documents are present and accurate. Privacy policy, terms of service, and any required disclosures should be published, linked from every page footer, and reference the correct legal entity – not a copy-pasted template from another property.
2. Cookie consent functions technically, not just visually. The banner must actually block non-essential scripts until consent is given. Testing this requires checking network requests, not just confirming the banner renders.
3. Business identification is visible. Depending on jurisdiction, this means a business registration number, VAT ID, or company registration details displayed where regulations require them – typically the footer or an imprint/about page.
4. SSL certificate is valid and correctly configured. Check that the certificate covers the exact subdomain, isn’t self-signed or expired, and that mixed content (HTTP resources on an HTTPS page) isn’t breaking the padlock.
5. Security headers are set. Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, and related headers should be configured for the new site specifically, not inherited by assumption from the main domain’s server config.
6. Accessibility statement is published. Even a simple microsite benefits from a basic accessibility statement, particularly if it’s linked from a larger site that already has one – inconsistency between properties draws unwanted scrutiny.
7. Consumer rights notices display correctly. If the site sells anything or collects data tied to consumer protection laws, opt-out and rights information needs to be present and functional, not just mentioned in a policy document nobody reads.
Common misconception: “It’s just a microsite, it doesn’t need full compliance”
This is one of the most persistent myths in web compliance, and it’s wrong. Regulators and courts don’t distinguish between a “real” website and a microsite – if a site collects data, uses cookies, or operates in a regulated market, the same legal obligations apply regardless of how small or temporary the property is meant to be.
In practice, microsites are often riskier precisely because they’re treated as disposable. A campaign page that runs for six weeks can still trigger a GDPR complaint, and a business registration omission on a regional landing page carries the same consequences as one on the main corporate site. Scale doesn’t change the legal requirement, only how much attention the site usually gets.
Building the checklist into the launch process
Making compliance part of the launch workflowThe most reliable approach is to treat compliance verification as a required launch gate, the same way QA or performance testing would be. That means:
Running through the checklist before DNS is pointed to the new site, not after.
Assigning ownership – someone specific confirms each item, rather than assuming “someone” checked it.
Documenting what was verified and when, since audit trails matter if a regulator or customer ever raises a question later. For teams formalizing this, documenting compliance decisions for an audit trail is worth building into the process from day one.
Re-checking after any template or hosting change, since a “quick fix” to styling can silently break a security header configuration.
Mobile versions deserve separate attention here too. Cookie banners, consent mechanisms, and even privacy policy links sometimes render or function differently on mobile templates, so a checklist review should explicitly cover both, echoing patterns seen in mobile versus desktop compliance discrepancies.
FAQ
Does a microsite need its own privacy policy, or can it link to the parent company’s?
It can link to the parent company’s policy as long as that policy accurately describes the data practices of the microsite itself, including any additional trackers or forms unique to that page. If the microsite collects different data or uses different third-party tools, a supplementary notice or updated policy section is needed.
How often should a launched microsite be re-checked after go-live?
Beyond the initial launch check, sites should be reviewed after any content, template, or plugin update, since these changes frequently break cookie consent scripts or security header configurations without any visible symptom on the front end.
What’s the fastest way to check all these items before a tight launch deadline?
Working from a written checklist, such as a comprehensive website compliance checklist, and assigning specific owners to each category (legal, technical, accessibility) prevents items from falling through the cracks when time is short.
A pre-launch checklist doesn’t need to be exhaustive to be effective – it needs to be consistent, applied to every new property regardless of size, and treated as a launch requirement rather than an afterthought. Sites that skip this step tend to discover compliance gaps only after a customer complaint, a regulator inquiry, or a lost sale from a broken checkout disclosure – all of which cost far more to fix than the ten minutes it takes to run through the list before go-live. For teams unsure where basic business details should even appear, reviewing how business ID visibility requirements work is a good starting point before the next site goes out the door.