Schema.org 30.1 muda o vocabulário: veja o que ajustar no JSON-LD

A versão 30.1 do Schema.org, lançada em setembro de 2026, promoveu termos, aposentou propriedades antigas e abriu vocabulário novo. Quem usa JSON-LD para rich results e para aparecer em respostas de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → tem itens concretos para revisar.

O Schema.org publicou a versão 30.1 do vocabulário em 16 de setembro de 2026, segundo o changelog oficial de releases do projeto. Não é um anúncio dramático: é o tipo de atualização incremental que passa batido na correria, mas que decide se um Product, um Event ou uma Offer continuam sendo lidos corretamente por quem consome dados estruturados, do Google ao rich result até os sistemas que alimentam respostas de buscadores generativos.

O problema de ignorar esses changelogs é que schema.org não avisa individualmente quando descontinua uma propriedade que seu site usa há anos. Ela só marca o termo como pendente, depois como "attic" (aposentado), e segue em frente. Quem não acompanha a lista de releases acumula JSON-LD com campos mortos, que na melhor das hipóteses são ignorados e na pior geram erro de validação silencioso.

O que entrou na versão 30.1

A 30.1 concentrou esforço em duas frentes, segundo o changelog: comércio eletrônico↳E-commerce21 conteúdosECBR Club: novo espaço para devs se conectarem ao ecossistema de e-commerceDev (Back & Front) · mai 2025TOTVS anuncia joint venture com VTEXMarketing Tech · mai 2019Jovens da Brasilândia recebem formação gratuita em tecnologiaGestão Dev & TI · jul 2025Ver tudo em Marketing Tech → e rastreabilidade de produto. Para e-commerce, chegaram as propriedades consumerNotice, isOftenBoughtWith e specification, todas de uso em Product, além de valueGroup em PropertyValue, itemPopularity em Offer e minimumOrderValue em ShippingRateSettings. Também entrou o valor de enumeração MaximumRetailPrice em PriceTypeEnumeration.

A segunda frente é regulatória: suporte à descoberta do Digital Product Passport (DPP) da União Europeia. Isso trouxe a classe DigitalProductPassport e a propriedade hasDigitalProductPassport, utilizável em Product e Offer, além de EnvironmentalProductDeclaration e DeclarationOfConformity como subtipos de Certification, e propriedades como authorizedRepresentative, importer, recycledContentPercentage e substanceOfConcern em Product.

Para quem vende para a Europa, isso não é cosmético: o Digital Product Passport é parte de uma agenda regulatória da União Europeia voltada à rastreabilidade de produtos, e marcar esses dados desde já em Product é o tipo de trabalho que compensa fazer com antecedência, enquanto a adoção ainda é baixa e a concorrência não terminou de se adaptar.

Reclassificações: de "pending" para GA

O ponto que mais passa despercebido é a promoção de termos de pending para GA (generally available), registrada nas PRs #4876 e #4861 do changelog. No vocabulário do Schema.org, todo termo novo nasce como pending: existe, pode ser usado, mas ainda está sob avaliação de adoção antes de virar parte estável da especificação.

Em resumo: um termo pending é apostado, não garantido; um termo GA já tem histórico de uso real sustentando a promoção. Isso importa para quem decide onde investir esforço de marcação: propriedades recém-promovidas a GA nesta 30.1 são as que mais provavelmente continuam estáveis nos próximos anos, porque passaram pelo crivo de adoção que o próprio changelog cita como critério.

O changelog não lista individualmente quais termos migraram de status nesta promoção específica (só referencia as PRs), o que é uma lacuna de transparência real do processo. Na prática, o jeito de confirmar status atual de um termo específico é consultar a página dele em schema.org e checar a anotação de pending versus ausência dela.

O que foi descontinuado e precisa sair do JSON-LD

Mais importante que o que entrou é o que saiu. Versões recentes do vocabulário aposentaram tipos e propriedades que ainda aparecem em implementações antigas:

A troca de GraphicNovel por SequentialArt é didática do tipo de reclassificação que o Schema.org vem fazendo: o novo tipo é subtipo tanto de VisualArtwork quanto de Book, o que descreve melhor a natureza híbrida de quadrinhos e HQs do que o tipo antigo descrevia. Quem ainda marca GraphicNovel no JSON-LD de um catálogo editorial precisa migrar para SequentialArt antes que o termo antigo saia de circulação de vez.

Há também uma mudança estrutural menos visível: a 30.0 (março de 2026) alterou Quantity para herdar de DataType em vez de Intangible. Isso não quebra marcação existente, mas muda como validadores e parsers posicionam o tipo na hierarquia, algo que afeta ferramentas que fazem inferência de tipo por herança em vez de checagem exata.

Tipos novos que abrem oportunidade de marcação

Além de patches e deprecações, o vocabulário ganhou tipos inteiramente novos nas últimas releases, que valem considerar mesmo sem obrigação regulatória:

• ConferenceEvent, subtipo de Event, com hasParticipationOffer e hasSponsorshipOffer (29.4, dez/2025): útil para quem organiza ou divulga eventos técnicos e quer marcar ingresso e patrocínio separadamente do evento genérico.
• PerformingArtsEvent, outro subtipo de Event (29.4): mais granular que marcar tudo como Event solto.
• OperatingSystem e RuntimePlatform, subtipos de SoftwareApplication (29.4): relevantes para quem documenta compatibilidade de software e hoje usa só texto livre em operatingSystem.
• MemberProgram e MemberProgramTier (28.0, set/2024): para marcar programas de fidelidade de forma estruturada, com níveis e benefícios via hasTierBenefit.
• Credential, mais genérico que o antigo modelo restrito a credenciais educacionais (30.0, mar/2026).

Nenhum desses tipos é exigência. A decisão de adotá-los é a mesma de sempre em SEO técnico: vale o esforço se a entidade descrita é central para o negócio e se há concorrência direta já fazendo a marcação mais rica.

O checklist de republicação

Para quem mantém JSON-LD em produção, a lista de verificação depois desta leva de releases fica assim:

1. Rodar uma busca no código-fonte por GraphicNovel, DeliveryTimeSettings, shippingSettingsLink, shippingLabel e transitTimeLabel e substituir pelos tipos atuais.
2. Validar o JSON-LD de Product e Offer num validador que reconheça schema.org 30.1 (o Rich Results Test do Google não necessariamente acompanha a versão mais recente do vocabulário em tempo real).
3. Para catálogos que vendem na União Europeia, avaliar a inclusão de hasDigitalProductPassport com antecedência à exigência regulatória.
4. Revisar se Quantity é usado em alguma validação customizada que dependia da hierarquia antiga (Intangible).
5. Medir, antes e depois da republicação, a cobertura de rich results no Google Search Console (relatório de melhorias) e a taxa de citação em ferramentas de busca com IA que exponham essa métrica.

Por que isso conecta com GEO

O changelog do Schema.org não menciona buscadores generativos: é documentação de vocabulário, não de ranqueamento. Mas a lógica por trás da adoção de dados estruturados em IA generativa é a mesma de sempre, só que com um fator a mais. Sistemas que resumem a web para responder perguntas tendem a preferir fontes onde a entidade já vem desambiguada: um Product com DigitalProductPassport e especificações estruturadas é mais fácil de citar com precisão do que um parágrafo de texto livre.

Isso é leitura própria, não declaração do Schema.org nem do Google: a aposta de quem faz SEO técnico desde que as respostas geradas por IA começaram a consumir tráfego de busca é que marcação mais granular reduz a chance de a entidade ser mal interpretada ou substituída por uma fonte concorrente mais bem estruturada. Não há dado público do Schema.org ligando versão de vocabulário a taxa de citação em IA, então o único jeito de validar isso no seu caso é medir antes e depois da republicação, com as mesmas páginas, no mesmo período.

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

Exemplo de JSON-LD atualizado para um produto que usa os termos novos de DPP e e-commerce da 30.1:

{
 "@context": "https://schema.org",
 "@type": "Product",
 "name": "Camiseta técnica modelo X",
 "consumerNotice": "Produto sujeito a devolução em até 30 dias",
 "hasDigitalProductPassport": {
 "@type": "DigitalProductPassport",
 "url": "https://exemplo.com/dpp/produto-x"
 },
 "isOftenBoughtWith": {
 "@type": "Product",
 "name": "Short técnico modelo Y"
 }
}

O ganho real de acompanhar esses changelogs não é estar na moda com o vocabulário mais novo: é não carregar, por anos, propriedades aposentadas que param de ser interpretadas por quem consome o dado, seja um rich result do Google, seja um agente que resume a página para responder a um usuário.

Fonte: Schema.org, Release Notes (changelog oficial de versões do vocabulário): https://schema.org/docs/releases.html↳HTML45 conteúdosA importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Como hostear seu site HTML gratuitamente com GitHub PagesDev (Back & Front) · jun 2025SQL Server – Como criar um versionamento de código das suas Stored Procedures em HTML e com comentários da alteraçãoData · nov 2020Ver tudo em Dev (Back & Front) →

Fonte: Schema.org — Release Notes (changelog oficial de versões do vocabulário)