Frontmatter do Conteúdo: Campos e Metadados SEO

Frontmatter é o elemento da página que os leitores nunca veem como um bloco e do qual todo sistema de publicação depende. Ele dá a um documento uma identidade, contrato de renderização, pré-visualização de busca, registro de propriedade, datas e entradas de schema. Um frontmatter quebrado pode selecionar o template errado, criar conflitos canônicos, perder o autor ou emitir marcação que contradiz a página.

O exemplar vivo é um registro ao nível do documento, exibido como código porque o frontmatter não deve se tornar uma caixa decorativa no corpo.

+++
entity = "guide-how-to"
id = "reset-api-key"
title = "How to Reset an API Key"
seoTitle = "How to Reset an API Key Safely"
description = "Reset an API key safely, replace it in every dependent service, verify the new credential, and revoke the exposed key without avoidable downtime."
url = "/academy/reset-an-api-key/"
image = "/images/academy/reset-api-key.png"
imageAlt = "API key settings with the Rotate key action highlighted"
date = "2026-08-27 10:00:00"
updated = "2026-09-03 14:30:00"
author = "maya-chen"
reviewedBy = "alex-rivera"
keywords = [ "reset API key", "rotate API key", "revoke API key" ]
taxonomy = [ "security", "account-administration" ]
canonical = "https://amicited.com/academy/reset-an-api-key/"

[[faq]]
question = "Does rotating an API key revoke the old key immediately?"
answer = "Not necessarily. Confirm the provider's rotation behavior before changing dependent services."
+++

Por que o frontmatter existe

Para um leitor, os metadados reduzem a incerteza. Um título preciso define o escopo, uma descrição útil conquista o clique, as identidades tornam as afirmações responsáveis e as datas revelam se a informação pode estar desatualizada. Esses sinais não compensam conteúdo fraco, mas sua ausência força o leitor a adivinhar.

Para as máquinas, o frontmatter substitui inferência por valores nomeados. Os templates mapeiam campos para títulos do navegador, links canônicos, registros de pessoas, datas, feeds, índices e JSON-LD sem extrair informações do texto. Isso é extraibilidade mecânica: fatos importantes têm uma localização e tipo consistentes.

Siga as regras de escrita de elementos: os metadados pertencem ao nível do documento; os elementos voltados ao leitor pertencem ao corpo. Uma linha de assinatura pode ser renderizada a partir do frontmatter, mas seu identificador autoritativo permanece lá.

Quando usar — e quando não usar

Toda página indexável precisa de um registro de frontmatter para identidade, renderização e roteamento. Rascunhos precisam dele quando entram em produção para que a validação possa falhar cedo.

Não oculte fatos do artigo no frontmatter. Limitações do produto, avisos de segurança, divulgações de afiliados, métodos e fontes devem permanecer visíveis onde os leitores possam avaliá-los. Um valor estruturado nunca substitui uma divulgação.

Quase-acertos causam mais dano:

• Rótulos de navegação, cópia de campanha e legendas sociais que variam independentemente são configurações de canal; não sobrecarregue o title.
• Fatos da organização compartilhados em todo o site pertencem ao registro da organização do site, não copiados em cada página onde se desviarão.
• Uma seção de perguntas e respostas pertence a [[faq]] apenas quando o mesmo conteúdo é renderizado visivelmente. FAQ oculto apenas para schema é inválido.
• Um rótulo de tópico pertence à taxonomy; não deve substituir a entity que identifica o tipo de postagem do documento.
• Um redirecionamento pertence à configuração de roteamento ou a um campo de aliases aprovado. O canonical identifica a versão preferida; ele não redireciona visitantes.

Onde posicionar

O frontmatter começa no primeiro byte com +++ e termina no delimitador correspondente antes do corpo. Nenhum cabeçalho, comentário, nota, shortcode ou bloco de metadados pode precedê-lo. Campos e arrays TOML pertencem a esse único registro.

O corpo começa após o delimitador de fechamento. O frontmatter não pode ficar entre o H1 e a introdução, ao lado de uma captura de tela, dentro de um componente ou no final. Uma marca de ordem de byte ou um comentário perdido pode impedir o reconhecimento. Chaves duplicadas, delimitadores YAML e segundos blocos são inválidos.

Anatomia

A legenda renderizada permanece na página para que permaneça legível e traduzível independentemente da imagem:

1. Limite: os delimitadores de abertura e fechamento +++ definem a única região de metadados.
2. Identidade: entity, id, type e url informam aos sistemas o que é o documento e onde ele está.
3. Descoberta: title, seoTitle, description, image, imageAlt e keywords apoiam pré-visualizações e recuperação.
4. Proveniência: date, updated, author e reviewedBy indicam quem é responsável e quando o trabalho foi validamente alterado.
5. Classificação: taxonomy junta a página a coleções de tópicos controladas sem redefinir sua identidade.
6. Controle de duplicação: canonical nomeia a URL pública preferida quando versões equivalentes podem ser alcançadas em outro lugar.
7. Coleções estruturadas: cada [[faq]] cria um registro tipificado de pergunta e resposta para renderização visível e schema.

Exemplos de design

O frontmatter tem variantes de contrato de dados, não estilos visuais. As capturas de tela emparelham registros fonte com sua pré-visualização ou linha de assinatura resultante.

Parâmetros

Estes são limites editoriais mesmo quando um analisador aceita mais. “Condicional” significa obrigatório quando sua condição declarada é verdadeira.

Referência por campo

Esta referência define o contrato de publicação para cada campo. “Obrigatório” significa que a validação deve interromper a publicação quando o campo ou sua derivação válida estiver ausente. “Condicional” significa que o requisito é ativado por um fato declarado, como uma imagem ser renderizada ou uma revisão independente ter ocorrido. Um padrão é seguro apenas quando produz o mesmo significado que um editor teria escolhido deliberadamente.

Identidade e roteamento

title, h1 e seoTitle

• Propósito — title dá ao documento seu nome editorial durável. h1 controla o cabeçalho principal na página quando o contexto do layout precisa de uma redação diferente. seoTitle controla o título do navegador/busca quando o padrão precisa de um qualificador conciso ou tratamento de marca. Separar esses campos evita que um rótulo de navegação, um cabeçalho de página e uma pré-visualização de busca sejam forçados em uma única string estranha.
• Tipo e formato — Cada um é uma string de texto simples. title é o valor fonte; substituições ausentes devem recorrer a ele. HTML, Markdown, decoração com emojis e marcas de truncamento manual não são valores válidos.
• Obrigatório? — title é obrigatório em toda página pública. h1 e seoTitle são opcionais e devem ser omitidos quando title funciona em todos os três contextos.
• Limites — Use 30–70 caracteres para title, 20–80 para h1 e 30–60 para seoTitle como faixas editoriais, não promessas de que uma interface de busca exibirá todos os caracteres. Deve haver um H1 renderizado.
• Quem ou o que consome — Templates de página, títulos do navegador, adaptadores de busca e redes sociais, cards de navegação, feeds, headline do schema, esquemas de acessibilidade e listagens editoriais.
• Regras — Todas as versões devem identificar o mesmo assunto, intenção e escopo. Uma diferença legítima resolve uma restrição de canal: por exemplo, o H1 pode dizer “Como Rotacionar uma Chave de API Sem Indisponibilidade”, enquanto o título SEO mais curto diz “Rotação de Chave de API: Guia Passo a Passo Seguro”. A seção posterior Título, H1 e título SEO explica o teste editorial.
• Erros comuns — Repetir uma palavra-chave nas três variantes, colocar um sufixo de marca no H1, mudar a promessa para perseguir cliques, incorporar o ano atual quando a página não é mantida anualmente, ou criar três valores meramente porque três campos existem.

slug e url

• Propósito — O slug é o segmento final do caminho; url é a rota pública relativa ao site que o contém. Juntos, eles dão à página um endereço estável para leitores, rastreadores, links, relatórios e migrações. A estabilidade é importante porque cada link conquistado e marcador salvo se torna dependente desse endereço.
• Tipo e formato — Use uma string de caminho em minúsculo, separada por hífen, como /academy/rotate-an-api-key/. Este repositório registra a rota completa em url; um CMS que possui um campo slug separado deve derivar o mesmo segmento final.
• Obrigatório? — Uma rota única é obrigatória para toda página pública. Pode ser gerada apenas onde uma seção tem uma regra determinística aprovada e verificações de colisão; as páginas do manual usam seus valores de url registrados.
• Limites — Prefira um slug curto e legível que preserve o assunto distintivo, geralmente de três a oito palavras úteis. Remova pontuação e modificadores vazios. Remova palavras de paragem como “o” ou “um” apenas quando o resultado permanecer natural e inequívoco; não há limite arbitrário de caracteres que justifique danificar o significado.
• Quem ou o que consome — Roteamento Hugo, links internos, breadcrumbs, geração canônica, sitemaps, feeds, análises, redirecionamentos e referências externas.
• Regras — Trate um slug publicado como um compromisso permanente. Decida-o a partir do tópico durável, não de um título de campanha ou ano transitório. Quando o título muda mas o tópico e a intenção não, mantenha o slug antigo. Se a página realmente se mover, crie a nova rota, retenha a rota antiga em aliases, atualize os links internos e teste o destino do redirecionamento.
• Erros comuns — Regenerar o slug sempre que o título muda, incluir sinônimos no caminho, reter datas que fazem o conteúdo perene parecer obsoleto, usar maiúsculas/minúsculas misturadas ou underscores, criar duas URLs que diferem apenas por uma barra final e alterar uma rota sem preservar a antiga.

canonical

• Propósito — Um canonical identifica a URL preferida entre versões equivalentes ou quase equivalentes acessíveis. Ele consolida a identidade; não move um visitante nem desculpa duplicação descontrolada.
• Tipo e formato — Uma URL absoluta HTTPS, incluindo o host pretendido e o caminho normalizado: https://amicited.com/academy/rotate-an-api-key/. O template pode derivar uma auto-referência do permalink da página quando o site tem um host e política de rota confiáveis.
• Obrigatório? — Toda página indexável deve emitir um canonical. O campo em si é condicional quando um valor correto de auto-referência é derivado automaticamente; defina-o explicitamente para um canonical excepcional ou entre domínios aprovado.
• Limites — Exatamente um destino canônico. O destino deve retornar um documento indexável bem-sucedido, usar o protocolo e host preferidos e representar substancialmente o mesmo conteúdo.
• Quem ou o que consome — O HTML <link rel="canonical">, motores de busca, verificações de sitemap e links internos, relatórios de desduplicação e identificadores de URL do schema.
• Regras — Auto-referência por padrão. Use um canonical entre domínios apenas quando outro publisher possui o equivalente preferido e ambas as partes pretendem a consolidação. Use um redirecionamento, não um canonical, quando a URL antiga foi substituída e os usuários devem sempre cair na nova. Mantenha canonical, URL do sitemap, hreflang, links internos e identidade do schema alinhados.
• Erros comuns — Apontar toda página paginada ou localizada para um pai genérico, canonicalizar conteúdo distinto, direcionar uma página de redirecionamento ou erro, misturar HTTP e HTTPS, usar o campo como substituto para um alias e assumir que as diretivas canônicas são garantidamente obedecidas.

aliases

• Propósito — aliases preserva rotas que anteriormente identificavam a mesma página, para que uma mudança não transforme links existentes e marcadores em becos sem saída. Ele registra o histórico de rotas em vez de criar identidades indexáveis alternativas.
• Tipo e formato — Um array TOML de caminhos relativos ao site, por exemplo aliases = [ "/blog/old-api-key-guide/" ]. Cada valor inclui uma barra inicial e final e deve ser único em todo o site.
• Obrigatório? — Opcional para uma página nova; obrigatório quando uma página publicada é movida de um caminho que o site controlava.
• Limites — Inclua toda rota conhecida de primeira parte anterior que ainda recebe links ou tráfego. Não adicione variantes especulativas de ortografia ou uma lista ilimitada de URLs de palavras-chave.
• Quem ou o que consome — A saída de alias do Hugo, processamento de redirecionamento de implantação quando configurado, QA de migração, monitores de link e usuários seguindo URLs antigas. Como o Hugo pode emitir uma página de alias em vez de um redirecionamento HTTP ao nível da origem, o comportamento da implantação deve ser verificado em vez de assumido.
• Regras — Uma página movida mantém seu caminho antigo funcionando. Cada alias deve resolver em um salto para a rota canônica atual. Atualize links internos para a nova URL mesmo quando o alias funciona e preserve o alias em edições posteriores, a menos que um sistema de redirecionamento documentado o substitua.
• Erros comuns — Excluir a página antiga sem um alias, encadear caminho antigo para caminho intermediário para caminho atual, tratar aliases como rotas de publicação duplicadas, apontar várias páginas não relacionadas para um destino conveniente ou assumir que a saída local do Hugo comprova o status HTTP de produção.

type e layout

• Propósito — Esses campos selecionam o contrato de renderização. type coloca uma página em uma classe de conteúdo com templates e comportamento compartilhados; layout solicita um template específico dentro dessa classe. A seleção correta garante que a página receba a navegação pretendida, slot de conteúdo, ativos e comportamento de schema.
• Tipo e formato — Strings registradas em minúsculo. Esta página usa type = "academy". Um valor de layout é um nome base de template como single, sem extensão de arquivo ou travessia de caminho.
• Obrigatório? — type é obrigatório quando a localização do conteúdo não implica seguramente o tipo pretendido ou quando o contrato do manual o exige. layout é opcional e deve ser omitido quando o template padrão do tipo está correto.
• Limites — Um valor para cada campo, escolhido apenas entre templates mantidos pelo site. Um novo valor é uma mudança de engenharia, não uma improvisação editorial.
• Quem ou o que consome — Ordem de busca do Hugo, templates, seleção de parciais, inclusão de CSS e JavaScript, adaptadores de schema e regras de validação.
• Regras — Escolha o tipo de postagem e o contrato de renderização antes de redigir. Use layout apenas para uma variante genuinamente suportada; não o use para compensar conteúdo que pertence a outro type. Verifique se uma substituição existe e aceita a forma do frontmatter da página.
• Erros comuns — Confundir a entity editorial com o type Hugo, nomear um arquivo de template que não existe, copiar um tipo de landing page em um documento academy, confiar na inferência de pasta durante uma migração e introduzir nomes de layout únicos que contornam melhorias compartilhadas.

Descoberta

description

• Propósito — A descrição ajuda um pesquisador qualificado ou destinatário de compartilhamento a decidir se esta página atende à necessidade. É cópia de pré-visualização, não uma introdução compactada e não um lugar para provar relevância através de repetição.
• Tipo e formato — Uma frase em texto simples. Deve nomear o termo principal naturalmente, declarar o valor concreto e adicionar escopo, público, método ou resultado útil.
• Obrigatório? — Obrigatório para toda página indexável neste manual.
• Limites — 150–160 caracteres, incluindo espaços. Esta é uma faixa de consistência editorial, não uma garantia de exibição: os motores de busca podem truncá-la ou reescrever o snippet a partir do conteúdo do corpo quando outra passagem se adequa melhor à consulta.
• Quem ou o que consome — Tags meta description, padrões de descrição Open Graph e Twitter, cards de listagem, feeds, pré-visualizações CMS, verificações de qualidade de busca e, às vezes, description do schema.
• Regras — Escreva para um clique do leitor certo. Torne a frase específica o suficiente para distinguir a página de outro resultado com um título semelhante. A seção Regras de descrição abaixo fornece a fundamentação e os testes de rejeição.
• Erros comuns — Duplicar o título, listar palavras-chave, começar com “Aprenda tudo sobre”, fazer uma afirmação não apoiada de melhor ou mais rápido, usar uma chamada para ação vaga, exceder a faixa devido a um sufixo de marca invisível ou assumir que o texto escrito deve aparecer literalmente nos resultados de busca.

keywords

• Propósito — Neste repositório, keywords registra o conjunto compacto de consultas e terminologia usado para QA editorial, busca no corpus, análise de cobertura e ferramentas internas. Ajuda os editores a reconhecer a linguagem que uma página deve usar com precisão; não é uma promessa de incluir cada frase mecanicamente.
• Tipo e formato — Um array de strings em linguagem natural, ordenadas do termo principal através de variantes significativas e terminologia intimamente relacionada.
• Obrigatório? — Obrigatório neste manual, incluindo páginas cujos templates públicos não renderizam os valores.
• Limites — Seis a oito entradas distintas. Cada entrada deve representar uma frase de consulta real ou termo necessário, não uma variação ao nível do token.
• Quem ou o que consome — Validadores editoriais, inventários de conteúdo, análise de busca e oportunidade, recuperação interna e ferramentas de migração. Os motores de busca públicos não usam este campo como sinal de ranking apenas porque ele existe.
• Regras — Mantenha o conjunto focado no escopo de uma página. Mescle maiúsculas/minúsculas, pontuação, singular/plural e duplicatas triviais de ordem de palavras. Use as frases para verificar cobertura e terminologia, nunca para ditar densidade não natural.
• Erros comuns — Tratar o campo como o mecanismo obsoleto de meta-keywords de ranking, adicionar dezenas de variantes, repetir o título como oito quase-duplicatas, inserir nomes de concorrentes que o corpo não discute e permitir que o array substitua a taxonomia adequada ou alvos de prompt.

targetPrompts

• Propósito — targetPrompts registra as perguntas ou solicitações completas que uma pessoa pode dar a um sistema de resposta de IA e para as quais esta página deve ser uma fonte útil. Os alvos de prompt preservam o contexto conversacional que frases curtas de palavras-chave omitem.
• Tipo e formato — Um array de strings completas em linguagem natural, por exemplo targetPrompts = [ "How do I rotate an API key without downtime?", "What should I check before revoking an old API key?" ]. Mantenha a redação como um usuário perguntaria, incluindo público, restrições ou comparação desejada.
• Obrigatório? — Condicional para páginas incluídas no rastreamento de prompts ou em um programa de conteúdo de visibilidade de IA; opcional quando não existe um conjunto de prompts rastreado.
• Limites — Use um conjunto pequeno e intencional, normalmente um prompt principal e até quatro variantes significativas. Um prompt pode ser mais longo que uma palavra-chave porque seus qualificadores carregam intenção.
• Quem ou o que consome — Briefings de conteúdo, fluxos de trabalho de rastreamento de prompts, auditorias de recuperação e cobertura, monitoramento de respostas de IA e avaliação editorial. Não é renderizado como texto de busca oculto.
• Regras — Separe prompts por necessidade real de informação, não por pontuação. Uma palavra-chave como “rotação de chave de API” nomeia um tópico; “Como uma equipe SaaS pode rotacionar uma chave de API sem interromper integrações?” nomeia um público, tarefa e restrição. A página deve responder honestamente a cada prompt armazenado.
• Erros comuns — Copiar o array de keywords para este campo, fabricar dezenas de variações sintáticas, registrar prompts mais amplos que a página, usar prompts como cabeçalhos do corpo independentemente do fluxo de leitura e afirmar cobertura de prompt quando a resposta depende de informações que a página não fornece.

Confiança e proveniência

date e updated

• Propósito — date preserva quando a página foi publicada pela primeira vez; updated informa a última alteração substantiva ou revisão concluída. Dois campos preservam o histórico enquanto mostram se a informação na qual os leitores confiam mudou.
• Tipo e formato — Strings de timestamp na convenção do site, AAAA-MM-DD HH:MM:SS. Mantenha uma política de fuso horário em todo o corpus para que feeds e comparações permaneçam determinísticos.
• Obrigatório? — date é obrigatório para páginas editoriais publicadas. updated é opcional até que ocorra uma alteração qualificante, então obrigatório se a página apresentar uma data modificada.
• Limites — Um valor cada. updated não pode preceder date nem estar no futuro. Uma correção feita minutos após a publicação ainda pode ser documentada, mas revisões rotineiras de rascunho antes da publicação não criam uma data atualizada.
• Quem ou o que consome — Linhas de assinatura e selos de atualização visíveis, feeds, sitemaps, datePublished e dateModified do schema, auditorias de atualização, ordenação e filas editoriais.
• Regras — Redefina updated para uma correção factual, instrução alterada, evidência nova ou removida, escopo revisado, recomendação materialmente alterada ou uma revisão documentada de afirmações sensíveis ao tempo. Nunca redefina para pontuação, formatação, trabalho de template ou uma edição apenas de timestamp. Veja Datas, autores e revisores para a fundamentação da política.
• Erros comuns — Sobrescrever a data original durante uma atualização, datar uma página no futuro para parecer nova, atualizar datas sem um diff de conteúdo, tratar uma implantação automatizada como uma atualização editorial e não registrar o que mudou no histórico de atualizações mantido.

author

• Propósito — author conecta o documento à entidade de pessoa responsável pelo seu trabalho. O link dá ao leitor e à máquina um caminho de uma página que faz afirmações para uma identidade mantida, especialização e outros trabalhos.
• Tipo e formato — Um identificador de autor estável que resolve através do registro de autores do site para uma URL de perfil e registro Person. Por exemplo, author = "maya-chen" é válido apenas se esse identificador resolver; um nome de exibição como "Maya Chen, SEO Expert" não é um substituto para o link de entidade.
• Obrigatório? — Obrigatório para páginas editoriais substantivas. Páginas transacionais podem usar um proprietário organizacional governado apenas quando o template e a política suportam esse tipo de entidade.
• Limites — Um responsável principal por padrão; use um array de identificadores documentado apenas quando o schema e os templates de linha de assinatura suportam coautoria genuína.
• Quem ou o que consome — Linhas de assinatura visíveis, links de perfil do autor, schema Article, feeds, relatórios de propriedade editorial, fluxos de trabalho de revisão e grafos de entidade.
• Regras — Resolva o identificador antes da publicação. O perfil deve identificar a mesma pessoa mostrada na linha de assinatura e permanecer mantido. Credite a pessoa responsável pelo conteúdo, não a pessoa que meramente o carregou.
• Erros comuns — Inserir uma string de nome não vinculada, usar “Admin” ou uma equipe editorial inventada, atribuir um executivo proeminente que não escreveu o trabalho, permitir que um identificador resolva para nenhum perfil e mudar a autoria para implicar especialização que não esteve envolvida.

reviewedBy, reviewedAt e reviewScope

• Propósito — Estes campos registram uma revisão independente distinta da autoria. reviewedBy identifica a entidade revisora; reviewedAt indica quando a revisão foi concluída; reviewScope diz o que o revisor verificou, para que o selo não implique aprovação além da evidência.
• Tipo e formato — reviewedBy é um identificador estável que resolve para um perfil de pessoa mantido. reviewedAt usa o formato de timestamp do site. reviewScope é uma declaração concisa em texto simples, como “Etapas de rotação de credenciais e avisos de segurança.”
• Obrigatório? — Condicional quando a lei, política de risco, sensibilidade do assunto ou a especificação do tipo de postagem exigem revisão independente. Quando reviewedBy está presente, a data e o escopo da revisão são obrigatórios como dados do registro de revisão, mesmo que um template específico os armazene em um registro editorial conectado em vez do frontmatter público.
• Limites — Nomeie apenas revisores reais. O escopo deve ser específico o suficiente para revelar exclusões sem se tornar um relatório de revisão. Um revisor deve ter competência relevante e não deve simplesmente duplicar o papel do autor.
• Quem ou o que consome — Componentes de “revisado por”, junções de entidade de pessoa, auditorias de governança, portões de publicação de alto risco, proveniência estruturada e logs de atualização.
• Regras — Complete a revisão após o conteúdo estar estável, capture descobertas e resolução no histórico editorial e reavalie quando alterações posteriores afetarem o escopo revisado. Independente significa que o revisor testa o trabalho em vez de endossar seu próprio rascunho.
• Erros comuns — Tratar revisão de texto como revisão especializada, exibir um revisor sem data ou escopo, nomear alguém que nunca viu a versão final, deixar o selo após uma reescrita substancial não revisada e implicar aprovação legal, médica ou técnica fora do escopo declarado.

Mídia e redes sociais

image e imageAlt

• Propósito — image seleciona o hero representativo e o ativo social; imageAlt fornece a alternativa textual funcional quando esse ativo é renderizado como conteúdo de página significativo. Manter o par junto evita que imagens de descoberta se tornem uma omissão de acessibilidade.
• Tipo e formato — image é um caminho de site resolvível ou URL absoluta aprovada. imageAlt é texto simples descrevendo a informação útil da imagem no contexto da página, não seu nome de arquivo ou palavra-chave alvo.
• Obrigatório? — Condicional por tipo de postagem e template. Se a página requer um hero ou imagem social dedicada, image é obrigatório. imageAlt é obrigatório sempre que essa imagem renderiza de forma informativa; uma renderização puramente decorativa deve usar um atributo alt vazio no template, não texto descritivo inventado.
• Limites — Use um ativo representativo. Para compatibilidade social, forneça uma fonte de 1200 × 630 pixels na proporção de corte esperada, mantenha o conteúdo importante longe das bordas e mantenha imageAlt conciso — normalmente 5–160 caracteres. O arquivo deve existir antes de ser referenciado.
• Quem ou o que consome — Componentes hero, cards de listagem, tags Open Graph e Twitter, campos de imagem do schema, feeds, pipelines de imagem, leitores de tela quando visível e QA de ativos.
• Regras — Escolha uma imagem que ainda comunique após um corte central e em tamanho de miniatura. Descreva sua função no contexto: “Configurações de chave de API com Rotate key destacado” é útil; “Chave de API” não é. Não coloque afirmações essenciais apenas dentro de pixels.
• Erros comuns — Referenciar um ativo planejado que não existe, usar um logotipo como imagem de todo artigo, incorporar texto pequeno que se torna ilegível em compartilhamentos, escrever “imagem de,” colocar palavras-chave no texto alternativo e assumir que o comportamento do texto alternativo social e da imagem visível são idênticos entre plataformas.

Campos Open Graph e Twitter card

• Propósito — Os metadados sociais controlam como uma URL é resumida quando compartilhada. Um título, descrição, URL, tipo e imagem consistentes ajudam os destinatários a reconhecer a página antes de clicar e reduzem a chance de uma plataforma selecionar um ativo irrelevante.
• Tipo e formato — Neste repositório, os templates derivam og:title e twitter:title de title, descrições de description, URLs do permalink, og:type do contexto do layout e ambas as tags de imagem de image com um fallback do site. twitter:card é emitido como summary_large_image. Estas são tags geradas, não campos de frontmatter duplicados por padrão.
• Obrigatório? — As tags de saída são obrigatórias em páginas públicas. Substituições separadas são opcionais e devem ser introduzidas apenas através de um contrato de template documentado; campos ad hoc não suportados como ogTitle não fazem nada.
• Limites — Uma pré-visualização coerente por página e uma imagem representativa de 1200 × 630. Mantenha a redação derivada dentro das faixas de título e descrição e teste o comportamento real de corte e sobreposição nas principais superfícies de compartilhamento.
• Quem ou o que consome — Redes sociais, clientes de mensagens, expansores de links, extensões de navegador, ferramentas de colaboração e depuradores de pré-visualização de compartilhamento.
• Regras — Prefira derivação para que as afirmações de busca e sociais permaneçam alinhadas. Substitua apenas quando o contexto social genuinamente precisa de um enquadramento diferente e o template o suporta. Uma imagem errada custa reconhecimento e confiança: o destinatário pode ver uma interface obsoleta, outro produto, uma afirmação enganosa ou um corte que esconde o assunto.
• Erros comuns — Criar campos que nenhum template lê, permitir que um fallback global mascare um hero obrigatório ausente, usar uma imagem retrato ou minúscula para um card largo, alterar o texto social para fazer uma promessa mais forte que a página e validar apenas o código fonte HTML em vez de uma pré-visualização obtida.

Classificação

taxonomy, categories e tags

• Propósito — A classificação conecta uma página a coleções governadas de tópico, formato, público ou produto. Ela alimenta arquivos e filtros úteis apenas quando cada vocabulário tem um significado declarado; caso contrário, os rótulos tornam-se uma pilha de sinônimos não controlados.
• Tipo e formato — Arrays de slugs registrados em minúsculo. Use taxonomy para o vocabulário de tópico controlado do repositório. Use categories apenas para uma pequena hierarquia editorial mutuamente inteligível e tags apenas para um vocabulário transversal governado quando essas taxonomias estão configuradas.
• Obrigatório? — Condicional ao tipo de postagem e design do arquivo. Páginas editoriais baseadas em tópico normalmente exigem um ou mais termos controlados; páginas utilitárias podem não exigir nenhum. Um campo não deve ser preenchido meramente porque um CMS o expõe.
• Limites — Para taxonomia geral, de um a cinco valores por vocabulário controlado. Cada termo precisa de uma definição, proprietário e regra de mesclagem. Crie um arquivo indexável apenas quando o termo representa demanda durável do leitor e o arquivo pode oferecer uma introdução única, inventário coerente, links internos e manutenção contínua.
• Quem ou o que consome — Páginas de arquivo, breadcrumbs, filtros, sistemas de conteúdo relacionado, navegação facetada, auditorias de conteúdo e segmentação de análises.
• Regras — Escolha o termo registrado mais restrito que agrupa a página com precisão. Mantenha singular/plural, abreviações e variantes ortográficas mapeadas para um valor canônico. Decida se os arquivos são indexáveis ao nível do vocabulário, não tag por tag após criação acidental.
• Erros comuns — Usar seo, SEO, otimizacao-busca e otimização de busca como valores separados, adicionar tags únicas para descrever cada substantivo, confundir um tipo de negócio com um tópico, gerar arquivos indexáveis com conteúdo fino e excluir termos sem migrar seus membros.

Chaves de junção do manual

• Propósito — playbookPillar, playbookFamily, playbookWave, postTypes, elements, businessTypes, journeyStage e amicitedFeatures são chaves de junção tipificadas. Elas permitem que uma página fonte apareça em bibliotecas e matrizes geradas sem que editores copiem cards manualmente. Esta página é o exemplo prático: seu pilar identifica um elemento, sua família agrupa orientações de metadados e seu array postTypes declara as especificações que a consomem.
• Tipo e formato — Chaves singulares usam slugs registrados em minúsculo: playbookPillar e playbookFamily são strings, playbookWave é um inteiro e journeyStage é uma string controlada. Chaves de relacionamento — postTypes, elements, businessTypes e amicitedFeatures — são arrays de slugs registrados de seus respectivos registros.
• Obrigatório? — playbookPillar e playbookWave são obrigatórios em registros do manual. playbookFamily é obrigatório quando o pilar tem famílias governadas. As junções de array e journeyStage são condicionais: popule apenas relacionamentos que o contrato da página realmente suporta.
• Limites — Um pilar, uma família dentro desse pilar, uma onda e um estágio de jornada, a menos que o modelo permita explicitamente múltiplos estágios. Arrays contêm chaves registradas únicas, não rótulos de exibição, prosa ou URLs.
• Quem ou o que consome — Listagens do hub do manual, matrizes entre pilares, filtros, cards de relacionamento, relatórios de completude, visualizações de onda e ferramentas internas que encontram capacidades relevantes do AmICited.
• Regras — Valide cada valor contra o registro canônico. A direção importa: uma página de tipo de postagem lista seus elements obrigatórios; uma página de elemento lista postTypes aplicáveis; uma página de tipo de negócio lista tipos de postagem úteis. Trate rótulos como apresentação e chaves como dados duráveis. Renomeie uma chave apenas através de uma migração que atualize cada lado da junção.
• Erros comuns — Inventar quase-sinônimos, armazenar títulos em vez de slugs, misturar inteiros e strings para ondas, adicionar um relacionamento porque duas páginas se mencionam, permitir que arrays recíprocos se contradigam e criar marcação de listagem mantida manualmente que se desvia dos metadados.

Campos derivados e estruturais

schemaType

• Propósito — schemaType seleciona o mapeamento de dados estruturados suportado mais específico que descreve com precisão a página visível. Ele diz ao adaptador de schema qual contrato de vocabulário aplicar; não transforma a página nessa coisa apenas por declaração.
• Tipo e formato — Um nome de tipo Schema.org registrado, como Article, selecionado entre os tipos que o adaptador do site suporta. Maiúsculas/minúsculas e ortografia devem corresponder ao registro.
• Obrigatório? — Condicional. Defina-o onde múltiplos mapeamentos de schema são válidos para o mesmo tipo Hugo ou onde o contrato do tipo de postagem exige um tipo explícito. Caso contrário, deixe o template derivar seu padrão seguro.
• Limites — Um tipo de página principal, com entidades aninhadas criadas pelo adaptador a partir do conteúdo real. O tipo selecionado deve satisfazer todas as propriedades necessárias e corresponder ao que um leitor pode ver.
• Quem ou o que consome — Adaptadores JSON-LD, validação de rich results, QA de conteúdo e relatórios de inventário de schema.
• Regras — Escolha a partir da função da página e evidência visível, não do recurso de busca que um editor deseja. Uma página de instruções sem um procedimento visível completo não pode ganhar precisão definindo um tipo de instruções. Mantenha URLs do schema, datas, pessoas e imagens sincronizados com seus campos fonte.
• Erros comuns — Selecionar um tipo mais específico sem seu conteúdo exigido, emitir vários tipos primários conflitantes, copiar um valor de schema de um template não relacionado, assumir que sintaxe válida garante elegibilidade e colocar afirmações em JSON-LD que os leitores não podem inspecionar.

Tempo de leitura

• Propósito — O tempo de leitura dá ao leitor uma estimativa aproximada de esforço. É derivado do corpo final renderizável para que a estimativa mude quando a carga real de leitura muda.
• Tipo e formato — Um número inteiro computado de minutos produzido a partir da política de contagem de palavras do pipeline de conteúdo. Blocos de código, tabelas, legendas e mídia incorporada devem seguir uma regra de contagem documentada.
• Obrigatório? — A exibição é opcional por template. Um campo de frontmatter escrito não é permitido como fonte da verdade.
• Limites — Arredonde consistentemente e aplique um mínimo de exibição sensato, como um minuto. A suposição precisa de palavras por minuto importa menos do que usar o mesmo método em todo o site e rotular o resultado como uma estimativa.
• Quem ou o que consome — Cabeçalhos de página, cards, feeds, segmentação de análises e leitores decidindo se devem iniciar um guia longo.
• Regras — Calcule após shortcodes e regiões excluídas serem tratados de acordo com a política do site. Recompute a cada build. Se um vídeo ou tarefa interativa alterar materialmente o tempo de conclusão, rotule isso separadamente em vez de corromper o tempo de leitura.
• Erros comuns — Escrever readingTime = 8, esquecer de atualizar após uma reescrita, apresentar falsa precisão, contar navegação e boilerplate e tratar um tutorial pesado em execução como oito minutos de leitura mais nenhum tempo de tarefa.

[[faq]]

• Propósito — [[faq]] armazena pares de perguntas e respostas visíveis uma vez para que a página e quaisquer dados estruturados de FAQ elegíveis não possam se distanciar.
• Tipo e formato — Um array TOML de tabelas; cada item contém uma question em texto simples e uma answer string autocontida.
• Obrigatório? — Condicional quando restam perguntas de acompanhamento genuínas após a página principal. Nunca é obrigatório meramente para preencher um template ou buscar um recurso de busca.
• Limites — Normalmente quatro a oito itens úteis em páginas do manual. Cada pergunta aparece uma vez, e toda resposta deve ser completa sem depender da ordem do acordeão.
• Quem ou o que consome — Renderização de FAQ visível, schema FAQPage quando elegível, navegação da página, QA de conteúdo e extração de respostas.
• Regras — Este é um contrato de referência cruzada: siga Por que o FAQ vive no frontmatter e as orientações posteriores de FAQ em vez de manter cópias separadas visível e de schema. Armazene apenas perguntas que todo leitor pode acessar na página.
• Erros comuns — Respostas ocultas apenas para schema, cabeçalhos duplicados disfarçados de perguntas, respostas promocionais, afirmações não suportadas, JSON-LD desatualizado e tratar a elegibilidade de resultado de busca como garantida.

[[lnks]]

• Propósito — [[lnks]] registra cada link interno governado usado no corpo, emparelhando sua âncora visível com um destino e descrição mantida. O registro torna os links inspecionáveis sem extrair HTML renderizado e suporta migração e QA.
• Tipo e formato — Um array TOML de tabelas com text, path e title. text é a âncora visível exata, path é uma URL relativa ao site com barra inicial e final, e title é a descrição da página de destino.
• Obrigatório? — Obrigatório para cada link interno do corpo governado por esta convenção de conteúdo. Links profundos de aplicativos e fontes externas seguem seus próprios registros e não são disfarçados como entradas [[lnks]].
• Limites — Um registro por ocorrência de link no corpo quando a mesma âncora pode apontar para destinos diferentes; caso contrário, registos duplicados exatos devem ser removidos. O destino deve existir ou estar no registro de slugs canônicos aprovado para o lançamento coordenado.
• Quem ou o que consome — Validação de links internos, migração de conteúdo, análise de relacionamentos, geração de título de link onde suportado e revisão editorial.
• Regras — Corresponda text à âncora do corpo textualmente, incluindo capitalização e pontuação dentro do link. Use o caminho canônico relativo ao site. Escreva title como uma descrição precisa do destino, não como instruções para a página atual. Atualize o registro e o corpo juntos.
• Erros comuns — Usar um valor de text mais longo que a âncora real, inventar um slug não registrado, omitir uma barra final, registrar um caminho antigo que redireciona, descrever a fonte em vez do destino e deixar um registro após seu link no corpo ser removido.

Obrigatório versus opcional por tipo de postagem

A matriz aplica os contratos acima aos doze tipos de postagem atualmente declarados por este elemento. R significa obrigatório, C significa condicional sob as regras do campo, D significa saída obrigatória que pode ser derivada com segurança e O significa opcional. “Identidade” inclui entity, id, title, type e a rota estável. “Descoberta” inclui description e keywords; prompts alvo permanecem condicionais para cada linha. aliases é sempre condicional a uma mudança, enquanto o tempo de leitura escrito nunca é obrigatório.

“Revisor condicional” não é permissão para pular a revisão onde a precisão ou o risco comercial a exige. Páginas de melhor-X e alternativas exigem revisão independente porque suas recomendações podem influenciar materialmente uma decisão e frequentemente mudam conforme produtos, preços e elegibilidade mudam. Para outras linhas, a política de risco, não o tempo disponível do editor, ativa o requisito. Da mesma forma, um canonical marcado como D ainda é obrigatório no HTML renderizado; apenas a entrada do frontmatter pode ser omitida quando o template pode gerar a auto-referência correta.

Validação do frontmatter

A validação deve rejeitar defeitos determinísticos automaticamente e reservar julgamento para questões que dependem de significado, evidência ou competência profissional. A divisão previne duas falhas opostas: pedir que revisores encontrem erros de sintaxe que um analisador pode detectar perfeitamente e fingir que uma regra de contagem de caracteres pode decidir se uma cópia é honesta.

Execute verificações determinísticas antes da revisão editorial para que o revisor veja um registro coerente. Em seguida, revise o HTML renderizado, não apenas o frontmatter: um valor fonte válido ainda é um defeito de produção se o template selecionado o ignora, mapeia para a tag errada, esconde a proveniência necessária ou gera um canonical que discorda da rota pública. A publicação só está completa quando o comportamento da fonte, renderização e destino concordam.

O campo entity

entity responde “qual tipo exato de postagem este documento é uma instância?” Não responde “que tópico esta página discute?” Essa distinção é importante porque dois documentos podem abordar o mesmo tópico enquanto fazem trabalhos diferentes. Uma entrada de glossário define “diagnóstico”; um artigo de blog pode relatar uma mudança na orientação diagnóstica. Se ambos usarem entity = "diagnosis", os sistemas downstream não podem escolher de forma confiável o template correto, regras de validação, grupo de análise ou migração.

Use o prefixo de grupo mais o slug do tipo de postagem para variantes dentro de uma família: guide-how-to, guide-ultimate, comparison-a-vs-b e comparison-alternatives-to-x. Use o nome simples para um tipo autônomo: product-page ou case-study. Registre o identificador uma vez, mantenha-o estável e nunca o altere porque o tópico ou consulta alvo mudou. Coloque conceitos de tópico em taxonomy e linguagem de consulta em keywords.

Título, H1 e título SEO

Estes valores podem diferir por contexto, mas devem descrever a mesma página. title é o padrão durável. h1 é o cabeçalho visível e pode ser mais natural no contexto. seoTitle serve ao navegador e resultados de busca e pode adicionar um diferenciador conciso, ano legítimo ou sufixo de marca.

Por exemplo, title = "Rotação de Chave de API", h1 = "Como Rotacionar uma Chave de API Sem Indisponibilidade" e seoTitle = "Rotação de Chave de API: Guia Passo a Passo Seguro" alinham-se em uma tarefa. “Ferramenta de Segurança Gratuita” como título SEO seria enganoso porque muda a promessa. Não crie diferenças meramente para inserir mais palavras-chave.

Regras de descrição

A descrição existe para ajudar um leitor qualificado a decidir clicar. Mantenha-a entre 150–160 caracteres, inclua o termo principal naturalmente, declare o benefício concreto da página e adicione um qualificador significativo como público, escopo ou resultado. Escreva uma frase fluente, não uma lista de palavras-chave.

O termo confirma relevância; repetição não agrega valor. Não duplique o título, use “Aprenda tudo sobre,” faça superlativos não suportados ou termine no meio do pensamento. Os sistemas de busca ainda podem selecionar texto visível diferente para uma consulta.

Datas, autores e revisores

date preserva o timestamp da primeira publicação. updated registra a última alteração substantiva: uma correção factual, nova evidência, instruções alteradas, escopo revisado, recomendação alterada ou revisão completa que confirma afirmações sensíveis ao tempo. Registre o que mudou no histórico editorial quando a política o exigir.

Corrigir pontuação, alterar um estilo de botão, reconstruir um template ou tocar no timestamp sozinho não redefine updated. Avançar uma data sem trabalho por trás dela é uma violação de política porque diz a leitores e máquinas que o conteúdo foi atualizado quando não foi. É deturpação, não uma tática de crescimento.

Os campos de autor e revisor carregam identidades responsáveis para linhas de assinatura e dados estruturados. O autor é responsável pelo trabalho. Use reviewedBy apenas quando ocorreu uma revisão qualificada e vincule ambos os identificadores a perfis mantidos. A página de fundamentos de confiança explica como autoria, datas, evidências e clareza de entidade apoiam a confiança sem garantir rankings.

Por que o FAQ vive no frontmatter

Um FAQ é conteúdo visível e uma coleção estruturada. Armazená-lo uma vez em [[faq]] permite que o template renderize o acordeão e o FAQPage JSON-LD idêntico, prevenindo schema oculto desatualizado.

Inclua perguntas de acompanhamento genuínas visíveis para todo leitor. Não duplique cabeçalhos, esconda promoções em respostas ou marque perguntas não exibidas. Marcação válida não garante um recurso de busca.

Sintaxe e exemplos de código

O contrato multiplataforma mapeia campos, não um componente visível. O seguinte envelope portátil é válido apenas em um arquivo de intercâmbio cujo importador reconhece diretivas de metadados:

:::frontmatter{entity="guide-how-to" id="reset-api-key" title="How to Reset an API Key"}
description: Reset an API key safely, replace it in dependent services, verify it, and revoke the exposed key without avoidable downtime.
author: maya-chen
:::

Deve ser normalizado para metadados de página nativos durante a importação. Não é válido no corpo de um artigo de produção. No Hugo, o mapeamento correto é TOML entre delimitadores +++ no primeiro byte, como mostrado no exemplar vivo. Não há deliberadamente um shortcode {{< frontmatter >}}: um shortcode executaria tarde demais e na região errada do documento.

No WordPress, mapeie os mesmos campos canônicos para campos de postagem registrados e post meta, por exemplo post_title, post_excerpt, post_name, _amicited_entity, _amicited_author e _amicited_reviewed_by. Um comentário como <!-- wp:amicited/frontmatter --> ou um shortcode [frontmatter] é inválido porque cria um bloco de corpo em vez de metadados de documento. Importadores e editores podem apresentar um painel de metadados, mas os valores armazenados devem permanecer anexados ao registro da postagem.

Exemplos

Bom: um registro coerente e responsável

entity = "guide-how-to"
id = "rotate-api-key"
title = "How to Rotate an API Key"
description = "Rotate an API key safely, update every dependent service, verify the replacement, and revoke the old credential without avoidable downtime."
url = "/academy/rotate-an-api-key/"
date = "2026-08-27 10:00:00"
updated = "2026-09-03 14:30:00"
author = "maya-chen"
reviewedBy = "alex-rivera"
keywords = [ "rotate API key", "API key rotation", "revoke API key", "credential security", "API security", "secret rotation" ]
taxonomy = [ "security", "account-administration" ]
canonical = "https://amicited.com/academy/rotate-an-api-key/"

Isso identifica uma variante de instruções, preserva o histórico, nomeia pessoas responsáveis e separa tópico da identidade da página. O timestamp atualizado é suportado por uma alteração documentada de instrução e revisão.

Ruim: o título repetido como descrição

title = "How to Rotate an API Key"
description = "How to Rotate an API Key"

A descrição não agrega benefício, escopo ou motivo para clicar. Também desperdiça o espaço de pré-visualização que poderia distinguir esta página de todo outro resultado usando o mesmo título.

Ruim: uma entidade reutilizada em dois tipos de postagem

# entrada de glossário
entity = "diagnosis"

# guia editorial
entity = "diagnosis"

O tópico compartilhado substituiu a identidade do tipo de postagem. Use valores registrados como glossary-term e guide-ultimate, depois atribua “diagnóstico” através de taxonomia ou palavras-chave.

Ruim: uma data atualizada sem diff de conteúdo

date = "2026-01-15 09:00:00"
updated = "2026-08-27 10:00:00" # apenas a data mudou

Nenhuma edição ou revisão substantiva suporta a afirmação de atualização. Mantenha updated inalterado ou omitido até que exista uma mudança real que possa ser inspecionada no histórico editorial.

Marcação de schema e acessibilidade

Metadados fornecem valores; o template permanece responsável pelo HTML semântico, foco, contraste, propósito do link e texto alternativo.

Regras de escrita

• Mantenha identificadores estáveis, em minúsculo e seguros para máquinas. Nunca recicle um id ou altere silenciosamente entity após a publicação.
• Use texto simples em campos tipo título. HTML, links Markdown, decoração com emojis e quebras de linha forçadas não pertencem a strings de metadados.
• Mantenha a descrição entre 150–160 caracteres e arrays de palavras-chave entre seis e oito frases distintas para este manual.
• Use pessoas reais registradas para campos de autor e revisor. Nunca crie um revisor cerimonial ou identidade genérica de “Equipe Editorial” a menos que seja uma entidade responsável mantida.
• Use uma taxonomia controlada. Variantes ortográficas e duplicatas singular/plural criam arquivos fragmentados.
• Referencie apenas imagens que existem e têm direitos de publicação. imageAlt descreve o conteúdo informativo da imagem, não seu alvo de SEO.
• Mantenha as respostas do FAQ diretas e autocontidas. As afirmações ainda exigem a mesma evidência e divulgação que a prosa em outros lugares da página.
• Nunca coloque segredos, notas privadas, tokens de acesso, instruções de embargo, dados pessoais ou afirmações legais não revisadas em frontmatter publicável.

Quais tipos de postagem usam frontmatter e onde

Todo tipo de postagem usa frontmatter no primeiro byte. A profundidade exigida muda com risco, intenção e schema, não com design visual.

Lista de verificação de QA

• O arquivo começa com +++, contém TOML válido e fecha o registro antes do conteúdo do corpo?
• entity é um identificador de tipo de postagem exato registrado em vez do tópico, campanha ou nome do site?
• id é único e estável, e url corresponde ao registro de slugs canônicos?
• title, h1 opcional e seoTitle opcional descrevem a mesma página sem alterações enganosas de escopo?
• A descrição tem 150–160 caracteres, contém o termo principal naturalmente e oferece uma razão concreta para clicar?
• Toda imagem referenciada existe, e imageAlt é preciso para a imagem que renderiza?
• A data de publicação está preservada, e todo valor de updated é suportado por um diff substantivo ou revisão documentada?
• Os identificadores de autor e revisor resolvem para perfis reais mantidos, e o revisor nomeado realmente revisou o trabalho?
• As palavras-chave estão limitadas a seis a oito frases úteis e os valores de taxonomia são extraídos de vocabulários controlados?
• O canonical usa HTTPS, resolve para a página preferida e concorda com o sitemap e links internos?
• Cada item de [[faq]] contém uma pergunta útil e resposta autocontida que renderizam visivelmente com redação idêntica?
• O JSON-LD gerado corresponde ao conteúdo visível, usa identificadores estáveis e passa na validação de sintaxe sem reivindicar tipos não suportados?
• Segredos, notas editoriais privadas, afirmações não suportadas e divulgações apenas no corpo estão ausentes do registro?

FAQ

O frontmatter é visível na página publicada?

O registro fonte está oculto, mas os templates podem renderizar o título, pessoas, datas e FAQ. Outros campos alimentam pré-visualizações, tags canônicas, feeds, sitemaps, schema e sistemas internos.

O campo de entidade deve conter o tópico ou o tipo de postagem?

Ele identifica o tipo exato de postagem. Tópicos compartilhados pertencem à taxonomia e palavras-chave, não no lugar da identidade do documento.

O título, H1 e título SEO podem ser diferentes?

Sim. O H1 pode ser mais natural e o título SEO pode adicionar um diferenciador, mas todas as versões devem fazer a mesma promessa.

Quando a data de atualização deve mudar?

Altere após uma revisão ou edição factual substantiva. Não altere por pontuação, estilo, trabalho de template ou uma atualização apenas de data.

Por que as perguntas de FAQ são armazenadas no frontmatter?

O array estruturado permite que uma única fonte renderize tanto o FAQ visível quanto o FAQPage JSON-LD correspondente. Isso evita que o schema se distancie do que os leitores podem inspecionar.