Un build que pasa te dice que el código compiló. Nada más. No es evidencia de que la página funcione, de que alguien pueda leerla, ni de que un buscador entienda lo que tiene enfrente — y tratarlo como evidencia es la forma en que un sitio se degrada en silencio mientras todos los focos siguen en verde.
Lo aprendimos por la vía directa. En el último mes nuestro propio sitio publicó encabezados invisibles, texto que se partía a la mitad de una palabra, enlaces internos rotos, H1 duplicados y páginas demasiado pobres para justificar su existencia. Ninguna de esas fallas fue detectada por nada. Todas pasaron un build limpio y se desplegaron.
Es una lista incómoda de publicar. También es la parte útil, porque el patrón salta a la vista en cuanto lo escribes: ninguna de esas fallas es un error de compilación. Son fallas de renderizado, de estructura, de criterio. El sistema de build nunca las buscó, y nunca dijo que lo hiciera. Los que estábamos tratando un código de salida exitoso como señal de calidad éramos nosotros.
Así que escribimos la verificación que de verdad necesitábamos. Es un script de shell que corre contra el output construido y comprueba exactamente lo que se rompió: encabezados que se renderizan invisibles, palabras que se cortan a media cadena, enlaces que no llevan a ningún lado, más de un H1 por página, páginas por debajo de un umbral de contenido. Corre antes del deploy y hace fallar la ejecución. Hay un segundo modo que lee Search Console, y ese a propósito nunca falla: los datos de búsqueda son evidencia que se interpreta, no una puerta que se pasa, y confundir las dos cosas produce una verificación en la que nadie confía.
El detalle importante es que no es un linter de buenas prácticas genérico. Cada comprobación es una cicatriz. Existe porque esa cosa exacta se rompió en ese sitio exacto, y por eso es lo bastante corta para leerla de una sentada y lo bastante específica como para que una falla siempre signifique algo. Los sets de reglas genéricos fallan al revés: son largos, son ruidosos, la gente aprende a pasarlos de largo, y la única falla real se pierde entre cuarenta advertencias sobre el alt de una imagen decorativa.
El mismo instinto movió la otra mitad del mes. Lo pasamos escribiendo reglas de marca, tono de voz, lógica de color, tipografía y design tokens como referencias estructuradas, en lugar de dejarlos como cosas que unas cuantas personas saben. Esa es la parte que se pierde de vista cuando se habla de trabajar AI-first. La ventaja no es un modelo generando tu copy. Es que un criterio que antes vivía en la cabeza de alguien —cómo deben verse nuestros encabezados, qué dice y qué no dice nuestra marca— pasa a ser algo que una máquina puede revisar en cada cambio, a las tres de la mañana, sin cansarse y sin ser amable al respecto.
Nada de esto es vistoso, y cuesta tiempo real que preferirías dedicarle al trabajo en sí. Sostenemos que es la opción más barata. La alternativa es enterarte por un cliente, o por una caída de posiciones dos meses después, y en ese punto estás pagando el arreglo y la credibilidad al mismo tiempo.
Así que la pregunta no es si tu build pasa. Es qué cosa tu build no ha buscado jamás. Ve a leer tu configuración de CI y pregúntate qué dejaría pasar; luego escribe las últimas cinco cosas que se rompieron en producción y cuenta cuántas aparecen ahí.
En nuestro caso fueron cero. Por eso existe el script.