Registro de actualizaciones: muestra qué cambió y cuándo

Un registro de actualizaciones es un registro fechado de cambios sustanciales en la página: qué cambió, por qué, y si la respuesta, recomendación o evidencia se modificó.

Registro de actualizaciones

27 de agosto de 2026 — Precios y recomendación actualizados
Se reemplazó el plan Starter descontinuado por el plan Essentials actual, se actualizó la tabla comparativa y se cambió la recomendación para los equipos que necesitan exportaciones de auditoría. Las fuentes se verificaron nuevamente contra la documentación de planes del proveedor.

12 de mayo de 2026 — Evidencia actualizada; conclusión sin cambios
Se reemplazaron dos referencias de funciones obsoletas y se verificaron los límites restantes de los planes. La opción recomendada no cambió.

Cada fecha está vinculada a un evento verificable. Un simple «Actualizado el 27 de agosto de 2026» no se explica; el registro expone el alcance y la consecuencia del trabajo.

Por qué es importante este elemento

Los lectores no tratan todos los cambios por igual. Corregir un encabezado mal escrito no equivale a revertir una recomendación, reemplazar un conjunto de datos o arreglar una instrucción insegura. Una única fecha de actualización agrupa esos eventos en la misma señal. En páginas que se usan para gastar dinero, seguir un procedimiento, interpretar una investigación o comprender una política, los lectores necesitan saber si la sección de la que dependen cambió.

Un registro de actualizaciones preserva la historia sin obligar a los lectores a comparar copias en caché. Responde cuatro preguntas: ¿Se mantuvo la página? ¿El cambio me afectó? ¿Se corrigió un error abiertamente? ¿La conclusión sigue respaldada? Respuestas claras crean responsabilidad y evitan una falsa actualización a partir de una fecha avanzada sin trabajo significativo.

Informa la consecuencia, no la actividad. «Enlaces actualizados» describe una acción. «Se reemplazó la fuente retirada para el total del mercado 2024; el valor y la conclusión no cambian» les dice a los lectores qué sigue siendo fiable. Si una conclusión cambió, dilos claramente.

La capacidad de extracción automatizada significa que el software puede separar cada evento en una fecha, tipo, resumen, detalle, sección afectada y referencia de evidencia. Los campos estables permiten que las auditorías encuentren correcciones, que los agentes expliquen recomendaciones cambiadas y que las migraciones preserven la historia. Un texto inconsistente obliga al software a adivinar dónde comienzan y terminan los eventos.

Por lo tanto, el propósito tipificado del elemento tiene prioridad sobre una línea de tiempo o lista de viñetas visualmente similar. Sigue las reglas de redacción de elementos : cuando el contenido registra revisiones de la página actual, codifícalo como un registro de actualizaciones. El renderizador puede usar una lista, tarjetas o un archivo expandible, pero los campos canónicos del evento deben sobrevivir a toda presentación.

Cuándo usarlo

Usa un registro de actualizaciones cuando los lectores puedan necesitar comparar la página actual con versiones anteriores. Los desencadenantes incluyen una recomendación cambiada, un hecho corregido, un método revisado, un conjunto de datos reemplazado, un cálculo alterado, una nueva versión, un cambio de elegibilidad, un modelo de precios actualizado, instrucciones modificadas o una opción archivada.

El elemento es más valioso cuando la autoridad se acumula con el tiempo. Una investigación puede recibir un denominador corregido; la documentación puede admitir una nueva interfaz; un explicador regulatorio puede distinguir una enmienda de una aclaración editorial. La reescritura silenciosa destruiría la historia que necesita un lector que regresa.

Usa una entrada de revisión con moderación cuando una revisión del alcance no encontró cambios. Etiquétala como «Revisado», nombra lo que se verificó y di que la conclusión no cambia. Esto es adecuado para estadísticas volátiles, precios, capacidades de productos o reglas; no es un permiso para fabricar actividad.

Los casos límite necesitan un tratamiento diferente:

• Una fecha de publicación o modificación: usa un sello de actualización para exponer las fechas canónicas de la página. El sello y el registro pueden funcionar juntos, pero uno no puede sustituir al otro.
• Historial de versiones de producto o cronograma de proyecto: describen cambios en el tema. Un registro de actualizaciones documenta cambios editoriales en la página actual.
• Salida de control de versiones: los mensajes de commit incluyen ruido de implementación, identificadores internos y detalles sensibles de seguridad. No son registros editoriales orientados al lector.
• Una lista de fuentes: un bloque de fuentes demuestra de dónde provienen las afirmaciones. El registro de actualizaciones indica cuándo y por qué cambiaron esas fuentes o afirmaciones.
• Mantenimiento menor: no registres correcciones ortográficas, de puntuación, de formato, compresión de imágenes, análisis, parámetros de seguimiento o una migración de plantilla a menos que el cambio haya alterado el significado o la accesibilidad.

Una página sin revisión sustancial necesita una fecha de publicación, no un panel vacío ni un historial ficticio.

Dónde colocarlo

Coloca el registro completo después de la respuesta, la evidencia, las conclusiones y las fuentes, pero antes del contenido relacionado, el formulario de suscripción al boletín o la llamada a la acción final. Los lectores primero necesitan la página actual, luego su historial. En páginas de investigación, estadísticas y políticas, el registro suele seguir a las fuentes o la metodología.

Si el cambio más reciente afecta cómo se debe leer la página, añade «Ver qué cambió» junto a la fecha principal y salta al registro completo. No dupliques la entrada allí. Una corrección que afecte la seguridad, el dinero, la elegibilidad o la conclusión también necesita un aviso junto a la afirmación corregida.

El registro puede compartir un área de mantenimiento con la autoría cuando ambos se mantengan distintos. No debe colocarse junto a un botón de compra, oferta por tiempo limitado, contador regresivo, calificación, testimonio o distintivo promocional; eso convierte la historia en urgencia o respaldo implícito. No lo fusiones con el bloque de fuentes: la razón por la que una fuente cambió es historia editorial, no una cita.

Mantén un único registro canónico. Una barra lateral puede enlazar a él, no duplicarlo. Después de cinco entradas, muestra las tres a cinco más recientes y expón el resto mediante «Ver actualizaciones anteriores». Mantén el historial completo en la página o en un archivo estable gobernado.

Anatomía

1. Título del elemento: Usa «Registro de actualizaciones», «Historial de revisiones» o una etiqueta aprobada más específica que siga siendo clara fuera del diseño de la página.
2. Fecha del evento: Muestra una fecha de calendario absoluta y expone el mismo valor como una marca de tiempo ISO 8601 para máquinas.
3. Tipo de evento: Distingue entre updated, corrected, reviewed, method-changed y archived sin depender del color.
4. Resumen: Nombra el objeto cambiado y el resultado en una línea concisa.
5. Detalle: Explica el estado anterior, el nuevo estado y la razón cuando esos datos ayuden al lector a interpretar la página.
6. Sección afectada: Opcionalmente enlaza al encabezado o figura estable que cambió, usando un fragmento que no será reutilizado.
7. Consecuencia: Indica si la respuesta, conclusión, recomendación, elegibilidad o instrucciones cambiaron.
8. Referencia de evidencia: Opcionalmente apunta a un identificador de fuente ya definido en el bloque de fuentes de la página.
9. Control de archivo: Revela entradas anteriores sin eliminarlas del documento ni del árbol de accesibilidad.

Las entradas deben seguir siendo comprensibles sin estilos. Los iconos, líneas y colores nunca transmiten el tipo o la consecuencia por sí solos.

Ejemplos de diseño

Las variantes reflejan la densidad de información y el riesgo editorial.

Fila compacta del último cambio

Usa una fila compacta para una sola revisión simple. Incluye fecha, tipo, resumen y consecuencia. Usa la lista estándar cuando la explicación supere dos oraciones.

Lista estándar de revisiones

Usa una lista con la más reciente primero para dos a cinco entradas, con el mismo orden de campos en toda la lista.

Variante de corrección

Para un error material, etiqueta «Corrección», muestra los estados incorrecto y corregido, indica el impacto y enlaza a la sección afectada. Enfatízalo sin lenguaje alarmista.

Cambio de método o versión

Cuando cambia un conjunto de datos, fórmula, versión de producto, jurisdicción o método, muestra las versiones antigua y nueva. Indica cuándo los resultados anteriores ya no son comparables.

Archivo expandible

Después de cinco entradas, etiqueta el archivo con su recuento de entradas y rango de fechas. Preserva los encabezados y la estructura de lista; no hagas que JavaScript sea la única forma de acceder al registro.

Vista en dispositivo estrecho

Apila fecha, tipo, resumen y detalle. Nunca recortes fechas ni ocultes el texto de consecuencia en móvil.

Parámetros

Los campos padre controlan la colección; los campos de elemento repetidos describen cada evento.

Las entradas son elementos repetidos, no un único campo HTML. El primer encabezado del padre se asigna a title; el primer encabezado de cada elemento se asigna a summary, y su cuerpo restante se asigna a detail. Las fechas, tipos, impacto, referencias y versiones siguen siendo atributos.

impact es obligatorio para que los lectores no tengan que inferir si la respuesta cambió. Usa not-applicable solo cuando el material no tenga conclusión. Una revisión sin ediciones usa type=reviewed e impact=unchanged.

Sintaxis y ejemplos de código

Todas las representaciones preservan los mismos campos. Los identificadores de fuente se refieren al bloque de fuentes canónico.

Directiva 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 de 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 es un contrato de adaptador, no un shortcode existente. Todos los parámetros están nombrados.

Bloques de 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 -->

WordPress debería exponer controles estructurados para fecha, tipo, impacto, sección y evidencia.

Ejemplos

Buena entrada de actualización

18 de julio de 2026 — Cálculo corregido
Se corrigió el denominador de la tasa de conversión, cambiando de todas las sesiones a sesiones de producto elegibles en la tabla «Rendimiento del canal». Los valores para búsqueda orgánica cambiaron del 3.1% al 2.4%; la clasificación de los canales y la conclusión del artículo no cambiaron. Los recuentos de sesiones subyacentes no se vieron afectados.

Esto funciona porque nombra el error, las definiciones antigua y nueva, la sección afectada, la consecuencia numérica y el estado de la conclusión. Los lectores pueden juzgar si el trabajo anterior necesita revisión.

Mala entrada de actualización

Verano 2026 — ¡Completamente actualizado!
Revisamos esta página e hicimos varias mejoras para que puedas confiar en que todo está al día.

Esto falla porque la fecha es vaga, «completamente» exagera el alcance, «varias mejoras» oculta hechos y «confiar» exige una conclusión no justificada. Si el trabajo fue cosmético, elimina la entrada. Si fue sustancial, nombra cada cambio relevante para la decisión.

Marcado de esquema y accesibilidad

Un registro de actualizaciones no tiene un tipo independiente de Schema.org. Permanece como contenido dentro del Article, TechArticle o Report contenedor. El evento sustancial más reciente puede respaldar dateModified; una revisión sin cambios no debe hacerlo. Nunca reemplaces datePublished.

No codifiques las entradas como CreativeWork, Event, HowToStep o ItemList; esos tipos implican significados que el registro no tiene. Usa HTML predecible: una sección etiquetada, elementos de lista, encabezados, <time datetime="2026-08-27">27 de agosto de 2026</time> y fragmentos estables.

Usa un elemento de lista por evento; CSS puede dibujar una línea de tiempo sin cambiar el orden. Indica que las entradas están ordenadas de la más reciente a la más antigua. Muestra el tipo en texto, no solo con color o iconos, y usa enlaces descriptivos.

Un archivo necesita un componente de divulgación nativo etiquetado con su recuento o rango. Todas las entradas deben ser accesibles mediante teclado y lectores de pantalla. No uses una región ARIA live. Preserva el orden de los encabezados y las fechas localizadas.

Coloca un aviso de corrección junto a la afirmación afectada y regístralo en el registro. El primero protege a los lectores inmediatos; el segundo preserva la historia.

Reglas de redacción

Comienza con el objeto cambiado y un verbo preciso: «Regla de elegibilidad aclarada», «Conjunto de datos reemplazado» o «Fórmula corregida». Mantén los resúmenes entre 4 y 14 palabras y los detalles entre 25 y 90 palabras. Usa una oración para el cambio y la razón, y otra para el impacto. Usa fechas absolutas localizadas y orden de la más reciente primero.

Explica la razón antes que el resultado. «El proveedor retiró Starter, así que lo reemplazamos con Essentials y reevaluamos la recomendación» registra la causa; «Mejoramos nuestra comparación» registra una opinión. Usa el tiempo pasado neutro.

Cada entrada importante debe responder estas preguntas:

• ¿Qué hecho, instrucción, método, fuente, alcance o conclusión específica cambió?
• ¿Por qué era necesario el cambio?
• ¿Dónde en la página ocurrió?
• ¿Cambió la respuesta principal, recomendación o conclusión?
• ¿Necesita el lector rehacer una decisión o acción basada en la versión anterior?

Crea una entrada por evento editorial, no por pulsación de tecla. Agrupa cambios relacionados de una misma revisión; separa trabajos no relacionados, impactos diferentes o fechas distintas. Muestra de tres a cinco y conserva el historial sustancial.

Nunca incluyas notas confidenciales, detalles de seguridad, vulnerabilidades, datos personales, atribuciones, hashes de commit sin procesar, tickets sin explicación, marketing, urgencia ni una bibliografía. Nunca prometas «100% actual», borres correcciones, reescribas entradas en silencio ni cambies la fecha de trabajo cosmético.

Si una entrada necesita corrección, preserva su fecha y añade un evento de corrección. Los deberes de privacidad, seguridad o legales pueden justificar la redacción; indica que el registro fue modificado y por qué, a un nivel apropiado.

Tipos de publicación que lo usan

El arreglo postTypes del frontmatter es la fuente de esta tabla. «Obligatorio» significa que el historial de revisiones sustanciales es parte del contrato de confianza del formato; «condicional» significa que el registro aparece una vez que ocurre un cambio que lo califica.

Una página nueva no necesita un registro vacío. Después de un cambio que lo califique, preserva el elemento.

Lista de verificación de control de calidad

• Cada entrada visible representa un evento editorial sustancial, no un cambio cosmético o automatizado.
• La fecha del evento es exacta, válida, no futura y coincide con el registro editorial aprobado.
• El resumen nombra el objeto cambiado y se mantiene dentro de 4–14 palabras.
• El detalle indica qué cambió y por qué antes de describir el beneficio.
• La entrada identifica si la respuesta, conclusión, recomendación, elegibilidad o instrucciones cambiaron.
• Una corrección material también aparece junto a la afirmación afectada.
• Los fragmentos de sección y los identificadores de evidencia se resuelven en destinos estables en la misma página canónica.
• El registro aparece después del contenido principal y las fuentes, pero antes de los módulos promocionales finales.
• El registro no está fusionado visualmente con un CTA, oferta, calificación, testimonio o bloque de fuentes.
• Las fechas usan valores semánticos <time>; los tipos de evento e impactos no dependen del color o los iconos.
• El control de archivo es operable mediante teclado, está claramente etiquetado y expone su contenido completo a la tecnología de asistencia.
• Una entrada solo de revisión no cambia dateModified; el evento sustancial más reciente coincide con la fecha de actualización canónica.
• No hay notas confidenciales, datos personales, detalles de seguridad, historial de implementación sin procesar ni lenguaje de marketing.
• El tipo de publicación de la página y el riesgo para el lector justifican el elemento.

Preguntas frecuentes

¿Toda edición de contenido pertenece al registro de actualizaciones?

No. Registra los cambios que alteren hechos, instrucciones, evidencia, alcance, interpretación, recomendaciones o la decisión de un lector. Omite correcciones ortográficas, de espaciado, de seguimiento, de plantilla y otras ediciones no sustanciales.

¿En qué se diferencia un registro de actualizaciones de una fecha de última actualización?

Una fecha de última actualización indica que ocurrió un cambio sustancial. Un registro de actualizaciones indica qué cambió, por qué cambió y si la respuesta o conclusión se modificó, para que la afirmación de mantenimiento pueda ser inspeccionada.

¿Debería aparecer primero la actualización más nueva o la más antigua?

Muestra primero la entrada más nueva en una página mantenida porque los lectores generalmente necesitan el cambio actual. Preserva el orden cronológico en la salida para máquinas y proporciona un archivo claramente etiquetado cuando la lista visible esté acortada.

¿Puede un registro de actualizaciones reemplazar los avisos de corrección?

No. Un error material necesita una corrección visible junto a la afirmación afectada, además de una entrada permanente en el registro. El registro preserva la historia; no debe ocultar una corrección al final de la página.

¿Deben aparecer en el registro las revisiones sin cambios?

Solo cuando el estado de la revisión sea importante para los lectores y la entrada esté etiquetada como «Revisado», no «Actualizado». Indica el alcance verificado y que no se requirió ningún cambio sustancial; no modifiques dateModified.