- Qué define al evento como tipo de contenido
- Estructura de URLs para eventos
- El problema de la fecha en la URL del evento
- Ciclo de vida del contenido del evento
- Datos estructurados para eventos
- El archivo de eventos: organización del histórico
- Para profundizar
Los eventos son el tipo de contenido web más claramente temporal. Un evento tiene fecha de inicio, fecha de fin y, entre medias, relevancia máxima para su audiencia. Pero esa temporalidad no implica que el contenido deba desaparecer cuando el evento termina: el evento pasado se convierte en registro histórico, en contenido de referencia, en prueba de actividad.
Gestionar bien los eventos como tipo de contenido requiere pensar en su ciclo de vida completo: antes, durante y después.
Qué define al evento como tipo de contenido
Tiene dimensión temporal obligatoria. A diferencia de cualquier otro tipo de contenido, un evento sin fecha no es un evento. La fecha no es un metadato opcional: es parte de la identidad del contenido.
Tiene ubicación. El evento ocurre en algún lugar: físico (una dirección), virtual (una plataforma) o híbrido. La ubicación es parte de la descripción del evento y puede ser relevante para la búsqueda.
Tiene un ciclo de relevancia definido. Antes del evento: máxima relevancia para registro y preparación. Durante: información en tiempo real. Después: contenido de resumen, materiales, grabaciones.
Puede ser recurrente. El mismo evento puede celebrarse anualmente, mensualmente o con cualquier otra periodicidad. La gestión de eventos recurrentes tiene implicaciones específicas en las URLs.
Estructura de URLs para eventos
Eventos únicos
/eventos/nombre-del-evento/
La estructura más simple. Adecuada para eventos que se celebran una sola vez o que no tienen una edición anterior con la que pudieran confundirse.
Eventos recurrentes
Si el mismo evento se celebra periódicamente, hay dos opciones:
Opción A: URL única que siempre apunta a la edición actual
/eventos/nombre-del-evento/ ← siempre la edición actual
/eventos/nombre-del-evento/2023/ ← edición anterior archivada
/eventos/nombre-del-evento/2022/ ← edición anterior archivada
Ventaja: la URL principal es siempre la misma, no acumula el año. Los enlaces externos a la URL principal siempre llevan a la edición actual. Inconveniente: requiere un proceso de archivado explícito con cada nueva edición.
Opción B: URL por edición
/eventos/nombre-del-evento-2024/
/eventos/nombre-del-evento-2023/
/eventos/nombre-del-evento-2022/
Ventaja: cada edición tiene su URL propia desde el principio, sin necesidad de archivado. Inconveniente: no hay una URL “central” del evento; cada edición es un contenido independiente.
Opción C: URL con año como segmento
/eventos/2024/nombre-del-evento/
/eventos/2023/nombre-del-evento/
Esta opción usa el año como nivel de agrupación cronológica. Tiene sentido si el sitio publica muchos eventos y quiere mantenerlos organizados por año en el archivo.
El problema de la fecha en la URL del evento
Los eventos son una de las pocas excepciones donde la fecha en la URL puede tener sentido. A diferencia de un artículo de blog donde la fecha envejece el contenido, en un evento recurrente el año en la URL diferencia ediciones distintas con contenido genuinamente distinto.
Pero hay matices:
- Si el evento solo se celebra una vez, la fecha en la URL no aporta valor.
- Si el evento es anual y cada edición tiene contenido muy distinto (ponentes, programa, lugar), el año en la URL facilita la distinción.
- Si el evento es mensual, el año solo no es suficiente; necesitaría mes y año, lo que produce URLs más largas.
Ciclo de vida del contenido del evento
El contenido de un evento cambia a lo largo de su ciclo de vida. La misma URL debe poder albergar distintos estados:
Estado 1: Anuncio El evento se anuncia antes de que esté completamente definido. La página existe con información básica: fecha, lugar, descripción general. Puede no tener programa ni ponentes confirmados.
Estado 2: Previo al evento Toda la información disponible: programa completo, ponentes, lugar detallado, precios, enlace de registro. Es el estado de máxima densidad informativa.
Estado 3: En curso Si el evento tiene varios días, puede ser relevante añadir actualizaciones en tiempo real: resúmenes de jornada, fotos, cambios de programa.
Estado 4: Post-evento El evento ha terminado. La página debe actualizarse: fotos, vídeos de las ponencias, materiales descargables, resumen. La fecha de registro ya no es relevante; en su lugar, los contenidos generados por el evento.
Estado 5: Archivado Meses o años después, el evento es historia. La página debe mantenerse como registro, pero puede simplificarse: una descripción del evento, los materiales más relevantes, las estadísticas de asistencia.
Datos estructurados para eventos
Los eventos son uno de los tipos de contenido con más soporte en Schema.org. El tipo Event incluye propiedades para: nombre, descripción, fecha de inicio, fecha de fin, ubicación (física o virtual), organizador, precio de entrada, estado del evento (programado, cancelado, pospuesto, online).
Implementar datos estructurados en eventos permite que los buscadores los muestren en resultados enriquecidos con fecha, lugar y precio directamente en la página de resultados, aumentando significativamente la visibilidad.
{
"@context": "https://schema.org",
"@type": "Event",
"name": "Nombre del evento",
"startDate": "2024-06-15T10:00:00+02:00",
"endDate": "2024-06-15T18:00:00+02:00",
"location": {
"@type": "Place",
"name": "Nombre del espacio",
"address": {
"@type": "PostalAddress",
"streetAddress": "Calle Ejemplo, 1",
"addressLocality": "Madrid",
"addressCountry": "ES"
}
},
"eventStatus": "https://schema.org/EventScheduled",
"eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode"
}
El archivo de eventos: organización del histórico
Un sitio con actividad regular de eventos genera un archivo histórico que debe organizarse para ser útil:
Separación de próximos eventos y eventos pasados. La página de índice de eventos (/eventos/) debería mostrar claramente los próximos eventos destacados y ofrecer acceso al archivo histórico. Mezclar eventos futuros y pasados sin distinción genera confusión.
Año como criterio de organización. Para archivos grandes, organizar por año es la forma más natural. /eventos/2024/ lista todos los eventos de ese año.
Indexación del archivo: Las páginas de archivo de eventos pasados deben indexarse si tienen contenido de valor (materiales, grabaciones, resúmenes). Si son simplemente listas vacías de eventos sin contenido adicional, pueden ponerse en noindex.