Keep the same event identifiable when its advertised date changes

Lock the occurrence and supported surface

Google’s Event guidance, checked 7 November 2026, limits its event experience to supported regions and languages and eligible public physical events. For cancellation or postponement with no new date, it retains identifying dates and location while changing status. Once rescheduling is confirmed, the new dates replace the active dates; previousStartDate can preserve the former start. These rules concern this search feature, not every event system.

Start with a single occurrence record and its existing page address. Identify which ticket or attendance commitment it represents. Two separately ticketed performances should not be collapsed into one correction merely because their names match. Confirm the organizer’s decision before translating it into data: considering a new date, postponing indefinitely and approving a replacement date are different states.

Build the transition record before editing

Create columns for previous state, authorized new state, original start, original location, confirmed replacement dates if any and the announcement readers should see. Mark each value as retained, changed or not yet known. Use explicit uncertainty rather than a plausible placeholder date that looks official. Keep the original evidence beside the transition so a later editor can understand why an old date remains in a changed listing.

Draft the reader-facing explanation separately from the machine-readable property changes. The public copy should make clear that the original date is no longer an invitation to attend. Retaining identifying information in structured data does not mean leaving an obsolete attendance instruction prominent and unqualified. Ask the event owner to approve the interpretation, especially when tickets, refunds or venue arrangements are being handled through another organization.

Test each state with a controlled occurrence

Use fictional fixtures for cancellation, postponement without a replacement and confirmed rescheduling. Compare the rendered announcement with the generated Event object for the same occurrence. Check that a template does not erase identity-bearing values whenever status stops being scheduled, or invent a new date merely because its publishing form requires one.

Then test the transition from unknown replacement to confirmed replacement. The accepted artifact should show which fields changed at that point and why. Check that a second performance was not accidentally updated through a shared title or copied content block. Do not reuse a cancellation fixture as a rescheduling fixture without resetting its evidence, since mixed test data can create a combination no organizer actually authorized.

Keep downstream observations separate from acceptance

Provide the implementation owner with the transition table, generated output and mismatches. A syntax validator can identify malformed data, but it cannot establish whether the organizer actually confirmed the new date. Conversely, an accurate announcement does not prove the template generated the intended status. Both factual authorization and implementation evidence belong in the acceptance record.

After an authorized release, distinguish the current source page from previously observed search displays. A correct transition cannot guarantee immediate recrawling or a particular presentation. Record the time of the source correction and route persistent discrepancies to the responsible owner. Keep refund communication, ticket replacement and attendee outreach outside this technical exercise unless separately approved; the table authorizes none of those commitments.

Make the reasoning concrete.

A fictional public exhibition is postponed while the organizer seeks another date. Its CMS proposes deleting the original start field and substituting the first day of next month to satisfy a required input.

The editor rejects the invented date. A separate rescheduling fixture is prepared only after a fictional organizer approval supplies confirmed replacement dates, keeping the unknown-date and known-date transitions distinct.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Occurrence

   Which existing event and ticketed performance is changing?

2. Authority

   What exact state has the organizer confirmed?

3. Retention

   Which identity-bearing values remain from the original listing?

4. Replacement

   Which new dates are confirmed rather than guessed?

5. Output

   Do the announcement and generated object express the same transition?

Watch for the wrong conclusion.

• Deleting identifying dates whenever an event stops being scheduled.
• Publishing a placeholder date as a confirmed replacement.
• Applying one occurrence’s change to every similarly named performance.

Sources & scope

Workflows, fixtures, worksheets and examples are original editorial analysis. Sources support the narrow attributed statements, not measured business results. Platform guidance is scoped to the documented implementation and date checked.

• Event (Event) structured data →Primary Google technical documentation · Supports: Supports the narrowly scoped eligibility and status-transition facts in section one. The transition table and fixtures are original; no event decision or external action is performed.