O schema LocalBusiness é o bloco de código que declara endereço, horário de funcionamento e área de atendimento do seu negócio num formato que a IA lê sem precisar adivinhar, o que aumenta a chance de ela citar você quando alguém pergunta pelo melhor serviço na sua cidade, no seu bairro ou "perto de mim". Marcar tem três partes: escolher o subtipo certo, preencher os campos de lugar com os mesmos dados que aparecem na página e publicar o bloco JSON-LD onde o negócio é descrito.
Schema LocalBusiness é o tipo de marcação do schema.org que descreve um negócio físico como uma entidade presa a um lugar: nome, endereço, coordenadas, horário e forma de contato, tudo em JSON-LD, o formato que buscadores e modelos de IA foram treinados para interpretar. Onde o tipo Organization descreve a empresa em abstrato, o LocalBusiness responde à pergunta que a busca local faz: onde isso fica e quando atende.
Este tutorial vai campo a campo. Se a ideia de marcar o site ainda soa nova, o artigo sobre dados estruturados cobre por que essa é a aposta mais barata do GEO técnico.
Quando usar LocalBusiness e qual subtipo escolher?
Use LocalBusiness quando o negócio tem um ponto físico que o cliente visita ou uma área de atendimento delimitada: um restaurante, uma clínica, uma loja de bairro, uma oficina, um salão. Se a empresa opera só online e vende para o Brasil inteiro, o tipo certo é outro (Organization para a marca, Product para o catálogo), e forçar o LocalBusiness seria declarar um endereço que não organiza nada.
A regra que o Google publica é direta: use o subtipo mais específico que se aplica. A documentação do schema.org lista dezenas de subtipos, e o adequado quase sempre existe.
- Restaurant, Bakery, CafeOrCoffeeShop para alimentação.
- Dentist, Physician, MedicalClinic para saúde.
- Store e derivados como ClothingStore e HardwareStore para varejo.
- AutoRepair, HairSalon, ProfessionalService para prestação de serviço.
Quando nenhum subtipo descreve bem o negócio, o LocalBusiness genérico é válido e funciona. O que não vale é usar um subtipo errado porque parece mais bonito: a marcação precisa bater com o que a página realmente é. Para escolher entre os tipos de marcação em geral, o artigo sobre quais tipos de schema usar organiza a decisão.
Como fica um bloco LocalBusiness completo?
Abaixo, um exemplo para um restaurante em São Paulo. Troque cada valor pelos dados do seu negócio, e nunca declare um horário, um telefone ou uma coordenada que não existe.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Restaurant",
"name": "Cantina Bella Massa",
"url": "https://www.cantinabellamassa.com.br",
"telephone": "+55-11-3000-0000",
"priceRange": "$$",
"servesCuisine": "Italiana",
"image": "https://www.cantinabellamassa.com.br/fachada.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "Rua dos Pinheiros, 1234",
"addressLocality": "São Paulo",
"addressRegion": "SP",
"postalCode": "05422-001",
"addressCountry": "BR"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": -23.56712,
"longitude": -46.69340
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "18:00",
"closes": "23:30"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Saturday", "Sunday"],
"opens": "12:00",
"closes": "23:30"
}
],
"areaServed": ["Pinheiros", "Vila Madalena", "Jardim Paulista", "Itaim Bibi"]
}
</script>
É tudo texto dentro de uma tag <script>, sem biblioteca nem dependência. As próximas seções destrincham os campos que mais pesam para a busca local.
Quais campos de localização a IA mais usa?
Três blocos respondem "onde": o endereço, as coordenadas e a área de atendimento. São eles que ligam o negócio a uma consulta com intenção geográfica.
address e PostalAddress: o endereço estruturado
O address não é uma linha de texto solta. É um objeto PostalAddress com campos separados, e cada um vira um dado que o modelo lê sem ter que interpretar:
streetAddress: rua e número.addressLocality: a cidade.addressRegion: a sigla do estado (SP, RJ, MG).postalCode: o CEP.addressCountry: o país, em código de duas letras (BR).
Endereço e nome são os dois únicos campos que o Google trata como obrigatórios para um negócio local, segundo a documentação do Search Central. Sem address, a marcação nem conta como local.
geo e GeoCoordinates: a coordenada exata
O geo carrega latitude e longitude num objeto GeoCoordinates. O endereço diz o nome do lugar; a coordenada diz o ponto exato no mapa, o que resolve casos em que o texto do endereço é ambíguo (duas ruas com nome parecido, um CEP que cobre uma área grande). O Google pede pelo menos cinco casas decimais para a precisão valer.
areaServed: o raio de atuação
O areaServed declara a cidade, o bairro ou a região que o negócio atende, e é o campo que mais conversa com a busca "perto de mim". Ele não está na lista de campos obrigatórios do Google para o resultado rico, mas é uma propriedade do schema.org que ajuda a IA a entender até onde o negócio alcança: uma pizzaria que entrega em quatro bairros, uma clínica que recebe pacientes de uma região metropolitana inteira.
O detalhe que faz esses três campos funcionarem é a consistência. O endereço marcado precisa ser igual ao endereço visível na página, no Google Business Profile e nos diretórios onde o negócio aparece. Quando as versões divergem (rua abreviada aqui, CEP diferente ali), a IA trata as variações como entidades distintas e a confiança cai. Esse alinhamento entre marca, endereço e presença externa é o que o artigo sobre GEO para negócios locais chama de NAP consistente.
Por que declarar horário e telefone muda a leitura da IA?
Horário e contato separam um endereço no papel de um negócio que de fato atende. O openingHoursSpecification e o telephone sinalizam operação real, e a IA usa esse sinal ao decidir o que recomendar e como descrever.
O openingHoursSpecification é uma lista de blocos. Cada bloco agrupa os dias com o mesmo horário e informa quando abre e quando fecha:
dayOfWeek: os dias, em inglês (Monday,Tuesday), como o schema.org define.opensecloses: os horários no formato de 24 horas (18:00,23:30).
Um negócio com horário diferente no fim de semana usa dois blocos, como no exemplo acima. Marcar o horário deixa a IA responder a perguntas do tipo "está aberto agora" e reforça que o ponto está em funcionamento, não abandonado.
O telephone entra com o código do país e o DDD (+55-11-3000-0000). Funciona como mais um ponto de ancoragem: um telefone que bate com o que aparece no site e no perfil do Google confirma que se trata do mesmo negócio real, e não de uma listagem velha.
LocalBusiness e Organization: preciso dos dois?
Depende do que o site é. Um negócio de ponto único pode usar só o LocalBusiness, que já herda os campos de identidade do Organization. Uma marca com presença institucional forte (página Sobre, redes sociais, cobertura de imprensa) e um ou mais pontos físicos costuma marcar os dois, porque descrevem coisas diferentes: o Organization é a identidade da empresa, o LocalBusiness é a unidade que atende num lugar.
O cuidado é não se contradizer. Se você marca os dois, o nome, o telefone e o site precisam ser idênticos nos dois blocos. Uma rede com várias unidades resolve isso com um Organization para a marca e um LocalBusiness por unidade, cada um com seu endereço e suas coordenadas. Declarações que brigam entre si (um telefone no bloco da marca, outro no bloco da unidade) reintroduzem a ambiguidade que a marcação existe para eliminar.
Como validar o LocalBusiness antes de publicar?
Valide o bloco antes de considerar o trabalho pronto, porque uma vírgula fora do lugar no JSON quebra a leitura inteira. Duas ferramentas gratuitas resolvem:
- Rich Results Test do Google (search.google.com/test/rich-results): mostra se a marcação está válida e o que o Google conseguiu ler.
- Schema Markup Validator (validator.schema.org): confere a sintaxe e lista os campos reconhecidos, sem o filtro de resultado rico do Google.
Confira três coisas no resultado: o tipo lido como o subtipo que você escolheu, o address com todos os subcampos preenchidos e nenhum erro de sintaxe. Aviso sobre campo opcional ausente não bloqueia. Erro de sintaxe, sim, e precisa ser corrigido antes de publicar. A mecânica de colar o bloco na página, decidir onde inserir e revalidar depois de cada mudança está no passo a passo de como implementar JSON-LD.
O que a marcação muda quando a IA olha o seu negócio
Sem o LocalBusiness, o modelo deduz onde você fica a partir de texto solto na página, e erra com frequência para negócios de porte médio e pequeno, justamente os que menos aparecem na web. Com o bloco no ar, endereço, coordenada, horário e área de atendimento ficam declarados no formato que o modelo foi treinado para ler. Quando alguém pergunta pelo melhor da sua categoria na sua cidade ou no seu bairro, o negócio marcado entra com um dado limpo a favor. O não marcado depende da sorte de o modelo ter costurado a informação certa.
Não é garantia de citação. A visibilidade em IA depende também de conteúdo com contexto geográfico e de presença nas fontes que os modelos leem, um retrato que o guia de GEO técnico organiza por camadas. A marcação é a camada que remove a ambiguidade sobre o lugar, e é das mais baratas de arrumar.
Na Promptis, a auditoria de site verifica página por página se o seu LocalBusiness está presente e bem formado, junto com os outros fatores de GEO técnico, e aponta o que falta. A primeira análise é grátis e não pede cartão: vale rodar antes de editar o schema no escuro.
