---
title: "Local Schema Markup: 4 Types Específicos Para Aparecer No Mapa"
url: "https://pmturbo.com/seo-tecnico/local-schema-markup-mapa/"
description: "Local Schema Markup: 4 tipos para aparecer no mapa — LocalBusiness, PostalAddress, GeoCoordinates e OpeningHoursSpecification | SEO Santa Catarina"
author: "Marcelo Menezes"
publisher: "PMTurbo"
date_published: "2026-06-01"
date_modified: "2026-06-02"
content_signal: ai-train=no, search=yes, ai-input=yes
---

# Local Schema Markup: 4 Types Específicos Para Aparecer No Mapa

**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](https://pmturbo.com/seo-tecnico/schema-markup-seo-local/). 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](https://pmturbo.com/seo-local/otimizacao-google-maps/).

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](https://pmturbo.com/seo-tecnico/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](https://pmturbo.com/servico/criacao-e-otimizacao-de-google-meu-negocio/) é 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](https://pmturbo.com/servico/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](https://pmturbo.com/seo-local/consistencia-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](https://pmturbo.com/seo-tecnico/schema-markup-seo-local/)**.

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](https://pmturbo.com/glossario/#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](https://pmturbo.com/glossario/#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](https://pmturbo.com/seo-tecnico/schema-markup-seo-local/) 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](https://pmturbo.com/seo-tecnico/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](https://pmturbo.com/seo-tecnico/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.

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](https://pmturbo.com/seo-local/consistencia-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](https://pmturbo.com/seo-local/otimizacao-google-maps/) 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.

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](https://pmturbo.com/seo-local/otimizacao-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.

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](https://pmturbo.com/seo-local/otimizacao-google-maps/) 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.

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.

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](https://pmturbo.com/seo-tecnico/schema-markup-seo-local/). 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](https://pmturbo.com/seo-local/mensuracao-roi-seo/). 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](https://pmturbo.com/seo-local/otimizacao-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](https://pmturbo.com/seo-local/otimizacao-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.

Veja também

- [SEO Técnico em Santa Catarina: Guia Completo para um Site Pronto para Ranquear em 2026](https://pmturbo.com/seo-tecnico/)
- [Erros de Rastreamento e Indexação no Google: Como Encontrar e Corrigir](https://pmturbo.com/seo-tecnico/erros-rastreamento-indexacao/)
- [Redirecionamentos 301 e 302: Quando Usar Cada Um sem Perder Ranking](https://pmturbo.com/seo-tecnico/redirecionamentos-301-302/)

[Marcelo Menezes](https://pmturbo.com/autor/marcelo-menezes/) é consultor de SEO Local em Florianópolis e região, especializado em posicionamento orgânico no Google, SEO técnico e estratégias de busca local para empresas de Santa Catarina. Atua com internet desde 1996 e possui formação em Tecnologia em Processamento de Dados pela UNESA, concluída em 1998, acumulando décadas de experiência prática no mercado digital.

Também é um dos fundadores da PMTurbo, agência especializada em SEO e presença digital. Ao longo da trajetória profissional, participou de projetos de otimização para empresas de diferentes segmentos, desenvolvendo estratégias voltadas para aumento de visibilidade no Google, autoridade digital, tráfego qualificado e geração de oportunidades através da busca orgânica.