Una buena revisión de una web no empieza mirando un informe lleno de colores, sino entendiendo dónde se atascan el rendimiento, la navegación y la conversión. En este artículo explico qué reviso cuando hago una auditoría de una web, cómo detecto fricciones técnicas y de UX, qué métricas me importan de verdad y qué arreglos suelen dar más resultado en un sitio de negocio o e-commerce.
La idea es que salgas con una visión práctica: señales para saber si tu sitio necesita revisión, un método de trabajo paso a paso, herramientas útiles y criterios para priorizar sin perder semanas en detalles secundarios. Si gestionas contenido, captación o una tienda online, esto te ayuda a convertir datos dispersos en decisiones concretas.
Lo esencial para evaluar una web sin perderse en métricas
- Una auditoría útil cruza rendimiento, técnica, UX, accesibilidad y analítica.
- Si el LCP supera 2,5 s, el INP 200 ms o el CLS 0,1, el usuario ya nota fricción.
- Las páginas con más tráfico y mayor impacto en conversión son las primeras que yo reviso.
- Las herramientas sirven poco si la medición está mal configurada o si no comparas móvil y escritorio.
- El objetivo no es generar una lista infinita de fallos, sino una hoja de ruta priorizada.
Qué mira una auditoría web de verdad
Para mí, una auditoría web es una revisión estructurada del sitio para detectar qué impide que cargue bien, se entienda bien y convierta bien. No la veo como un informe de errores sueltos, sino como una lectura conjunta de rendimiento, arquitectura, contenido, accesibilidad y medición.
Si una web informa pero no guía, carga pero no responde, o atrae visitas pero no las transforma en leads o ventas, el problema casi nunca está en un único punto. Suelen coincidir varios: imágenes pesadas, menús poco claros, formularios largos, scripts de terceros y datos mal medidos.- Rendimiento: cuánto tarda en verse y en reaccionar la página.
- Arquitectura: si el usuario entiende dónde está y cómo avanzar.
- UX: si los textos, botones y formularios facilitan la acción.
- Accesibilidad: si la web puede usarse con teclado, lector de pantalla y buen contraste.
- Analítica: si lo que medimos refleja el comportamiento real.
Las señales que me hacen abrir la lupa
Hay sitios que no necesitan una auditoría profunda y otros que la piden a gritos. Yo me pongo en modo revisión cuando veo una mezcla de tráfico estable con conversión floja, diferencias fuertes entre móvil y escritorio, páginas que se sienten lentas o abandonos raros en formularios y checkout.
También me salto a la revisión cuando se ha hecho una migración, un rediseño, un cambio de CMS o una campaña importante y los números no acompañan. Si la web “funciona” pero el negocio no lo nota, algo está perdiéndose por el camino.
- La página carga, pero el usuario tarda en ver el contenido principal.
- El móvil convierte bastante peor que el escritorio.
- Hay mucho tráfico, pero pocas páginas siguen el recorrido esperado.
- El formulario o el checkout pierden usuarios en un punto muy concreto.
- El equipo de soporte recibe quejas repetidas sobre navegación, lectura o errores.
Cuando además veo un LCP por encima de 2,5 segundos, un INP por encima de 200 ms o un CLS por encima de 0,1 en páginas clave, ya no hablo de una molestia menor: hablo de fricción real para la experiencia. A partir de ahí, el paso lógico es revisar el sitio por capas y no por intuición.
Cómo reviso rendimiento, técnica y experiencia de usuario paso a paso
Cuando quiero evitar una auditoría superficial, sigo el mismo orden: primero confirmo dónde está el freno, después miro por qué ocurre y por último priorizo qué tocar. Ese orden evita algo muy común: empezar por botones, colores o copy cuando el cuello de botella real está en una imagen, un script o un formulario roto.
Rendimiento visible
Aquí me fijo en lo que siente el usuario, no solo en la puntuación de una herramienta. Me interesa si la página muestra rápido el contenido principal, si responde sin retrasos y si el layout se mantiene estable mientras carga.
- LCP: mide cuándo aparece el contenido principal. Si sube demasiado, el sitio “parece” lento aunque el resto esté bien.
- INP: mide la respuesta a la interacción. Un botón que tarda en reaccionar mata la confianza.
- CLS: mide saltos inesperados. Un banner que desplaza un botón al hacer clic es un problema de UX, no un detalle estético.
En la práctica, yo miro primero la home, las landings con más tráfico y las páginas que más dinero mueven. En e-commerce suelen ser la categoría, la ficha de producto y el checkout; en servicios, la landing principal y el formulario de contacto.
Arquitectura y base técnica
Después reviso si la web se entiende y se rastrea bien. No me interesa que “funcione más o menos”; me interesa que el recorrido sea limpio, que no haya enlaces rotos y que el usuario no llegue a callejones sin salida.
- Estados HTTP y errores 404 o 5xx que afecten a rutas importantes.
- Redirecciones innecesarias o cadenas demasiado largas.
- Enlaces internos que no ayudan a avanzar ni a descubrir contenido clave.
- Plantillas que rompen en móvil o en determinados tamaños de pantalla.
- JavaScript excesivo o scripts de terceros que bloquean la interacción.
La parte técnica no es solo “SEO”. Si una web tiene un menú confuso, un buscador interno débil o un carrusel que ocupa media pantalla sin aportar nada, el problema ya está afectando a la usabilidad. Y eso, casi siempre, termina en menos conversión.
UX y conversión
En esta parte miro si la propuesta de valor se entiende en segundos, si la jerarquía visual guía la atención y si el siguiente paso está claro. La UX buena no se nota por decoración, se nota porque el usuario duda menos.- Claridad del mensaje principal arriba del todo.
- Botones con jerarquía real, no todos igual de visibles.
- Menús y categorías que reduzcan la carga mental.
- Formularios con el mínimo número de campos posible.
- Pruebas de confianza visibles: envío, devoluciones, atención, garantías.
- Checkout sin pasos extra, sin sorpresas y sin ruido.
Si una tienda online obliga a leer tres bloques de texto antes de entender precio, envío o devolución, la auditoría ya ha encontrado un problema. Lo mismo pasa con una landing donde el CTA se ve, pero no convence, o con un formulario que pide datos que nadie necesita en esa fase.
Lee también: Portada online para documentos y webs - cómo hacerla bien
Accesibilidad que no estorbe al negocio
La accesibilidad no es un bloque decorativo de la auditoría; es parte de la calidad real del sitio. Si la web no se puede usar bien con teclado, tiene contraste pobre o etiqueta mal los campos, excluye a parte del público y además complica la navegación a cualquiera que vaya con prisa o en móvil.
- HTML semántico y encabezados en orden lógico.
- Textos alternativos en imágenes relevantes.
- Etiquetas claras en campos y controles.
- Estados de foco visibles para teclado.
- Contraste suficiente entre texto y fondo.
- Contenido usable sin depender solo del color o de animaciones.
WCAG marca referencias claras: 4,5:1 de contraste mínimo para texto normal y 3:1 para títulos o texto grande. Cuando ese básico no se cumple, la web no solo pierde accesibilidad; pierde legibilidad, confianza y, en muchos casos, ventas.
Qué herramientas uso para no quedarme en impresiones
Yo no trabajo con una sola herramienta porque ninguna ve todo. Unas muestran laboratorio, otras muestran datos reales, otras enseñan comportamiento y otras revelan fricción. La clave no es coleccionarlas, sino saber qué pregunta responde cada una.
| Herramienta | Para qué me sirve | Qué no me dice |
|---|---|---|
| Lighthouse | Detectar problemas rápidos de rendimiento, accesibilidad y buenas prácticas | No refleja por sí sola el comportamiento real de todos los usuarios |
| PageSpeed Insights | Ver datos de laboratorio y de campo en una URL concreta | No explica por sí sola la causa exacta del problema |
| GA4 | Medir eventos, embudos, abandono y segmentación por dispositivo o canal | Si la implementación está mal, puede engañarte |
| Search Console | Revisar rendimiento orgánico, cobertura e incidencias de indexación | No enseña el detalle fino de la experiencia de usuario |
| Clarity o Hotjar | Observar mapas de calor y grabaciones para detectar fricción | Necesitan criterio para interpretar bien las muestras |
En rendimiento, me quedo con una regla simple: si LCP está por debajo de 2,5 segundos, INP por debajo de 200 ms y CLS por debajo de 0,1, la base suele ser razonable. Si la mayor parte del tráfico cae fuera de esos rangos, ya no hablo de pulir detalles, sino de atacar fricción real.
Y hay otra idea que no suelo perder de vista: una puntuación alta en laboratorio no compensa una mala experiencia en producción. Si el sitio va bien en una prueba aislada pero el usuario real abandona, la prioridad sigue siendo el problema del usuario.
Cómo priorizo lo que arreglar primero
La parte más difícil no es detectar fallos, sino decidir qué arreglar primero. Yo uso un criterio muy simple: impacto, exposición y esfuerzo. Un problema que bloquea una compra, afecta a móvil y se repite en páginas muy visitadas va delante de cualquier ajuste cosmético.
- Bloqueante: checkout caído, formulario que no envía, error de carga o navegación imposible.
- Alta prioridad: lentitud en páginas clave, CTA confuso, saltos de contenido o abandonos claros en el embudo.
- Prioridad media: mensajes poco claros, confianza insuficiente, estructura de contenido mejorable.
- Baja prioridad: retoques visuales que no cambian la experiencia ni la conversión.
En una web de negocio, yo empiezo por lo que toca al dinero y a la claridad. Si una mejora necesita dos días y afecta a la mayor parte de las sesiones, suele ir delante de un detalle visual que consume una semana y apenas cambia nada. Esa disciplina ahorra mucho tiempo al equipo.
Los fallos que más hacen perder dinero
La mayoría de las webs no fallan por una gran catástrofe, sino por la suma de pequeñas fricciones. Y ahí veo patrones muy repetidos: medir solo puntuaciones, auditar escritorio y olvidarse del móvil, o revisar la home y dejar intacto el checkout.
- Confundir una nota de herramienta con una buena experiencia real.
- No segmentar por dispositivo, canal o tipo de página.
- Cargar demasiados scripts de terceros que ralentizan y rompen la interacción.
- Hacer cambios grandes sin una medición previa y una validación posterior.
- Optimizar un detalle visual mientras el formulario sigue perdiendo usuarios.
- Ignorar la accesibilidad básica y tratarla como un extra opcional.
Cuando veo esos errores juntos, casi siempre hay una misma causa de fondo: se mira el sitio desde dentro del equipo, no desde el recorrido del usuario. La auditoría sirve precisamente para corregir ese sesgo.
Las primeras mejoras que suelen devolver resultados rápido
Si tuviera que empezar mañana en una web de negocio, no abriría veinte frentes a la vez. Iría a por las mejoras que quitan fricción de forma inmediata y dejan una base mejor para seguir iterando.
- Comprimir imágenes y servir la versión correcta para cada dispositivo.
- Reducir JavaScript no crítico y revisar scripts externos que no aportan valor claro.
- Aclarar la propuesta principal y los CTAs en las páginas con más tráfico.
- Acortar formularios y eliminar campos que no son necesarios en esa fase.
- Revisar contraste, foco y etiquetas para que la interacción sea más simple.
- Dejar bien configurados los eventos clave para saber si el cambio funciona.
Si empiezo por ahí, la revisión deja de ser un documento bonito y se convierte en una ruta de trabajo medible. Ahí es donde de verdad mejora una web: menos fricción, más claridad y datos que permiten decidir con seguridad.
