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. 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.