Most event sites start life as a flyer. Someone exports the poster, adds a ticket link, and calls it done. When I built the Great Lakes Cigar Festival site, I wanted a WordPress event website that answered the questions people actually ask before they buy a ticket, and then I wanted proof they used it. This post covers both halves: how I structured the site, and what I watched in GA4 afterward.
Start with the questions, not the pages
Before I opened WordPress I wrote down what a visitor wants to know. When is it. Where is it. How much. Who will be there. Can I park. That list is short, and it should be. Every page on the site had to earn its place by answering one of those.
The trap with festivals is the PDF. Organizers love a nicely designed vendor list or schedule as a PDF because the designer already made it. On a phone it is miserable. You pinch, you zoom, you lose your place. Search engines barely read it. So the first rule I set was simple: if it is information people need, it lives as real text on a real page.
What should an event website include?
This is the question I see people search most, and my answer is shorter than the long checklists out there. For a one or two day event, you need these:
- A home page with the date, the location and a ticket button above the fold.
- A tickets page that explains each ticket type in plain words and links straight to checkout.
- A schedule page written as text, broken up by day and time.
- A vendors page with names, a line about each, and a link out when they have a site.
- A sponsors section that gives sponsors visible credit without burying the ticket button.
- Location and parking details, with a map link that opens the phone’s map app.
- An FAQ for the questions the organizers kept answering by email.
That’s it. Blog sections, photo galleries from five years ago, long history pages: those can come later if someone wants them. They should not sit between a visitor and the ticket.
How I built it in WordPress
I kept the build plain on purpose. A clean theme, a page builder for layout, and as few plugins as I could get away with. Every plugin is something that can break on update day, so each one has to justify itself.
For tickets, you have two routes. You can sell inside WordPress with an event ticketing plugin, or you can link out to a ticketing platform. Selling inside WordPress keeps people on your domain. Linking out is less to maintain and the platform handles refunds and scanning at the gate. For a festival run by a small team, linking out is often the saner choice. Whatever you pick, make the ticket button the same everywhere: same label, same color, same destination.
The schedule and vendor list were the pages that changed the most as the date got closer. I set them up so the organizers could edit text blocks without touching the layout. If a vendor drops out on Thursday, someone should be able to fix the page in two minutes from a laptop. If updating the site needs me every time, the site will go stale.
Sponsors were a balancing act. They paid, so they deserve real visibility. But a wall of logos at the top of the home page pushes the date and ticket button down. I gave them a dedicated block lower on the home page and a sponsors page, and linked each logo to the sponsor’s site.
How do you track event ticket clicks in GA4?
Launching the site is half the job. The other half is finding out if people used it the way you planned. I’m not going to quote numbers here, but I’ll tell you exactly what I looked at, because these checks work on any event site.
If tickets are sold on another platform, GA4 will not see the purchase by default. What it can see is the click. GA4’s enhanced measurement tracks outbound clicks automatically, so a click on a ticket link that goes to another domain shows up as a click event with the link URL attached. Go to Reports, then Engagement, then Events, open the click event, and look at the link URL dimension. That tells you how many sessions reached the ticket platform.
If you want something cleaner, mark the ticket button with a class and set up a custom event in Google Tag Manager, something like ticket_click. Then mark it as a key event in GA4. Now you can compare ticket clicks by source and by device without digging through every outbound link.
Other reports I checked:
- Pages and screens. Which pages got attention. If the schedule page gets more views than the home page, people are coming back to plan their day, and that page should be easy to reach.
- Tech, by device category. For events, phone traffic tends to dominate, especially close to the date. If that is true for you, test every page on a phone before anything else.
- Traffic acquisition. Where visitors come from. If social posts drive most visits, the landing page for those posts matters more than anything in the menu.
- Path exploration. In the Explore section, start from the home page and see where people go next. If they bounce between vendors and schedule and never hit tickets, the ticket button is not where they expect it.
Search Console is worth a look too. The queries tab shows what people typed to find the site. When the festival name plus “parking” or “tickets” shows up, that is a page or FAQ answer you should have.
What I’d tell any event organizer
Keep it boring and fast. People visiting an event site are trying to make a decision, usually on their phone, often the week of. They do not need animation. They need the date, the price and a button.
Give the organizers edit access to the parts that change. The schedule and vendor list will change. Plan for that on day one.
And set up the ticket click tracking before you announce anything. Once the promo posts go out, the traffic you care about arrives in a burst. If tracking is not live by then, you will never get that data back.
So here is the takeaway: before launch, open the site on your phone, find the ticket button within five seconds, click it, then confirm the click shows up in GA4’s realtime report. If all three work, you are ready to promote.