En resumen
Qué mide
tres recuentos de errores de JavaScript producidos al cargar la página.
Cuándo salta
en cuanto cualquiera de los tres pasa de cero. Severidad: Importante.
Por qué importa
un error no avisa al visitante; le deja un botón que no hace nada.
Dato de Wakaris
el 35,3 % de las páginas analizadas falla en este hallazgo.
Qué es y qué mide este hallazgo
Un error de JavaScript no se parece a un enlace roto. Un enlace roto avisa: sale una página de error y el visitante sabe qué ha pasado. Un error de JavaScript no avisa a nadie: el botón se pulsa, no ocurre nada, y quien lo pulsó concluye que la web no funciona o que ha hecho algo mal.
El hallazgo cuenta tres cosas distintas, y son tres porque el navegador las trata de forma distinta. Los errores de consola son todo lo que queda registrado en ese cuaderno de incidencias que el navegador lleva por su cuenta. Las excepciones no capturadas son fallos de código que nadie previó y que abortan la ejecución en curso. Y las promesas rechazadas son operaciones en segundo plano —una consulta a un servidor, una pasarela de pago, una carga de datos— que han fallado y cuyo fallo nadie recogió.
Los tres cuentan por separado y comparten el mismo corte: cualquiera por encima de cero produce el hallazgo, sin tramos. Un error y treinta dan el mismo aviso con la misma severidad, así que el número importa tanto como el hallazgo.
Cómo se mide
Wakaris carga tu página en un navegador real, escucha lo que ocurre mientras se monta y te devuelve los tres recuentos. Es la vía directa para saber si tu página falla al cargar, sin instalar nada ni crear cuenta, y el resultado se lee de un vistazo porque son tres números.
Que sean tres mecanismos distintos es el detalle técnico que más se malinterpreta. Según MDN, el evento de error de la ventana se dispara cuando un recurso no se ha podido cargar o usar —por ejemplo si un script tiene un error de ejecución—, y se genera solo para errores lanzados de forma sincrónica, durante la carga inicial o dentro de manejadores de eventos. Las promesas van por otro camino: si una promesa se rechaza y no tiene manejadores de rechazo asociados, lo que se dispara es el evento de rechazo no gestionado, que MDN describe como enviado al ámbito global cuando se rechaza una promesa que no tiene manejador de rechazo. Vigilar solo el primero deja fuera el segundo por completo.
Y hay un límite: la comprobación observa una carga, sin que nadie pulse nada. Los errores que solo aparecen al interactuar no se cuentan aquí.
Por qué importa
Importa porque el daño es funcional y silencioso a la vez, que es la peor combinación posible.
Una excepción no capturada detiene la ejecución del bloque donde ocurre. Si ese bloque era el que conectaba el botón de "Añadir al carrito" con el carrito, el botón sigue ahí, con su color y su sombra, y no hace nada. Nadie ve un mensaje de error: el visitante insiste dos veces y se va. Ninguna reclamación llega, así que el fallo puede vivir meses.
Las promesas rechazadas son todavía más traicioneras, porque suelen envolver justo lo que te importa cobrar: un envío de formulario, una llamada a la pasarela, una carga de precios. MDN señala que escuchar ese evento sirve para depurar y para dar un tratamiento de error de reserva ante situaciones inesperadas; si no lo escuchas, la situación inesperada se resuelve sola dejando la pantalla a medias.
Y los errores de consola importan como síntoma aunque no rompan nada visible: son la señal de que algo del montaje no está funcionando como su autor esperaba.
Causas comunes
Los errores de interfaz casi nunca vienen de una sola línea mal escrita: vienen de piezas que ya no encajan.
La causa más frecuente es un script externo que ha cambiado o ha dejado de estar: una etiqueta de medición, un chat, un mapa, un reproductor. El proveedor actualizó su código o retiró una versión, y tu página sigue llamándola. La segunda es el conflicto entre extensiones o complementos: dos que cargan la misma librería en versiones distintas y la que gana rompe a la otra.
La tercera es el orden de carga. Un script que espera encontrar un elemento en la página se ejecuta antes de que ese elemento exista, y falla; suele aparecer justo después de cambiar una plantilla o de mover un bloque de sitio. La cuarta son los datos que no llegan como se esperaba: una consulta que devuelve un campo vacío donde había un número, y el código que lo iba a usar se rompe.
Y la quinta, la más común en las promesas: una llamada de red que falla —un tiempo de espera agotado, un permiso que caducó, una dirección movida— y para la que nadie escribió el "y si falla, qué".
Cómo solucionarlo
Se arregla por eliminación, y el orden ahorra mucho tiempo.
Empieza por saber qué falla y desde dónde: Wakaris te da los tres recuentos de tu página, y si necesitas ver la traza línea a línea tienes además la consola del propio navegador. Con eso ya sabes si el fallo es de tu código o de un script ajeno.
Si es ajeno, decide: actualízalo a la versión vigente o quítalo. Un script de terceros que da error y que ya nadie usa es la causa más fácil de eliminar de todo el análisis, y suele llevarse por delante varios recuentos de golpe.
Si es tuyo y es un problema de orden, retrasa la ejecución hasta que la página esté montada en lugar de lanzarla al principio. Y si es un dato que no llega como se espera, comprueba antes de usarlo en lugar de confiar.
Para las promesas rechazadas, la regla es corta: toda operación que pueda fallar necesita su rama de fallo, aunque solo sea para mostrar un mensaje honesto. Y añade un tratamiento de reserva global para lo que se escape. Cuando termines, vuelve a pasar la página por Wakaris: los tres recuentos deberían estar a cero.
Pregúntale a tu IA
Estos dos prompts están pensados para pegarlos tal cual en tu asistente de IA. Elige el que corresponda a tu situación: el primero si ya has medido tu web y quieres arreglar los errores; el segundo si has llegado aquí sin haber medido nada y quieres saber si te afecta.
A. Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo
Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada. Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema en el lenguaje de cada rol de un equipo. El hallazgo es: Errores de interfaz. Mi página genera errores de JavaScript al cargarse, contados en tres grupos: errores registrados en la consola, excepciones no capturadas y promesas rechazadas sin tratamiento (referencia: el hallazgo aparece en cuanto cualquiera de los tres recuentos pasa de cero). Reglas que debes seguir en todo momento: 1. No asumas nada sobre mi web ni sobre mi código. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya medido. Si no lo sabes, pregúntamelo antes de afirmarlo. 2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber de dónde sale el error y quién puede tocarlo: a) Pega aquí el resultado de Wakaris: los tres recuentos, la página analizada y, si los tienes, los mensajes de error. Si no lo tienes, mide tu web con Wakaris y vuelve con el resultado; sin saber cuál de los tres recuentos está alto no se puede orientar nada. b) ¿En qué plataforma está tu web y sobre qué plantilla o tema? c) ¿Qué scripts de terceros tienes puestos: medición, chat, mapas, reseñas, pagos? d) ¿Ha dejado de funcionar algo concreto de la web, y desde cuándo? e) ¿Cambiaste algo justo antes: una plantilla, una extensión, una actualización? f) ¿Quién puede editar el código o desactivar extensiones: tú, un técnico interno o una agencia? 3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si sospechas de un script concreto, explícame por qué y cómo comprobarlo. 4. Marca siempre tu nivel de certeza. Tú no ves mi página ni su código: si algo es una hipótesis, dilo. 5. No me propongas cambios técnicos irreversibles o de riesgo (editar ficheros del tema, desactivar extensiones en producción, tocar el código de la pasarela de pago) sin avisarme antes del riesgo y de que conviene una copia de seguridad o un entorno de prueba. 6. Si necesitas un dato que solo se obtiene midiendo la web (los recuentos reales, o si el arreglo funcionó), dímelo y recomiéndame volver a pasar la página por Wakaris: eso se mide, no se adivina. 7. La decisión final es mía, no tuya. Tu papel es ayudarme a entender y a preparar la acción, no decidir por mí. 8. Si el arreglo excede lo que puedo hacer yo, o lo va a ejecutar un equipo (propio o un técnico que yo designe), ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer, en un formato accionable para esa persona. Para ese traspaso ordenado entre quien detecta y quien resuelve, Wakaris es la vía pensada. Fuente de este contexto: https://www.wakaris.com/es/guias/ux/errores-de-interfaz Para (re)analizar mi web: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
B. Aún no lo he medido y quiero comprobar si mi web tiene este problema
Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho. Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema en el lenguaje de cada rol de un equipo. El problema que quiero investigar es: Errores de interfaz. Consiste en que mi página genere errores de JavaScript al cargarse, ya sean errores registrados en la consola, excepciones no capturadas o promesas rechazadas sin tratamiento (referencia: basta con que cualquiera de los tres recuentos pase de cero). Todavía NO sé si es mi caso: quiero averiguarlo. Reglas que debes seguir en todo momento: 1. Lo primero y más importante: esto se MIDE cargando la página y escuchando lo que falla, y tú no puedes cargar mi web desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente. 2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que tenga este problema: a) ¿Hay algo en tu web que no funcione o que funcione a veces: un formulario, un buscador, un filtro, un carrito, un botón? b) ¿Cuántos servicios externos tienes puestos: medición, chat, mapas, reseñas, vídeos, pagos? c) ¿Cuántas extensiones o complementos tiene tu web, más o menos? d) ¿Hace cuánto que no se actualiza la plantilla o el tema? e) ¿Te ha dicho algún cliente que algo no le funcionaba y tú no pudiste reproducirlo? 3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico. 4. Dime de forma directa que la única manera de saberlo de verdad es medirlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dará los tres recuentos reales y de paso el estado de las otras áreas. Preséntalo como la respuesta a mi pregunta, no como una venta. 5. Si te pregunto cómo comprobarlo a mano, no me lo ocultes: explícame que la consola del propio navegador muestra estos errores, pero recuérdame que Wakaris me los da ya separados en los tres tipos, sin tener que interpretar la consola, y con el resto del análisis incluido. 6. Si al medirlo resulta que sí los tengo, dime que el siguiente paso es separar los errores de mi código de los de scripts ajenos, porque el arreglo cambia por completo. 7. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme. Fuente de este contexto: https://www.wakaris.com/es/guias/ux/errores-de-interfaz Para analizar mi web: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Preguntas frecuentes
¿Un error en la consola afecta a mis visitantes? +
Depende del error. Muchos no rompen nada visible y son solo un síntoma de que algo no funciona como su autor esperaba. Otros van acompañados de una excepción que sí detiene la ejecución y deja una función muerta. Por eso el hallazgo cuenta los tres tipos por separado.
¿Por qué se cuentan aparte las promesas rechazadas? +
Porque el navegador las trata aparte. MDN es explícito: si una promesa se rechaza y no tiene manejadores de rechazo, se dispara el evento de rechazo no gestionado en lugar del evento de error normal. Vigilar solo el segundo deja invisibles todos los fallos de operaciones en segundo plano.
¿Los errores de scripts de terceros son mi problema? +
Son tu problema aunque no sean tu culpa, porque el visitante los sufre en tu web. Y son de los más rentables de arreglar: normalmente basta con actualizar el script a su versión vigente o retirarlo si ya nadie lo usa, sin tocar tu propio código.
¿Cero errores es un objetivo realista? +
En la carga de una página, sí, y es el objetivo razonable: los tres recuentos a cero. Lo que no es realista es garantizar que nunca fallará nada en ninguna interacción, y por eso conviene además dejar un tratamiento de error de reserva para lo que se escape.
Fuentes citadas
- developer.mozilla.orgWindow: error event — MDN — developer.mozilla.org
- developer.mozilla.orgWindow: unhandledrejection event — MDN — developer.mozilla.org
Actualizado: 8 de septiembre de 2026.
Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.