\u00daltima actualizaci\u00f3n: julio de 2026<\/strong><\/p>\n\n\n\nEl marketing no es para los d\u00e9biles. Especialmente si se trata de marketing digital y usted tiene que mantener su propio sitio web. Antes se dec\u00eda que internet nunca olvida, pero para las empresas peque\u00f1as eso no era un gran problema. A menos que se hiciera viral, casi nadie notaba siquiera que uno hab\u00eda estado ah\u00ed. <\/p>\n\n\n\n
Sin embargo, durante el \u00faltimo a\u00f1o, a medida que la IA reemplaza cada vez m\u00e1s a los motores de b\u00fasqueda tradicionales (por mucho que algunos se resistan), esa frase ha cambiado un poco. La IA tampoco olvida; es m\u00e1s, le penaliza por errores de maneras que jam\u00e1s habr\u00eda imaginado. Y eso a\u00f1ade much\u00edsima complejidad al marketing digital. \u00bfPor qu\u00e9 le cuento todo esto? Pues bien, porque hoy, amigos, voy a contarles la historia de los grandes altibajos de la creaci\u00f3n de sitios web y mi propia experiencia con ello. <\/p>\n\n\n\n
El proyecto que revel\u00f3 el problema<\/h2>\n\n\n\n El lanzamiento de una sola <\/em>p\u00e1gina de funcionalidad nos mostr\u00f3 exactamente lo roto que estaba nuestro proceso de revisi\u00f3n de sitios web. Escuche, \u00bfqu\u00e9 es lo peor que puede pasar despu\u00e9s de que un sitio web se publique con un error? \u00bfUn compa\u00f1ero (o varios) lo se\u00f1ala? \u00bfUn usuario amable lo se\u00f1ala? \u00bfUn usuario no tan amable se queja de informaci\u00f3n enga\u00f1osa? \u00bfUna vista general de IA lo recoge y lo trata como la verdad? Elija su veneno. <\/p>\n\n\n\nClaro, se trata de errores completamente distintos, y usted est\u00e1 convencido de que a usted eso nunca podr\u00eda pasarle. Yo tambi\u00e9n pensaba as\u00ed\u2026 Hasta ese d\u00eda que lo cambi\u00f3 todo. <\/p>\n\n\n\nComo profesional del marketing, a veces tiene que explicar conceptos en los que usted mismo es bastante mediocre. Aun as\u00ed, tiene que tomar ese tema, desglosarlo en esos conceptos \u00abgeniales\u00bb fundamentales y presentarlos. El problema es que usted todav\u00eda no termina de entender de qu\u00e9 se trata. Y para nuestro equipo, fue una funci\u00f3n orientada a desarrolladores la que cambi\u00f3 por completo la forma en que aprobamos nuestros sitios web. <\/p>\n\n\n\n
La tarea consist\u00eda en crear una p\u00e1gina de funcionalidad sobre esa gran novedad que encantar\u00eda 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\u00eda, 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.<\/p>\n\n\n\n
El coste de todo esto <\/h2>\n\n\n\n Si todav\u00eda queda alguna duda sobre lo que pas\u00f3, se lo digo claramente: tuvimos que rehacer toda la p\u00e1gina de funcionalidad dos veces, incluso despu\u00e9s <\/em>de publicarla. S\u00ed, ha o\u00eddo bien. Revisamos y publicamos la misma p\u00e1gina 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\u00f3 apenas un mes. Solo 31 d\u00edas para finalizar una p\u00e1gina compuesta por 4 bloques est\u00e1ticos y 1 interactivo, realmente no es tanto\u2026 <\/em>Para que se haga una idea, ahora podemos hacer 3 o 4 en el mismo tiempo.<\/p>\n\n\n\nAhora imagine que no tiene esa misma suerte con sus revisores. Cada etapa del proceso tarda de 3 a 4 d\u00edas en aprobarse, y luego le queda una monta\u00f1a de correcciones que hacer antes de que termine la semana para poder iniciar el nuevo ciclo de aprobaci\u00f3n el lunes. <\/p>\n\n\n\n
Qu\u00e9 hicimos mal (y probablemente usted tambi\u00e9n)<\/h2>\n\n\n\n Hay una raz\u00f3n por la que algunos procesos de revisi\u00f3n de sitios web duran m\u00e1s que otros, y en nuestro caso, hubo cuatro errores muy grandes y evidentes:<\/p>\n\n\n\n
Nunca est\u00e1bamos revisando realmente el sitio web<\/h3>\n\n\n\n El principal problema con el website proofing para nosotros era que nunca est\u00e1bamos revisando realmente un sitio web. A veces era una captura de pantalla de un fragmento de un bloque con una l\u00ednea roja alrededor de un elemento err\u00f3neo. <\/p>\n\n\n\n
A veces era una instant\u00e1nea de una p\u00e1gina, guardada en PDF. Eso no est\u00e1 tan mal, pensar\u00e1 usted; al menos Adobe permite anotar. \u00a1Falso! El 10 % de la p\u00e1gina no estaba ah\u00ed debido a la divisi\u00f3n natural entre p\u00e1ginas del PDF, as\u00ed que perd\u00edamos l\u00edneas de texto o ve\u00edamos un elemento cortado por la mitad simplemente porque ca\u00eda justo en un salto de p\u00e1gina. <\/p>\n\n\n\n
La tercera opci\u00f3n era la mejor; simplemente exportaba el sitio web como JPEG y lo sub\u00eda a una herramienta de revisi\u00f3n en l\u00ednea, rezando para que la calidad fuera suficiente para que todos pudieran leer el texto. Y luego pasaba los siguientes 3 d\u00edas laborables intentando hacer zoom para que pareciera una p\u00e1gina web de verdad. Pero al menos no hab\u00eda partes faltantes ni comentarios recortados.<\/p>\n\n\n\nNunca pod\u00edamos aprobar los elementos interactivos<\/h3>\n\n\n\n Otro problema era que nunca pod\u00edamos aprobar los elementos interactivos, los botones y los distintos resultados. Una captura de pantalla no muestra qu\u00e9 pasa cuando se pasa el cursor sobre una tarjeta, c\u00f3mo se ve un men\u00fa desplegable abierto en lugar de cerrado, o si un formulario realmente se env\u00eda en vez de quedarse ah\u00ed, sin m\u00e1s, luciendo bonito. Todo parec\u00eda un elemento visual, no una p\u00e1gina real. Est\u00e1bamos aprobando c\u00f3mo se ve\u00eda un sitio web congelado en el tiempo, no lo que realmente hac\u00eda una vez que alguien interactuaba con \u00e9l.<\/p>\n\n\n\n
Y como nada de eso se pod\u00eda evaluar a partir de una exportaci\u00f3n est\u00e1tica, otra persona ten\u00eda 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\u00e1pida. No ayudaba que esto siempre ocurriera despu\u00e9s de que ya se hubiera dado la aprobaci\u00f3n \u00aboficial\u00bb, as\u00ed que se sent\u00eda menos como control de calidad y m\u00e1s como descubrir, en el peor momento posible, que lo que todos acababan de aprobar en realidad estaba discretamente roto. Y siempre fallaba algo. As\u00ed que cada dos semanas, dedicaba media hora a escribir un correo electr\u00f3nico apenado explicando por qu\u00e9 el lanzamiento se retrasaba otra vez.<\/p>\n\n\n\n
El feedback viv\u00eda en tres lugares distintos a la vez<\/h3>\n\n\n\n Cada formato que us\u00e1bamos para el website proofing se convert\u00eda en su propio canal de feedback independiente. Es decir, tener tres \u00abformatos\u00bb distintos de sitio web significaba autom\u00e1ticamente tener tambi\u00e9n tres fuentes de feedback distintas. Ten\u00edamos algunas anotaciones en la herramienta, algunas m\u00e1s del PDF, y luego muchas m\u00e1s en chats privados y algunas en grupos. <\/p>\n\n\n\n
As\u00ed que, lo que sol\u00edamos hacer era que yo tomaba una captura de pantalla de cada comentario recibido y luego lo pon\u00eda en un documento de Google a modo de lista de verificaci\u00f3n. Y cada vez que se hac\u00eda un cambio, volv\u00eda a ese documento y marcaba otro elemento. Bastante pr\u00e1ctico, pero una pesadilla de organizar y apenas funcional. Como esa laptop que lleva a\u00f1os desafiando las leyes de la f\u00edsica con solo seguir funcionando.<\/p>\n\n\n\nLos revisores no pod\u00edan saber qu\u00e9 hab\u00eda cambiado ya<\/h3>\n\n\n\n Tampoco ten\u00edamos manera de mostrarles a los revisores qu\u00e9 hab\u00eda cambiado desde su \u00faltima ronda de comentarios. Y mi parte favorita de todo el proceso es el \u00abOh, \u00bfcambi\u00f3 lo que le ped\u00ed hace dos rondas?\u00bb S\u00e9 que no lo dicen con mala intenci\u00f3n, y entiendo que el cambio era peque\u00f1o y casi invisible, pero a m\u00ed me tom\u00f3 dos horas, y para m\u00ed es muy visible. <\/p>\n\n\n\n
Pero eso es lo que acaba pasando cuando recibe aprobaciones de personas que tienen much\u00edsimo trabajo propio, y no hay ning\u00fan recordatorio de c\u00f3mo se ve\u00eda la p\u00e1gina antes. Y enviar ambas opciones tampoco es una alternativa, a menos que ponga un gran letrero de \u00abdesactualizado\u00bb en toda la p\u00e1gina, como una triste marca de agua. <\/p>\n\n\n\nPor qu\u00e9 finalmente decidimos solucionarlo<\/h2>\n\n\n\n Antes del incidente de la p\u00e1gina de funcionalidad, todo este proceso era solo una molestia. Algunos simplemente quer\u00edan seguir adelante y no prestaban mucha atenci\u00f3n a lo que hab\u00eda en la p\u00e1gina. Otros no ten\u00edan suficientes accesos, as\u00ed que ped\u00edan una versi\u00f3n est\u00e1tica o directamente no volv\u00edan a mirarla una vez publicada. <\/p>\n\n\n\n
Sin embargo, tras el incidente de la p\u00e1gina de funcionalidad, se mostr\u00f3 informaci\u00f3n incorrecta en vivo durante un tiempo, y la IA la recogi\u00f3 casi de inmediato; hubo consenso en que hab\u00eda 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\u00f3n. <\/p>\n\n\n\n
Pero entonces (bastante r\u00e1pido, en realidad), entendimos que la respuesta estaba justo delante de nosotros. Ya ten\u00edamos una herramienta de revisi\u00f3n a nuestra disposici\u00f3n, varios clientes que la necesitaban en su flujo de trabajo, y nuestra propia motivaci\u00f3n interna para tener una forma de revisar sitios web. As\u00ed que decidimos que, en lugar de buscarla, deb\u00edamos construirla. <\/p>\n\n\n\n
\u00bfQu\u00e9 es el website proofing?<\/h2>\n\n\n\n\n \n <\/span>\n Definici\u00f3n\n <\/span>\n Website proofing<\/p>\n
El website proofing consiste en revisar un sitio web en producci\u00f3n o en preproducci\u00f3n, en escritorio, tablet y m\u00f3vil, antes de que se publique, con comentarios anclados al punto exacto de la p\u00e1gina. Sustituye las capturas de pantalla, los PDF y los hilos de correo por un \u00fanico lugar donde ver, navegar y aprobar el sitio tal y como funcionar\u00e1 en realidad.<\/p>\n<\/aside>\n\n\n\n
El website proofing consiste en revisar un sitio web en producci\u00f3n o en preproducci\u00f3n, en escritorio, tablet y m\u00f3vil, antes de que se publique, con comentarios anclados al punto exacto de la p\u00e1gina. Sustituye las capturas de pantalla, los PDF y los hilos de correo por un \u00fanico lugar donde ver, navegar y aprobar el sitio tal y como funcionar\u00e1 en realidad.<\/p>\n\n\n\n
Una herramienta que hace eso se llama herramienta de revisi\u00f3n (o proofing) de sitios web. Es una plataforma centralizada que le permite revisar y anotar sitios web o p\u00e1ginas espec\u00edficas de forma interactiva. Eso significa que puede hacer clic en botones, ver animaciones y navegar por el sitio mientras sigue pudiendo dejar comentarios anclados. <\/p>\n\n\n\n
As\u00ed que, ahora, en lugar de pasar por todo el proceso de exportar y enviar un sitio web est\u00e1tico, simplemente introduzco su URL, a\u00f1ado las direcciones de correo de todas las personas que necesitan aprobarlo, y hago clic en enviar. O, a\u00fan m\u00e1s f\u00e1cil, simplemente copio el enlace y lo env\u00edo al chat grupal, y ahora todos pueden opinar sobre una p\u00e1gina en la que pas\u00e9 dos d\u00edas trabajando. <\/p>\n\n\n\n
Ya existen algunas herramientas de website proofing en el mercado, algunas creadas espec\u00edficamente para sitios web (BugHerd<\/a>, Pastel), y algunas herramientas de revisi\u00f3n en l\u00ednea m\u00e1s generales con website proofing a\u00f1adido, como PageProof<\/a>. Pero ninguna de ellas exist\u00eda dentro de nuestro propio flujo de trabajo cuando m\u00e1s la necesit\u00e1bamos. As\u00ed que decidimos tomar el camino m\u00e1s sencillo y crear la nuestra.<\/p>\n\n\n\n