Para aparecer no mapa do Google e no Local Pack, sua empresa precisa de quatro tipos específicos de schema markup. São eles: LocalBusiness, PostalAddress, GeoCoordinates e OpeningHoursSpecification. Juntos, eles dizem ao buscador quem você é, onde fica, em quais coordenadas e quando atende.
Esses códigos transformam dados ambíguos em sinais que a máquina entende. Eles alimentam o Google Maps, o Local Pack e as respostas de IA. É essa estrutura que decide se você aparece no mapa ou não.
Usar só o LocalBusiness genérico entrega ao Google metade da informação. Os três tipos complementares são o que falta para gerar confiança de localização. Aqui você vê cada um com código real, validação e exemplos.
O que é local schema markup
Local Schema Markup é um conjunto de dados estruturados do vocabulário Schema.org. Ele descreve um negócio local de um jeito que algoritmos leem sem ambiguidade. O objetivo é eliminar qualquer dúvida sobre onde você está.
Um texto na página diz "Atendemos na Avenida Paulista". O schema diz "streetAddress": "Avenida Paulista, 1000" dentro de um objeto tipado. Essa diferença separa um site invisível de um negócio que aparece no Local Pack.
O schema não é um fator de ranqueamento isolado. Ele é o mecanismo de desambiguação que liga sua entidade às buscas com localização. O Google favorece quem tem sinais explícitos e validáveis. Vale ler também Core Web Vitals Perfeito no blog.
A diferença entre schema markup e Google Business Profile
Existe uma confusão comum que precisa ser resolvida aqui. O Google Business Profile é o perfil cadastrado na plataforma do Google. O Local Schema Markup é o código que vive no seu próprio site.
Os dois não competem. Quando os dados do site batem com os do Business Profile, o Google ganha confiança cruzada na sua entidade. Essa consistência é um dos sinais mais subestimados do SEO local.
A tabela abaixo separa os papéis. Vale ler também Robots.txt e Sitemap no blog.
| Elemento | Onde vive | Função principal | Controle |
|---|---|---|---|
| Google Business Profile | Plataforma do Google | Exibe ficha no Maps e Local Pack | Cadastro manual |
| Local Schema Markup | Código do seu site | Desambigua a entidade para o crawler | Total, no seu HTML |
| NAP (Name, Address, Phone) | Site, perfis, diretórios | Consistência de citação | Exige auditoria |
A regra de ouro é a consistência NAP. Nome, endereço e telefone do schema têm que ser idênticos aos do Business Profile e das citações externas. Uma diferença entre "Av." e "Avenida" já dilui a confiança da entidade.
Por que quatro tipos e não apenas um
A pergunta é direta. Se existe o LocalBusiness, por que ele não basta? A resposta está na arquitetura aninhada do Schema.org.
O LocalBusiness é o objeto-pai. Ele depende de propriedades tipadas para carregar os dados que importam para o mapa. Sem elas, a entidade fica incompleta. Vale ler também Core Web Vitals para SEO local no blog. Vale ler também Robots.txt e Sitemap no blog.
Endereço não é uma string solta, é um objeto PostalAddress. Coordenadas não são texto, são um objeto GeoCoordinates. Horário não é uma frase, é um objeto OpeningHoursSpecification Detalhamos isso em Otimização de Imagens para SEO..
Cada tipo responde a uma pergunta do framework 5W2H aplicado à localização. O LocalBusiness responde quem é o negócio. O PostalAddress responde onde ele fica No artigo Erros de Rastreamento e Indexação no Google, aprofundamos esse tema..
O GeoCoordinates responde a posição exata em latitude e longitude. O OpeningHoursSpecification responde quando o negócio atende. Sem os quatro juntos, o Google recebe uma entidade incompleta Vale ler também Auditoria Técnica de SEO no blog..
Entidade incompleta gera baixa confiança de localização. Isso vira menos aparições no Local Pack e posições piores no Maps. Por isso os quatro formam um sistema, não uma escolha Detalhamos isso em Links Internos e Arquitetura de Site..
LocalBusiness schema: o tipo 1 e a base de tudo
O LocalBusiness é o objeto-pai do seu markup local. Ele declara que aquela página representa um negócio físico que atende em um local. Todos os outros três tipos ficam aninhados dentro dele No artigo Hierarquia H1-H6, aprofundamos esse tema..
O grande erro aqui é usar LocalBusiness puro quando existe um tipo mais específico. O Schema.org tem subtipos como Restaurant, Dentist, Plumber e HVACBusiness. Quanto mais específico o tipo, mais clara fica a entidade para o Google.
A escolha do @type certo é um sinal de relevância. Um dentista que usa "@type": "Dentist" entrega contexto que LocalBusiness genérico não entrega. Essa precisão ajuda o Google a casar você com buscas da sua categoria No artigo HTTPS + HSTS Header, aprofundamos esse tema..
Propriedades obrigatórias do LocalBusiness
Três propriedades formam o núcleo inegociável. São name, address e telephone. Sem elas, o markup não cumpre sua função local Detalhamos isso em Profundidade de Cliques..
O name é o nome exato do negócio. O address recebe o objeto PostalAddress. O telephone usa o formato internacional, com código do país.
Além delas, url, image e priceRange fortalecem a ficha. O image deve apontar para uma URL de imagem real. O priceRange aceita faixas como "$$" ou valores em reais.
Exemplo de LocalBusiness em JSON-LD
O JSON-LD é o formato recomendado pelo Google. Ele fica isolado num bloco <script> e não se mistura ao HTML visível. Isso facilita manutenção e reduz erros de implementação.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Plumber",
"name": "Hidráulica Floripa Express",
"image": "https://hidraulicafloripa.com.br/logo.jpg",
"url": "https://hidraulicafloripa.com.br",
"telephone": "+554833334444",
"priceRange": "R$ 150 - R$ 800",
"address": {
"@type": "PostalAddress",
"streetAddress": "Rua das Palmeiras, 250",
"addressLocality": "Florianópolis",
"addressRegion": "SC",
"postalCode": "88010-000",
"addressCountry": "BR"
}
}
</script>Repare que o address não é texto. Ele abre um objeto PostalAddress completo. É esse aninhamento que o Google espera ver.
PostalAddress schema: o tipo 2 e o endereço que a máquina entende
O PostalAddress quebra o endereço em campos separados. Em vez de uma linha única, cada parte ganha sua própria propriedade. Isso elimina a ambiguidade que trava o ranqueamento local.
Um endereço escrito como "Rua das Palmeiras 250 Floripa SC" obriga o Google a adivinhar onde termina a rua e começa a cidade. O PostalAddress entrega tudo mastigado. A máquina não precisa interpretar nada.
As cinco propriedades essenciais
O endereço completo se divide em cinco campos principais. Cada um responde a uma camada da localização. Juntos, eles formam um endereço sem brechas.
| Propriedade | O que representa | Exemplo |
|---|---|---|
streetAddress |
Rua e número | Rua das Palmeiras, 250 |
addressLocality |
Cidade | Florianópolis |
addressRegion |
Estado ou UF | SC |
postalCode |
CEP | 88010-000 |
addressCountry |
País em código ISO | BR |
O addressCountry usa o padrão ISO 3166-1. Para o Brasil, é BR, não "Brasil". Esse detalhe técnico evita erros de validação.
O erro de consistência que derruba o markup
O PostalAddress precisa bater com o NAP do site inteiro. Se o rodapé diz "Av. das Palmeiras" e o schema diz "Avenida das Palmeiras", o Google percebe o conflito. Essa divergência reduz a confiança na entidade.
A solução é padronizar o endereço em uma única forma. Defina a versão oficial e replique em todos os lugares. Site, schema, Business Profile e diretórios precisam falar a mesma língua.
Um cenário real ilustra o impacto. Uma clínica em Florianópolis tinha o CEP errado no schema e o correto no Google. O conflito segurou a ficha fora do Local Pack até a correção, que levou cerca de duas semanas para refletir.
PostalAddress aninhado no LocalBusiness
O PostalAddress raramente vive sozinho. Ele entra como valor da propriedade address dentro do LocalBusiness. Essa é a estrutura correta que o Google documenta.
"address": {
"@type": "PostalAddress",
"streetAddress": "Rua das Palmeiras, 250",
"addressLocality": "Florianópolis",
"addressRegion": "SC",
"postalCode": "88010-000",
"addressCountry": "BR"
}Note que o objeto sempre declara seu próprio @type. Isso vale para todos os tipos aninhados. Sem o @type, o validador não reconhece o objeto.
GeoCoordinates schema: o tipo 3 e a posição exata no mapa
O GeoCoordinates entrega ao Google a posição geográfica precisa do negócio. Ele usa latitude e longitude, não palavras. É a diferença entre dizer "perto da praça" e cravar um ponto exato no mapa.
O PostalAddress diz o endereço, mas o Google ainda precisa convertê-lo em coordenadas. Esse processo se chama geocodificação. O GeoCoordinates pula essa etapa e entrega o ponto pronto.
Isso importa muito em buscas do tipo "perto de mim". O Google calcula proximidade usando coordenadas. Quanto mais exato o seu ponto, mais confiável fica o cálculo de distância até o usuário.
As duas propriedades centrais
O GeoCoordinates tem dois campos essenciais. São latitude e longitude. Ambos usam o formato decimal, não graus e minutos.
A latitude varia de -90 a 90. A longitude varia de -180 a 180. No Brasil, a maioria dos valores é negativa nas duas pontas.
Use pelo menos seis casas decimais. Cada casa decimal a mais aumenta a precisão em metros. Coordenadas curtas demais apontam para o quarteirão errado.
Como pegar as coordenadas corretas
O jeito mais simples é abrir o Google Maps. Clique com o botão direito sobre a porta exata do negócio. O primeiro número que aparece é a latitude, o segundo é a longitude.
Cuidado com o ponto e a vírgula. No JSON-LD, o separador decimal é sempre o ponto. Usar vírgula quebra a validação.
"geo": {
"@type": "GeoCoordinates",
"latitude": -27.595377,
"longitude": -48.548050
}Esse objeto entra na propriedade geo do LocalBusiness. Assim como o endereço, ele declara o próprio @type. A estrutura aninhada se repete em todos os tipos.
O erro de coordenada que joga você para outra cidade
Trocar latitude por longitude é o erro mais comum. O resultado coloca o negócio no meio do oceano ou em outro país. O Google ignora ou desprioriza fichas com coordenadas impossíveis.
Um caso real mostra o estrago. Uma loja em Florianópolis inverteu os dois valores no schema. A ficha passou a sinalizar uma posição perto da África, e o negócio sumiu do Local Pack local por semanas.
A correção é simples mas exige conferência. Sempre teste a coordenada colando-a de volta no Google Maps. Se o pino não cair na sua porta, o valor está errado.
OpeningHoursSpecification schema: o tipo 4 e o quando do negócio
O OpeningHoursSpecification declara os horários de funcionamento de forma estruturada. Ele alimenta o selo "Aberto agora" no Maps. Esse selo influencia diretamente o clique do usuário.
Horário em texto solto não serve. O Google precisa saber, por dia, quando você abre e fecha. O OpeningHoursSpecification entrega isso em campos que a máquina lê na hora.
Esse tipo também responde a buscas com intenção temporal. Consultas como "aberto agora perto de mim" filtram por horário. Sem o markup, você fica de fora desse filtro.
As propriedades de horário
Três campos formam a base. São dayOfWeek, opens e closes. Cada bloco de horário vira um objeto separado.
| Propriedade | O que representa | Exemplo |
|---|---|---|
dayOfWeek |
Dia ou dias da semana | Monday |
opens |
Horário de abertura | 08:00 |
closes |
Horário de fechamento | 18:00 |
Os dias usam nomes em inglês. O horário usa o formato 24 horas. Sempre com dois dígitos, como 08:00 e não 8:00.
Como lidar com horários diferentes por dia
Um negócio raramente tem o mesmo horário todos os dias. A solução é criar vários objetos OpeningHoursSpecification. Cada bloco agrupa os dias que compartilham o mesmo horário.
O intervalo de almoço também tem regra. Se você fecha do meio-dia às 14h, crie dois blocos para o mesmo dia. Um da manhã e outro da tarde.
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "08:00",
"closes": "18:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "Saturday",
"opens": "08:00",
"closes": "12:00"
}
]Esse array entra na propriedade openingHoursSpecification do LocalBusiness. Os colchetes indicam que são vários objetos. O domingo, ausente do exemplo, é entendido como fechado.
O detalhe que mantém o selo "aberto agora" correto
Horário errado no schema gera frustração e penalidade indireta. O usuário chega achando que está aberto e encontra a porta fechada. Isso gera avaliações negativas e desconfiança.
Atualize o schema sempre que mudar o horário. Feriados e datas especiais pedem o campo extra validFrom e validThrough. Assim o Google sabe que aquele horário é temporário.
A consistência também vale aqui. O horário do schema precisa bater com o do Business Profile. Divergência entre os dois confunde o Google e enfraquece a ficha.
Como implementar os 4 tipos em um único bloco JSON-LD
Os quatro tipos não vivem separados. Eles se unem em um único bloco <script> dentro do LocalBusiness. Esse bloco é a entidade local completa que o Google espera ler.
O PostalAddress entra em address. O GeoCoordinates entra em geo. O OpeningHoursSpecification entra em openingHoursSpecification.
Coloque o bloco no <head> ou perto do fim do <body>. Use uma única instância por página de negócio. Duplicar o markup gera conflito de entidade.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Plumber",
"name": "Hidráulica Floripa Express",
"image": "https://hidraulicafloripa.com.br/logo.jpg",
"url": "https://hidraulicafloripa.com.br",
"telephone": "+554833334444",
"priceRange": "R$ 150 - R$ 800",
"address": {
"@type": "PostalAddress",
"streetAddress": "Rua das Palmeiras, 250",
"addressLocality": "Florianópolis",
"addressRegion": "SC",
"postalCode": "88010-000",
"addressCountry": "BR"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": -27.595377,
"longitude": -48.548050
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "08:00",
"closes": "18:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "Saturday",
"opens": "08:00",
"closes": "12:00"
}
]
}
</script>Esse é o markup final unificado. Ele responde quem, onde, em que ponto e quando. É a estrutura que sustenta sua presença no Local Pack e no Maps.
Como validar e testar o markup
Markup sem validação é aposta cega. Duas ferramentas resolvem isso. Elas mostram erros antes que o Google os encontre.
A primeira é o Schema Markup Validator do Schema.org. Ela confere se a sintaxe e os tipos estão corretos. A segunda é o Rich Results Test do Google.
O Rich Results Test mostra se o markup é elegível para recursos visuais. Cole a URL ou o código e rode o teste. Erros aparecem em vermelho, avisos em amarelo.
Depois da publicação, acompanhe no Google Search Console. O relatório de dados estruturados lista erros em escala. Ele revela problemas que só aparecem com o site indexado.
Erros comuns ao implementar local schema
A maioria das falhas se repete. Conhecer os erros economiza semanas de retrabalho. A tabela abaixo reúne os mais frequentes.
| Erro | Impacto | Correção |
|---|---|---|
| Inverter latitude e longitude | Negócio aparece em outra cidade ou país | Testar o pino no Google Maps |
| NAP divergente entre site e schema | Perda de confiança na entidade | Padronizar nome, endereço e telefone |
| Vírgula como separador decimal | Falha de validação do JSON | Usar sempre ponto |
Usar LocalBusiness genérico |
Menos contexto de categoria | Escolher o subtipo específico |
| Markup duplicado na página | Conflito de entidade | Manter uma única instância |
| Horário desatualizado | Selo "Aberto agora" errado | Sincronizar com o Business Profile |
Outro erro silencioso é o schema sem correspondência visual. O Google exige que o dado do markup também apareça na página. Marcar um endereço que não está visível viola as diretrizes.
Como o local schema conversa com AI Overviews e LLMs
Dados estruturados não servem só ao ranqueamento clássico. Eles facilitam a leitura por modelos de linguagem. Uma entidade bem marcada é mais fácil de citar e resumir.
O AI Overviews e assistentes de busca preferem fontes claras. Quando seus dados de localização são explícitos, a chance de citação aumenta. O schema reduz a ambiguidade que confunde a máquina.
Isso transforma o markup em ativo de autoridade. Você não otimiza só para a página de resultados. Você prepara sua entidade para a busca conversacional.
Perguntas frequentes
O que é local schema markup?
É um conjunto de dados estruturados do Schema.org que descreve um negócio local. Ele informa nome, endereço, coordenadas e horário de forma legível por máquina. O objetivo é aparecer no Maps e no Local Pack.
Quais são os 4 tipos para aparecer no mapa?
São LocalBusiness, PostalAddress, GeoCoordinates e OpeningHoursSpecification. O primeiro é o objeto-pai. Os outros três ficam aninhados dentro dele.
Schema markup melhora o ranqueamento local de fato?
Ele não é um fator de ranqueamento direto isolado. Mas é o mecanismo que desambigua sua entidade para o Google. Essa clareza aumenta a confiança e a frequência de aparição local.
JSON-LD ou microdata: qual usar?
O Google recomenda o JSON-LD. Ele fica isolado em um bloco de script e não se mistura ao HTML visível. Isso reduz erros e facilita a manutenção.
Preciso do Google Business Profile mesmo usando schema?
Sim, os dois são complementares. O Business Profile gera a ficha no Maps. O schema reforça os mesmos dados a partir do seu site.
Como pego as coordenadas corretas?
Abra o Google Maps e clique com o botão direito sobre a porta do negócio. O primeiro número é a latitude, o segundo é a longitude. Use pelo menos seis casas decimais.
O schema funciona para negócio com vários endereços?
Sim, cada local recebe sua própria página e seu próprio markup. Você cria um LocalBusiness por unidade. Nunca junte vários endereços no mesmo bloco.
Com que frequência devo atualizar o markup?
Atualize sempre que mudar endereço, telefone ou horário. Feriados pedem campos temporários de validade. Markup desatualizado prejudica a experiência e a confiança.
Posicionamento final: local schema como vantagem competitiva
A maioria dos concorrentes para no LocalBusiness genérico. Implementar os quatro tipos completos é o que separa quem aparece de quem fica invisível. A diferença está no detalhe técnico que poucos executam.
O schema bem feito alinha site, Business Profile e citações em uma só verdade. Essa consistência constrói confiança de entidade ao longo do tempo. É um ativo que compõe, não uma tarefa única.
Quem domina LocalBusiness, PostalAddress, GeoCoordinates e OpeningHoursSpecification controla os sinais que definem a presença no mapa. O próximo passo é validar seu markup atual e corrigir o que estiver faltando. A vantagem fica com quem trata dados estruturados como estratégia, não como detalhe.