Schema de vagas de emprego: remoto, híbrido e multi-cidade

O schema de vagas de emprego (JobPosting) tem uma armadilha específica para quem publica vagas remotas ou híbridas: o Google exige um campo — jobLocationType — que não existe na maioria dos templates de ATS e de sites de carreira brasileiros, e pede um segundo campo — applicantLocationRequirements — sempre que o primeiro aparece. Sem eles, a vaga pode falhar no Rich Results Test ou simplesmente não aparecer como remota no Google for Jobs, mesmo com todo o resto do markup correto.

Este guia cobre três situações que respondem pela maior parte dos erros: como marcar uma vaga totalmente remota sem esquecer de indicar de quais países os candidatos podem se candidatar, como diferenciar híbrido de remoto no schema — são propriedades diferentes, não graus da mesma escala — e como publicar uma única vaga aberta em várias cidades sem multiplicar conteúdo duplicado pelo site. Não é sobre os campos básicos de uma JobPosting, que já são bem documentados. É sobre a parte que trava especificamente as vagas com componente remoto.

A base que precisa estar certa antes de pensar em remoto

Antes de mexer em jobLocationType vale confirmar que o restante do JobPosting está completo, porque o Google rejeita a vaga inteira se faltar qualquer propriedade obrigatória — remota ou não. As obrigatórias são title, description, datePosted, hiringOrganization (com name e, se possível, logo) e jobLocation, que só pode ser omitido em vagas 100% remotas que tragam applicantLocationRequirements. O validThrough é exigido quando a vaga tem data de encerramento, e sua ausência faz o mecanismo assumir prazo indefinido, o que tende a deixar vagas encerradas circulando no índice como se ainda estivessem abertas.

employmentType também merece estar presente sempre que fizer sentido (FULL_TIME, PART_TIME, CONTRACTOR, INTERN), porque é um dos filtros mais usados por quem busca vaga no Google — e é justamente o tipo de campo que passa despercebido em times que herdaram um template pronto e nunca revisaram o que ele de fato preenche.

Vale reparar também na description. O schema aceita marcação HTML básica dentro dela — parágrafos, listas, negrito — e é comum que integrações automáticas removam essa formatação ao gerar o JSON, entregando um bloco de texto corrido. Isso não invalida a vaga, mas empobrece como ela é exibida nos resultados de vaga do Google, que respeita parte dessa formatação ao renderizar a descrição para quem está buscando.

• title — o cargo real, sem inflar com termos que não aparecem na descrição
• description — o texto completo da vaga dentro do schema, não um resumo
• datePosted e validThrough — datas reais, atualizadas a cada renovação
• hiringOrganization.name — o nome da empresa contratante, não o nome do ATS que hospeda a página

jobLocationType: o interruptor que liga o modo remoto

jobLocationType é a propriedade que diz ao Google que a vaga pode ser exercida remotamente. O único valor reconhecido é TELECOMMUTE, escrito exatamente assim. Fora desse valor específico, o campo é ignorado — vagas marcadas como "remoto", "home office" ou "trabalho remoto" no lugar de TELECOMMUTE simplesmente não acionam o comportamento remoto no Google for Jobs, mesmo que a descrição em texto livre deixe isso claríssimo para um leitor humano.

O erro mais comum em sites brasileiros é remover jobLocation ao adicionar jobLocationType sem colocar nada no lugar. Pela documentação do Google, jobLocation só pode ser omitido quando applicantLocationRequirements está presente; sem nenhum dos dois, a validação falha. Se a vaga remota tem um escritório de referência, manter jobLocation com esse endereço também é válido, e o país desse endereço passa a valer como padrão para a elegibilidade dos candidatos.

• "jobLocationType": ["TELECOMMUTE"] sinaliza vaga remota — e precisa desse valor exato
• jobLocation só pode ser omitido em vaga 100% remota se applicantLocationRequirements estiver presente
• sem jobLocationType, o Google trata a vaga como presencial no endereço informado, ainda que a descrição diga o contrário

applicantLocationRequirements: quem pode se candidatar

Sempre que jobLocationType traz TELECOMMUTE, o Google exige que pelo menos um país elegível seja indicado, de preferência com applicantLocationRequirements (na falta dela, vale o país de jobLocation) — a propriedade que delimita de onde a pessoa candidata pode estar para se aplicar à vaga. Sem ela, uma vaga remota fica ambígua: remota para o mundo todo, ou remota só dentro do Brasil? O schema resolve isso com um objeto do tipo Country, aninhado dentro de applicantLocationRequirements, informando o nome do país.

Esse é, na prática, o campo que mais falta em vagas publicadas por empresas brasileiras — porque boa parte dos plugins e templates de página de carreira foi criada antes de essa propriedade existir na especificação, e ninguém voltou para adicioná-la depois. Uma vaga remota restrita a candidatos no Brasil precisa de um Country com name igual a "Brazil", seguindo o padrão em inglês que aparece nos próprios exemplos de referência do Google — mesmo que todo o resto da vaga esteja em português. Para contratação remota aberta a mais de um país, applicantLocationRequirements aceita uma lista de objetos Country, um para cada país elegível; o Google não infere isso a partir do idioma da vaga nem do domínio do site.

• TELECOMMUTE sem applicantLocationRequirements e sem jobLocation falha na validação
• um único país: um objeto Country com name (ex.: "Brazil")
• vários países elegíveis: uma lista de objetos Country, um por país

Híbrido não é "remoto pela metade"

O erro conceitual mais frequente em vagas híbridas é tratar o modelo como um meio-termo dentro da mesma escala do remoto — e, por isso, adicionar jobLocationType TELECOMMUTE também para posições que exigem presença regular no escritório. TELECOMMUTE é reservado para papéis que podem ser exercidos sem exigência de presença física em local nenhum. Uma vaga híbrida, por definição, tem essa exigência — só que parcial. Ela não se encaixa no valor da propriedade, então a resposta correta costuma ser não usar jobLocationType, e deixar jobLocation carregando o endereço do escritório onde a presença é esperada.

Isso não é só uma questão de compliance técnico com a especificação. Marcar uma vaga híbrida como TELECOMMUTE faz com que ela apareça nos filtros de busca remota do Google for Jobs, atraindo candidaturas de pessoas que não podem — ou não querem — cumprir os dias presenciais combinados. O problema não é o rastreador rejeitar a vaga; é a vaga aparecer no lugar errado e gerar candidaturas que não avançam. Se o modelo híbrido tem nuances (dias fixos, presença quinzenal, escolha do colaborador), esse detalhe vai na description em texto livre, que o Google também lê e usa para qualificar a vaga — não em um valor de propriedade que não foi desenhado para representar meio-termo.

Uma vaga, várias cidades: schema único ou páginas separadas

Essa é a decisão que mais gera conteúdo duplicado em sites de carreira: uma empresa abre a mesma posição simultaneamente em três ou quatro cidades e precisa decidir se isso é uma vaga com várias localizações ou várias vagas com o mesmo conteúdo. As duas soluções existem no schema, e a escolha errada é o que cria duplicidade.

Quando é literalmente a mesma requisição — mesmo cargo, mesmos requisitos, mesma descrição, abrindo simultaneamente em mais de um endereço — a forma correta é uma única JobPosting com jobLocation recebendo uma lista de objetos Place, um por cidade. O Google entende isso como uma vaga só, que aparece para buscas feitas perto de qualquer uma das localizações listadas, sem que você precise publicar a mesma descrição em páginas diferentes.

Quando as posições são, na prática, independentes — equipes diferentes, gestores diferentes, ou você quer que cada cidade tenha sua própria página capaz de ranquear isoladamente para buscas locais — aí sim cada cidade merece sua própria JobPosting, com datePosted e identificador próprios. O ponto que costuma passar batido é que cada página, nesse caso, precisa variar de fato: contexto do time, particularidades do escritório, benefícios locais. Uma vaga clonada trocando só o nome da cidade no meio do texto é candidata natural a ser tratada como conteúdo duplicado, com o schema correto ou não — o markup estruturado não resolve um problema que está no texto visível da página.

Há ainda um caso híbrido dos dois modelos: uma vaga remota, mas restrita a candidatos de determinadas praças, por exemplo para facilitar encontros presenciais ocasionais. Isso não se resolve listando várias cidades em jobLocation, porque jobLocation descreve onde o trabalho é fisicamente baseado, não de onde o candidato pode se inscrever. A ferramenta certa aqui continua sendo applicantLocationRequirements — se a exigência é por país, o Country já resolve; se a empresa realmente quer restringir por região dentro do país, isso costuma ficar mais claro na description em texto livre do que forçado em uma propriedade que não foi desenhada para granularidade de cidade.

• mesma requisição, várias cidades: um jobLocation com array de Place na mesma JobPosting
• vagas independentes por cidade: uma JobPosting por página, com conteúdo que varia de verdade entre elas
• o que nunca ajuda: clonar a página trocando só o nome da cidade

Erros que mais derrubam a validação de vagas remotas e híbridas

A maior parte dos problemas de validação em vagas com componente remoto se repete entre sites diferentes, porque nasce da mesma lacuna nos templates disponíveis no mercado.

• TELECOMMUTE presente sem applicantLocationRequirements — o Google passa a considerar apenas o país de jobLocation, o que pode restringir a vaga mais do que o pretendido
• jobLocationType adicionado e jobLocation removido sem applicantLocationRequirements — sem um dos dois, a validação falha
• validThrough vencido ou nunca preenchido — a vaga expira silenciosamente da lógica de indexação, mas continua acessível como se estivesse aberta
• jobLocationType usando um valor fora da enumeração do schema.org, como "remoto" ou "home office" em vez de TELECOMMUTE — o Google só reconhece o valor exato
• a mesma vaga publicada em várias páginas de cidade com texto idêntico e sem variação real de conteúdo

Testando antes de publicar em escala

Vale testar pelo menos um URL representativo de cada variante de template — vaga remota, vaga híbrida, vaga multi-cidade — porque cada uma exige uma combinação diferente de propriedades, e uma variante passando na validação não garante que as outras estejam corretas. O Rich Results Test mostra se o JobPosting é elegível para os resultados de vaga, e o relatório de vagas de emprego dentro do Search Console mostra o comportamento agregado ao longo do tempo, incluindo páginas com erro que só aparecem depois de publicadas em produção.

A parte que costuma ser esquecida depois do lançamento é o ciclo de vida da vaga. Quando uma posição fecha, atualizar validThrough para a data real de encerramento — ou remover a página de forma que ela retorne um status adequado — evita que o schema continue anunciando uma vaga que não existe mais. Deixar o markup antigo no ar, sem atualização, é uma das razões mais comuns para a cobertura de vagas de um domínio degradar aos poucos no Search Console, mesmo quando cada vaga individual, no momento em que foi publicada, estava tecnicamente correta.