Recurring events wreck your sitemap — the canonical-date dedup fix

If you run an events site, recurring events are a quiet SEO landmine. A single weekly trivia night, encoded naively, can become dozens of near-identical URLs that Google flags as duplicate or low-value — and they drag the rest of your site down with them. We had 532 of these on one product. Here is how the cleanup worked.

How recurring events explode your URL space

An event has a date. A recurring event has many dates. The naive model generates one URL per occurrence: the same trivia night, the same description, the same venue, at a different dated URL every single week, forever into the future and the past.

To a search crawler these look like dozens of pages that are 95 percent identical — same title, same body, same everything except a date. That is the textbook definition of duplicate content. Multiply across every recurring event on the site and you have hundreds of near-dupes competing with each other and diluting the authority of your genuinely unique pages.

On the product in question, this produced 532 occurrence URLs where a few dozen distinct events would have been the honest count.

The symptom in Search Console

The tell was a spike in "Excluded by noindex" and duplicate-content signals in Google Search Console. Google was finding all these occurrence pages, recognizing they were substantially the same, and declining to index most of them — while still spending crawl budget discovering them. The site looked, to Google, like it was padding its page count with reruns.

The fix: a canonical page per event, dated views deduped

The model we moved to: each distinct event has ONE canonical page. Individual dated occurrences either do not get their own indexable URL at all, or they point a canonical link back to the single event page. The recurring schedule lives on the canonical page (every Tuesday, 7pm) instead of being exploded into one page per Tuesday.

We kept a canonical dated view where it genuinely helps a user — someone linking to a specific night — but those views declare the main event page as their canonical, so search engines consolidate all the signal onto one URL instead of splitting it across fifty.

The sitemap result: the recurring-event URLs collapsed from 532 to 98 — the actual number of distinct, indexable events plus the handful of dated views worth surfacing. Every remaining URL is something a person would actually search for.

Where the dedup has to live

An important detail: the dedup belongs in the sitemap-generation and canonical logic, and ideally upstream in how occurrences are stored, not bolted on as an afterthought. If your scraper or importer creates a row per occurrence, the explosion starts at the data layer and every downstream surface inherits it. Collapsing recurring events to one event plus a recurrence rule at ingest is the cleanest fix; canonical tags are the safety net when you cannot change ingest.

What I would tell another team

The change took an events site from looking like a duplicate-content farm to looking like what it is: a few dozen real events, each with one clean page. 532 to 98, no events lost.

If your events calendar is quietly generating reruns Google hates, [we have done this cleanup before](https://bluewaveprojects.com/booking).

More from BlueWave