Web · Event websites
The event microsite checklist: what to launch eight weeks out
A site that grows with the programme
Eight weeks before an event, an event microsite should already be live with the essentials: the name, date, venue, a short reason to attend, working registration and a privacy notice. Agenda, speakers, travel details and on-the-day information can follow in stages. Launching early with less beats launching late with everything, for Copenhagen events and anywhere else.
The timeline
Why launch eight weeks before the event?
Eight weeks is roughly the point at which invitees start making real decisions. Busy professionals fill their calendars weeks ahead, travellers need time to book flights and hotels, and managers may need to approve attendance. For a conference, a product launch or a large corporate party in Copenhagen, a site that appears three weeks out arrives after many people have already said no to something else that day.
There is a practical reason too. A microsite that goes live early gives you time to find problems while the stakes are low: a broken form, a confusing ticket type, an email that lands in spam. Fixing those with 50 registrations is easy. Fixing them with 500 is not.
For smaller internal events, four to six weeks can be enough. For international conferences or events where guests fly in, ten to twelve weeks is safer. Eight is a sensible default for most corporate events.
What must be live on launch day?
The launch version should be short, accurate and complete in the things it does say. Nothing on it should need correcting a week later.
- Event name, date and time, including the time zone if guests come from abroad.
- Venue and city, even if the room is not yet confirmed. “Central Copenhagen, venue announced in March” is better than nothing.
- Why attend, in two or three sentences. Who it is for and what they will get from it.
- Registration or ticketing that works on a phone, with a clear statement of price or that attendance is free.
- Organiser details and a contact address for questions.
- Privacy notice and cookie consent that reflect what you actually collect and track.
- Sharing basics: a page title, description and preview image so links look right on LinkedIn and in email.
- An “add to calendar” file so the date goes straight into Outlook or Google Calendar.
Choose the address early, too. A subdomain or a short path on your main domain is often easier to manage and trust than a new domain bought for one event. Our event and campaign microsites page explains how we decide between them.
How should registration and guest data be handled?
Registration is the part of the site that has to be flawless. It is also where most legal obligations sit.
- Ask only for what you need. Name, email and company are often enough. Dietary requirements and accessibility needs can be collected later, closer to the date.
- Be clear about purpose. Under GDPR, guests should know why you collect each piece of information and how long you keep it. Dietary and health information needs particular care.
- Separate marketing consent. Agreeing to attend is not agreeing to a newsletter. Use a separate, unticked checkbox if you want permission for future marketing.
- Test confirmation emails. Send them to Gmail, Outlook and a corporate address. Check that they arrive, are not marked as spam and contain the date, place and a way to cancel.
- Plan capacity. Decide what happens when places run out: a waiting list, a closed form or a message to contact the organiser.
Dedicated ticketing platforms, including Billetto and Eventbrite which are widely used in Denmark, handle payments and capacity well. A simple form is often better for free invitation-only events, where a branded experience matters more than ticket sales.
What gets added in weeks six to three?
This is the period for building interest. Plan the content in waves, and treat each new piece as a reason to send a short reminder to invitees who have not yet registered.
| When | Add to the site | Use it for |
|---|---|---|
| Week 6 | Speakers or performers, with photos and short bios | First reminder email and social posts |
| Week 5 | Draft agenda with session times | Helping people justify the day to their manager |
| Week 4 | Venue details, map, travel and accommodation | Guests travelling from outside Copenhagen |
| Week 3 | FAQ: dress code, accessibility, food, parking | Reducing emails to the organiser |
Travel information deserves real attention for Copenhagen events. Guests from abroad want to know how to get from the airport, which is a short Metro ride from the city centre, whether the venue is near a Metro or S-train station, and where to stay. Danish guests will want to know about parking and bicycle access. Write this once, carefully, and link to it from the confirmation email.
Keep an eye on the numbers during this period. Registrations per week, the share of invitees who opened each reminder and the pages people visit before registering tell you whether the event is on track. If sign-ups stall in week four, there is still time to change the message, extend an early-bird price or ask speakers to share the link. In week one, there is not. Make sure analytics and the registration count are visible to the whole event team, not only to whoever built the site.
What needs to happen in the final fortnight?
In the last two weeks, the site changes from a marketing tool into a practical guide for people who are coming.
- Lock the agenda and mark any late changes clearly rather than silently editing times.
- Publish arrival information: entrance, check-in times, cloakroom, Wi-Fi and who to call if lost.
- Prepare the day-of page. A simple mobile page with the running order, room names and a map works better than a downloadable PDF.
- Test check-in. If guests show a QR code from their confirmation, test scanning it at the venue with the actual devices and network.
- Check load and uptime. Reminder emails sent to everyone at once can bring a spike in traffic. Make sure the hosting copes.
- Agree who can edit the site on the day, and how fast a change can be published.
The site and the event run on the same timetable, so the people building the site should be in the production schedule. When we handle full event production, the microsite is planned alongside the run sheet for exactly this reason.
What happens to the microsite after the event?
Decide this before launch, not after. The usual options:
- Turn it into a recap. Replace registration with photos, a short film and presentation downloads. This works well for annual events, where next year’s guests will look at last year’s.
- Redirect it. Point the address to a relevant page on your main site so links in old emails and posts still go somewhere useful.
- Keep it for next year. A recurring event benefits from a stable address that builds up links and search visibility over time.
Whichever you choose, deal with the registration data. Delete or anonymise what you no longer need, keep only what guests agreed to, and close forms so nobody registers for an event that has passed. Then send a thank-you email with a link to the recap while the day is still fresh in people’s minds.
Planning questions
Getting an event site
live on time
A single page on your main site is enough for small, simple events with one session and a short guest list. A separate microsite becomes worthwhile once you have several sessions, speakers, ticket types, travel information or partners who need visibility. It also helps when the event has its own visual identity, or when the main site’s navigation, menus and approval processes would get in the way. A sensible middle option is a small section on your existing domain, such as a subdomain, with its own design and navigation. That keeps the trust of your main brand while letting the event team move quickly.
A focused microsite with registration can usually be ready in two to four weeks, provided the content and decisions are available. The design and build are rarely the slow part. Waiting for the date, venue, ticket prices, speaker approvals and privacy wording is what delays launches. To hit an eight-week launch, start the site roughly ten to twelve weeks before the event, with a short brief and the essential facts confirmed. Sites that need payment integration, several languages or custom check-in tools take longer, so mention those requirements at the very start of the conversation.
Yes, but treat it with care, because allergy and some dietary information can reveal health or religious details that GDPR protects more strictly. Only ask if catering genuinely needs it, explain why on the form, and get the guest’s explicit agreement. Limit access to the people who plan the food, share only what the caterer needs, and delete the information after the event. Many organisers ask a neutral question such as “Do you have any dietary requirements?” with a free text field, rather than a list of conditions. For anything unusual, check with your data protection adviser or the guidance from Datatilsynet, the Danish Data Protection Agency.
Use the language the event itself is held in. If the programme is in English, as many Copenhagen conferences and international company events are, an English site sets the right expectation and serves guests from abroad. If the event is in Danish, a Danish site is more natural, even though most Danes read English well. Two languages make sense when the audience is genuinely mixed, for example a public event with international visitors. Keep both versions equally up to date, because a Danish page with an older agenda than the English one causes confusion. Registration emails should follow the language the guest chose.