Gerador de schema de empresa local

Como gerar o schema de empresa local

Uma unidade por página, uma página por unidade. O gerador escreve a marcação e o bloco visível a partir dos mesmos valores, para os dois nunca dizerem coisas diferentes.

1. Escolha o tipo de negócio mais específico. Restaurant, Bakery, Dentist, BarOrPub e os outros são subtipos de LocalBusiness e herdam tudo o que ele tem. Use LocalBusiness só quando nada mais específico servir.
2. Preencha nome e endereço no padrão dos Correios. São as duas únicas propriedades obrigatórias. Logradouro, número e bairro no primeiro campo; cidade, UF e CEP nos seus. O resto do formulário deixa o resultado mais rico, não mais válido.
3. Escreva o horário como regras, uma por linha. O bar que abre no sábado às 18h e fecha às 3h é uma linha — sáb 18:00-03:00 —, não duas. Feriado é um intervalo de datas mais a palavra fechado. Cada linha vira uma OpeningHoursSpecification.
4. Leia os avisos antes de copiar. Precisão das coordenadas, faixa de preço longa demais, parte do endereço faltando, um dia coberto por duas regras — cada um é algo que o Google ignora ou lê diferente do que você quis dizer.
5. Cole as duas saídas. O JSON-LD vai no head ou no body da página da unidade; o bloco de endereço e a tabela de horário, onde o cliente lê. A tabela mostra os dias em português; no JSON-LD eles seguem os nomes do schema.org. Gere tudo de novo quando o horário mudar.

Endereço brasileiro em PostalAddress: bairro, UF, CEP e +55

Um gerador de schema de empresa local transforma os dados de uma unidade em JSON-LD LocalBusiness — os dados estruturados que o Google lê para endereço, horário de funcionamento e departamentos de uma empresa. Só duas propriedades são obrigatórias, name e address, e é no endereço que o formato brasileiro não cabe sozinho num formulário pensado nos Estados Unidos.

O PostalAddress do schema.org tem logradouro, cidade, região, CEP e país, mas nenhuma propriedade para bairro. Os Correios agrupam o bairro na linha do logradouro — tipo, nome, número, complemento e bairro —, e é ali que ele entra no markup também: no fim do streetAddress. O Google pede o maior número possível de partes do endereço, e o mapeamento fica assim:

Três detalhes dos Correios. O CEP não leva a sigla CEP antes nem ponto no meio: 05433-010, não 05.433-010. Há cidades com CEP único e cidades com um CEP por logradouro — use o da rua quando ele existir. E no Distrito Federal o município é um só, Brasília: a região administrativa entra como bairro.

No telefone, o Google pede o código do país e o código de área. Pelo plano de numeração da Anatel, é +55, o DDD de dois dígitos e o número — oito dígitos no fixo, nove no celular, e todo celular brasileiro começa com 9 desde fevereiro de 2017. Assim: +55 11 3456-7890 no fixo, +55 11 91234-5678 no celular.

Madrugada, feriado e intervalo de almoço

O Google é explícito sobre o horário que passa da meia-noite — a página em português chama de horário de funcionamento na madrugada: abertura e fechamento vão numa única OpeningHoursSpecification. O boteco que abre no sábado às 18h e fecha no domingo às 3h é uma regra — dayOfWeek: Saturday, opens: 18:00, closes: 03:00 —, não uma de sábado até 23:59 mais outra de domingo a partir de 00:00. O schema.org diz o mesmo pelo outro lado: quando closes é menor que opens, o intervalo avança para o dia seguinte.

Este gerador lê uma regra por linha, com os dias em português — abreviados, como seg e sáb, ou por extenso, como segunda-feira — ou em inglês, e a palavra fechado para o dia sem expediente. Cada linha abaixo é um exemplo de sintaxe:

ter-qui 17:00-00:30
      sex-sáb 12:00-03:00                      # madrugada, uma regra só
      seg     fechado                          # opens e closes em 00:00
      seg-dom 24h                              # opens 00:00, closes 23:59
      2026-12-24..2026-12-25 seg-dom fechado   # validFrom / validThrough

As codificações das três últimas linhas são do Google: aberto 24 horas é opens em 00:00 e closes em 23:59; fechado o dia todo, os dois em 00:00; e o fechamento sazonal usa validFrom e validThrough no formato AAAA-MM-DD. Especificação sem essas datas vale o ano inteiro.

O caso brasileiro que os exemplos do Google não cobrem é o intervalo de almoço — a loja que abre das 8h às 12h e das 14h às 18h. O Perfil da Empresa no Google aceita isso com duas entradas no mesmo dia; a página de dados estruturados de empresa local não traz exemplo de dois horários no mesmo dia. Aqui, escreva o mesmo dia em duas linhas — seg-sex 08:00-12:00 e seg-sex 14:00-18:00 — e o gerador escreve as duas regras sem reclamar; ele só avisa quando os horários do mesmo dia se sobrepõem ou quando uma das linhas diz fechado, porque aí as duas regras se contradizem de verdade.

Perfil da Empresa no Google e o JSON-LD: dois lugares, a mesma informação

Quem procura uma empresa na Pesquisa ou no Maps pode ver um painel de informações e, numa busca como "os melhores restaurantes de São Paulo" — o exemplo é da própria documentação em português —, um carrossel de empresas. O horário que aparece ali você define no Perfil da Empresa no Google; os dados estruturados dizem a mesma coisa a partir do seu site. Os dois precisam concordar, e o gerador cuida só de um deles.

• Feriado se avisa com antecedência. O Perfil da Empresa tem horário especial para quando a empresa muda o horário por um período ou fica fechada por até seis dias seguidos, e o Google recomenda confirmar o horário nos feriados oficiais mesmo quando nada muda. A lista de Feriados no Google para o Brasil traz datas nacionais e estaduais — o 20 de novembro, Dia Nacional de Zumbi e da Consciência Negra, é uma delas —, e nessas datas o perfil pode mostrar um aviso de que o horário pode ser diferente.
• No site, o mesmo feriado vira uma linha sazonal. 2026-12-24..2026-12-25 seg-dom fechado gera a especificação com validFrom e validThrough ao lado da semana normal.
• Uma unidade, uma página, um @id. A documentação do Google não fala de @id, mas ele deixa de ser enfeite quando o site tem mais de uma unidade: cada página com um nó LocalBusiness, cada nó com um @id estável e a propriedade url apontando para a própria página. A página que lista as unidades linka para elas, não as imita.

O que é obrigatório — e as estrelas que não vêm

Obrigatórios são dois, name e address; o resto é recomendado. Onde o Google declara consequência:

• Precisão das coordenadas. geo.latitude e geo.longitude com pelo menos cinco casas decimais. Três casas são uns cem metros — outro prédio na mesma quadra. O gerador avisa abaixo de cinco.
• Faixa de preço. priceRange precisa ter menos de cem caracteres; com 100 ou mais, o Google não mostra faixa de preço nenhuma. Serve $$ ou um intervalo como R$ 30-60, não um parágrafo sobre o rodízio.
• Departamento. Um department aninhado leva o nome no formato {nome da loja} {nome do departamento} — gMart e gMart Pharmacy, no exemplo do Google —, a não ser que o departamento tenha marca própria.
• País. addressCountry leva o código ISO 3166-1 de duas letras: BR.

E a caixa no fim do formulário existe para ser recusada. Pelas diretrizes de snippet de avaliação, páginas com LocalBusiness não se qualificam para as estrelas quando a empresa controla as avaliações sobre si mesma — inclusive pelo widget de avaliações do Google ou do Facebook incorporado no site. review e aggregateRating são recomendados só para sites que registram avaliações de outras empresas locais, como um guia ou um diretório. As regras vizinhas estão no gerador de schema de avaliação e no gerador de schema de produto; a regra da marcação igual à página, base de todas estas ferramentas, está no gerador de schema FAQ.