Schema de negócio local: o guia completo

Quando um mecanismo de busca chega até a página de uma loja, um consultório ou um restaurante, ele não lê contexto do jeito que uma pessoa lê. Ele encontra texto solto: um endereço enfiado no rodapé, um telefone numa barra lateral, um horário escrito numa frase qualquer no meio do conteúdo. O schema de negócio local — o tipo LocalBusiness, ou um de seus subtipos mais específicos, do vocabulário mantido em schema.org — existe para tirar essa adivinhação da equação. Em vez de o mecanismo de busca inferir que aquela sequência de números é um telefone e aquele texto é um endereço, o markup declara isso de forma explícita, num formato estruturado que a máquina lê sem ambiguidade.

Isso não é enfeite técnico nem mais um item de checklist. É a diferença entre uma página que descreve um negócio em prosa e uma página que declara os fatos desse negócio de um jeito que pode ser processado por software. Este guia cobre o que de fato entra nesse markup, como escolher o tipo certo, o ponto que decide se ele ajuda ou atrapalha — a consistência entre o que está marcado, o que está na página e o que está nos seus outros perfis — e os erros mais comuns em negócios com mais de um endereço e em horários fora do padrão.

O que o markup LocalBusiness realmente faz

Na prática, o schema de negócio local é um bloco de dados estruturados, normalmente escrito em JSON-LD, embutido no HTML da página. Ele não aparece para quem lê o site — é invisível ao visitante e existe só para o software que processa a página junto com a pessoa. Dentro dele, cada fato do negócio vira um par de chave e valor: o nome numa propriedade, o endereço postal em outra, o telefone em outra, seguindo um vocabulário padronizado que qualquer parser reconhece, não só o do Google.

O efeito prático é remover a adivinhação. Sem o markup, um mecanismo de busca tenta inferir o endereço a partir de texto solto na página — um endereço citado como exemplo num post de blog pode até ser confundido com o endereço real do negócio. Com o markup declarado, essa inferência para de ser necessária.

As propriedades que realmente importam

Nem toda propriedade do vocabulário LocalBusiness carrega o mesmo peso. Um conjunto relativamente pequeno sustenta a maior parte do valor prático:

• name — o nome oficial do negócio, exatamente como se apresenta em outros lugares, sem variações criativas ou palavras-chave enfiadas no meio.
• address, estruturado como PostalAddress, com rua, cidade, estado, CEP e país em campos separados — não como uma única string de texto solto.
• telephone, no formato internacional completo sempre que possível, para eliminar ambiguidade de DDD.
• geo, com latitude e longitude via GeoCoordinates — útil sobretudo quando o negócio fica num shopping ou complexo com vários pontos de referência.
• openingHoursSpecification, que declara o horário dia a dia, não como frase livre.
• priceRange, um indicador aproximado de faixa de preço, útil para sinalizar a categoria do negócio.
• url, apontando para a página canônica daquele negócio específico — não para a home genérica quando existe uma página própria da unidade.
• sameAs, uma lista de links para os perfis oficiais em outras plataformas — o Perfil da Empresa no Google, uma rede social, um diretório setorial relevante.

Um bloco de LocalBusiness com apenas nome e URL é tecnicamente válido, mas carrega uma fração pequena do valor que o mesmo bloco carregaria com endereço, telefone, geo e horário completos.

Escolha o tipo mais específico disponível

O vocabulário de schema.org organiza LocalBusiness como um tipo genérico com dezenas de subtipos: Restaurant, Dentist, ClothingStore, ProfessionalService, HairSalon, AutoRepair, e por aí vai, cada um com propriedades adicionais próprias do segmento. Usar o genérico quando existe um subtipo específico é desperdiçar informação que o vocabulário já oferece de graça.

Um restaurante marcado como Restaurant, em vez de simplesmente LocalBusiness, pode declarar cardápio, tipo de cozinha e faixa de preço com propriedades feitas sob medida. Um consultório odontológico marcado como Dentist entra automaticamente numa categoria mais restrita do que "negócio local genérico", o que ajuda o mecanismo de busca a entender que tipo de entidade está processando, sem depender de inferência a partir do texto.

Quando o negócio não se encaixa perfeitamente em nenhum subtipo — um espaço de coworking, por exemplo — o caminho é escolher o mais próximo disponível, em vez de recuar direto para o genérico só porque nenhuma opção é perfeita. LocalBusiness genérico continua legítimo quando não há subtipo aplicável; só não deve ser a escolha padrão por comodidade.

O ponto que decide tudo: consistência

Aqui está o núcleo do assunto, e é o ponto que a maioria dos guias trata como detalhe menor quando na verdade é o que determina se todo o resto teve algum efeito. O markup precisa concordar, ao mesmo tempo, com três coisas: com o que está escrito na própria página, com o seu perfil de negócio (o Perfil da Empresa no Google, por exemplo) e com os seus outros perfis e listagens — diretórios, redes sociais, cadastros setoriais.

Um endereço declarado no schema que diverge do endereço no rodapé da mesma página não é um detalhe cosmético — é uma contradição direta entre duas fontes que deveriam ser a mesma. Um telefone no markup diferente do telefone no Perfil da Empresa no Google não corrige uma informação desatualizada em outro lugar; cria duas versões concorrentes da mesma verdade, e o mecanismo de busca não tem como saber qual está certa. Nesse cenário, dados contraditórios são piores do que dados ausentes: um site sem markup é uma fonte incompleta, enquanto um site com markup que contradiz outras fontes já demonstrou não ser confiável sobre fatos do próprio negócio.

Isso muda como tratar o markup depois de publicado. Não é um bloco de código que se escreve uma vez e se esquece; é um espelho de fatos que precisa ser atualizado toda vez que qualquer um deles muda — endereço, telefone, horário, faixa de preço — e atualizado nos três lugares ao mesmo tempo, não só num deles.

Negócios com múltiplas localizações: uma página, um local

Um erro recorrente em redes com várias unidades é tentar resolver tudo numa página só: uma página institucional listando todos os endereços, com um único bloco de LocalBusiness tentando representar a rede inteira, ou vários blocos empilhados na mesma página tentando cobrir cada unidade. Isso confunde exatamente a associação que o schema existe para deixar clara, porque o markup descreve uma entidade situada num lugar físico específico.

O padrão que funciona é o oposto: cada unidade tem a sua própria página, com o seu próprio bloco de LocalBusiness contendo endereço, telefone, horário e geolocalização daquela unidade, e nada além disso. A página institucional pode continuar existindo como um índice que lista e linka cada unidade — mas quem carrega o markup completo é a página própria de cada endereço. Esse desenho também facilita a consistência: é bem mais fácil manter o endereço de uma unidade correto na página daquela unidade do que manter dez endereços corretos dentro de um único bloco numa página genérica.

Horário de funcionamento e os casos que quase sempre saem errados

A propriedade openingHoursSpecification declara, para cada dia da semana, o horário de abertura e fechamento. Até aí é direto. Onde a maioria dos sites erra é nos casos que fogem do horário comercial padrão.

O padrão mais comum nesses três casos é o mesmo: o horário é configurado uma vez, no lançamento do site, cobrindo só a semana comum, e nunca mais revisado. O resultado é um schema que declara "aberto" num feriado em que a loja está fechada — o que volta direto ao ponto da consistência: é o markup contradizendo a realidade, na cara de quem está tentando confiar nele.

• Feriados: se o negócio fecha ou muda o horário em feriados, isso precisa de uma especificação própria, com data de início e fim, sobrepondo o horário regular só naquele período — não uma nota solta em texto que o schema ignora.
• Horário partido: um negócio que fecha para almoço não representa isso como um intervalo único de manhã até a noite; precisa de duas faixas separadas para o mesmo dia.
• Mudanças sazonais: horário de verão diferente do de inverno, ou horário estendido em datas do calendário de varejo, também exige uma especificação com período de validade, não uma edição manual esquecida depois que a data passa.

O que esse markup faz — e o que ele não faz

Vale ser direto sobre os limites, porque circula bastante desinformação em torno disso. O schema de negócio local dá suporte ao entendimento do negócio pelo mecanismo de busca e pode ser pré-requisito de elegibilidade para determinados formatos de exibição nos resultados — mas não é, sozinho, um fator que produz posicionamento no pacote de mapas ou em qualquer ranking local. Qualquer conteúdo que prometa "adicione este schema e apareça no topo do Google Maps" descreve uma relação de causa e efeito que não existe.

O posicionamento local depende de proximidade, relevância e um conjunto de sinais de reputação e perfil — avaliações, categoria correta, completude do Perfil da Empresa no Google, sinais de engajamento — fatores sem relação direta com a presença de um bloco de JSON-LD na página. O schema entra nessa equação como facilitador de leitura correta dos fatos, não como insumo de ranking direto.

Validação e manutenção contínua

Publicar o markup uma vez não encerra o trabalho. Existem ferramentas de validação — testadores de dados estruturados que apontam erros de sintaxe, propriedades ausentes ou tipos malformados — e vale rodar o bloco nelas depois de qualquer alteração no site, principalmente depois de trocas de template ou migrações de plataforma, porque esses eventos são a causa mais comum de um schema que funcionava até a véspera parar de existir na página sem que ninguém perceba.

Mas a validação sintática resolve só metade do problema. Ela confirma que o JSON está bem formado e as propriedades obrigatórias estão presentes; não confirma que o telefone declarado ainda é o certo, ou que o horário ainda corresponde à loja de verdade. Essa segunda checagem é manual e recorrente: sempre que um fato do negócio muda no mundo real, o markup precisa mudar junto, no mesmo momento — não numa revisão trimestral que ninguém agenda. Tratar o schema como um documento vivo, amarrado ao ciclo de mudanças do próprio negócio, é o que mantém válido o ponto central deste guia: o valor do markup depende inteiramente de ele continuar dizendo a verdade.