Microformats: história, conceitos e guia prático

Microformats são pequenos padrões de HTML que dizem a uma máquina o que determinado conteúdo já diz a uma pessoa. Um nome deixa de ser apenas texto e passa a ser reconhecível como o nome de alguém. Um artigo pode expor título, autor, data, conteúdo e endereço permanente. Um evento pode informar horário e local sem exigir uma API separada.

O princípio parece modesto, mas carrega uma ideia poderosa: a própria página visível pode ser, ao mesmo tempo, documento para leitura e fonte de dados estruturados. Não é preciso abandonar o HTML, duplicar todo o conteúdo em outro arquivo ou depender de uma plataforma central para tornar a informação reutilizável.

Esta pesquisa percorre a origem dos microformats, a passagem dos primeiros formatos para o microformats2, a sintaxe atual, os principais vocabulários e sua relação com a IndieWeb. A parte prática mostra como marcar uma identidade, um artigo, um feed e um evento, como conferir o JSON extraído e como aplicar o padrão em HTML, Ghost e Astro.

Resumo executivo

Microformats não são uma linguagem nova, um banco de dados nem um substituto universal de Schema.org. São convenções abertas adicionadas ao HTML comum, principalmente por meio de nomes de classes e valores do atributo rel.

O formato atual é o microformats2, frequentemente abreviado como mf2. Sua gramática principal cabe em cinco prefixos:

Um cartão pessoal mínimo pode ser escrito assim:

<a class="h-card" href="https://example.com/">Pablo Murad</a>

Um parser compatível infere name a partir do texto e url a partir do href. Em algo mais elaborado, as propriedades são declaradas:

<div class="h-card">
  <img class="u-photo" src="/pablo.jpg" alt="Retrato de Pablo Murad">
  <a class="p-name u-url" href="https://example.com/">Pablo Murad</a>
  <p class="p-note">Programador, escritor e administrador de servidores.</p>
</div>

As descobertas mais importantes são:

• o movimento nasceu entre 2003 e 2005, primeiro com relações em links, como XFN, e depois com dados estruturados por classes, como hCard e hCalendar;
• o termo “microformat” foi apresentado publicamente em fevereiro de 2004, e o site microformats.org foi lançado em junho de 2005;
• microformats2 foi proposto em 2010 para tornar a escrita mais clara e permitir parsers genéricos;
• sua filosofia é “humanos primeiro, máquinas depois”: aproveitar conteúdo visível, HTML semântico e padrões já usados;
• os vocabulários mais importantes para um site pessoal são h-card, h-entry e h-feed;
• microformats2 tem papel central na IndieWeb e é usado como modelo de dados por Micropub; Webmention não exige mf2 para transportar a notificação, mas consumidores costumam usá-lo para interpretar e apresentar a página de origem;
• para SEO moderno, mf2 e Schema.org/JSON-LD têm objetivos diferentes e podem coexistir;
• a melhor implementação começa pequena: uma h-card representativa, uma h-entry por publicação, um h-feed nas listagens e validação com um parser real.

Metodologia e critérios

A pesquisa priorizou fontes primárias:

• especificações, histórico, princípios e vocabulários mantidos pela comunidade microformats.org;
• recomendações do W3C para Micropub e Webmention;
• padrão vivo de HTML do WHATWG;
• documentação do Google para diferenciar microformats de marcação voltada a resultados enriquecidos;
• repositórios oficiais de parsers e da suíte de testes.

O histórico foi tratado com cuidado. A página oficial registra como precursor conceitual uma proposta de Dan Connolly, em 2000, mas ressalta que os criadores de XFN e microformats não a conheciam na época. Portanto, ela não deve ser apresentada como o nascimento direto do movimento. A cronologia efetiva começa com os experimentos de 2003 e 2004.

As páginas da wiki também misturam especificações estáveis, rascunhos maduros, registros históricos e propostas. Esta pesquisa diferencia essas categorias e evita chamar todo microformat de “padrão W3C”. O algoritmo de parsing de microformats2 é uma especificação comunitária viva, com implementações interoperáveis; Micropub e Webmention, por sua vez, foram publicados como recomendações W3C.

O que são microformats

A explicação mais simples

Considere este HTML:

<article>
  <h2>Minha primeira nota</h2>
  <p>Publicado em 29 de julho de 2026.</p>
</article>

Uma pessoa entende que existe uma publicação, que ela tem um título e que foi publicada em determinada data. Um programa genérico vê elementos e texto, mas não sabe com segurança o papel de cada trecho.

Com microformats2:

<article class="h-entry">
  <h2 class="p-name">Minha primeira nota</h2>
  <p>
    Publicado em
    <time class="dt-published" datetime="2026-07-29">
      29 de julho de 2026
    </time>.
  </p>
</article>

A página continua legível, acessível e estilizada da mesma forma, mas um parser reconhece:

• um objeto do tipo h-entry;
• uma propriedade name;
• uma propriedade published.

A definição introdutória da comunidade descreve microformats como pequenos padrões de HTML para representar coisas normalmente publicadas na web, como pessoas, eventos, posts, avaliações e tags. A ideia central não é esconder metadados: é acrescentar significado ao conteúdo que já está na página.

O que eles não são

Microformats não são:

• uma nova linguagem de programação;
• uma extensão que o visitante precisa instalar;
• um arquivo paralelo obrigatório;
• uma API com servidor e autenticação;
• uma ontologia capaz de descrever qualquer coisa;
• um mecanismo visual;
• garantia automática de rich snippets no Google;
• substituto para HTML semântico, acessibilidade, RSS, JSON-LD ou APIs quando esses recursos são necessários.

O microformat não “faz” nada sozinho no navegador. Ele cria uma interface de dados no HTML. O valor aparece quando um leitor social, agregador, buscador, extensão, importador, bot ou aplicação interpreta a marcação.

O plural importa

“Microformats” nomeia a abordagem e a família de formatos. h-card, h-entry e h-event são vocabulários diferentes dentro dessa família. “microformats2” é a sintaxe contemporânea que permite processá-los de forma genérica.

Também existem microformats de relação, definidos por valores de rel, por exemplo:

<a href="https://github.com/exemplo" rel="me">Meu GitHub</a>
<a href="/tags/linux" rel="tag">Linux</a>
<a href="/licenca" rel="license">Licença deste conteúdo</a>

Eles expressam a relação entre o documento atual e o destino do link.

A ideia filosófica: a página é o dado

Humanos primeiro, máquinas depois

Os princípios oficiais orientam a:

• resolver um problema específico;
• começar com a solução mais simples possível;
• evoluir a partir de usos reais;
• projetar para pessoas primeiro e máquinas depois;
• preferir dados visíveis a metadados invisíveis;
• reutilizar HTML semântico e padrões interoperáveis;
• manter formatos modulares e incorporáveis;
• favorecer desenvolvimento e publicação descentralizados.

Isso não significa ignorar máquinas. Significa que o conteúdo principal não deve existir apenas em uma camada invisível e possivelmente desatualizada. Quando a data que o parser lê é a mesma que a pessoa vê, a chance de divergência diminui.

DRY: não repetir o mesmo fato

Imagine uma data exibida em português e repetida em um bloco separado:

<p>29 de julho de 2026</p>
<meta name="data-interna" content="2026-07-28">

Uma manutenção incompleta já criou uma contradição. O HTML moderno permite manter a apresentação humana e o valor preciso no mesmo elemento:

<time class="dt-published" datetime="2026-07-29">
  29 de julho de 2026
</time>

Há duas representações necessárias, mas uma única unidade visível e semântica. É uma aplicação prática de DRY, não uma proibição absoluta de valores legíveis por máquina.

“Pavimentar os caminhos já usados”

O processo de criação de microformats observa como as pessoas publicam determinada informação, documenta exemplos reais e só então procura os padrões recorrentes. A metodologia oficial chama isso de “pave the cowpaths”: padronizar caminhos que já existem, em vez de inventar um esquema ideal sem uso comprovado.

O procedimento geral é:

1. definir o problema e os casos de uso;
2. recolher exemplos reais de publicação;
3. estudar formatos anteriores;
4. identificar propriedades recorrentes;
5. favorecer o conjunto pequeno que resolve a maioria dos casos;
6. criar propostas;
7. conseguir publicadores e consumidores independentes;
8. revisar a proposta conforme o uso real.

Esse empirismo ajuda a explicar por que os vocabulários são relativamente pequenos e por que propriedades experimentais não têm o mesmo peso que propriedades amplamente publicadas e consumidas.

Como os microformats surgiram

Antes do nome: antecedentes

A web já possuía HTML semântico, links tipados e formatos específicos, como vCard para contatos e iCalendar para eventos. O problema era a distância entre o documento que uma pessoa lia e os dados que uma aplicação importava.

Em 21 de março de 2000, Dan Connolly sugeriu usar XHTML como fonte primária de dados: se uma versão legível por humanos já precisava existir, por que não partir dela? A cronologia oficial considera essa a referência conceitual mais antiga encontrada, mas deixa claro que os fundadores de XFN e microformats só conheceram o texto anos depois. É um antecedente paralelo, não uma linha direta de autoria.

2003: relações entre pessoas e links

Em 11 de março de 2003, durante uma sessão no SXSW Interactive, Tantek Çelik propôs usar rel="friend" em links de blogroll. Três dias depois, Kevin Marks apresentou Vote Links, uma experiência para expressar concordância ou discordância em links.

No dia 15 de dezembro de 2003, Tantek Çelik, Eric Meyer e Matthew Mullenweg lançaram o XHTML Friends Network, ou XFN, versão 1.0. Ele permitia descrever relações humanas usando o atributo rel:

<a href="https://ana.example/" rel="friend met">Ana</a>

O exemplo declara que a autora considera Ana uma amiga e que as duas já se encontraram pessoalmente. A página continua sendo HTML comum; o significado adicional nasce de um vocabulário compartilhado.

2004: “lowercase semantic web” e o termo microformat

Em janeiro de 2004 surgiu o rascunho de XOXO, um formato de listas e outlines baseado em HTML. Em 11 de fevereiro, Tantek Çelik apresentou publicamente a expressão lowercase semantic web, contrapondo uma evolução prática e incremental a projetos mais abrangentes da Web Semântica.

Na mesma data, Tantek Çelik e Kevin Marks fizeram a apresentação “Real World Semantics” na conferência O’Reilly Emerging Technologies. Segundo o registro histórico, ali o termo microformat foi apresentado e definido publicamente. A relação rel="license", para indicar a licença de uma página, também recebeu sua primeira apresentação pública ampla.

Em agosto chegou XFN 1.1, incluindo rel="me" para relacionar páginas que representam a mesma pessoa. Esse pequeno valor ainda tem uso relevante: uma ligação recíproca entre site pessoal e perfil externo pode provar associação entre as duas identidades. Mastodon, por exemplo, usa essa relação na verificação de links de perfil.

Setembro de 2004: hCard e hCalendar

Durante o FOO Camp de 2004 foram concebidos:

• hCard, para publicar pessoas e organizações no HTML, inspirado em vCard;
• hCalendar, para eventos, inspirado em iCalendar.

Esses formatos levaram a abordagem além das relações de links. Passaram a usar classes HTML para identificar objetos e propriedades.

Um hCard clássico usava:

<div class="vcard">
  <span class="fn">Ada Lovelace</span>
</div>

O nome “hCard” era o nome do formato; a classe raiz, entretanto, era vcard, e o nome completo usava fn. Essa diferença e a falta de prefixos uniformes se tornariam relevantes na evolução futura.

2005: comunidade, site e expansão

Em 2005 foram desenvolvidos formatos como hReview, dedicado a avaliações. Houve uma trilha sobre microformats no WWW2005 Dev Day. Em 20 de junho de 2005, microformats.org foi lançado durante um workshop da Supernova.

A definição de lançamento, escrita por Dan Cederholm com ajuda de Tantek Çelik, sintetizou a identidade do projeto: formatos simples e abertos, construídos sobre padrões existentes, projetados para humanos primeiro e máquinas depois.

Nos anos seguintes surgiram ou amadureceram formatos para entradas de blog, currículos, receitas, produtos, geolocalização, listas e outros domínios. Empresas, buscadores, ferramentas de navegador e plataformas sociais experimentaram ou adotaram partes desse ecossistema.

Os limites da primeira geração

Os microformats clássicos, depois chamados informalmente de microformats1 ou mf1, provaram a ideia, mas acumularam dificuldades:

• a classe raiz nem sempre lembrava o nome do formato;
• propriedades como url, photo ou summary podiam colidir com classes usadas para CSS;
• o parser precisava conhecer cada vocabulário;
• o parser também precisava saber antecipadamente se uma propriedade era texto, URL ou data;
• cada novo formato exigia atualização nas bibliotecas;
• existiam padrões especiais e exceções históricas;
• misturar e aninhar vocabulários podia produzir ambiguidades.

Por exemplo, url não dizia ao parser por si só que o valor deveria vir de href; published não informava que precisava de regras de data. A biblioteca necessitava de uma tabela específica para cada vocabulário.

2010: nasce o microformats2

Em 2 de maio de 2010, durante uma sessão no FOO East, foi proposta e explorada a reformulação chamada microformats2.

O objetivo não era abandonar a filosofia original. Era aprender com anos de publicação, parsing, microdata e RDFa e tornar o sistema:

• mais previsível para quem escreve;
• mais simples para quem implementa parsers;
• extensível sem alterar o algoritmo a cada novo vocabulário;
• compatível, quando possível, com o conteúdo clássico existente.

A grande solução foram os prefixos. Em u-photo, o u- já informa que o valor é uma URL. Em dt-published, dt- já informa que se trata de data ou hora. h-entry identifica de forma explícita uma raiz.

2014 a 2017: encontro com a padronização da Web Social

Em 2014, o W3C abriu o Social Web Working Group. Seu charter histórico reconheceu formatos e protocolos usados pela comunidade IndieWeb, incluindo h-entry, h-card, h-cite, Webmention e IndieAuth.

Em 2017, Webmention e Micropub chegaram a recomendações W3C. Microformats2 não virou, como um todo, uma recomendação W3C. A distinção correta é:

• a sintaxe de parsing e os vocabulários são mantidos como especificações abertas da comunidade microformats;
• Micropub, recomendação W3C, usa os vocabulários de microformats2 e seu formato JSON;
• Webmention, recomendação W3C, transporta a notificação entre URLs; microformats2 é frequentemente usado depois para extrair autor, conteúdo, tipo de interação e outros dados da página de origem.

Em 2026, um novo Social Web Working Group do W3C foi aberto para manter recomendações como Micropub, Webmention, ActivityPub e WebSub. Isso não muda o status comunitário dos vocabulários mf2, mas mostra que os protocolos com os quais eles se integram continuam relevantes.

Da primeira geração ao microformats2

Microformats2 substitui a sintaxe clássica para novos projetos. Parsers maduros ainda podem oferecer compatibilidade com mf1, o que ajuda a consumir páginas antigas. Não há motivo para começar uma implementação nova com vcard ou hentry, exceto quando um consumidor legado comprovadamente exigir classes de compatibilidade.

A gramática do microformats2

h-*: a raiz de um objeto

Uma classe iniciada por h- declara que o elemento representa um objeto estruturado:

<div class="h-card">...</div>
<article class="h-entry">...</article>
<section class="h-event">...</section>

A letra remete a “hypermedia”. A raiz delimita onde suas propriedades serão procuradas.

p-*: texto simples

Use p- para propriedades cujo valor principal é texto:

<h1 class="p-name">Construindo uma web pessoal</h1>
<p class="p-summary">Um guia curto para começar.</p>
<a class="p-category" href="/tags/indieweb">IndieWeb</a>

O parser normalmente extrai o texto visível. Certos elementos possuem regras específicas, como img usando alt.

u-*: URLs

Use u- para endereços:

<a class="u-url" href="https://example.com/post/">Link permanente</a>
<img class="u-photo" src="/imagem.jpg" alt="Descrição da imagem">
<a class="u-in-reply-to" href="https://outra.example/post/">Em resposta a</a>

O parser sabe procurar o atributo apropriado, como href, src ou data, e resolver URLs relativas com base no endereço do documento.

dt-*: datas, horas e durações

O elemento time é a forma mais clara:

<time class="dt-published" datetime="2026-07-29T14:30:00-03:00">
  29 de julho de 2026, às 14h30
</time>

O visitante lê a representação natural; a máquina recebe uma data inequívoca com fuso. O algoritmo de parsing dá prioridade ao atributo datetime em elementos adequados.

Evite publicar horários importantes sem fuso quando representam um instante global. 2026-07-29T14:30:00-03:00 é mais preciso que 29/07/26 14:30.

e-*: HTML incorporado

Use e- quando preservar a marcação interna é parte do dado:

<div class="e-content">
  <p>Este é o <strong>conteúdo completo</strong> da publicação.</p>
</div>

O resultado canônico inclui, em geral, uma forma textual e uma forma HTML. Isso permite a um leitor mostrar links, ênfase, listas e imagens do post, em vez de receber apenas texto achatado.

As propriedades são opcionais e repetíveis

Microformats2 define objetos como conjuntos de propriedades opcionais e capazes de ter vários valores. Uma publicação pode ter várias categorias:

<a class="p-category" href="/tags/html">HTML</a>
<a class="p-category" href="/tags/indieweb">IndieWeb</a>

O JSON resultante guarda arrays mesmo quando existe um único valor. Uma aplicação que espera apenas um autor ou uma URL deve escolher conscientemente como tratar valores adicionais, normalmente usando o primeiro valor válido.

Uma classe pode cumprir vários papéis

Microformats convivem com CSS e outras classes:

<a
  class="p-name u-url nome-do-autor text-lg"
  href="https://example.com/"
>
  Pablo Murad
</a>

p-name fornece texto, u-url fornece URL, e as demais classes podem ser usadas pelo projeto. Não é preciso criar elementos extras.

Microformats aninhados

Um objeto pode ser propriedade de outro. Uma h-entry pode conter uma h-card como autor:

<article class="h-entry">
  <h1 class="p-name">Uma publicação</h1>

  <a class="p-author h-card" href="https://example.com/">
    Pablo Murad
  </a>
</article>

O mesmo elemento é:

• a propriedade author da entrada;
• a raiz de um novo objeto h-card.

O parser retorna o autor como objeto estruturado, não apenas como string.

Propriedades implícitas

Para os casos mais simples, o algoritmo pode inferir name, url e photo.

<a class="h-card" href="https://example.com/">Pablo Murad</a>

Gera conceitualmente:

{
  "type": ["h-card"],
  "properties": {
    "name": ["Pablo Murad"],
    "url": ["https://example.com/"]
  }
}

Essa conveniência é ótima em uma menção curta. Em componentes complexos, propriedades explícitas costumam ser mais fáceis de revisar.

Value Class Pattern

O Value Class Pattern permite extrair apenas partes de um elemento ou combinar fragmentos. Ele é útil quando a apresentação visual separa data e horário:

<p class="dt-start">
  <time class="value" datetime="2026-08-15">15 de agosto</time>,
  às <time class="value">19:30</time>
</p>

Um parser pode compor os valores. Para projetos novos, não use esse padrão por reflexo. Um único <time datetime="..."> costuma ser mais simples e menos sujeito a erros.

Relações rel

Além de objetos baseados em classes, o parser coleta relações em links:

<a href="https://social.example/@pablo" rel="me">Perfil social</a>
<a href="/tags/fedora" rel="tag">Fedora</a>
<a href="https://creativecommons.org/licenses/by/4.0/" rel="license">
  CC BY 4.0
</a>

O JSON canônico de uma página possui, em alto nível:

{
  "items": [],
  "rels": {},
  "rel-urls": {}
}

items contém objetos h-*. rels agrupa os destinos por relação. rel-urls preserva informações por URL, como texto do link, mídia e outras relações encontradas.

Principais vocabulários

A página principal da especificação lista os vocabulários atuais. Alguns têm uso muito mais amplo do que outros.

h-card: pessoas e organizações

É o ponto de partida mais útil. Pode representar:

• a identidade principal de um site pessoal;
• o autor de uma publicação;
• uma organização;
• um participante;
• um contato;
• um local ou estabelecimento, quando combinado com endereço e coordenadas.

Propriedades comuns:

Exemplo:

<section class="h-card">
  <img
    class="u-photo"
    src="https://example.com/images/pablo.webp"
    alt="Retrato de Pablo Murad"
  >

  <h2>
    <a class="p-name u-url" href="https://example.com/">
      Pablo Murad
    </a>
  </h2>

  <p class="p-note">
    Programador, escritor e entusiasta de servidores autohospedados.
  </p>

  <a class="u-email" href="mailto:contato@example.com">
    contato@example.com
  </a>
</section>

Privacidade: tudo isso é publicável e raspável. Não marque endereço residencial, telefone pessoal ou e-mail que você não queira expor. Microformats facilitam a leitura por software, inclusive software indesejado.

h-entry: publicações

h-entry representa conteúdo datado ou episódico:

• artigos;
• notas curtas;
• fotos;
• respostas;
• curtidas;
• republicações;
• check-ins;
• vídeos;
• áudio;
• registros de alterações.

Propriedades centrais incluem:

Exemplo completo:

<article class="h-entry">
  <header>
    <h1 class="p-name">
      Microformats devolvem contexto ao HTML
    </h1>

    <p>
      Por
      <a class="p-author h-card" href="https://example.com/">
        Pablo Murad
      </a>
      em
      <time
        class="dt-published"
        datetime="2026-07-29T10:00:00-03:00"
      >
        29 de julho de 2026
      </time>
    </p>
  </header>

  <p class="p-summary">
    Uma introdução curta à marcação legível por pessoas e máquinas.
  </p>

  <div class="e-content">
    <p>
      A ideia é marcar o conteúdo que já existe, sem criar uma segunda
      versão invisível do artigo.
    </p>
  </div>

  <footer>
    <a class="u-url" href="https://example.com/microformats">
      Link permanente
    </a>

    <a class="p-category" href="https://example.com/tags/html">
      HTML
    </a>
  </footer>
</article>

h-feed: uma coleção de publicações

h-feed transforma uma página inicial, arquivo ou listagem em um feed HTML:

<main class="h-feed">
  <h1 class="p-name">Publicações de Pablo</h1>

  <a class="p-author h-card" href="https://example.com/">
    Pablo Murad
  </a>

  <article class="h-entry">
    <h2 class="p-name">
      <a class="u-url" href="/posts/primeira/">Primeira publicação</a>
    </h2>
  </article>

  <article class="h-entry">
    <h2 class="p-name">
      <a class="u-url" href="/posts/segunda/">Segunda publicação</a>
    </h2>
  </article>
</main>

Segundo a especificação de h-feed, as h-entry aninhadas aparecem como filhos do feed. Isso possibilita que um leitor descubra e acompanhe publicações diretamente do HTML.

Um feed HTML não precisa substituir RSS ou Atom. Oferecer ambos amplia a compatibilidade:

<link
  rel="alternate"
  type="application/rss+xml"
  title="RSS"
  href="/rss/"
>

h-event: eventos

Propriedades comuns:

• p-name;
• p-summary;
• dt-start;
• dt-end;
• dt-duration;
• p-location, que pode conter h-card, h-adr ou h-geo;
• u-url;
• p-category.

<article class="h-event">
  <h2 class="p-name">Encontro de software livre</h2>

  <p class="p-summary">
    Conversa aberta sobre Fedora, BSD e autohospedagem.
  </p>

  <p>
    <time class="dt-start" datetime="2026-08-15T19:00:00-03:00">
      15 de agosto de 2026, às 19h
    </time>
    até
    <time class="dt-end" datetime="2026-08-15T22:00:00-03:00">
      22h
    </time>
  </p>

  <div class="p-location h-card">
    <span class="p-name">Espaço Comunitário Exemplo</span>
    <span class="p-adr h-adr">
      <span class="p-locality">São Paulo</span>
    </span>
  </div>

  <a class="u-url" href="https://example.com/eventos/encontro">
    Página do evento
  </a>
</article>

Outros vocabulários

h-cite é amplamente usado na IndieWeb para descrever a publicação citada, respondida, curtida ou republicada, embora sua situação documental seja menos consolidada que a dos vocabulários principais. Em vez de pressupor suporte universal, teste os consumidores que pretende atender.

O que um parser realmente produz

O algoritmo de parsing de microformats2 é independente dos vocabulários. Em linhas gerais, ele:

1. interpreta o documento segundo as regras de HTML;
2. encontra raízes h-*;
3. recolhe propriedades prefixadas dentro de cada raiz;
4. aplica a regra correspondente a texto, URL, data ou HTML;
5. processa objetos aninhados;
6. infere propriedades simples quando permitido;
7. coleta relações rel;
8. retorna uma estrutura JSON canônica.

Para a entrada:

<article class="h-entry">
  <h1 class="p-name">Olá, web aberta</h1>
  <a class="u-url" href="https://example.com/ola">Permalink</a>
  <time class="dt-published" datetime="2026-07-29">Hoje</time>
  <div class="e-content"><p>Minha primeira nota.</p></div>
</article>

O resultado é semelhante a:

{
  "items": [
    {
      "type": ["h-entry"],
      "properties": {
        "name": ["Olá, web aberta"],
        "url": ["https://example.com/ola"],
        "published": ["2026-07-29"],
        "content": [
          {
            "html": "<p>Minha primeira nota.</p>",
            "value": "Minha primeira nota."
          }
        ]
      }
    }
  ],
  "rels": {},
  "rel-urls": {}
}

Dois detalhes são essenciais:

• nomes de propriedades perdem o prefixo no JSON: p-name vira name;
• valores são arrays, mesmo quando há somente um.

Essa serialização não deve ser confundida com JSON-LD. É a representação canônica do resultado de parsing mf2 e também serve como base para requisições e respostas complexas do Micropub.

Relação com a IndieWeb

Identidade com h-card e rel="me"

Em um site pessoal, uma h-card representativa descreve quem o site representa. Links rel="me" conectam outras páginas da mesma identidade:

<div class="h-card">
  <a class="p-name u-url" href="https://pablo.example/">
    Pablo Murad
  </a>

  <a
    class="u-url"
    href="https://social.example/@pablo"
    rel="me"
  >
    Perfil social
  </a>
</div>

Uma ligação de volta no perfil externo torna a associação bidirecional. De acordo com a documentação de rel="me", esse padrão pode ser usado para consolidação de identidade e verificação de domínio.

Isso prova controle suficiente para criar os links nas duas pontas. Não prova identidade civil, confiabilidade ou autoria de todo conteúdo.

Publicações com h-entry

Uma h-entry oferece a leitores e serviços dados como:

• quem publicou;
• quando;
• qual é a URL canônica;
• qual é o conteúdo;
• se é uma resposta, curtida ou republicação;
• onde há cópias sindicadas.

Essa estrutura permite que páginas HTML participem de experiências sociais sem depender do formato interno do CMS.

Feeds HTML com h-feed

Um leitor pode processar a página inicial ou o arquivo como h-feed, extrair as entradas e acompanhar atualizações. O site ainda pode manter RSS ou Atom para consumidores tradicionais.

Webmention

Webmention é um protocolo para uma URL avisar outra de que a mencionou. O fluxo básico é:

1. a página de origem cria um link para a página de destino;
2. o remetente descobre o endpoint Webmention do destino;
3. envia source e target;
4. o receptor busca source;
5. confirma que o link para target realmente existe;
6. armazena ou atualiza a menção.

Microformats2 não é obrigatório para verificar a existência do link. Porém, depois da verificação, um receptor pode interpretar a h-entry de origem para apresentar:

• nome e avatar do autor;
• trecho do conteúdo;
• data;
• tipo de interação;
• permalink.

Sem mf2, o receptor pode fazer uma prévia simples, usar metadados alternativos ou mostrar somente a URL.

Micropub

Micropub é uma API aberta para criar, atualizar e remover conteúdo no próprio site por meio de clientes externos.

Uma criação simples, codificada como formulário, pode usar:

h=entry&content=Olá%20mundo&category[]=indieweb&category[]=html

Uma criação em JSON usa a estrutura de microformats2:

{
  "type": ["h-entry"],
  "properties": {
    "content": ["Olá mundo"],
    "category": ["indieweb", "html"]
  }
}

O microformat no HTML é a representação publicada; a estrutura mf2 em Micropub funciona como modelo de dados entre cliente e servidor. O servidor não precisa salvar internamente o conteúdo nessa forma, desde que cumpra o protocolo.

Post Type Discovery

Na IndieWeb, o tipo de post pode ser inferido pelas propriedades:

• name + conteúdo longo sugere artigo;
• photo sugere foto;
• in-reply-to sugere resposta;
• like-of sugere curtida;
• repost-of sugere republicação;
• video ou audio sugerem mídia.

A vantagem é evitar dezenas de classes-raiz diferentes. Muitos tipos sociais continuam sendo h-entry; suas propriedades descrevem a intenção.

Microformats, HTML semântico, Schema.org e Open Graph

Essas tecnologias não são concorrentes perfeitas. Elas servem a consumidores e objetivos diferentes.

Microformats não substituem HTML semântico

Prefira:

<article class="h-entry">
  <h1 class="p-name">Título</h1>
  <time class="dt-published" datetime="2026-07-29">29 de julho</time>
</article>

em vez de transformar tudo em div e span. As classes acrescentam uma camada; os elementos continuam responsáveis pela estrutura básica.

Microformats não garantem rich results

A documentação do Google informa suporte, para seus recursos de dados estruturados, a JSON-LD, Microdata e RDFa, recomendando normalmente JSON-LD por facilidade de manutenção. Microformats2 não aparece como formato atual para elegibilidade aos rich results documentados.

Portanto:

• use mf2 quando quiser interoperabilidade com IndieWeb, leitores, parsers e ferramentas compatíveis;
• use Schema.org no formato recomendado pela documentação específica do buscador quando quiser concorrer a recursos enriquecidos;
• não remova mf2 só porque também existe JSON-LD;
• mantenha os dois coerentes com o conteúdo visível.

Uma pilha sensata para um artigo é:

HTML semântico
    + microformats2 para web aberta/IndieWeb
    + JSON-LD Schema.org para buscadores
    + Open Graph para prévias
    + RSS ou Atom para leitores tradicionais

Cada camada tem um consumidor real.

A vantagem e o risco dos dados visíveis

Com mf2, uma mudança no texto visível tende a atualizar também o valor extraído. Com JSON-LD, o CMS pode gerar um bloco rico sem alterar a estrutura visual, o que facilita dados complexos, mas também cria o risco de o bloco ficar divergente.

Não há vencedor universal. A escolha deve considerar:

• consumidores desejados;
• capacidade do CMS;
• complexidade do modelo;
• facilidade de teste;
• risco de duplicação;
• custo de manutenção.

Implementação prática em um site pessoal

Etapa 1: marque a identidade principal

Na página inicial ou no cabeçalho:

<header class="h-card">
  <img
    class="u-photo"
    src="/images/avatar.webp"
    width="160"
    height="160"
    alt="Pablo Murad sorrindo diante de uma estante"
  >

  <h1>
    <a class="p-name u-url" href="https://example.com/">
      Pablo Murad
    </a>
  </h1>

  <p class="p-note">
    Escrevo sobre software, web independente e autohospedagem.
  </p>

  <nav aria-label="Perfis de Pablo">
    <a href="https://github.com/example" rel="me">GitHub</a>
    <a href="https://social.example/@pablo" rel="me">Fediverso</a>
  </nav>
</header>

Use uma URL absoluta e estável como u-url. Faça os perfis externos apontarem de volta quando suportarem link de site.

Etapa 2: marque cada página individual como h-entry

O permalink é a fonte canônica da entrada:

<article class="h-entry">
  <header>
    <h1 class="p-name">Título do artigo</h1>

    <a class="p-author h-card" href="https://example.com/">
      Pablo Murad
    </a>

    <time
      class="dt-published"
      datetime="2026-07-29T09:00:00-03:00"
    >
      29 de julho de 2026
    </time>
  </header>

  <div class="e-content">
    <p>Conteúdo do artigo.</p>
  </div>

  <a class="u-url" href="https://example.com/artigos/titulo">
    Permalink
  </a>
</article>

O ideal é que a h-entry seja um item de nível superior no permalink, não acidentalmente aninhada dentro de outra raiz que mude seu papel no resultado.

Etapa 3: marque listagens como h-feed

Na homepage e em arquivos:

<main class="h-feed">
  <h1 class="p-name">Artigos recentes</h1>

  <!-- cards de listagem, cada um com h-entry -->
</main>

Em cada card:

<article class="h-entry">
  <h2 class="p-name">
    <a class="u-url" href="https://example.com/artigos/titulo">
      Título do artigo
    </a>
  </h2>

  <time class="dt-published" datetime="2026-07-29">
    29 de julho de 2026
  </time>

  <p class="p-summary">Resumo visível do artigo.</p>
</article>

Não marque como e-content um resumo truncado se ele não é o conteúdo completo que deseja fornecer ao consumidor. Use p-summary.

Etapa 4: declare interações

Resposta:

<a class="u-in-reply-to" href="https://outra.example/post/123">
  Em resposta a esta publicação
</a>

Curtida:

<a class="u-like-of" href="https://outra.example/post/456">
  Curti esta publicação
</a>

Republicação:

<a class="u-repost-of" href="https://outra.example/post/789">
  Republicação
</a>

Cópia em outra rede:

<a class="u-syndication" href="https://social.example/@pablo/123">
  Ver cópia no Fediverso
</a>

Essas propriedades precisam estar dentro da h-entry correspondente.

Etapa 5: preserve descoberta de protocolos e feeds

No head:

<link rel="canonical" href="https://example.com/artigos/titulo">
<link rel="alternate" type="application/rss+xml" href="/rss/">
<link rel="webmention" href="https://example.com/webmention">

As relações de descoberta não são propriedades da h-entry, mas fazem parte de uma implementação completa.

Exemplo para um tema Ghost

Em um template de post do Ghost, a estrutura conceitual pode ser:

{{#post}}
<article class="{{post_class}} h-entry">
  <header>
    <h1 class="p-name">{{title}}</h1>

    {{#primary_author}}
      <a class="p-author h-card" href="{{url absolute="true"}}">
        {{#if profile_image}}
          <img
            class="u-photo"
            src="{{img_url profile_image size="xs"}}"
            alt=""
          >
        {{/if}}
        <span class="p-name">{{name}}</span>
      </a>
    {{/primary_author}}

    <time
      class="dt-published"
      datetime="{{date format="YYYY-MM-DDTHH:mm:ssZ"}}"
    >
      {{date format="DD [de] MMMM [de] YYYY"}}
    </time>
  </header>

  {{#if custom_excerpt}}
    <p class="p-summary">{{custom_excerpt}}</p>
  {{/if}}

  <div class="e-content">
    {{content}}
  </div>

  <a class="u-url" href="{{url absolute="true"}}">
    Link permanente
  </a>

  {{#foreach tags}}
    <a class="p-category" href="{{url absolute="true"}}">{{name}}</a>
  {{/foreach}}
</article>
{{/post}}

Cuidados:

• confirme o formato de data efetivamente produzido pelo helper na versão do Ghost;
• não use texto alternativo redundante em um avatar meramente decorativo junto ao nome; se a imagem acrescenta informação, escreva um alt útil;
• mantenha o u-url absoluto;
• marque o conteúdo renderizado completo como e-content;
• evite uma h-card global invisível duplicando dados sem necessidade;
• teste o HTML final entregue pelo servidor, não apenas o template.

Em cards de listagem, use h-entry, p-name, u-url, dt-published e p-summary. Não replique o artigo completo se a página só mostra um resumo.

Exemplo para Astro

Um componente Post.astro simples:

---
const {
  title,
  description,
  published,
  updated,
  canonicalURL,
  author,
} = Astro.props;
---

<article class="h-entry">
  <header>
    <h1 class="p-name">{title}</h1>

    <a class="p-author h-card" href={author.url}>
      {author.photo && (
        <img class="u-photo" src={author.photo} alt="" width="48" height="48" />
      )}
      <span class="p-name">{author.name}</span>
    </a>

    <time class="dt-published" datetime={published.toISOString()}>
      {published.toLocaleDateString("pt-BR")}
    </time>

    {updated && (
      <time class="dt-updated" datetime={updated.toISOString()}>
        Atualizado em {updated.toLocaleDateString("pt-BR")}
      </time>
    )}
  </header>

  {description && <p class="p-summary">{description}</p>}

  <div class="e-content">
    <slot />
  </div>

  <a class="u-url" href={canonicalURL}>Link permanente</a>
</article>

Cuidados específicos:

• published precisa ser um Date válido antes de chamar toISOString();
• URLs relativas devem ser resolvidas contra Astro.site;
• o HTML final precisa conter o conteúdo; um componente que só aparece após JavaScript pode não atender consumidores que não executam scripts;
• valide páginas geradas em produção, pois base URL e caminhos de imagens podem mudar no build.

Como testar e validar

Parser online

O caminho mais rápido é o parser do pin13, que aceita uma URL e mostra a estrutura mf2 extraída.

Verifique:

• existe exatamente a h-card representativa esperada?
• o permalink produz uma h-entry de nível superior?
• name, author, published, content e url têm os valores corretos?
• o conteúdo HTML foi preservado?
• URLs relativas foram resolvidas?
• as entradas de uma listagem aparecem dentro de h-feed?
• rel="me" e outras relações aparecem em rels?

Um parser mostra o que a máquina leu; ele é mais útil do que revisar classes apenas a olho.

JavaScript e Node.js

O repositório oficial microformats-parser oferece parser para navegador e Node.js, com compatibilidade mf1.

Instalação:

npm install microformats-parser

Exemplo conforme a API da versão instalada:

const { mf2 } = require("microformats-parser");

const html = `
  <article class="h-entry">
    <h1 class="p-name">Teste local</h1>
  </article>
`;

const result = mf2(html, {
  baseUrl: "https://example.com/"
});

console.log(JSON.stringify(result, null, 2));

Confira o README da versão instalada, pois assinaturas e opções de bibliotecas podem evoluir.

Python

mf2py é uma implementação em Python:

python -m pip install mf2py

Exemplo:

import mf2py

parsed = mf2py.parse(url="https://example.com/post/")
print(parsed)

Use timeouts, limites de tamanho e proteção contra SSRF antes de permitir que usuários forneçam URLs a um parser executado no servidor.

PHP

php-mf2 é um parser genérico para PHP. É instalado normalmente pelo Composer:

composer require mf2/mf2

Consulte a documentação do pacote para a API atual. Assim como em Python e Node, buscar URLs arbitrárias exige controles de rede.

Testes automatizados

A organização microformats mantém uma suíte compartilhada de testes. Ela é útil para autores de parsers e também como catálogo de casos-limite.

Para um site, uma automação mais simples costuma bastar:

1. gerar ou acessar uma página de exemplo;
2. executar um parser;
3. localizar a primeira h-entry;
4. confirmar tipo e propriedades obrigatórias do projeto;
5. falhar o build quando um template remove a marcação.

Exemplo de intenção:

entrada.type contém "h-entry"
entrada.properties.name[0] não está vazio
entrada.properties.url[0] é a URL canônica
entrada.properties.published[0] é uma data válida
entrada.properties.content[0].html contém o corpo esperado

Microformats2 não torna essas propriedades universalmente obrigatórias. Elas são obrigatórias para a política do seu site, o que é diferente.

Valide também o restante

Uma página pode ter mf2 perfeito e continuar ruim. Faça ainda:

• validação de HTML;
• teste de teclado;
• auditoria de headings;
• verificação de texto alternativo;
• conferência de datas e fusos;
• teste do RSS/Atom;
• Rich Results Test para Schema.org, se usado;
• teste de Webmention, se implementado;
• inspeção sem JavaScript.

Erros comuns

Usar classes sem raiz

Errado:

<h1 class="p-name">Título</h1>

Sem uma raiz h-*, a propriedade não pertence a um objeto microformat.

Correto:

<article class="h-entry">
  <h1 class="p-name">Título</h1>
</article>

Escolher o prefixo errado

Evite:

<a class="p-url" href="/post">Post</a>
<span class="p-published">2026-07-29</span>
<div class="p-content"><strong>Texto</strong></div>

Prefira:

<a class="u-url" href="/post">Post</a>
<time class="dt-published" datetime="2026-07-29">29 de julho</time>
<div class="e-content"><strong>Texto</strong></div>

Colocar autor fora da entrada

Uma h-card no cabeçalho do site não garante que todo consumidor atribuirá automaticamente cada h-entry a ela. A inferência de autoria tem convenções próprias e pode variar.

A opção robusta é associar o autor dentro da entrada:

<a class="p-author h-card" href="https://example.com/">Pablo Murad</a>

Criar vários candidatos a identidade principal

Um cabeçalho, um rodapé, uma página de equipe e cada autor podem produzir várias h-card. Isso não é errado, mas pode dificultar a descoberta da identidade representativa.

Defina uma h-card principal clara na homepage e inspecione o JSON final. Não esconda cópias adicionais só para “reforçar” a informação.

Duplicar metadados escondidos

Evite:

<span class="p-author" hidden>Pablo Murad</span>
<span class="dt-published" hidden>2026-07-29</span>

Se o autor e a data já aparecem, marque os elementos visíveis. Dados escondidos podem ficar obsoletos e contrariam o espírito do formato.

Há casos legítimos para valores técnicos não visíveis, mas devem ser exceção justificada, não a arquitetura padrão.

Data ambígua ou sem fuso

29/07/26 depende de contexto. Para um instante preciso:

<time datetime="2026-07-29T18:45:00-03:00" class="dt-published">
  29 de julho de 2026, às 18h45
</time>

Marcar resumo como conteúdo completo

Em listagens, e-content pode induzir o leitor a tratar um trecho como o corpo inteiro. Use p-summary quando a página exibe apenas uma sinopse.

Esquecer o permalink

Uma entrada sem u-url pode ser legível, mas é menos útil para leitores, Webmentions e deduplicação. Prefira URL absoluta e canônica.

Confiar apenas no nome da classe

Uma classe digitada corretamente pode estar no elemento errado, fora da raiz ou capturar conteúdo inesperado. Sempre veja o JSON do parser.

Tratar mf2 como recurso de SEO

Implementar microformats exclusivamente esperando rich snippets é uma expectativa errada. Use a documentação específica do buscador e Schema.org para esse objetivo.

Alterar o visual para satisfazer o formato

Microformats devem se adaptar ao conteúdo real. Se a marcação exige muitos blocos artificiais ou texto duplicado, reveja a estrutura. É normal acrescentar uma data, autor ou permalink que também melhora a experiência humana; não é normal poluir a página com um painel de metadados só para o parser.

Segurança, privacidade e robustez

Publicação consciente

Uma h-card facilita exportação e reutilização. Isso inclui coleta automatizada. Publique somente:

• e-mail destinado ao público;
• telefone comercial;
• cidade ou região quando necessário;
• endereço físico de negócio, não residência;
• imagem cuja reutilização pública você aceita.

Parsing de páginas remotas

Um serviço que aceita uma URL para extrair microformats precisa se proteger contra:

• SSRF contra localhost, rede interna e metadados de nuvem;
• redirecionamentos para endereços privados;
• respostas enormes;
• HTML profundamente aninhado;
• compactação abusiva;
• respostas lentas;
• tipos de conteúdo inesperados;
• URLs com credenciais;
• excesso de requisições;
• HTML malicioso exibido sem sanitização.

Controles mínimos:

• permitir apenas HTTP e HTTPS;
• resolver DNS e bloquear faixas privadas, loopback e link-local;
• validar novamente cada redirecionamento;
• usar timeout curto;
• limitar bytes baixados e quantidade de redirecionamentos;
• não executar JavaScript;
• analisar em processo isolado quando o risco justificar;
• sanitizar e-content antes de republicar HTML;
• guardar cache e aplicar rate limit.

Webmention tem preocupações semelhantes. A especificação recomenda impedir acesso a recursos locais e limitar buscas.

Conteúdo não é confiança

Uma página pode declarar:

<span class="p-author h-card">Pessoa famosa</span>

Isso não prova que a pessoa famosa publicou a página. Microformats representam afirmações feitas pelo documento. Confiança depende de domínio, autenticação, assinatura, links verificáveis e contexto.

O que ainda torna microformats relevante

HTML como API de baixo custo

Uma API tradicional exige rota, versão, documentação, autenticação em alguns casos e manutenção separada. Microformats não substituem APIs transacionais ou consultas complexas, mas fornecem uma interface pública básica quase sem infraestrutura adicional.

Um pequeno site estático pode publicar dados interoperáveis sem servidor de aplicação.

Independência do CMS

WordPress, Ghost, Astro, Hugo, Eleventy ou HTML manual podem produzir a mesma h-entry. O consumidor não precisa conhecer a estrutura interna de cada plataforma.

Degradação elegante

Se nenhum parser visitar a página, ela continua sendo uma página. Se o CSS falhar, a estrutura permanece. Se o JavaScript não executar, o HTML ainda contém os dados.

Componibilidade

Uma h-card pode estar dentro de h-entry, h-event ou h-review. Um h-feed agrega entradas. As mesmas propriedades aparecem em contextos diferentes.

Limites reais

O ecossistema é menor que o de Schema.org e JSON-LD em SEO. Parte da documentação comunitária é antiga ou tem status de rascunho. Ferramentas podem implementar subconjuntos. Alguns vocabulários têm poucos consumidores modernos.

Isso não invalida o formato, mas muda a estratégia:

• implemente primeiro o núcleo de uso comprovado;
• teste com consumidores reais;
• não acrescente dezenas de propriedades só porque existem;
• mantenha RSS, JSON-LD e Open Graph quando eles atendem outros públicos;
• trate microformats como uma camada útil, não como religião tecnológica.

Um roteiro de adoção em quatro níveis

Nível 1: identidade

Tempo aproximado: menos de uma hora em um site simples.

• adicionar uma h-card visível;
• marcar nome, URL e foto;
• adicionar links rel="me";
• validar a homepage.

Nível 2: publicações

• colocar h-entry em artigos e notas;
• marcar p-name, e-content, dt-published, p-author e u-url;
• usar p-summary em cards;
• validar um artigo com e sem imagem.

Nível 3: descoberta

• colocar h-feed em homepage e arquivos;
• manter RSS ou Atom;
• usar URLs absolutas e canônicas;
• verificar paginação;
• testar um leitor ou consumidor compatível.

Nível 4: recursos sociais

• receber e enviar Webmentions;
• marcar respostas, curtidas e republicações;
• expor endpoint Micropub;
• testar segurança de busca remota;
• automatizar regressões de parsing.

Não comece pelo nível 4 se a identidade e os permalinks ainda estão inconsistentes.

Checklist de implementação

Identidade

• Existe uma h-card principal visível.
• p-name contém o nome correto.
• u-url aponta para a URL canônica do site.
• u-photo tem imagem estável e texto alternativo adequado.
• Links de identidade usam rel="me" somente quando representam a mesma pessoa ou organização.
• Dados pessoais sensíveis foram excluídos.

Publicação

• Cada permalink contém uma h-entry.
• O título usa p-name quando existe.
• O corpo completo usa e-content.
• O resumo usa p-summary.
• O autor está associado por p-author, idealmente como h-card.
• A data usa dt-published e datetime.
• Alterações relevantes podem usar dt-updated.
• O permalink absoluto usa u-url.
• Tags visíveis usam p-category.

Feed

• A listagem possui h-feed.
• Cada item é uma h-entry.
• Cards não fingem conter o artigo completo.
• Paginação mantém marcação válida.
• RSS ou Atom continua disponível quando útil.

Qualidade

• A página funciona sem JavaScript.
• O HTML é semanticamente apropriado.
• O parser retorna o objeto esperado.
• Não há propriedades importantes vazias.
• Não há metadados ocultos divergentes.
• URLs relativas são resolvidas corretamente.
• Datas incluem fuso quando necessário.
• O teste foi feito na URL publicada.

Recomendações práticas

Para um site pessoal, blog ou projeto IndieWeb, a melhor combinação inicial é:

1. h-card na homepage, com nome, URL, foto e uma descrição curta.
2. h-entry em cada publicação, com autor, data, conteúdo e permalink.
3. h-feed nas páginas de listagem, sem remover RSS.
4. rel="me" nos perfis realmente equivalentes, preferencialmente com ligação de volta.
5. Validação no pin13 e em um parser local, guardando uma página de teste como regressão.
6. JSON-LD separado para Schema.org, quando houver objetivo de busca compatível.
7. Webmention somente depois do núcleo, com validação de URLs, limites e sanitização.

Para o seu contexto específico, Ghost e Astro conseguem produzir mf2 sem plugins pesados. O melhor é editar os componentes ou templates que já renderizam autor, data, título, conteúdo e cards. Acrescente as classes neles, em vez de criar uma segunda árvore escondida.

Não tente marcar tudo de uma vez. Uma implementação pequena, visível e testada vale mais que vinte propriedades que nenhum consumidor usa e ninguém confere.

Conclusão

Microformats surgiu de uma pergunta prática: como fazer o HTML que já publicamos carregar significado suficiente para ser reutilizado por software? A resposta começou com relações em links, amadureceu em formatos como XFN, hCard e hCalendar e, depois de anos de uso, ganhou uma gramática mais uniforme em microformats2.

Seu maior valor não está na quantidade de vocabulários. Está na decisão arquitetural de tratar a página visível como fonte de dados. Isso aproxima conteúdo, semântica e interoperabilidade, reduz dependência de plataformas e permite que um site simples participe de leitores, feeds HTML, publicação via Micropub e conversas por Webmention.

Microformats2 não venceu todas as disputas de dados estruturados, nem precisa vencer. Ele funciona melhor como uma camada discreta da web aberta: HTML semântico para todos, propriedades legíveis por parsers, Schema.org quando o buscador exige, Open Graph para prévias e RSS para leitores tradicionais.

Para aprender de verdade, o próximo passo não é memorizar todos os vocabulários. É marcar uma página real com h-card, h-entry e h-feed, abrir o resultado num parser e comparar o que você pretendia dizer com aquilo que a máquina realmente entendeu.

Fontes consultadas

• Microformats.org: o que são microformats
• Microformats.org: introdução
• Microformats.org: sobre o projeto
• Princípios dos microformats
• Processo de desenvolvimento de microformats
• Por que começar por exemplos reais
• História dos microformats
• XHTML Friends Network — XFN
• Microformats2: visão geral e exemplos
• Convenções de prefixos do microformats2
• Especificação de parsing de microformats2
• Formato JSON canônico de microformats2
• Vocabulário h-card
• Vocabulário h-entry
• Vocabulário h-feed
• Vocabulário h-event
• Relação rel=me
• Relação rel=tag
• Relação rel=license
• Value Class Pattern
• Lista de parsers de microformats
• Validadores e parser online
• Pin13 Microformats Parser
• Microformats Parser para JavaScript e Node.js
• mf2py para Python
• php-mf2 para PHP
• Suíte oficial de testes de microformats
• W3C: Recomendação Webmention
• W3C: Recomendação Micropub
• W3C: charter histórico do Social Web Working Group
• W3C: charter do Social Web Working Group de 2026
• WHATWG: padrão vivo de HTML
• Google Search Central: introdução a dados estruturados
• Google Search Central: diretrizes gerais de dados estruturados

Nota sobre atualidade

Pesquisa concluída em 29 de julho de 2026. Microformats2 é uma especificação viva e alguns vocabulários são rascunhos comunitários. Bibliotecas, propriedades experimentais, consumidores e regras de plataformas podem mudar; confirme decisões de implementação nas especificações e repositórios oficiais.