How to Do SEO for Event Pages

Event-page SEO can fail when each event is treated as disposable: a fresh URL every year, optimized in the run-up to the date, then abandoned. That can throw away what the event page accumulated. The better model is the event as a franchise: one permanent URL holds the event’s identity year after year, collecting links and history while you update it for each edition. Archive pages preserve past editions, correct Event structured data makes the page eligible for Google’s event features, early publication gives it time to be found, and post-event content keeps it useful between cycles.

A recurring event is a long-lived asset, not a series of one-offs. Once you see it that way, the tactical decisions follow.

Franchise versus instance

Take an annual conference. The instance approach gives it a new URL each year, /techsummit-2025/ and then /techsummit-2026/, each starting from nothing and competing with last year’s page for the same brand search. The franchise approach gives it one permanent home, /techsummit/, updated every year. Every media mention and link points at that single URL.

Pair the permanent URL with archive pages. When an edition ends, move its specifics to a dated archive page, such as /techsummit/2025/, which answers searches about that year (speakers, recap, photos) and links back to the main page. The main URL stays focused on the next or current edition; the archives catch searches about past editions.

Event structured data, by Google’s current documentation

Mark up the page with Event structured data so it can be eligible for Google’s event experiences. Google’s Event structured data documentation lists three required properties:

• name: the full title of the event. The documentation says not to put the venue name here; use location.name for that.
• startDate: the start date and time in ISO 8601 format. Add both date and time, and include the UTC offset. The documentation notes that if no timezone is given, Google uses the timezone of the event’s location.
• location: a Place, with location.name and a detailed street address in location.address.

It then lists recommended properties, such as a description of the specific event, and asks that the description focus on the event itself rather than repeating the date and location, which belong in their own properties.

Validate the markup in the Rich Results Test before and after publishing, and again whenever dates or the venue change.

Keep the markup honest when plans change

Events get cancelled, postponed and moved. The Event documentation says how to handle each with the eventStatus property:

• Cancelled: set eventStatus to EventCancelled, and don’t remove or change other properties such as startDate or location.
• Postponed, new date unknown: set eventStatus to EventPostponed, again keeping the other values as they were.
• Rescheduled: once the new date is known, set eventStatus to EventRescheduled and update startDate and endDate. You can add previousStartDate to record the old date; if you do, eventStatus must be EventRescheduled.

A page whose markup still shows last month’s date as scheduled misleads both readers and search features. Updating eventStatus the day a plan changes is part of running the page.

Publish early, update in steps

As soon as the date and venue are confirmed, publish the page with those basics. You don’t need the full agenda to go live; you need the page to exist and be found while competitors may still have a placeholder. Each later confirmation, speakers, schedule, ticket tiers, is an update to the same page.

This matters for time-bound searches in particular. A search that combines your category with a year or season can only be matched by a page that already exists and already names those dates.

The searches to cover

Event searches fall into three groups, and one franchise page plus its archives can serve them all:

• Branded: the event’s name and variants. The franchise URL should own these.
• Category plus place: “marketing conference in Austin.” Clear location information on the page and in the markup supports these.
• Category plus time: “tech conferences spring 2026.” These reward early publication, because the page has to name the dates before it can match.

Working with the aggregators

Large event platforms and listing sites compete for broad terms with a breadth of listings a single event can’t match. Rather than meeting them head-on, go more specific. Your page can carry what theirs can’t: the real agenda, speaker detail, venue logistics and context for your exact audience.

Then use them. List the event on relevant platforms and, where they allow it, link those listings to your franchise URL. Give the aggregators a concise, factual summary, and keep the depth, full agenda, speaker bios, venue detail and registration specifics, for your own page, so yours is clearly the richer destination for anyone researching the event, and the platforms don’t carry a copy of your page.

After the event

The work doesn’t stop when the doors close. Publish recaps, session recordings, slides and key takeaways on or linked from the franchise page. Searches for recordings, slides and “what was announced at” the event may arrive afterward, and a page that holds that content can keep answering them after the event.

For a recurring event, keep the franchise page describing the upcoming edition in its markup, and move to the next confirmed date when one edition ends. A page still advertising a date that has passed misleads readers who land on it.

Keep events as sections of one domain. A separate domain per event splits the links and history the franchise model is meant to gather.

Frequently asked questions

Should I create a new URL for each year’s event?

No. Use one permanent URL updated each year, and move each edition’s specifics to dated archive pages that link back to it.

Which Event schema properties are required?

Google’s Event documentation lists name, startDate and location as required, with location as a Place that includes a name and a detailed address. Include a UTC offset in startDate, add recommended properties such as a description, and validate in the Rich Results Test.

What do I change in the markup if the event is postponed?

Set eventStatus to EventPostponed and leave the other properties as they were. When the new date is known, switch to EventRescheduled and update startDate and endDate, optionally adding previousStartDate.