Schema de eventos: guía práctica para SEO

Cuando alguien busca una conferencia, un webinar o un concierto, Google no lee la página como una persona: intenta extraer un puñado de datos concretos —qué es, cuándo empieza, dónde ocurre, si es presencial u online, si hay entradas disponibles y a qué precio— para poder mostrarlos directamente en el buscador o pasarlos a un asistente. El marcado Event de schema.org, en formato JSON-LD, es el mecanismo para entregar esos datos de forma explícita, en lugar de esperar que un rastreador adivine la fecha a partir de una frase como 'el próximo 15 de septiembre' escondida en el tercer párrafo.

Sin ese marcado, el buscador tiene que inferir la información a partir de texto libre, y esa inferencia falla con más frecuencia de la que parece: confunde la fecha de publicación del artículo con la fecha del evento, no distingue un evento presencial de uno online, o simplemente no reúne suficiente certeza para mostrar nada especial en los resultados. Con las propiedades correctas, esa ambigüedad desaparece y el evento se vuelve elegible para aparecer con fecha, ubicación y disponibilidad directamente en la búsqueda.

A quién le sirve realmente este marcado

El schema de eventos no es útil para cualquier página que mencione una fecha; es útil para quien organiza algo que ocurre en un momento concreto y quiere que ese algo sea encontrable como evento. Los casos claros son los recintos y salas que publican su cartelera, los organizadores de conferencias y ferias, los proveedores de formación que repiten el mismo curso varias veces al año, y cualquier equipo que gestiona webinars o sesiones online recurrentes. También aplica a negocios locales que anuncian catas, talleres o clases periódicas, y a asociaciones que publican jornadas o congresos anuales.

Si tu contenido solo menciona una fecha de forma incidental —un artículo de blog que dice 'lanzamos esta función en marzo'— no es un evento en el sentido de schema.org, y forzar el marcado ahí no ayuda a nadie: añade una entidad Event vacía de sustancia que compite por atención con el marcado que sí importa en el resto del sitio.

Las propiedades que importan y las que casi siempre están mal

El vocabulario de Event tiene decenas de propiedades opcionales, pero solo un puñado determina si el marcado es útil o puramente decorativo. Son también, en este orden, las que con más frecuencia aparecen mal puestas cuando se audita una plantilla de eventos:

• Fechas con zona horaria. `startDate` y, siempre que exista, `endDate` deben ir en formato ISO 8601 con el offset horario incluido, por ejemplo `2026-09-15T19:00:00-06:00`, no solo la fecha sin hora ni la hora sin zona. Un evento sin zona horaria es ambiguo para cualquier persona que no esté en tu misma ciudad, y lo es todavía más para un evento online con asistentes en varios países.
• Ubicación según la modalidad real. Un evento presencial necesita un `Place` con dirección postal completa —calle, ciudad, código postal—, no solo el nombre de la ciudad. Uno online necesita un `VirtualLocation` con la URL de acceso, y `eventAttendanceMode` puesto en `OnlineEventAttendanceMode` (o `MixedEventAttendanceMode` si hay opción híbrida). El error más repetido es marcar un webinar como si tuviera una dirección física, simplemente porque la plantilla de eventos del sitio solo contempla el campo `Place` y nadie añadió la alternativa virtual.
• Offers con disponibilidad y precio real. Si hay entradas, `offers` debe incluir `price`, `priceCurrency` y `availability` (`InStock`, `SoldOut`, `PreOrder`, entre otros). Un evento gratuito también necesita un bloque `offers` con `price` en cero, no la omisión del campo entero: omitirlo comunica 'no sé si hay entradas', no 'es gratis'.
• El estado del evento. `eventStatus` existe precisamente para `EventScheduled`, `EventPostponed`, `EventRescheduled`, `EventCancelled` y `EventMovedOnline` cuando un evento presencial pasa a ser virtual. Casi ningún sitio lo actualiza cuando cambia el plan, así que el buscador sigue mostrando una fecha o una modalidad que ya no es real, semanas después de que el organizador la cambiara en la propia página.

Eventos recurrentes: por qué cada sesión necesita su propia URL

Cuando el mismo taller se repite cada martes, la tentación es tener una única URL y reescribir la fecha cada semana. Es la solución más simple de mantener y la más problemática para SEO: el rastreador indexa una versión de la página con una fecha concreta, y si no vuelve a pasar por ahí antes de la siguiente sesión, sigue mostrando esa fecha caducada en los resultados —o, peor todavía, la muestra para una sesión que ya ocurrió y a la que ya nadie puede apuntarse.

La práctica que funciona es dar una URL propia a cada ocurrencia, al menos a las próximas dentro de un horizonte razonable, cada una con su propio bloque `Event` completo: su fecha, su disponibilidad de entradas, su propio estado si cambia. La página general de la serie —'Taller de fotografía, todos los martes'— puede seguir existiendo como página de entrada al tema, pero funciona mejor como página de navegación hacia las sesiones concretas que como un único evento cuya fecha se reescribe en silencio semana tras semana. schema.org también admite la propiedad `subEvent` para relacionar una página de serie con sus ocurrencias individuales cuando ambas existen como URLs separadas.

El problema del ciclo de vida: la fecha pasa y la página se queda

Aquí está el fallo más común en la práctica, y el que casi nunca se anticipa al montar la plantilla de eventos: una página de evento es correcta durante unas semanas y después queda mal indefinidamente. La fecha pasa, la entrada probablemente ya no está a la venta, y la página sigue en el índice con un `startDate` en el pasado y, muchas veces, con exactamente el mismo marcado que tenía cuando el evento todavía era futuro. Una persona llega desde la búsqueda esperando poder inscribirse a algo que ya sucedió, y eso daña la confianza en el resto del sitio, no solo en esa página.

Esto no se resuelve con una revisión manual ocasional; hay que decidirlo antes de publicar la primera página de evento, como parte del diseño de la plantilla. Hay tres salidas razonables, y la que de verdad no funciona es no elegir ninguna y dejar que la fecha simplemente venza:

• Archivar con un marco de evento pasado. Mantener la URL, pero cambiar visiblemente el encabezado y el texto a pasado ('Este evento tuvo lugar el...'), retirar la oferta de entradas del marcado o marcar su `availability` como agotada, y si el evento no vuelve a repetirse, quitar el bloque `Event` por completo en lugar de dejarlo con una fecha vencida flotando en el JSON-LD.
• Redirigir hacia la siguiente edición. Si el evento es anual o periódico y la página antigua no aporta nada por sí misma una vez pasada la fecha, una redirección 301 hacia la página de la próxima edición mantiene la señal de relevancia acumulada sin arrastrar fechas muertas en el índice.
• Mantener una página de serie permanente. Para formatos muy recurrentes —una clase semanal, un webinar mensual— una página fija que describe el formato y enlaza a las próximas fechas, sin llevar ella misma un único `startDate`, evita el problema por diseño: nunca queda caducada porque nunca afirma una fecha concreta como propia.

Validar el marcado y mantenerlo alineado con lo que ve el usuario

La prueba de resultados enriquecidos detecta errores de sintaxis y propiedades ausentes, pero no detecta el fallo más dañino: que el JSON-LD diga una cosa y la página visible diga otra. Si el marcado indica `EventScheduled` con una fecha, pero el texto de la página ya anuncia que el evento se pospuso, eso no es un error de validación —pasa la prueba sin problema— y es exactamente el tipo de discrepancia que las directrices de datos estructurados señalan como incumplimiento: el marcado debe describir el contenido visible de la página, no una versión alternativa o desactualizada de ese contenido.

En la práctica, esto significa que cualquier cambio de fecha, de modalidad o de estado tiene que tocar dos sitios a la vez: el texto que lee la persona y el bloque `Event` que lee el rastreador. Si tu flujo de publicación permite editar uno sin el otro —por ejemplo, un editor de contenido que cambia el texto visible mientras el JSON-LD lo genera una plantilla que solo lee campos que nadie actualizó— ahí es exactamente donde aparece la discrepancia, no en la sintaxis del JSON. Vale la pena revisar ese flujo de trabajo antes de auditar el marcado en sí: casi siempre el problema no está en cómo se escribe el `Event`, sino en quién es responsable de actualizarlo cuando algo cambia.