Cómo detectamos que un portal cambió su estructura sin avisar
Un rediseño puede mover botones sin alterar datos o cambiar campos, páginas y cobertura. Contratos, fixtures y revisión humana permiten distinguirlos.
Por Marco Ferreiro ·
Un portal oficial puede rediseñarse de un día para otro. A veces sólo cambia el color de un botón. Otras veces desaparece una columna, se agrega paginación o la búsqueda deja de incluir cierto estado. Si el sistema sólo controla que la página responda, los dos casos parecen saludables.
Detectar el cambio exige medir estructura y significado por separado. Y cuando no podemos confirmar la cobertura, la respuesta debe fallar de manera visible.
Qué llamamos cambio de estructura
No se limita al HTML. Incluye cualquier modificación que afecte cómo se encuentra o interpreta información:
- nombres o tipos de campos;
- tablas convertidas en tarjetas;
- estados renombrados;
- botones y pasos de navegación;
- paginación o scroll incremental;
- filtros predeterminados;
- archivos descargables;
- mensajes de cobertura;
- formato de fechas y montos;
- endpoint o esquema documentado.
Un cambio visual puede ser inocuo. Uno pequeño en un filtro puede excluir la mitad de los resultados.
Señales en capas
Monitoreamos al menos cinco capas:
- transporte: DNS, TLS, status y tiempo;
- acceso: autenticación, desafío y sesión autorizada;
- estructura: componentes y campos esperados;
- semántica: estados, unidades y cobertura;
- resultado: cantidad, paginación y finalización.
Una respuesta 200 sólo satisface parte de la primera. No demuestra que la búsqueda haya ocurrido ni que se haya leído la última página.
Cada alerta indica qué capa cambió para evitar diagnosticar “portal caído” cuando sólo venció una sesión.
Fixtures sin datos personales
Conservamos ejemplos públicos, sintéticos o autorizados que cubren estados conocidos. Eliminamos patentes, nombres, documentos, actas y tokens antes de versionarlos.
Una fixture incluye estructura y valores inventados equivalentes, no un HTML real con información sensible. Los tests comprueban:
- presencia de campos obligatorios;
- ausencia permitida de opcionales;
- enumeraciones conocidas;
- formato de fecha e importe;
- navegación hasta el final;
- mensajes de cero resultados y error.
Si el portal prohíbe automatización, no se usa para extracción. La verificación se realiza mediante el canal permitido y revisión manual.
Contrato visible y contrato interno
Cuando hay OpenAPI, la descripción permite documentar operaciones, parámetros y respuestas. Versionamos el documento y validamos ejemplos. Aun así, la implementación puede cambiar antes que la documentación.
En una web sin API documentada, el contrato interno es más prudente: registra lo que vimos y la fecha, sin presentar selectores como garantía del organismo.
Datos Argentina recomienda documentar interfaces y ejemplos para facilitar el uso. Esa práctica reduce ambigüedad, pero el consumidor sigue necesitando detectar diferencias reales.
Rediseño inocuo
Supongamos que una tabla pasa a tarjetas. Los mismos campos, estados, cantidades y páginas siguen disponibles. El parser falla porque buscaba filas, pero la revisión humana confirma que la cobertura no cambió.
Creamos una nueva versión del adaptador, añadimos fixtures de tarjetas y repetimos casos. No publicamos resultados hasta completar la validación.
El incidente se clasifica “cambio de presentación”. Su impacto operativo existe, aunque no haya pérdida de datos.
Cambio que altera significado
Otro portal elimina el filtro “todas” y deja “pendientes” como vista única. La cantidad baja. Adaptar el selector no recupera estados pagados o en revisión.
La versión nueva registra una cobertura distinta. El producto debe comunicarla y evitar comparaciones históricas como si fueran equivalentes.
Si el organismo no explica el cambio, conservamos evidencia y consultamos el canal oficial. No afirmamos que los datos fueron eliminados: decimos que dejaron de estar visibles en la interfaz observada.
Paginación agregada sin aviso
Un caso crítico ocurre cuando la primera página sigue igual, pero aparece un botón siguiente. El extractor devuelve un conjunto válido y corto; ningún error técnico se dispara.
Por eso controlamos total, tamaño de página, cursor y condición de final. Una fixture con más elementos que el límite obliga a recorrer al menos dos páginas.
Si la navegación falla a mitad, el resultado es parcial. No deducimos que el último elemento leído sea el último disponible.
Estados y campos desconocidos
Un estado nuevo no se mapea automáticamente a “pendiente”. Conservamos el valor original y detenemos decisiones que dependan de su significado.
Un campo que antes era número y ahora es texto puede indicar moneda, rango o mensaje. Convertirlo con una expresión flexible puede producir un monto falso.
La política es aceptar campos adicionales para observación cuando sea seguro, pero rechazar cambios incompatibles en datos críticos. El evento registra ejemplo saneado y versión.
Confirmación contra el portal y comunicaciones
La alerta técnica inicia una revisión humana en el dominio oficial. Comprobamos avisos, preguntas frecuentes, términos y comunicados. En SINAI, las condiciones explican que las jurisdicciones son responsables de cargar y actualizar información; una diferencia puede originarse allí y no en el diseño.
Documentamos qué se confirmó y qué es inferencia. Si no hay comunicado, no inventamos uno a partir de la fecha del despliegue.
También verificamos que no sea una página falsa o un intermediario. Los cambios de dominio requieren una validación más fuerte.
Fallar cerrado sin ocultar información
Cuando falta un campo crítico o no termina la paginación, la fuente queda unverified o partial. El consumidor recibe ese estado junto con otras fuentes que sí completaron.
No devolvemos un arreglo vacío. Vacío significa que una consulta válida y completa no encontró filas dentro de su cobertura; un parser roto significa que no sabemos.
La caché anterior puede mostrarse sólo si está marcada con su fecha y política. No se presenta como dato actual.
Rehabilitar una fuente
Antes de volver a producción exigimos:
- fixtures nuevas y anteriores;
- casos de cero, uno y múltiples resultados;
- paginación completa;
- estados conocidos y desconocidos;
- revisión manual de cobertura;
- comparación controlada con la interfaz oficial;
- monitoreo reforzado después del cambio.
La aprobación queda vinculada a la versión del adaptador y a la fecha. Si el portal cambia otra vez, no reutilizamos una certificación indefinida.
Métricas que ayudan
Medimos tasa de campos ausentes, estados desconocidos, páginas por consulta, diferencia respecto de patrones históricos y duración. No usamos patentes ni textos de actas como etiquetas.
Una caída brusca de resultados es una señal, no prueba de rotura. Puede reflejar un cambio real de datos. La combinamos con alertas estructurales y casos controlados.
Los screenshots de QA se almacenan restringidos y se redactan antes de compartir.
Qué podemos afirmar
Este método no predice cada rediseño ni convierte una web en API estable. Permite detectar que el contrato observado cambió, aislar la capa y evitar que una lectura incompleta se publique como ausencia de infracciones.
La diferencia esencial es semántica: “no encontramos filas” sólo es válido después de comprobar que el portal autorizado respondió, la consulta terminó y la cobertura sigue siendo la que declaramos.
Metodología
- Alcance
- Comparación de fixtures públicas saneadas y contratos visibles antes y después de cambios simulados de campos, tabla y paginación.
- Unidad de análisis
- Una versión de interfaz identificada por estructura, campos, estados, navegación, cobertura y fecha de verificación.
- Cobertura
- OpenAPI, Datos Argentina, SINAI y HTTP consultados el 14 de agosto de 2026.
Limitaciones
- Los portales sin contrato técnico requieren más verificación manual y no permiten inferir intención del cambio.
- Las fixtures no prueban todos los estados posibles y deben complementarse con observación autorizada.
Fuentes
- OpenAPI Specification 3.1.1 — OpenAPI Initiative (consultada el )
- Documentación y recursos de la API de Series de Tiempo — Jefatura de Gabinete de Ministros (consultada el )
- Términos y condiciones de la consulta de infracciones SINAI — Agencia Nacional de Seguridad Vial (consultada el )
- Consulta de infracciones SINAI — Agencia Nacional de Seguridad Vial (consultada el )
- RFC 9110 — HTTP Semantics — RFC Editor (consultada el )
Preguntas frecuentes
¿Todo cambio de HTML implica pérdida de cobertura?
No. Puede ser sólo presentación. Hay que comprobar campos, estados, paginación y resultados antes de clasificar el impacto.
¿Podemos automatizar cualquier portal oficial?
No. Sólo se accede conforme a autorización, documentación y términos. Si no hay permiso o interfaz soportada, se usa el canal oficial permitido.
¿Qué hacemos mientras la fuente está en revisión?
La marcamos no verificada o parcial. Nunca transformamos una falla de lectura en “sin multas”.
Notas relacionadas
Cómo verificamos que un portal de multas sea realmente oficial
Un diseño convincente, un candado HTTPS o aparecer primero en Google no prueban oficialidad. Verificamos dominio, cadena institucional, trámite publicado y canales antes de confiar datos.
De fuente oficial a resultado: el recorrido de una consulta en multas.ar
Entre ingresar una patente y mostrar un resultado hay decisiones sobre alcance, respuesta de cada fuente, normalización y trazabilidad. Documentarlas evita que un error parezca un cero.
Auditar una respuesta: los cinco campos que siempre revisamos
De dónde salió el dato, cómo terminó la lectura, cuándo se observó, a qué registro pertenece y a qué fecha corresponde el importe. Son cinco controles y conviene mirarlos siempre en el mismo orden.