Schema de eventos: datas, local e preço para o Google

Schema de evento é o tipo Event do schema.org — a marcação que informa ao Google, em campos estruturados, os dados essenciais de um evento: o nome, quando começa e termina, onde acontece (ou o link, quando é online) e se ainda dá para comprar ingresso e por quanto. Sem essa marcação, o Google até tenta extrair essas informações do texto da página, mas de forma inconsistente. É essa inconsistência — não a ausência total de dados — que faz um evento perfeitamente real não aparecer no carrossel de eventos nem no rich result correspondente.

Este texto não é uma introdução a dados estruturados de um modo geral — parte do princípio de que você já sabe o que é JSON-LD e por que ele existe. O foco aqui é o que é específico do tipo Event: as propriedades que o Google de fato usa, os erros que aparecem quase sempre em implementações reais e um problema que nenhum outro schema comum tem da mesma forma — uma data de validade embutida no próprio conteúdo, que faz a página estar certa por semanas e errada para sempre depois disso.

Quem realmente precisa marcar eventos

Nem todo site precisa disso. Schema de evento faz sentido para quem publica páginas cujo valor inteiro depende de quando e onde algo acontece: casas de shows e espaços para eventos corporativos, escolas e provedores de treinamento com turmas em datas fixas, organizadores de feiras, congressos e festivais, e qualquer empresa que rode webinars ou sessões ao vivo com regularidade. O fio condutor não é o setor, é o formato da página.

Se a página em questão é uma reunião de vendas agendada por link individual, isso não é um evento no sentido do schema.org — é um agendamento. Schema de evento serve para algo com data, lugar (físico ou virtual) e, na maioria dos casos, capacidade ou preço: o tipo de informação que vale a pena o Google mostrar antes mesmo do clique.

• Locais e casas de eventos com uma agenda de datas, cada uma merecendo sua própria marcação
• Escolas e provedores de treinamento com turmas, cursos ou workshops com início e fim definidos
• Empresas que rodam webinars recorrentes — mensal, trimestral, ou por lançamento
• Organizadores de feiras, congressos e festivais, com agendas de vários dias e múltiplas sessões

As propriedades que o Google realmente lê

O rich result de evento do Google não usa tudo que existe no vocabulário Event do schema.org — ele depende de um conjunto específico de propriedades, e é a falta ou o erro nelas que mais frequentemente explica por que um evento correto no conteúdo visível simplesmente não aparece como evento nos resultados de busca.

• name — o nome do evento, limpo, sem o texto promocional que costuma ficar ao lado dele na página (não é o lugar para colar "Ingressos a partir de R$50! Compre já")
• startDate e endDate — sempre em ISO 8601 com o fuso horário explícito, algo como 2026-09-15T19:00:00-03:00. Horários sem fuso são um erro comum: o horário pode ser interpretado no fuso errado, e um evento às 19h no horário de Brasília pode acabar exibido em outro horário
• location — para um evento presencial, um objeto Place com endereço real e verificável, não o endereço da sede da empresa se o evento acontece em outro lugar. Para um evento online, o equivalente é VirtualLocation, com a URL de acesso — e é exatamente aqui que muita implementação erra, marcando um webinar com um endereço físico só porque o template foi copiado de um evento presencial
• eventAttendanceMode — declara se o evento é presencial, online ou híbrido, e precisa ser coerente com o que location descreve
• offers — um objeto Offer com price, priceCurrency, availability (InStock, SoldOut, PreOrder etc.) e a URL real de compra. Mesmo um evento gratuito se beneficia de uma Offer com price zero: isso sinaliza inscrição confirmada e aberta, não "data a definir"
• eventStatus — EventScheduled é o padrão, mas existem valores específicos para EventPostponed, EventRescheduled, EventCancelled e EventMovedOnline. Essa propriedade existe justamente para que uma mudança de planos seja uma atualização de campo, não a exclusão silenciosa da página

Eventos recorrentes: por que cada ocorrência pede sua própria URL

A tentação, num workshop mensal ou numa aula recorrente, é manter uma única página e simplesmente reescrever a data todo mês. Isso quebra por um motivo estrutural: o Google rastreia e armazena em cache uma URL específica. Se essa URL é reescrita silenciosamente, existe sempre uma janela em que a versão indexada mostra uma data que já passou, ou em que alguém clica a partir da busca e cai numa página que já mudou desde o último rastreamento. E, do lado da apresentação, uma URL fixa também impede o Google de listar várias datas futuras de uma vez — porque, para o rastreador, só existe a versão mais recente daquela página.

A prática mais estável é o inverso: cada ocorrência recebe sua própria URL e sua própria marcação Event — algo como /eventos/workshop-setembro-2026, /eventos/workshop-outubro-2026, e assim por diante — com uma página de índice separada, sem data própria, que lista as próximas ocorrências e linka para cada uma. Quando as ocorrências são estruturalmente idênticas, isso vira um problema de template, não de conteúdo: o que muda entre elas é a URL e os poucos campos de data, local e preço, gerados a partir da mesma base.

O problema do ciclo de vida

Toda página de evento tem uma característica que quase nenhum outro tipo de conteúdo tem: ela está correta por um período definido e depois fica errada para sempre. Um artigo sobre como configurar um sitemap não vence. Uma página que diz "Workshop dia 15 de setembro, inscrições abertas" está simplesmente errada a partir do dia 16 — e continua no ar, publicada, indexada, com o schema intacto, dizendo exatamente a mesma coisa.

A falha mais comum aqui não é técnica, é operacional: ninguém volta para atualizar a página depois que o evento acontece. É comum encontrar sites com centenas de páginas de evento com startDate no passado, eventStatus ainda como EventScheduled, listadas como se fossem próximas, às vezes ainda linkadas a partir de um menu "Próximos Eventos" que ninguém revisou. Esse é exatamente o padrão que as diretrizes do Google sobre dados estruturados de evento tratam como problema — marcação que faz um evento parecer que ainda vai acontecer, ou que os ingressos ainda estão disponíveis, quando isso já não é verdade. A consequência costuma ser silenciosa: a página perde a elegibilidade para o rich result sem nenhum aviso explícito que conecte uma coisa à outra.

A saída é decidir com antecedência o que acontece com uma página depois da data, e não improvisar caso a caso quando o evento já passou. Existem três padrões razoáveis, e a escolha certa depende de quanto valor a URL específica já acumulou:

• Arquivar com moldura de evento passado — manter a página no ar, já que ela pode ter links e histórico de rastreamento que valem a pena preservar, mas reescrever o enquadramento no passado, remover ou atualizar o eventStatus e trocar qualquer "Comprar ingresso" por algo como "Este evento já aconteceu — veja a próxima edição"
• Redirecionar para a próxima ocorrência — quando a URL é genérica, um /workshop-mensal fixo em vez de uma URL datada, um redirecionamento 301 da edição vencida para a atual evita deixar uma versão obsoleta indexada e mantém num só lugar a autoridade que a URL foi acumulando
• Página permanente de série, sem data própria — uma página estável sobre o evento ou a série em si, formato, histórico, para quem é, que nunca carrega um startDate específico e apenas linka para a ocorrência datada que estiver com inscrições abertas no momento

Qualquer um dos três padrões exige um gatilho operacional — uma revisão periódica de páginas com startDate no passado, ou uma etapa automática no fluxo de publicação de novos eventos. O problema recorrente raramente é a falta de uma solução; é a falta de um processo que a aplique no momento certo.

Validação: sintaxe correta não basta

Vale checar duas coisas separadas, e a maioria das implementações só checa a primeira. A primeira é sintaxe: o JSON-LD está bem formado e as propriedades obrigatórias estão presentes — isso a Ferramenta de Teste de Resultados Ricos do Google e o validador do próprio schema.org confirmam rapidamente. A segunda é paridade: tudo que está declarado no JSON-LD também precisa estar visível, em texto, na página que uma pessoa lê.

Schema de evento não é um campo a mais para preencher no momento da publicação — é um contrato de dados que precisa continuar sendo mantido enquanto a página existir. Quando a validade do evento expira, o schema precisa expirar junto, de um jeito decidido com antecedência, e não descoberto meses depois numa auditoria.

• Se o JSON-LD diz que o preço é R$150 e a página visível mostra R$180, essa divergência por si só é uma violação das diretrizes de dados estruturados, independente de qualquer outro campo estar tecnicamente correto
• Se o eventStatus diz EventScheduled e o texto da página diz "cancelado", o mesmo problema se aplica na direção contrária
• Vale reexecutar os dois testes depois de qualquer mudança de template — um ajuste de layout pode remover um campo visível da página sem tocar em nada no schema, e a paridade quebra sem que ninguém tenha mexido diretamente na marcação