¿Qué es el website proofing? Nuestra pesadilla de aprobación, resuelta

Post is also avalible in:

Última actualización: julio de 2026

El marketing no es para los débiles. Especialmente si se trata de marketing digital y usted tiene que mantener su propio sitio web. Antes se decía que internet nunca olvida, pero para las empresas pequeñas eso no era un gran problema. A menos que se hiciera viral, casi nadie notaba siquiera que uno había estado ahí.

Sin embargo, durante el último año, a medida que la IA reemplaza cada vez más a los motores de búsqueda tradicionales (por mucho que algunos se resistan), esa frase ha cambiado un poco. La IA tampoco olvida; es más, le penaliza por errores de maneras que jamás habría imaginado. Y eso añade muchísima complejidad al marketing digital. ¿Por qué le cuento todo esto? Pues bien, porque hoy, amigos, voy a contarles la historia de los grandes altibajos de la creación de sitios web y mi propia experiencia con ello.

El proyecto que reveló el problema

El lanzamiento de una sola página de funcionalidad nos mostró exactamente lo roto que estaba nuestro proceso de revisión de sitios web. Escuche, ¿qué es lo peor que puede pasar después de que un sitio web se publique con un error? ¿Un compañero (o varios) lo señala? ¿Un usuario amable lo señala? ¿Un usuario no tan amable se queja de información engañosa? ¿Una vista general de IA lo recoge y lo trata como la verdad? Elija su veneno. 

Claro, se trata de errores completamente distintos, y usted está convencido de que a usted eso nunca podría pasarle. Yo también pensaba así… Hasta ese día que lo cambió todo. 

Como profesional del marketing, a veces tiene que explicar conceptos en los que usted mismo es bastante mediocre. Aun así, tiene que tomar ese tema, desglosarlo en esos conceptos «geniales» fundamentales y presentarlos. El problema es que usted todavía no termina de entender de qué se trata. Y para nuestro equipo, fue una función orientada a desarrolladores la que cambió por completo la forma en que aprobamos nuestros sitios web. 

La tarea consistía en crear una página de funcionalidad sobre esa gran novedad que encantaría a los desarrolladores, porque les facilita el trabajo; casi no necesitan configurar nada, pero el resultado parece una tarea muy profesional y casi imposible, lograda en un chasquido de dedos. El sonido de ese chasquido de dedos venía, de hecho, de mi propio escritorio, mientras intentaba hacer todas las correcciones en una hora y conseguir que la aprobaran tres personas distintas sin acceso al entorno de desarrollo. Dos veces.

El coste de todo esto 

Si todavía queda alguna duda sobre lo que pasó, se lo digo claramente: tuvimos que rehacer toda la página de funcionalidad dos veces, incluso después de publicarla. Sí, ha oído bien. Revisamos y publicamos la misma página tres veces. Y solo porque tuvimos la suerte de contar con revisores que dieron su feedback a la primera oportunidad posible, todo el proceso nos llevó apenas un mes. Solo 31 días para finalizar una página compuesta por 4 bloques estáticos y 1 interactivo, realmente no es tanto…  Para que se haga una idea, ahora podemos hacer 3 o 4 en el mismo tiempo.

Ahora imagine que no tiene esa misma suerte con sus revisores. Cada etapa del proceso tarda de 3 a 4 días en aprobarse, y luego le queda una montaña de correcciones que hacer antes de que termine la semana para poder iniciar el nuevo ciclo de aprobación el lunes. 

Qué hicimos mal (y probablemente usted también)

Hay una razón por la que algunos procesos de revisión de sitios web duran más que otros, y en nuestro caso, hubo cuatro errores muy grandes y evidentes:

Nunca estábamos revisando realmente el sitio web

El principal problema con el website proofing para nosotros era que nunca estábamos revisando realmente un sitio web. A veces era una captura de pantalla de un fragmento de un bloque con una línea roja alrededor de un elemento erróneo. 

A veces era una instantánea de una página, guardada en PDF. Eso no está tan mal, pensará usted; al menos Adobe permite anotar. ¡Falso! El 10 % de la página no estaba ahí debido a la división natural entre páginas del PDF, así que perdíamos líneas de texto o veíamos un elemento cortado por la mitad simplemente porque caía justo en un salto de página. 

La tercera opción era la mejor; simplemente exportaba el sitio web como JPEG y lo subía a una herramienta de revisión en línea, rezando para que la calidad fuera suficiente para que todos pudieran leer el texto. Y luego pasaba los siguientes 3 días laborables intentando hacer zoom para que pareciera una página web de verdad. Pero al menos no había partes faltantes ni comentarios recortados.

Nunca podíamos aprobar los elementos interactivos

Otro problema era que nunca podíamos aprobar los elementos interactivos, los botones y los distintos resultados. Una captura de pantalla no muestra qué pasa cuando se pasa el cursor sobre una tarjeta, cómo se ve un menú desplegable abierto en lugar de cerrado, o si un formulario realmente se envía en vez de quedarse ahí, sin más, luciendo bonito. Todo parecía un elemento visual, no una página real. Estábamos aprobando cómo se veía un sitio web congelado en el tiempo, no lo que realmente hacía una vez que alguien interactuaba con él.

Y como nada de eso se podía evaluar a partir de una exportación estática, otra persona tenía que revisar todos los botones, animaciones y resultados por separado, a mano, haciendo clic en cada elemento del sitio en vivo para confirmar que realmente funcionaba. No era una tarea agradable, ni tampoco rápida. No ayudaba que esto siempre ocurriera después de que ya se hubiera dado la aprobación «oficial», así que se sentía menos como control de calidad y más como descubrir, en el peor momento posible, que lo que todos acababan de aprobar en realidad estaba discretamente roto. Y siempre fallaba algo. Así que cada dos semanas, dedicaba media hora a escribir un correo electrónico apenado explicando por qué el lanzamiento se retrasaba otra vez.

El feedback vivía en tres lugares distintos a la vez

Cada formato que usábamos para el website proofing se convertía en su propio canal de feedback independiente. Es decir, tener tres «formatos» distintos de sitio web significaba automáticamente tener también tres fuentes de feedback distintas. Teníamos algunas anotaciones en la herramienta, algunas más del PDF, y luego muchas más en chats privados y algunas en grupos. 

Así que, lo que solíamos hacer era que yo tomaba una captura de pantalla de cada comentario recibido y luego lo ponía en un documento de Google a modo de lista de verificación. Y cada vez que se hacía un cambio, volvía a ese documento y marcaba otro elemento. Bastante práctico, pero una pesadilla de organizar y apenas funcional. Como esa laptop que lleva años desafiando las leyes de la física con solo seguir funcionando.

Los revisores no podían saber qué había cambiado ya

Tampoco teníamos manera de mostrarles a los revisores qué había cambiado desde su última ronda de comentarios. Y mi parte favorita de todo el proceso es el «Oh, ¿cambió lo que le pedí hace dos rondas?» Sé que no lo dicen con mala intención, y entiendo que el cambio era pequeño y casi invisible, pero a mí me tomó dos horas, y para mí es muy visible.

Pero eso es lo que acaba pasando cuando recibe aprobaciones de personas que tienen muchísimo trabajo propio, y no hay ningún recordatorio de cómo se veía la página antes. Y enviar ambas opciones tampoco es una alternativa, a menos que ponga un gran letrero de «desactualizado» en toda la página, como una triste marca de agua.

Por qué finalmente decidimos solucionarlo

Antes del incidente de la página de funcionalidad, todo este proceso era solo una molestia. Algunos simplemente querían seguir adelante y no prestaban mucha atención a lo que había en la página. Otros no tenían suficientes accesos, así que pedían una versión estática o directamente no volvían a mirarla una vez publicada. 

Sin embargo, tras el incidente de la página de funcionalidad, se mostró información incorrecta en vivo durante un tiempo, y la IA la recogió casi de inmediato; hubo consenso en que había que hacer algo al respecto. Al principio, buscamos hacia afuera: plugins, herramientas adicionales o puentes de API para cargar el sitio web dentro de una herramienta de revisión. 

Pero entonces (bastante rápido, en realidad), entendimos que la respuesta estaba justo delante de nosotros. Ya teníamos una herramienta de revisión a nuestra disposición, varios clientes que la necesitaban en su flujo de trabajo, y nuestra propia motivación interna para tener una forma de revisar sitios web. Así que decidimos que, en lugar de buscarla, debíamos construirla. 

¿Qué es el website proofing?

El website proofing consiste en revisar un sitio web en producción o en preproducción, en escritorio, tablet y móvil, antes de que se publique, con comentarios anclados al punto exacto de la página. Sustituye las capturas de pantalla, los PDF y los hilos de correo por un único lugar donde ver, navegar y aprobar el sitio tal y como funcionará en realidad.

Una herramienta que hace eso se llama herramienta de revisión (o proofing) de sitios web. Es una plataforma centralizada que le permite revisar y anotar sitios web o páginas específicas de forma interactiva. Eso significa que puede hacer clic en botones, ver animaciones y navegar por el sitio mientras sigue pudiendo dejar comentarios anclados. 

Así que, ahora, en lugar de pasar por todo el proceso de exportar y enviar un sitio web estático, simplemente introduzco su URL, añado las direcciones de correo de todas las personas que necesitan aprobarlo, y hago clic en enviar. O, aún más fácil, simplemente copio el enlace y lo envío al chat grupal, y ahora todos pueden opinar sobre una página en la que pasé dos días trabajando. 

Ya existen algunas herramientas de website proofing en el mercado, algunas creadas específicamente para sitios web (BugHerd, Pastel), y algunas herramientas de revisión en línea más generales con website proofing añadido, como PageProof. Pero ninguna de ellas existía dentro de nuestro propio flujo de trabajo cuando más la necesitábamos. Así que decidimos tomar el camino más sencillo y crear la nuestra.

Cómo el website proofing resolvió cada uno de estos problemas

Y esta herramienta de website proofing resolvió estupendamente muchos de nuestros contratiempos internos, así que decidimos que funcionaba lo bastante bien como para presentársela. Y para no hacer afirmaciones sin fundamento, permítame mostrarle cómo una herramienta de revisión de sitios web nos facilitó muchísimo la vida. 

Si esto le suena familiar, es porque es una versión de mayor riesgo de un problema sobre el que ya hemos escrito antes: por qué el método tradicional le está haciendo perder tiempo. Las capturas de pantalla y los hilos de correo son lentos sin importar lo que esté aprobando.

Qué debería tener una herramienta de revisión de sitios web

Después de vivir las distintas variantes del «website proofing», tengo mis propias opiniones sobre lo que distingue a una herramienta de revisión real de una solución improvisada disfrazada de herramienta de revisión. Para mí, siempre se ha tratado de la rapidez con la que se puede enviar a revisión y de lo fácil que resulta para los demás acceder a ella. Así que, esto es lo que considero innegociable, de parte de alguien que probó primero todas las formas equivocadas de hacerlo:

• Carga la página real, en vivo o en preproducción, no una captura de pantalla, un PDF o una exportación JPEG de esta
• Le permite cambiar entre las vistas de escritorio, tablet y móvil sin abrir tres pestañas separadas
• Le permite hacer clic en botones, activar animaciones y navegar a páginas vinculadas
• Ancla los comentarios al punto exacto de la página en lugar de dispersarlos
• Hace seguimiento de las versiones, para que nadie vuelva a señalar algo que usted ya corrigió dos rondas atrás
• Funciona con un único enlace compartible, para que cualquiera pueda opinar, tenga o no accesos de desarrollo
• Genera un informe final de lo que se aprobó, y por quién, para que exista un registro real ante cualquier pregunta

Si una herramienta no cumple con la mayoría de estos puntos, honestamente está revisando un rumor de sitio web. Y esa no es una buena posición en la que estar. 

Quién definitivamente necesita una herramienta de website proofing

Pero no todos los equipos la necesitan. Si es un desarrollador independiente publicando su propio sitio de portafolio, adelante con su vida, probablemente no necesite que su madre le ancle comentarios en la sección principal. Pero si más de una persona tiene que dar el visto bueno antes de que una página se publique, y especialmente si algunas de esas personas no tienen la paciencia de un desarrollador para los entornos de preproducción, esto es para usted. Así que, si usted es:

• Un equipo de marketing y/o creativo que lanza o renueva un sitio
• Alguien a quien un revisor sin memoria alguna de cómo lucía la página le ha preguntado «¿ya hizo esos cambios de noviembre?»
• Equipos donde el departamento legal, un gerente u otro departamento debe dar el visto bueno antes de que algo se publique, sin poder esperar tener acceso a un entorno de desarrollo
• Agencias que entregan un sitio terminado a un cliente que desea un registro limpio y exportable de lo que realmente se aprobó
• Equipos de desarrollo cansados de ser los únicos que pueden abrir el enlace de preproducción, a quienes les encantaría dejar de recibir comentarios sobre sus bloques interactivos una vez en producción

Si leyó esta lista y asintió con más de un punto, ya sabe por qué construimos esto.

En resumen

Puede que se esté preguntando por qué he dedicado tanto tiempo y tantas palabras a mis propias pesadillas de aprobación. Es una pregunta justa. La respuesta corta es que esta es la historia de Approval Studio, no una hipotética. No investigamos este problema desde fuera. Lo vivimos desde dentro, rehicimos la misma página tres veces, mantuvimos un Google Doc como nuestra única fuente confiable porque nada más lo era lo suficiente, y nos preguntaron «¿ya lo cambiaste, por cierto?» más veces de las que estoy dispuesta a admitir por escrito.

Así que construimos nuestra propia función de website proofing para solucionar esto, la probamos internamente en nuestros propios lanzamientos hasta que realmente confiamos en ella (no solo esperamos que funcionara), y ahora estamos listos para que más personas la usen. Si prefiere no escribir su propia versión de esta historia, apúntese a la lista de espera. Le avisaremos en el momento en que esté disponible, y nunca más tendrá que explicarle a su gerente un botón roto después de un lanzamiento.