Is your event website still working for you next year?

Why an event website compounds

Brand searches add up. A conference that runs every year gets searched by name all year: "[event name] 2027 dates", "[event name] speakers", "[event name] tickets". Those searches are the clearest signal you have that people want to come back, and they land on whatever page has answered them before.

Links add up. Speakers, sponsors, partner associations and media link to the event. A link earned in 2026 still counts in 2027 if it points to an address that still exists and still talks about the event.

AI answers draw on the same things. Assistants such as ChatGPT, Claude, Perplexity and Google's AI features answer event questions from pages they can read. A site that states the facts plainly, keeps them consistent and is linked from elsewhere gives them a source for your event's dates, venue and price. If they cannot read it, they fall back on a listing site, an old press release, or nothing at all.

The common thread is the same address, readable by machines, saying the same facts consistently.

Step one: look at your site the way a crawler does

Open your event's home page, then use your browser's View page source (not "Inspect", which shows the page after scripts have run). Search the source for your event's date, the venue, a ticket price and one speaker's name.

If they are there, crawlers can read them. If the source is mostly script tags and a line such as "You need to enable JavaScript to run this app", the facts only exist after the browser runs the page's code.

That matters more than it used to. Google renders JavaScript, so Google Search usually still finds the content. AI crawlers mostly do not: a study of traffic across Vercel's network found that "none of the major AI crawlers currently render JavaScript", naming OpenAI's GPTBot, Anthropic's ClaudeBot and PerplexityBot among them (Vercel and MERJ, December 2024). Its first recommendation was to server-render critical content. For those crawlers, a page built only in the browser is a page with no event on it.

Eight things to check

1. One address, kept from edition to edition. Use the same address for the event every year and keep past editions reachable from it, as an archive page or a "previous years" section, rather than deleting them. If the address has to change, redirect the old one to the new one with a permanent (301) redirect, so the links and searches it collected carry over.

2. The facts are in the page text. Dates, city and venue, who the event is for, ticket types and prices, the agenda headlines and the speakers should all appear in the HTML the server sends, not only after scripts run. This is the single biggest difference between a site AI assistants can quote and one they cannot.

Some sites also publish a plain-text summary for AI tools at /llms.txt. It is a proposed convention rather than a standard (llmstxt.org), and there is no guarantee that a given assistant reads it. For an event it costs little: the dates, venue, prices, agenda, speakers and FAQ in one file.

3. Event structured data, filled in properly. Structured data is a block of machine-readable facts in the page, using the schema.org vocabulary. For an event, Google's documentation lists four required properties (name, startDate, location and its address) and recommends more, including endDate, eventStatus, image, offers with price, currency and the date sales open, organizer with name and website, and performer (Google Search Central).

Two of those are often missing or wrong on event platforms:

• organizer should be you, the organiser, with your own website, not the platform you registered through.
• performer is where speakers belong. When someone asks an assistant "who is speaking at …?", this is the field that answers.

Sessions can go in as subEvent items with their own time, room and speakers. Three more fields matter for events in particular:

• sponsor: sponsors want the exposure, and "who sponsors …?" is a question assistants get asked.
• eventAttendanceMode: in person, online or mixed. A hybrid event marked as in person only can be left out of answers about events people can join online.
• location: the venue's name, with the street address, city and country as separate fields, and the hall or room kept apart from the venue name. Questions such as "conferences in Singapore in March" turn on city and country, and a venue name buried in the street line does not help.

One caveat: Google's dedicated event search experience is only available in certain countries and languages, and Google does not promise to show it even then. Structured data is still worth doing everywhere, because it is the cleanest way to state the facts for any machine that reads the page.

4. Every page has its own title, and the title carries your name. Agenda, speakers, venue and FAQ pages should each have their own title and declare themselves as the canonical (preferred) address. When every page claims to be the home page, search engines treat them as duplicates and show only one.

Look at what follows the event name in the title and in the share card's site name. If it is the platform's brand, every search result and every shared link advertises the platform. It should be your name, as in "Payments Summit 2027 · [your organisation]", or the event name alone. That is where the brand reach of a well-run event site goes.

5. A share image. When someone pastes your link into LinkedIn, WhatsApp, Slack or an email, the preview comes from Open Graph tags. Without an og:image the preview is a single line of text. Set a share image (a cover image, or a card with the event name, date and city) and use the large card format, so the link looks like an event and not a footnote.

6. A sitemap, and private pages kept out. Public pages (home, agenda, every speaker, venue, FAQ) should be listed in a sitemap. Pages that belong to one person (their ticket, their schedule, their account) should carry a noindex tag and stay out of the sitemap. Blocking them in robots.txt as well keeps crawlers away, but robots.txt on its own only stops crawling, not indexing: a blocked address that is linked from somewhere can still turn up in results.

7. Language versions linked to each other. If the event runs in more than one language, each version should point to the others with hreflang tags. Otherwise search engines may show the wrong language, or treat translations as duplicates.

8. An FAQ written in the attendee's words. "Is there parking?", "Can I transfer my ticket?", "Is lunch included?", "What is the refund policy?" Short questions with short, specific answers are exactly what assistants lift into their replies. Write them once and keep them consistent with the rest of the site. Marking them up as FAQPage states each question and answer plainly for machines, though Google itself has shown FAQ rich results only for a small set of authoritative sites since 2023, so do not expect the questions to appear under your search result.

Where AI gets events wrong, and how to prevent it

The usual failure is not an invented event but mixed sources: last year's date with this year's venue, an early-bird price that has expired, a speaker who withdrew. The fix is unglamorous:

• State the key facts (dates, venue, price range, who it is for, refund policy) once, in plain sentences, on a page that crawlers can read.
• Keep them the same everywhere: home page, structured data, FAQ, social posts.
• When something changes, change it at the source and leave a dated note ("Moved to Hall B on 3 March") rather than silently editing.
• Tell search engines when it changes. IndexNow lets a site notify Bing and several other search engines as soon as a page changes, instead of waiting for the next crawl (indexnow.org). Google does not take part, but its crawler revisits pages that change often.
• Let removed pages go. A page that no longer exists should return a real 404. A site that answers every unknown address with its home page (a "soft 404") keeps old and mistyped addresses alive in search.

How to tell whether it is working

Compounding is only worth the effort if you can see it.

• Verify the site with Google Search Console and Bing Webmaster Tools. Both accept a short verification tag in the page head, so this works even when the event site sits on your platform's domain, provided the platform lets you add the tag. You then see which searches show your event, how often, and which pages they land on, year after year.
• Count registrations from AI assistants separately. Visits from chatgpt.com, perplexity.ai, gemini.google.com, copilot.microsoft.com and similar sites usually carry that address as the referrer. Grouping them as one channel shows how much of your audience now arrives through an answer rather than a search. Some apps strip the referrer, so treat the figure as a floor, not a total.

What it compounds into

By the third edition, an event site that has kept its address and its facts in order starts each year with:

• brand searches that already land on it,
• links from past speakers, sponsors and media that still count,
• AI assistants that already have a source for the event's basic facts,
• an archive that shows sponsors and speakers the event's track record.

None of that is a marketing campaign. It is the by-product of treating the event website as a long-lived asset rather than a registration form with a countdown on it.

Where bagevent stands

Every event on bagevent gets its own website on a branded address. As of October 2026, each event site:

• sends the event's content in the HTML itself, in the page's language: dates, venue, ticket types and prices, speakers, programme, sponsors and FAQ, so crawlers that do not run JavaScript read the same event that visitors see;
• carries Event structured data with the organiser's name, every speaker as a performer, each session as a subEvent with its room, the sponsors, the price range and when sales open, and whether the event is in person, online or mixed;
• puts the event name and then the organiser's name in the home page title and share card by default, and leads each speaker page's title with the speaker;
• has a share image and large share cards;
• answers unknown addresses with a real 404;
• publishes an /llms.txt with the event's facts;
• lists the home page, the speaker pages and each language version in a sitemap, keeps attendees' own pages out of search with noindex, and links language versions with hreflang;
• tells Bing and the other search engines that take IndexNow when dates, venue, prices, programme or speakers change, once the edits have settled;
• lets the organiser add Google and Bing verification tags in the event's website settings;
• counts registrations that arrive from ChatGPT, Perplexity, Gemini, Copilot, Claude and similar assistants as their own source in the event and organisation reports;
• asks for the city and country when an in-person event's venue is entered.

You can run the View page source test above on any bagevent event site, ours included: summit.bagevent.io.