SEO para vídeo no seu site: schema, sitemap e desempenho

Vídeo no seu próprio site e vídeo no YouTube são dois problemas de otimização diferentes, mesmo que a busca "SEO para vídeo" misture os dois. Este texto trata do primeiro: como fazer o Google entender, indexar e exibir um vídeo que vive numa página do seu domínio — não como fazer aquele vídeo subir no ranking de busca do YouTube.

A pauta aqui é prática: os dados estruturados que realmente mudam o que aparece na SERP, o sitemap de vídeo e os casos em que ele ainda faz diferença, a transcrição e os capítulos como texto rastreável, e a escolha de arquitetura que mais pesa no desempenho — embutir o player do YouTube ou hospedar o vídeo com um player próprio, medida em LCP.

As duas perguntas que "SEO para vídeo" costuma misturar

Quem digita "SEO para vídeo" geralmente quer uma de duas coisas. A primeira é fazer um vídeo hospedado no YouTube aparecer melhor nos resultados de busca do próprio YouTube — isso depende de título, thumbnail, taxa de retenção, tags e do comportamento de quem assiste dentro da plataforma. Se é esse o seu problema, vale procurar um guia dedicado à otimização de vídeo dentro do YouTube; as alavancas ali são de plataforma, não de rastreamento web.

A segunda pergunta — a que este texto responde — é diferente: você tem uma página no seu domínio com um vídeo embutido ou hospedado nela, e quer que o Google entenda do que se trata, extraia informações estruturadas e, idealmente, mostre um resultado rico com miniatura, duração ou até um trecho específico do vídeo direto na busca. Esse problema é de schema, de rastreamento de texto e de performance de carregamento — os três assuntos que seguem.

Dados estruturados VideoObject: o que cada campo entrega na SERP

O Google não assiste ao seu vídeo; ele lê o que você declara sobre ele. O vocabulário schema.org VideoObject é como essa declaração é feita, e cada campo que você preenche tem um efeito específico na SERP — não é uma lista de metadados burocráticos, é literalmente o que decide se o resultado tem miniatura grande, badge de duração ou nenhum tratamento especial.

• thumbnailUrl: sem ele não há miniatura no resultado — e sem miniatura, um resultado de vídeo compete visualmente como um link de texto comum. A imagem declarada também precisa corresponder a um frame real do vídeo, com resolução alta o suficiente para qualificar o formato de miniatura grande; uma imagem genérica ou que não bate com o conteúdo reduz a chance de o resultado aparecer com destaque.
• uploadDate e duration: alimentam o badge de duração e ajudam o Google a posicionar o vídeo entre resultados mais recentes ou mais antigos sobre o mesmo tema.
• contentUrl ou embedUrl: aponta para o arquivo real ou para o player embutido — sem um dos dois, o Google não tem como confirmar que existe de fato um vídeo reproduzível na página.
• description: é texto rastreável de verdade, não um resumo decorativo — vale escrever como se fosse o parágrafo de abertura de um artigo sobre o tema do vídeo.
• hasPart com objetos Clip: é o que permite o recurso de "momentos-chave" — links que levam direto para um ponto específico do vídeo na busca, cada um com seu próprio name, startOffset e uma url com parâmetro de tempo. O recurso também aceita capítulos declarados na descrição do vídeo ou uma transcrição com marcação de tempo como fonte alternativa do mesmo dado, e ter as duas formas aumenta a chance de ele aparecer de forma consistente.

Sitemap de vídeo: quando ainda vale a pena

Um sitemap de vídeo é um arquivo XML separado, ou uma extensão do sitemap comum de páginas, que lista cada vídeo com metadados como localização do player, restrições de país, se é conteúdo ao vivo e a data de expiração, quando existir. Ele existe desde antes do VideoObject virar prática comum, e por um bom tempo foi a forma mais confiável de garantir que o Google soubesse que uma página continha vídeo.

Hoje, com VideoObject bem implementado em cada página, o sitemap deixou de ser a única fonte de verdade — mas continua valendo a pena em situações específicas: um catálogo grande de vídeos em que nem toda página é alcançada por uma navegação interna forte; vídeos hospedados fora do domínio principal, como um subdomínio de mídia, que o rastreamento normal levaria mais tempo para alcançar; ou conteúdo ao vivo e efêmero, em que a velocidade de descoberta importa mais do que em um vídeo evergreen.

Quando o sitemap de vídeo faz sentido, vale usar as tags próprias do formato: player_loc para apontar o player embutido, restriction para bloquear países onde o conteúdo não pode ser exibido, family_friendly para sinalizar classificação de conteúdo, e live para marcar transmissões em andamento. Várias delas têm equivalente em VideoObject (regionsAllowed, isFamilyFriendly, BroadcastEvent para transmissões ao vivo), então o ganho real do sitemap está na descoberta mais rápida nos casos específicos citados acima, não em dados exclusivos.

Onde ele passou a ser dispensável: um blog com uma dúzia de vídeos, cada um em uma página já bem linkada e já indexada, com VideoObject completo. Nesse cenário o sitemap de vídeo raramente muda o resultado, porque o Google já tem o caminho até a página e já tem os dados estruturados nela. A pergunta prática é se existe algum vídeo que o rastreamento normal do site demoraria a encontrar sozinho; se a resposta é não, manter o sitemap atualizado rende pouco pelo esforço que exige.

Capítulos e transcrição como texto rastreável

Capítulos — marcações de tempo com um título curto para cada trecho do vídeo — fazem duas coisas ao mesmo tempo: dão à pessoa que assiste uma forma de pular direto para o trecho que interessa, e dão ao Google um conjunto de âncoras textuais associadas a pontos exatos do vídeo. É esse par de nome de capítulo mais timestamp que sustenta a exibição de momentos específicos na busca, junto com o hasPart e os objetos Clip do schema.

A transcrição é a peça que mais gente pula e a que mais pesa. Um rastreador não assiste a um vídeo — ele lê. Uma transcrição completa transforma um vídeo de três minutos, que sem ela contribuiria talvez com uma frase de description, em várias centenas de palavras de texto real, pesquisável, com todas as variações de linguagem que a pessoa efetivamente falou. É esse texto que faz o vídeo competir por buscas de cauda longa que nenhum título curto conseguiria cobrir sozinho.

• Publicar a transcrição como texto visível na própria página, e não apenas como um arquivo de legenda referenciado dentro do player, que o rastreador não necessariamente processa da mesma forma que texto de página.
• Revisar a legenda gerada automaticamente antes de publicar, porque erro de reconhecimento de fala vira erro de indexação.
• Quebrar a transcrição em blocos alinhados aos capítulos, o que reforça a mesma estrutura em dois formatos ao mesmo tempo.

Embed do YouTube x player próprio: a decisão que mais custa em LCP

Se o vídeo está no topo da página — comum em landing pages e em artigos que abrem com um vídeo de apresentação — o elemento do player é, na prática, o candidato mais provável a Largest Contentful Paint. Isso transforma a escolha de como embutir o vídeo de uma questão estética em uma questão de métrica de Core Web Vitals.

O embed padrão do YouTube, o iframe gerado pela opção compartilhar e incorporar, carrega, além do player em si, uma quantidade relevante de JavaScript de terceiros antes de renderizar qualquer coisa visível: scripts de rastreamento, o código do player, conexões para múltiplos domínios do Google. Em conexões móveis mais lentas, isso empurra o LCP para trás mesmo quando o resto da página já terminou de carregar.

O padrão que resolve isso sem abandonar o YouTube é conhecido como facade: a página carrega apenas uma imagem estática do pôster do vídeo com um botão de play sobreposto, e o iframe real só é criado quando a pessoa clica. O maior elemento visível continua sendo uma imagem leve, o LCP é medido contra essa imagem, e o custo pesado do player só entra em cena depois da interação — quando já não afeta a métrica que o Google usa para pontuar a página.

A alternativa mais radical é sair do YouTube por completo: hospedar o arquivo com uma tag video nativa, ou por um serviço de streaming próprio, com controle direto sobre compressão, formato e taxa de bits adaptativa. Isso custa mais para operar — armazenamento, banda, eventualmente transcodificação — mas elimina de vez o peso de scripts de terceiros e dá controle total sobre o que carrega e em que momento. Vale o custo quando o vídeo é central para o propósito da página; não vale quando é um complemento ocasional a um artigo de texto.

Vale medir os dois lados antes de decidir: dados de laboratório, de uma ferramenta como o Lighthouse rodada localmente, mostram o efeito isolado do embed em condições controladas, enquanto dados de campo, do relatório Core Web Vitals do Search Console ou do CrUX, com base em visitantes reais, mostram o que de fato acontece em conexões variadas. Um embed que parece aceitável num teste de laboratório em banda larga pode se revelar o gargalo real quando confrontado com o percentil mais lento dos visitantes móveis — é essa divergência entre laboratório e campo que costuma justificar trocar o embed padrão pelo facade.

• Embed padrão do YouTube: mais simples de implementar, sem custo de hospedagem próprio, mas com o maior peso de JavaScript de terceiros e o risco mais alto para o LCP.
• Embed em facade: mantém o vídeo no YouTube, mas adia o carregamento do player até a interação — o meio-termo mais barato de implementar.
• Hospedagem própria: controle total sobre formato, compressão e carregamento, ao custo de armazenamento e banda próprios.

Pôster, preload e o vídeo como elemento LCP

Seja qual for a arquitetura escolhida, o pôster — a imagem estática mostrada antes da reprodução — merece o mesmo tratamento de qualquer imagem crítica de LCP: formato moderno como AVIF ou WebP, dimensão real de exibição em vez de uma imagem maior sendo redimensionada por CSS, e nenhum carregamento adiado nela se estiver acima da dobra, porque atrasar de propósito o carregamento do próprio elemento que será medido como LCP é contraproducente.

Para a tag video nativa, o atributo preload metadata busca só o suficiente para exibir dimensões e o primeiro quadro, sem baixar o arquivo inteiro antes de ser necessário. Para embeds de terceiros, uma tag de preconnect apontando para o domínio do player adianta a negociação de conexão, embora não elimine o peso do script em si — é uma otimização pequena e útil, mas que não substitui o facade quando o embed está de fato acima da dobra.

Checklist para publicar um vídeo pronto para rastreamento

Antes de publicar uma página com vídeo, vale confirmar estes pontos:

• VideoObject completo na página, com thumbnailUrl, contentUrl ou embedUrl, uploadDate e duration preenchidos.
• Capítulos com nome e timestamp, refletidos também como objetos Clip dentro de hasPart, quando o vídeo tiver seções distintas.
• Transcrição publicada como texto visível na página, revisada manualmente, e não apenas guardada como arquivo de legenda.
• Decisão consciente entre embed padrão, embed em facade ou hospedagem própria, avaliada com o vídeo tratado como elemento LCP sempre que estiver acima da dobra.
• Sitemap de vídeo incluído apenas se houver vídeos que o rastreamento normal do site não alcançaria com a mesma velocidade.