The calendar had already learned to show one concert when Ticketmaster and SeatGeek both listed it. On November 13, 2026, its event sitemap was still offering 3,255 individual listing URLs.
Inside the application, those records belonged to groups representing real shows. Outside it, each provider listing had its own page and declared its own address as canonical. The display had absorbed the grouping decision. The pages offered to crawlers had not.
I had two representations of the same calendar, and they disagreed about how many things it contained.
An event group preserves the useful differences between listings. Providers can have different titles, prices, ticket links, and identifiers for the same concert. Keeping those records makes it possible to retain their information while displaying a single show. Each group also identifies a primary listing.
That primary already existed in the data. The repair was to carry its identity through the other places where the site described an event.
Before using it more widely, I checked the relationships it depended on. Every group had exactly one member marked primary. That member agreed with the group’s separate primary-event reference. Members of each group shared the event date.
Those checks mattered because the change would make other pages defer to the selected listing. A missing primary or contradictory reference would turn a display inconsistency into an address problem. The audit established that the existing groups could support the change without another round of matching or merging.
I then added a shared lookup for the preferred event slug, the readable part of its address. For a secondary listing, it finds the group’s primary listing and returns that listing’s slug. A page that stands on its own keeps its own address.
The event renderer uses that result in three places: the canonical link, the event URL inside its structured data, and the Open Graph URL supplied for link previews. All three receive the same resolved address.
The provider pages remain available. Following an older link can still reach the listing it originally identified. The metadata now carries the group’s choice of preferred address without requiring the underlying provider records to disappear.
The sitemap uses the same lookup to select active, upcoming listings with their own preferred addresses. Its index also uses that selection when calculating the event count and latest modification time. That keeps the sitemap’s summary and its contents attached to the same rule.
There is an important exception to following the primary: it has to remain a usable destination for the active listing.
Suppose the group’s primary has become inactive while a secondary provider still carries the show as active. Automatically deferring to the old primary would suppress the active listing from the sitemap. I kept that listing’s own canonical address and sitemap entry. The lookup also requires a primary with an actual slug before returning a replacement address.
The count after the change made that exception visible. The sitemap went from 3,255 event URLs to 2,076. Of those, 2,051 were group primaries, 18 were ungrouped listings, and seven were active listings whose primaries had gone inactive.
Those numbers describe the inventory at the time of the repair. Dates pass, listings arrive, and provider statuses change, so the count will move. The composition was useful evidence: it accounted for the surviving URLs instead of treating the smaller total as sufficient verification.
I also checked the public output using a Googlebot user agent. An OCT On Company Time duplicate in Anaheim pointed its canonical at the group primary and no longer appeared in the sitemap. An UnLoco listing exercised the inactive-primary exception: it retained its own canonical and its sitemap slot.
The verification followed both branches all the way to the published pages. One duplicate deferred to the shared event address. One active exception remained discoverable at its own. The calendar’s grouping decision was finally present in the HTML and sitemap it served.