Registo de Atualizações: Mostrar o Que Mudou e Quando

Um registo de atualizações é um registo datado de alterações substantivas na página: o que mudou, porquê e se a resposta, recomendação ou evidência se alterou.

Registo de atualizações

27 de agosto de 2026 — Preço e recomendação atualizados
Substituiu o plano Starter descontinuado pelo plano Essentials atual, atualizou a tabela comparativa e alterou a recomendação para equipas que necessitam de exportações de auditoria. As fontes foram reverificadas junto à documentação de planos do fornecedor.

12 de maio de 2026 — Evidência atualizada; conclusão inalterada
Substituiu duas referências de funcionalidades obsoletas e verificou os restantes limites de planos. A opção recomendada não mudou.

Cada data está ligada a um evento inspecionável. Um simples “Atualizado a 27 de agosto de 2026” é inexplicado; o registo expõe o âmbito e a consequência do trabalho.

Por que este elemento é importante

Os leitores não tratam todas as alterações da mesma forma. Corrigir um título com erro ortográfico não equivale a reverter uma recomendação, substituir um conjunto de dados ou corrigir uma instrução insegura. Uma única data de atualização colapsa esses eventos no mesmo sinal. Em páginas usadas para gastar dinheiro, seguir um procedimento, interpretar pesquisa ou compreender uma política, os leitores precisam de saber se a secção de confiança foi alterada.

Um registo de atualizações preserva o histórico sem forçar os leitores a comparar cópias em cache. Responde a quatro perguntas: A página foi mantida? A alteração afetou-me? Um erro foi corrigido abertamente? A conclusão ainda é suportada? Respostas claras criam responsabilidade e evitam falsa atualidade a partir de uma data avançada sem trabalho significativo.

Relate consequência, não atividade. “Links atualizados” descreve uma ação. “Substituiu a fonte retirada para o total de mercado de 2024; o valor e a conclusão estão inalterados” diz aos leitores o que permanece fiável. Se uma conclusão mudou, diga-o claramente.

A extraibilidade por máquina significa que o software pode separar cada evento numa data, tipo, resumo, detalhe, secção afetada e referência de evidência. Campos estáveis permitem que auditorias encontrem correções, que agentes expliquem recomendações alteradas e que migrações preservem o histórico. Prosa inconsistente força o software a adivinhar onde os eventos começam e terminam.

A finalidade tipificada do elemento tem portanto precedência sobre uma linha cronológica ou lista de marcadores visualmente semelhante. Siga as regras de escrita de elementos : quando o conteúdo regista revisões à página atual, codifique-o como um registo de atualizações. O renderizador pode usar uma lista, cartões ou um arquivo expansível, mas os campos canónicos do evento devem sobreviver a toda e qualquer apresentação.

Quando usar

Use um registo de atualizações quando os leitores possam precisar de comparar a página atual com versões anteriores. Os gatilhos incluem uma recomendação alterada, facto corrigido, método revisto, conjunto de dados substituído, cálculo alterado, nova versão, elegibilidade alterada, modelo de preço atualizado, instruções modificadas ou opção arquivada.

O elemento é mais valioso quando a autoridade se acumula ao longo do tempo. Uma investigação pode receber um denominador corrigido; uma documentação pode suportar uma nova interface; um explicador regulatório pode distinguir uma emenda de uma clarificação editorial. A reescrita silenciosa destruiria o histórico que um leitor que retorna necessita.

Use uma entrada de revisão com moderação quando uma revisão com âmbito definido não encontrou alterações. Identifique-a como “Revisto,” nomeie o que foi verificado e diga que a conclusão está inalterada. Isto adequa-se a estatísticas voláteis, preços, capacidades de produtos ou regras; não é permissão para fabricar atividade.

Casos próximos necessitam de tratamento diferente:

• Uma data de publicação ou modificação: use um selo de atualização para expor as datas canónicas da página. O selo e o registo podem funcionar em conjunto, mas um não pode substituir o outro.
• Histórico de lançamento de produto ou cronologia de projeto: descrevem alterações no tema. Um registo de atualizações regista alterações editoriais à página atual.
• Saída de controlo de versões: mensagens de commit incluem ruído de implementação, identificadores internos e detalhes sensíveis à segurança. Não são registos editoriais para o leitor.
• Uma lista de fontes: um bloco de fontes comprova de onde vieram as alegações. O registo de atualizações diz quando e por que essas fontes ou alegações mudaram.
• Manutenção menor: não registe ortografia, pontuação, formatação, compressão de imagens, análise, parâmetros de rastreio ou migração de modelo, a menos que a alteração tenha modificado o significado ou a acessibilidade.

Uma página sem revisão substantiva necessita de uma data de publicação, não de um painel vazio ou histórico fictício.

Onde colocar

Coloque o registo completo após a resposta, evidências, conclusões e fontes, mas antes de conteúdo relacionado, captura de newsletter ou a chamada para ação final. Os leitores precisam primeiro da página atual, depois do seu histórico. Em páginas de pesquisa, estatísticas e políticas, o registo geralmente segue as fontes ou a metodologia.

Se a alteração mais recente afetar a forma como a página deve ser lida, adicione “Veja o que mudou” junto à data principal e salte para o registo completo. Não duplique a entrada ali. Uma correção que afete segurança, dinheiro, elegibilidade ou a conclusão também necessita de um aviso junto à alegação corrigida.

O registo pode partilhar uma região de manutenção com a autoria quando ambos permanecem distintos. Não pode ficar junto a um botão de compra, oferta por tempo limitado, contagem decrescente, classificação, testemunho ou selo promocional; isso transforma história em urgência ou endosso implícito. Não o funda no bloco de fontes: a razão pela qual uma fonte mudou é história editorial, não uma citação.

Mantenha um registo canónico. Uma barra lateral pode ligar-se a ele, não duplicá-lo. Após cinco entradas, mostre as três a cinco mais recentes e exponha o restante através de “Ver atualizações anteriores.” Mantenha o histórico completo na página ou num arquivo estável e governado.

Anatomia

1. Título do elemento: Usa “Registo de atualizações,” “Histórico de revisões” ou um rótulo aprovado mais restrito que permanece claro fora do design da página.
2. Data do evento: Mostra uma data de calendário absoluta e expõe o mesmo valor como carimbo temporal ISO 8601 legível por máquina.
3. Tipo de evento: Distingue updated, corrected, reviewed, method-changed e archived sem depender de cor.
4. Resumo: Nomeia o objeto alterado e o resultado numa linha concisa.
5. Detalhe: Explica o estado antigo, o novo estado e o motivo quando esses factos ajudam o leitor a interpretar a página.
6. Secção afetada: Opcionalmente liga ao cabeçalho ou figura estável alterada, usando um fragmento que não será reaproveitado.
7. Consequência: Indica se a resposta, conclusão, recomendação, elegibilidade ou instruções mudaram.
8. Referência de evidência: Opcionalmente aponta para um identificador de fonte já definido no bloco de fontes da página.
9. Controlo de arquivo: Revela entradas anteriores sem as eliminar do documento ou da árvore de acessibilidade.

As entradas devem permanecer compreensíveis sem estilo. Ícones, linhas e cores nunca transmitem tipo ou consequência sozinhos.

Exemplos de design

As variantes refletem a densidade de informação e o risco editorial.

Linha compacta de alteração mais recente

Use uma linha compacta para uma única revisão simples. Inclua data, tipo, resumo e consequência. Use a lista padrão quando a explicação exceder duas frases.

Lista de revisão padrão

Use uma lista do mais recente primeiro para duas a cinco entradas, com a mesma ordem de campos ao longo de toda a lista.

Variante com correção em destaque

Para um erro material, identifique “Correção,” mostre os estados incorreto e corrigido, indique o impacto e ligue à secção afetada. Dê ênfase sem linguagem alarmista.

Alteração de método ou versão

Quando um conjunto de dados, fórmula, versão de produto, jurisdição ou método muda, mostre as versões antiga e nova. Indique quando os resultados anteriores já não são comparáveis.

Arquivo expansível

Após cinco entradas, identifique o arquivo com a sua contagem de entradas e intervalo de datas. Preserve cabeçalhos e estrutura de lista; não torne o JavaScript o único meio de aceder ao registo.

Viewport estreito

Empilhe data, tipo, resumo e detalhe. Nunca corte datas nem oculte texto de consequência em dispositivos móveis.

Parâmetros

Os campos pai controlam a coleção; os campos de item repetidos descrevem cada evento.

As entradas são itens repetidos, não um campo HTML único. O primeiro cabeçalho do pai mapeia para title; o primeiro cabeçalho de cada item mapeia para summary, e o corpo restante mapeia para detail. Datas, tipos, impacto, referências e versões permanecem como atributos.

impact é obrigatório para que os leitores não tenham de inferir se a resposta mudou. Use not-applicable apenas quando o material não tem conclusão. Uma revisão sem edições usa type=reviewed e impact=unchanged.

Sintaxe e exemplos de código

Todas as representações preservam os mesmos campos. Identificadores de fonte referem-se ao bloco de fontes canónico.

Diretiva Markdown portátil

:::update-log{order=newest-first visibleItems=3}
## Update log

::item{date="2026-08-27" type=updated impact=changed affectedSection="plans" evidenceRef="vendor-plans"}
### Pricing and recommendation updated

Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.
::

:::

Contrato de shortcode Hugo

{{< update-log title="Update log" order="newest-first" visibleItems="3" >}}
  {{< update-log-item date="2026-08-27" type="updated" impact="changed" affectedSection="plans" evidenceRef="vendor-plans" >}}
  ## Pricing and recommendation updated
  Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.
  {{< /update-log-item >}}
{{< /update-log >}}

Este é um contrato de adaptador, não um shortcode existente. Cada parâmetro é nomeado.

Blocos WordPress

<!-- wp:amicited/update-log {"title":"Update log","order":"newest-first","visibleItems":3} -->
<!-- wp:amicited/update-log-item {"date":"2026-08-27","type":"updated","impact":"changed","affectedSection":"plans","evidenceRef":["vendor-plans"]} -->
<h3>Pricing and recommendation updated</h3>
<p>Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.</p>
<!-- /wp:amicited/update-log-item -->
<!-- /wp:amicited/update-log -->

O WordPress deve expor controlos estruturados para data, tipo, impacto, secção e evidência.

Exemplos

Boa entrada de atualização

18 de julho de 2026 — Cálculo corrigido
Corrigiu o denominador da taxa de conversão de todas as sessões para sessões elegíveis de produtos na tabela “Desempenho do canal.” Os valores para pesquisa orgânica mudaram de 3,1% para 2,4%; a classificação dos canais e a conclusão do artigo não se alteraram. As contagens subjacentes de sessões não foram afetadas.

Isto funciona porque nomeia o erro, as definições antiga e nova, a secção afetada, a consequência numérica e o estado da conclusão. Os leitores podem avaliar se o trabalho anterior necessita de revisão.

Má entrada de atualização

Verão de 2026 — Totalmente renovado!
Revimos esta página e fizemos várias melhorias para que possa confiar que tudo está atualizado.

Isto falha porque a data é vaga, “totalmente” exagera o âmbito, “várias melhorias” oculta factos e “confiar” exige uma conclusão imerecida. Se o trabalho foi cosmético, elimine a entrada. Se substantivo, nomeie cada alteração relevante para a decisão.

Marcação Schema e acessibilidade

Um registo de atualizações não tem um tipo Schema.org autónomo. Permanece como conteúdo dentro do Article, TechArticle ou Report que o contém. O evento substantivo mais recente pode suportar dateModified; uma revisão sem alterações não deve. Nunca substitua datePublished.

Não codifique entradas como CreativeWork, Event, HowToStep ou ItemList; esses tipos implicam significados que o registo não possui. Use HTML previsível: uma secção identificada, itens de lista, cabeçalhos, <time datetime="2026-08-27">27 de agosto de 2026</time> e fragmentos estáveis.

Use um item de lista por evento; o CSS pode desenhar uma linha cronológica sem alterar a ordem. Indique que as entradas estão do mais recente primeiro. Mostre o tipo em texto, não apenas com cores ou ícones, e use links descritivos.

Um arquivo necessita de uma divulgação nativa identificada com a sua contagem ou intervalo. Todas as entradas devem ser acessíveis por teclado e leitores de ecrã. Não use uma região ARIA live. Preserve a ordem dos cabeçalhos e as datas localizadas.

Coloque um aviso de correção junto à alegação afetada e registe-o no registo. O primeiro protege os leitores imediatos; o segundo preserva o histórico.

Regras de escrita

Comece com o objeto alterado e um verbo preciso: “Regra de elegibilidade esclarecida,” “Conjunto de dados substituído,” ou “Fórmula corrigida.” Mantenha resumos entre 4–14 palavras e detalhes entre 25–90 palavras. Use uma frase para a alteração e motivo, outra para o impacto. Use datas absolutas localizadas e exibição do mais recente primeiro.

Explique o motivo antes do resultado. “O fornecedor retirou o Starter, por isso substituímo-lo pelo Essentials e reavaliamos a recomendação” regista a causa; “Melhorámos a nossa comparação” regista opinião. Use o pretérito neutro.

Cada entrada material deve responder a estas perguntas:

• Que facto, instrução, método, fonte, âmbito ou conclusão específicos foram alterados?
• Por que a alteração foi necessária?
• Onde na página ocorreu?
• A resposta, recomendação ou conclusão principal mudou?
• O leitor precisa de refazer uma decisão ou ação com base na versão anterior?

Crie uma entrada por evento editorial, não por tecla premida. Agrupe alterações relacionadas de uma revisão; separe trabalho não relacionado, impactos diferentes ou datas diferentes. Mostre três a cinco e retenha o histórico material.

Nunca inclua notas confidenciais, detalhes de segurança, vulnerabilidades, dados pessoais, culpas, hashes de commit brutos, tickets inexplicados, marketing, urgência ou uma bibliografia. Nunca prometa “100% atual,” apague correções, reescreva entradas silenciosamente ou redate trabalho cosmético.

Se uma entrada precisar de correção, preserve a sua data e adicione um evento de correção. Deveres de privacidade, segurança ou legais podem justificar expurgo; indique que o registo foi alterado e porquê a um nível apropriado.

Tipos de publicação que o utilizam

O array postTypes do frontmatter é a origem desta tabela. “Obrigatório” significa que o histórico de revisões substantivas faz parte do contrato de confiança do formato; “condicional” significa que o registo aparece assim que ocorre uma alteração qualificativa.

Uma página nova não precisa de registo vazio. Após uma alteração qualificativa, preserve o elemento.

Lista de verificação QA

• Cada entrada visível representa um evento editorial substantivo, não uma alteração cosmética ou automatizada.
• A data do evento é exata, válida, não futura e corresponde ao registo editorial aprovado.
• O resumo nomeia o objeto alterado e mantém-se entre 4–14 palavras.
• O detalhe indica o que mudou e porquê antes de descrever o benefício.
• A entrada identifica se a resposta, conclusão, recomendação, elegibilidade ou instruções mudaram.
• Uma correção material também aparece junto à alegação afetada.
• Fragmentos de secção e identificadores de evidência resolvem para alvos estáveis na mesma página canónica.
• O registo aparece após o conteúdo principal e fontes, mas antes de módulos promocionais finais.
• O registo não está visualmente fundido com um CTA, oferta, classificação, testemunho ou bloco de fontes.
• As datas usam valores semânticos <time>; tipos de evento e impactos não dependem de cor ou ícones.
• O controlo de arquivo é operável por teclado, claramente identificado e expõe o seu conteúdo completo à tecnologia assistiva.
• Uma entrada apenas de revisão não altera dateModified; um evento substantivo mais recente concorda com a data atualizada canónica.
• Notas confidenciais, dados pessoais, detalhes de segurança, histórico bruto de implementação e linguagem de marketing estão ausentes.
• O tipo de publicação da página e o risco do leitor justificam o elemento.

FAQ

Toda edição de conteúdo pertence ao registo de atualizações?

Não. Registe alterações que modifiquem factos, instruções, evidências, âmbito, interpretação, recomendações ou a decisão do leitor. Omita ortografia, espaçamento, rastreamento, modelo e outras edições não substantivas.

Como um registo de atualizações difere de uma data de última atualização?

Uma data de última atualização indica que ocorreu uma alteração substantiva. Um registo de atualizações indica o que mudou, por que mudou e se a resposta ou conclusão se alterou, para que a alegação de manutenção possa ser inspecionada.

A atualização mais nova ou a mais antiga deve aparecer primeiro?

Mostre a entrada mais nova primeiro numa página mantida, porque os leitores geralmente precisam da alteração atual. Preserve a ordem cronológica na saída de máquina e forneça um arquivo claramente identificado quando a lista visível for encurtada.

Um registo de atualizações pode substituir avisos de correção?

Não. Um erro material necessita de uma correção conspicua junto à alegação afetada, além de uma entrada permanente no registo. O registo preserva o histórico; não deve ocultar uma correção no final da página.

Revisões sem alterações devem aparecer no registo?

Apenas quando o estado da revisão for relevante para os leitores e a entrada estiver identificada como “Revisto,” não “Atualizado.” Indique o âmbito verificado e que nenhuma alteração substantiva foi necessária; não altere dateModified.