Una fecha futura no es un calendario

Cada artículo de este sitio lleva una fecha de publicación en su cabecera. Aparece bajo el título, entra en los datos estructurados que lee un buscador y es la única fecha que el mapa del sitio llega a imprimir. Debería ser un hecho.

Durante un tiempo, veinticuatro de ellos no lo eran. Llevaban fechas repartidas por los seis días siguientes, porque quien los escribió tenía en mente un ritmo de publicación y lo puso en el archivo. Nueve idiomas cada uno, o sea doscientos dieciséis archivos. Cada una de esas páginas estaba publicada, era rastreable y estaba indexada, y cada una le contaba a un rastreador, en forma legible por máquina, que había salido en un día que aún no había ocurrido.

No había nada en rojo. La compilación estaba verde, las pruebas estaban verdes, las páginas se servían. Lo único capaz de ver la contradicción era una máquina leyendo la página, y las máquinas no abren incidencias.

Lo que decía el historial

Lo primero que había que establecer era cuál de las dos fechas era cierta. Eso es una sola orden: preguntar a git cuándo se añadió cada archivo por primera vez. Los veinticuatro se añadieron el mismo día, en tres entregas, por tres rondas del mismo trabajo nocturno. No hubo despliegue de seis días. La dispersión era una intención escrita en un campo reservado a observaciones.

Esa distinción es el artículo entero. Un campo que registra lo ocurrido no puede expresar además lo que se planea, porque un lector no sabe distinguir ambas cosas y un rastreador tampoco.

Por qué no se construyó el planificador

La reparación evidente es volver ciertas las fechas haciendo que el sitio las respete: ocultar un artículo hasta que llegue la suya. Aquí es la reparación equivocada por dos motivos independientes, y merece la pena detallar ambos porque el primero se pasa por alto con facilidad.

Este sitio se genera de forma estática. Las páginas se renderizan una vez, durante la compilación, y se sirven como archivo. Una puerta sobre la fecha se evalúa entonces en tiempo de compilación y nunca más. A medianoche no aparece nada; aparece cuando alguien compila. Una puerta de fecha no produce por tanto un calendario de publicación, sino un conjunto de páginas ausentes hasta que da la casualidad de que se ejecuta un despliegue ajeno.

El segundo motivo es peor. Esas doscientas dieciséis direcciones ya estaban rastreadas. Ocultarlas hasta su fecha nominal significa servir un 404 durante hasta seis días en páginas que un buscador ya ha visto e indexado. Un 404 en una dirección ya indexada no es «vuelve más tarde», es una señal de retirada, y recuperarse de eso cuesta mucho más que la falsedad que se corregía.

Así que las fechas se corrigieron al día en el que el trabajo aterrizó de verdad, tocando solo esa línea en cada uno de los doscientos dieciséis archivos, y en su lugar se retiró la posibilidad de escribir una fecha futura.

La puerta está en el origen y no tiene escapatoria

La compilación de contenido rechaza ahora cualquier fecha de cabecera posterior al día en que compila. No un aviso: una compilación fallida con el nombre del archivo y ambas fechas en el mensaje.

Dos pequeñas decisiones dentro merecen nombre. Compara con el hoy de la zona horaria propia del proyecto y no con UTC, porque un artículo publicado aquí a las doce y media de la noche lleva la fecha de aquí, y una comparación contra UTC rechazaría un archivo el día mismo de su publicación. Y no hay anulación a propósito: ni variable de entorno ni bandera. Una escapatoria en una regla así se usa una vez por un buen motivo y después de forma permanente, y un calendario va en una lista de tareas y no en la cabecera de un archivo ya entregado.

Hay una segunda puerta más adelante, en el registro que arma los artículos publicados, y deja fuera todo artículo cuya fecha de publicación siga en el futuro. Es una red de seguridad para los caminos que no pasan por la compilación: un archivo editado a mano, una fusión que mezcla dos generaciones, una copia restaurada. Solo controla la fecha de publicación y no la de modificación, porque una errata en un campo de fecha no debe hacer desaparecer una página ya indexada.

Y esa segunda puerta se evalúa una vez, al cargar el módulo durante la compilación. Eso está escrito en un comentario al lado, porque quien suponga otra cosa acabará escribiendo el planificador contra el que argumenta esta sección.

Una fecha que no se puede deducir es mejor omitirla

La misma ronda tuvo que decidir qué fecha, si alguna, corresponde a las páginas de documentación, que no tienen cabecera. Se presentaron tres candidatas, y las tres son falsas.

Las páginas de documentación no llevan por tanto fecha de publicación en sus datos estructurados. Nada es mejor que una cifra plausible, porque una cifra plausible es la que nadie comprueba.

El mismo razonamiento ya regía el mapa del sitio. Las rutas fijas no llevan fecha de modificación alguna, y el motivo no es pereza: su contenido es código y su texto vive en nueve catálogos de traducción, así que cualquier fecha calculable seguiría algo distinto de lo que ve el lector. Un buscador que pide tres veces una página «cambiada» y la encuentra igual aprende a ignorar el campo, y entonces el campo es peor que ausente en las páginas donde sí es real. Los artículos sí llevan una, porque está en la cabecera junto al título, donde quien reescribe el texto la ve de verdad.

Tras este trabajo la cobertura no cambió en absoluto: las direcciones de artículo llevan fecha de modificación y todo lo demás no, igual que antes. Lo que cambió es que doscientas dieciséis de esas fechas estaban en el futuro, y ahora ninguna lo está.

Otra contradicción, resuelta con identidad

Al revisar los datos estructurados apareció una versión menor del mismo problema: en algunas páginas el autor y el editor eran dos entidades separadas sin relación declarada. Leídas al pie de la letra, esas páginas afirmaban que el artículo lo había escrito una empresa y lo había publicado otra. Ambas apuntan ahora al mismo identificador. Nadie se habría quejado, y seguía siendo una afirmación nuestra que no era cierta.

Lo que dejaríamos escrito

1. 01No ponga nunca una intención en un campo que registra una observación. Un lector no puede separarlas, y una máquina tampoco.
2. 02Contraste la afirmación con el historial. Una orden sobre el historial de archivos decidió cuál de dos fechas era la real, y contradijo a los veinticuatro archivos.
3. 03Una puerta de fecha en un sitio generado de forma estática no es un calendario. A medianoche no aparece nada; aparece en la siguiente compilación.
4. 04No oculte direcciones ya indexadas. Un 404 en una página rastreada es una señal de retirada, y la cura cuesta más que la enfermedad.
5. 05Ponga la puerta donde se comete el error, haga fallar la compilación y no añada anulación. Ponga una segunda puerta más adelante para los caminos que se saltan la primera.
6. 06Omita una fecha que no pueda deducir con honestidad. Tres fuentes plausibles, las tres equivocadas, significa que la salida honesta es ninguna.

Para que quede claro qué es esto: esto es mantenimiento de un sitio web público, no una función de producto, y no cambió ningún comportamiento por el que alguien pague. Parte de ello queda sin probar. Los datos estructurados se validaron contra su propio esquema y leyéndolos, no con un rastreador real ni con una tarjeta de vista previa real. Nada de esto se midió contra el índice de un buscador, porque esa medición tarda semanas y nadie debería esperarla antes de retirar una falsedad.

Del trabajo de sitio en Provibr. Lo que cuesta mantener dieciséis mil textos correctos en nueve idiomas está en dieciséis mil claves, nueve idiomas, y cómo una colisión de números de campo en un protocolo pasó inadvertida está en dos rondas, un número de campo.