Website for business types · 12 Nov 2026 · 6 min read
Event website: what to include and when to put it live
An event website has a deadline built in. This guide covers what attendees need to see, when to launch the site, how to handle registration and what to do with the pages once the event has finished.
The short answer
An event website should state what the event is, when and where it happens, who it is for, how to register and how to contact the organisers. Launch a simple page as soon as the date and place are fixed, add the programme and speakers as they are confirmed, and decide in advance whether the site stays as an archive or points to the next edition.
What an event website needs
An event website exists to get the right people to turn up, informed and registered. It might serve a conference, a festival, a workshop, a fundraiser or a trade fair, and in each case a visitor arrives with the same short list of questions. Answer them in plain text near the top of the page.
| The visitor asks | What to show |
|---|---|
| What is it? | The event name, a one-sentence description and who it is for |
| When is it? | Dates and start and finish times with the time zone; for several days, an outline of each |
| Where is it? | Venue name, address as text, how to arrive and access information; a joining link for online sessions |
| What happens? | The programme, speakers, sessions or activities |
| How do I join? | The registration or ticket route, any deadline and what is included |
| Is it for me? | Audience, level, languages and accessibility |
| What if I need help? | A contact route, a short list of questions and answers, and a code of conduct if you have one |
| Who is behind it? | Organisers, partners and sponsors, used with their permission |
When should the site go live before the event?
As soon as the date and venue are firm enough to publish and you have somewhere for interested people to leave their details. A single page with the basics and an email sign-up is far better than a full site that arrives late. Build up from there as information is confirmed.
| Stage | What the site shows | Note |
|---|---|---|
| Announcement | Name, dates, place, audience, email sign-up | One page is enough |
| Calls for speakers, exhibitors or volunteers | A form, the selection process and the dates involved | Publish the deadlines to avoid confusion |
| Programme released | Schedule, speakers, venue details | Mark gaps as to be confirmed instead of leaving blanks |
| Registration open | Tickets or registration, questions and answers, travel and stay information | Test the whole process before announcing it |
| Final weeks | Practical details and any changes | Use a dated banner for updates |
| Event days | Live schedule, maps, a help contact | Keep pages light, because signal at venues can be poor |
| Afterwards | Thanks, recordings, photographs, next date | See the section on what happens to the site |
The right timing depends on the size of the event, how far people travel and how long registration takes. Events with an international audience need to publish earlier, because attendees may have to arrange travel and permission to enter the country.
Registration, tickets and bookings
Decide first whether to use your own form or a booking system. A form suits a small free event. A booking system suits anything with limited places, several ticket types or payments, because it can count places, send confirmations and issue tickets. The guide to choosing an online booking system lists what to compare.
Collect only what you need, and add a field for access or dietary needs if they affect arrangements. Say what is included in a ticket, state the refund or transfer terms in plain words and show whether prices include sales tax or VAT, where local rules ask for it. Show a waiting list when places run out rather than a dead button. Payments should go through your payment provider's own secure page. After registration, send a confirmation that repeats the date, time, place and how to get help.
Programme, speakers and venue pages
Publish the programme as a web page, and not just as a PDF, so it can be read on a phone and updated quickly. For a long programme, allow filtering by day or track. State the time zone, and for hybrid or online sessions show times in the visitor's own zone where the tool allows it. Add a ‘last updated’ note so attendees know which version they are looking at.
Give each speaker a photograph, a short biography and the sessions they take part in. For the venue, give the address as text, a link to a map, public transport and parking, step-free routes and the nearest places to stay. Where visitors come from other countries, link to the official government source for entry rules instead of summarising them yourself, since requirements change.
Keeping the site fast when attention peaks
Traffic to an event site is uneven. It spikes after an announcement, when tickets open and on the day itself, and many visitors will be on phones with a weak signal. Compress images, avoid heavy autoplay video, and test the site on a mobile connection. The guide to checking and improving website speed shows how to measure and fix the common causes.
Google's Core Web Vitals are a set of measures of loading, responsiveness and visual stability, and the guide to Core Web Vitals explains what each one means. Ask your host how the site will cope with a short burst of traffic before the registration date, and plan for it.
Event information in search results
Google documents event structured data, a way of describing an event's name, start date and location in the page code, and offers a Rich Results Test for checking markup. The rules for which events qualify have changed in the past, including for online events, so check the current documentation before relying on it. Markup does not promise that a listing will appear.
Whether or not you use markup, put the event name, city and year in the page title and use one stable address for a recurring event, such as one page that is updated each year, with earlier editions kept under their own addresses.
What happens to the site after the event?
Decide this before launch. Leaving the site untouched after the final day invites confusion, and deleting it loses a page that people may still search for.
| Option | Use it when | Notes |
|---|---|---|
| Keep it as an archive | The content has lasting value, such as recordings, slides and photographs | Add a clear line that the event has taken place and remove registration buttons |
| Point it to the next edition | The event recurs | Reuse the same address, or redirect the old one to the new page |
| Replace it with a thank-you page and sign-up | The event was a one-off, but the audience may return | Offer an email list for future news |
| Take it down | The event has no further value to attendees | Redirect to a relevant page, never leave an error |
Delete or archive attendee data according to your privacy policy and local rules. Keep the domain registered and the hosting paid for as long as you want the address to work, and see the guide to domain name, website and hosting to know which renewals matter. Decide at the start whether the event gets its own domain or a page on an existing site. A separate domain suits an event with its own brand and a long life, and a page on your main site is simpler for a one-off.
Briefing a developer
Gather the event name, dates, venue, a draft programme, registration needs, brand materials, a list of who will update the site and the date by which it must be live. Say whether the event is one-off or recurring, because that changes the right setup. The guide on how to write a website brief for a developer shows how to put it on paper.
If you want a site built to a fixed date, Liftup Technologies offers website development and will need the content list and the launch date in the brief.
Related guides
- Website development
- Domain name vs website vs hosting
- How to check and improve website speed
- How to write a website brief for a developer
- Online booking system for a website how to choose
- Nonprofit website what it needs
Questions and answers
What should an event website include?
It should state what the event is, the dates and times with the time zone, the venue or online link, the programme, how to register, who it is for and how to get help. Add speaker pages, travel and access information and a short list of questions and answers.
When should the site go live before the event?
As soon as the date and place are firm enough to publish and you can collect interested people's contact details. Start with one simple page, then add the programme, speakers and registration as they are confirmed. Events that draw international audiences need to publish earlier so people can plan travel.
What happens to the site after the event?
Choose one of four routes: keep it as an archive, point it to the next edition, replace it with a thank-you page and sign-up, or take it down with a redirect. Remove registration buttons, handle attendee data under your privacy policy and keep the domain renewed if the address should keep working.
Do I need a separate domain for my event?
Not always. A page on your existing site is simpler for a one-off event and benefits from your existing audience. A separate domain suits an event with its own brand and a long life, such as an annual conference. Choose before you print or share addresses.
How do I handle schedule changes?
Update the programme page first, add a dated notice at the top and email registered attendees if the change affects them. Keep a last updated note on the schedule so people know which version they see. Avoid pop-ups that cover the page.
How do I make the site work for people travelling from other countries?
State the time zone on every date, link to official government sources for entry rules, offer information in the languages your audience uses and show whether prices include sales tax or VAT where required. Make sure the site works on a slow mobile connection.
Tell us what you are building.
A short call, a written plan and a fixed quote. No obligation.