Auditoría de sitios web en 2026: checklist completa de SEO, Core Web Vitals, accesibilidad y seguridad

En 2026, la auditoría debe realizarse por capas. Google sigue basando la visibilidad en fundamentos técnicos y contenido creado principalmente para las personas, aunque los resultados también pueden aparecer en funciones impulsadas por IA. Los Core Web Vitals deben evaluarse con datos reales, la accesibilidad no puede confirmarse solo con un escáner y la seguridad exige mucho más que un certificado SSL.

Esta guía recorre todo el proceso: indexación y SEO, LCP, INP y CLS, WCAG 2.2, encabezados de seguridad, formularios, analítica y orden de implementación de las mejoras.

TL;DR: empieza por los fallos críticos: web caída, bloqueos de indexación, redirecciones incorrectas, problemas de HTTPS y vulnerabilidades. Después mejora los Core Web Vitals, la accesibilidad de los recorridos principales, el contenido y el enlazado interno. Una puntuación de 100/100 en una herramienta no sustituye los datos de Search Console, las pruebas en dispositivos reales ni la revisión manual.

Normas, umbrales y fuentes verificados por última vez el 23 de julio de 2026.

Áreas principales de la auditoría

Área	Qué comprobar	Cómo es un buen resultado	Prioridad
Indexación	robots.txt, noindex, sitemap, canonical, estados HTTP	páginas importantes accesibles e indexables, duplicados consolidados	crítica
SEO y contenido	intención, títulos, encabezados, enlaces internos, datos estructurados	cada página importante tiene un objetivo claro y valor único	alta
Rendimiento	LCP, INP, CLS, TTFB, JavaScript, imágenes, fuentes	CWV en rango «bueno» para el percentil 75	alta
Accesibilidad	teclado, foco, semántica, contraste, formularios, lectores de pantalla	recorridos clave conformes con WCAG 2.2 AA	alta
Seguridad	HTTPS, encabezados, cookies, dependencias, autorización, copias	sin vulnerabilidades críticas ni exposición innecesaria	crítica
UX y conversión	móvil, formularios, navegación, errores, confianza	el usuario completa la tarea principal sin fricción innecesaria	alta
Medición	Search Console, analítica, registros, monitorización	datos completos, respetuosos con la privacidad y accionables	media

¿Qué incluye realmente una auditoría web?

Una auditoría completa combina al menos seis perspectivas:

1. SEO técnico: si un rastreador puede acceder al sitio, renderizarlo, seguir sus enlaces e identificar la URL canónica correcta.
2. Calidad del contenido: si la página responde a una necesidad real, tiene una estructura lógica y no duplica innecesariamente otras páginas.
3. Rendimiento: cuánto tarda en aparecer el contenido principal, cómo responde la página y si el diseño se desplaza durante la carga.
4. Accesibilidad: si el servicio puede utilizarse con teclado, lector de pantalla, zoom y sin depender exclusivamente del color.
5. Seguridad y privacidad: si las comunicaciones, sesiones, formularios, dependencias y datos están correctamente protegidos.
6. UX y objetivos de negocio: si los visitantes entienden la oferta y pueden realizar la acción más importante sin pasos innecesarios.

Las herramientas automáticas son un buen punto de partida, pero no pueden evaluarlo todo. Lighthouse detecta parte de los problemas de rendimiento y accesibilidad, pero no sabe si la oferta se entiende, si un formulario responde a las necesidades del cliente o si un mensaje de error ayuda realmente a recuperarse.

Antes de empezar: define el alcance y la muestra de URL

El error más habitual es analizar solo la página de inicio. En la práctica deben comprobarse tipos de página representativos:

• página de inicio,
• principal página de servicio o producto,
• artículo o guía,
• categoría o listado,
• formulario de contacto, registro o checkout,
• página de resultados de búsqueda,
• versión lingüística,
• página 404 y otros estados de error,
• página que requiera autenticación, si existe.

En una web pequeña puede bastar una muestra de varias o una docena de URL. En una tienda, portal o aplicación conviene auditar plantillas, no URL aleatorias. Si una plantilla de producto tiene un canonical incorrecto o carga un script pesado, el problema puede afectar a miles de páginas.

Antes de la auditoría reúne:

• acceso a Google Search Console y analítica,
• lista de los objetivos de negocio más importantes,
• sitemap y plantillas principales,
• información sobre cambios, migraciones y caídas de tráfico,
• datos de monitorización de errores y registros del servidor,
• dispositivos y navegadores más utilizados por los clientes.

1. Auditoría de SEO técnico e indexación

Comprueba los códigos HTTP y las variantes del dominio

Cada URL importante debe devolver el estado adecuado:

• 200 para una página operativa,
• 301 o 308 para una redirección permanente,
• 404 o 410 para contenido eliminado,
• 5xx solo ante un error real del servidor, no como estado permanente.

Comprueba http/https, www/non-www, barras finales y mayúsculas. Todas las variantes deben conducir a una versión coherente. Evita cadenas de redirecciones y redirigir muchas URL antiguas a una página de inicio sin relación con el contenido original.

Revisa robots.txt, noindex y el acceso a recursos

El archivo robots.txt controla el rastreo a nivel de descarga, pero no elimina una página de los resultados de búsqueda. Una URL bloqueada puede seguir apareciendo en el índice si Google la descubre desde otras fuentes. Para excluirla se utilizan, entre otras medidas, noindex, protección con contraseña o eliminación del recurso.

Comprueba que:

• las secciones importantes no estén bloqueadas por error,
• el entorno de pruebas esté protegido y no solo oculto en robots.txt,
• Google pueda cargar CSS, JavaScript e imágenes necesarios para renderizar,
• el sitemap esté en la dirección correcta y contenga solo páginas canónicas,
• no haya quedado un noindex tras publicar la versión de producción.

Evalúa canonicales y duplicados

La URL canónica indica la versión preferida de contenido duplicado o muy similar. Google considera el canonical una señal fuerte, pero puede escoger otra URL cuando el resto de señales no son coherentes.

Comprueba la consistencia entre:

• rel="canonical",
• redirecciones,
• enlaces internos,
• sitemaps XML,
• versiones lingüísticas,
• protocolo y host.

El canonical debería apuntar normalmente a una URL activa con 200, no a un error, una redirección o una URL marcada como noindex.

Comprueba el renderizado JavaScript

Google procesa las aplicaciones JavaScript en fases: rastreo, renderizado e indexación. El contenido generado en el cliente puede procesarse más tarde que el HTML disponible inmediatamente, por lo que la información y los enlaces críticos no deberían depender de un script frágil.

En SPA y servicios híbridos revisa:

• HTML visible antes de ejecutar JavaScript,
• enlaces como verdaderos elementos <a href>,
• gestión de códigos de estado,
• metadatos generados para cada URL,
• comportamiento al abrir directamente una subpágina,
• errores de hidratación y llamadas API fallidas,
• indexación de paginación y listas con scroll infinito.

Controla las versiones lingüísticas

En una web multilingüe cada versión debe tener una URL propia y estable. Revisa:

• atributos hreflang correctos,
• referencias recíprocas entre versiones,
• un x-default opcional,
• canonical hacia la misma versión de idioma,
• ausencia de redirecciones automáticas que bloqueen rastreadores,
• títulos, descripciones, contenido y navegación traducidos.

Checklist de SEO técnico

• Las URL importantes devuelven 200.
• Las redirecciones son directas y lógicas.
• No hay bloqueos accidentales en robots.txt.
• Producción no contiene un noindex no deseado.
• El sitemap XML solo contiene URL canónicas.
• Canonicales, enlaces y sitemap son coherentes.
• JavaScript no oculta contenido crítico a los rastreadores.
• Las páginas 404 devuelven realmente 404.
• Las versiones lingüísticas usan hreflang correctamente.
• Parámetros y filtros no generan duplicación masiva.

2. Auditoría de contenido y SEO on-page

Cada página debe tener un objetivo principal

El título, H1, introducción, contenido y llamada a la acción deben responder a la misma intención. Si una página intenta vender un servicio, explicar conceptos básicos y posicionarse para una docena de búsquedas inconexas, normalmente no hace bien ninguna de esas cosas.

Comprueba:

• que el title sea único y descriptivo,
• que el H1 principal refleje el contenido,
• que el fragmento en buscadores invite al clic sin promesas exageradas,
• que H2 y H3 formen una estructura lógica,
• que la respuesta aparezca pronto y no tras una introducción larga,
• que el artículo aporte experiencia, ejemplos y fuentes,
• que la fecha de actualización corresponda a un cambio real.

Google recomienda contenido útil, fiable y creado principalmente para personas, no páginas diseñadas únicamente para manipular el ranking.

El enlazado interno debe crear estructura

Un buen enlazado interno ayuda al usuario a continuar y muestra al buscador la relación entre temas. Utiliza textos de anclaje descriptivos en lugar de muchos «haz clic aquí».

Enlaces naturales desde este artículo:

• Estado del sitio web de POLPROG,
• Core Web Vitals en la práctica,
• Estrategia web,
• Rendimiento,
• Seguridad,
• Cómo planificar una web empresarial que genera clientes.

Busca también páginas huérfanas, sin ningún enlace interno entrante.

Imágenes, datos estructurados y Open Graph

Las imágenes deben tener nombres útiles, dimensiones adecuadas y texto alternativo cuando transmiten información. Una imagen decorativa suele necesitar alt="". Google admite formatos habituales como JPEG, PNG, WebP, SVG y AVIF.

Revisa:

• width y height para limitar desplazamientos,
• srcset y sizes,
• compresión y formato,
• carga diferida fuera del primer viewport,
• texto alternativo,
• datos estructurados coherentes con el contenido visible,
• og:title, og:description, og:image y og:url.

Para la comprobación práctica utiliza el Conversor y optimizador de imágenes y la Vista previa de Open Graph.

SEO en experiencias de búsqueda con IA

Google indica que para las funciones de IA siguen siendo válidas las prácticas SEO fundamentales. No hace falta añadir archivos especiales ni marcado nuevo solo para aparecer en AI Overviews o AI Mode. La página debe ser indexable y cumplir los requisitos habituales de Search.

La estrategia más sensata consiste en:

• publicar respuestas claras y completas,
• utilizar fuentes y ejemplos prácticos,
• actualizar la información que cambia con rapidez,
• evitar contenido repetitivo generado en masa,
• mantener estructura semántica y enlazado interno,
• monitorizar tráfico y consultas en Search Console.

3. Core Web Vitals y rendimiento

Umbrales actuales

Los Core Web Vitals incluyen tres métricas. La evaluación debe hacerse sobre el percentil 75 de visitas reales, por separado en móvil y escritorio.

Métrica	Qué mide	Bueno	Necesita mejora	Malo
LCP	aparición del mayor elemento de contenido	≤ 2,5 s	2,5-4,0 s	> 4,0 s
INP	retraso de respuesta a las interacciones	≤ 200 ms	200-500 ms	> 500 ms
CLS	estabilidad visual del diseño	≤ 0,1	0,1-0,25	> 0,25

Los datos de campo reflejan la experiencia real; los datos de laboratorio ayudan a reproducir un problema. No deben confundirse. Una web puede obtener buen resultado en Lighthouse local y tener un INP deficiente en teléfonos antiguos o un LCP lento en un país concreto.

Cómo mejorar LCP

Causas habituales:

• servidor lento o falta de caché,
• imagen hero demasiado pesada,
• recurso LCP descubierto solo mediante JavaScript,
• CSS y fuentes que bloquean el renderizado,
• cadenas largas de solicitudes,
• lógica pesada antes de pintar.

Acciones:

• mejorar TTFB y caché,
• servir la imagen con dimensiones adecuadas,
• usar formato moderno y compresión,
• priorizar el recurso principal,
• no aplicar lazy loading a la imagen LCP,
• reducir CSS y scripts críticos,
• usar CDN cuando realmente acorte la distancia al usuario.

Cómo mejorar INP

INP empeora por tareas largas en el hilo principal, exceso de JavaScript, renderizados costosos y manejadores de eventos que hacen demasiado trabajo.

Comprueba:

• duración de tareas en el panel Performance,
• scripts de terceros,
• componentes que se renderizan de nuevo con cada cambio,
• listas grandes sin virtualización,
• operaciones síncronas sobre memoria y DOM,
• validación de formularios y animaciones durante la interacción.

Divide tareas largas, aplaza trabajo no crítico y envía al navegador el mínimo JavaScript necesario.

Cómo mejorar CLS

Fuentes comunes de desplazamientos:

• imágenes e iframes sin dimensiones,
• anuncios sin espacio reservado,
• banners de cookies insertados sobre el contenido,
• fuentes cargadas tarde,
• componentes añadidos antes del contenido existente,
• animación de propiedades que afectan al layout.

Reserva espacio, utiliza placeholders estables y prueba toda la secuencia de carga, no solo la captura final.

No optimices únicamente la puntuación de Lighthouse

Lighthouse es una prueba de laboratorio en condiciones controladas. Un proceso sólido combina:

• Search Console y su informe de Core Web Vitals,
• datos CrUX o RUM,
• Lighthouse y panel Performance,
• pruebas en un dispositivo más lento,
• monitorización de regresiones tras el despliegue.

4. Auditoría de accesibilidad según WCAG 2.2

WCAG 2.2 define criterios que requieren evaluación automática y humana. Un escáner no puede confirmar por sí solo la conformidad completa, porque parte de los criterios depende del contexto y de pruebas de interacción.

Teclado y foco

Recorre la ruta principal sin ratón:

• ¿se alcanza cada elemento interactivo?,
• ¿el orden del foco es lógico?,
• ¿el indicador de foco es claramente visible?,
• ¿un modal mantiene el foco y lo devuelve al cerrarse?,
• ¿existe alguna trampa de teclado?,
• ¿se puede omitir la navegación repetida?

Semántica y lectores de pantalla

Comprueba:

• un H1 lógico y jerarquía correcta,
• landmarks header, nav, main y footer,
• botones y enlaces reales en lugar de div clicables,
• nombres accesibles para iconos,
• anuncios de cambios dinámicos,
• orden de lectura correcto,
• idioma del documento en lang.

ARIA debe complementar HTML semántico, no sustituirlo sin necesidad.

Formularios y errores

Cada campo debe tener etiqueta visible y asociación programática con su descripción. El error debe explicar qué corregir y no puede indicarse solo mediante color.

Prueba:

• etiquetas e instrucciones,
• campos obligatorios,
• atributos de autocompletado,
• orden de tabulación,
• mensajes de error,
• resumen de errores tras enviar,
• funcionamiento con zoom y pantalla estrecha,
• límites de tiempo y posibilidad de ampliarlos.

Contraste, zoom y movimiento

Controla el contraste de texto, iconos y estados de foco. Prueba la web con zoom del 200 % y 400 %, texto ampliado y viewport estrecho. El contenido no debería requerir desplazamiento horizontal salvo cuando esté justificado.

Las animaciones deben respetar prefers-reduced-motion y el contenido que se mueve automáticamente debe poder detenerse cuando afecte a la comprensión.

Checklist de accesibilidad

• Todo el recorrido funciona con teclado.
• El foco es visible y lógico.
• Encabezados y landmarks describen la estructura.
• Botones y enlaces tienen nombres comprensibles.
• Los formularios tienen etiquetas y errores útiles.
• El contraste cumple WCAG 2.2 AA.
• El contenido funciona con zoom y reflow.
• Las imágenes informativas tienen texto alternativo adecuado.
• El movimiento se puede reducir.
• Las tareas clave se han probado con lector de pantalla.

5. Auditoría de seguridad y privacidad

HTTPS es el comienzo, no el final

Toda la web debe funcionar mediante HTTPS sin contenido mixto activo. Revisa validez del certificado, cadena de confianza, protocolos soportados, renovación automática y redirección HTTP a HTTPS. Lighthouse señala las páginas sin HTTPS, pero no realiza una prueba de penetración completa.

Puedes verificar dominio y certificado con el Inspector de DNS y SSL.

Encabezados de seguridad

Los encabezados no corrigen una autorización rota, pero limitan clases de ataque y comportamientos inseguros del navegador. OWASP Secure Headers Project mantiene recomendaciones y ejemplos actualizados.

Revisa como mínimo:

• Content-Security-Policy,
• Strict-Transport-Security,
• X-Content-Type-Options: nosniff,
• Referrer-Policy,
• Permissions-Policy,
• protección de embedding mediante frame-ancestors,
• atributos seguros de cookies: Secure, HttpOnly y SameSite adecuado.

Conviene implantar CSP por fases: empezar con Content-Security-Policy-Report-Only, analizar informes y después activar la política. Una configuración copiada debe adaptarse a los recursos reales de la web.

Para una revisión rápida utiliza el Inspector de encabezados de seguridad.

OWASP Top 10:2025 como mapa de riesgos

OWASP Top 10:2025 incluye control de acceso roto, mala configuración, fallos de cadena de suministro, errores criptográficos, inyección, diseño inseguro, fallos de autenticación, integridad de software o datos, fallos de registro y alertas, y mala gestión de condiciones excepcionales.

Comprueba en la práctica:

• si un usuario puede leer o modificar datos de otro,
• si el panel administrativo tiene protección adicional,
• si la API valida permisos en el servidor,
• si dependencias e imágenes de contenedor se actualizan,
• si los secretos están fuera del repositorio y del código cliente,
• si entradas y salidas se validan y codifican,
• si las sesiones caducan y pueden revocarse,
• si los registros evitan contraseñas, tokens y datos sensibles,
• si los errores ocultan stack traces y detalles de infraestructura,
• si existen copias y se ha probado la restauración.

Para aplicaciones con autenticación, pagos o datos de clientes, utiliza OWASP ASVS para definir el alcance en lugar de limitarte a una lista de encabezados.

Privacidad y analítica

Revisa:

• qué scripts se ejecutan antes del consentimiento,
• si los formularios recogen solo los datos necesarios,
• periodos de retención,
• acceso de empleados y proveedores,
• posibilidad de retirar el consentimiento,
• configuración de Consent Mode, si se utiliza,
• registro de direcciones IP e identificadores,
• coherencia de la política de privacidad con el funcionamiento real.

No asumas que un banner de cookies garantiza el cumplimiento. Lo importante es qué carga y transmite realmente la web.

6. UX, móvil y conversión

Una auditoría técnica puede aprobar mientras la web sigue sin cumplir su objetivo. Recorre la ruta principal como un usuario nuevo:

• ¿se entiende en la primera pantalla a qué se dedica la empresa?,
• ¿cada CTA describe una acción concreta?,
• ¿la navegación evita tener que adivinar?,
• ¿el formulario pide solo información necesaria?,
• ¿los errores se corrigen fácilmente?,
• ¿teléfono y correo se pueden tocar en móvil?,
• ¿los elementos evitan solaparse?,
• ¿los pop-ups permiten usar el contenido?,
• ¿los mensajes de éxito son inequívocos?,
• ¿la web funciona con conexión lenta y solicitudes fallidas?

Prueba también la página 404, resultados vacíos, producto o servicio no disponible, sesión expirada y pago fallido. Los estados excepcionales suelen determinar si el usuario vuelve.

Para webs orientadas a captar contactos, consulta Cómo planificar una web empresarial que genera clientes.

7. Medición, monitorización y calidad de datos

Search Console muestra el rendimiento en Google Search; la analítica muestra qué hace el usuario tras llegar. Combinar ambas perspectivas ayuda a distinguir un problema de visibilidad de uno de conversión.

Comprueba:

• que la propiedad de Search Console cubra la variante correcta,
• errores de indexación y acciones manuales,
• consultas, páginas, países y dispositivos,
• cambios de clics e impresiones tras publicar,
• integridad de eventos analíticos,
• exclusión de tráfico interno y bots,
• exactitud del embudo de conversión,
• alertas de errores JavaScript y servidor,
• monitorización de disponibilidad y certificado.

No corrijas todo a la vez sin referencia. Guarda el estado inicial y despliega grupos de cambios para medir su efecto.

¿Cuánto tarda una auditoría?

Los siguientes valores son estimaciones prácticas, no un estándar oficial. El alcance depende del número de plantillas, acceso a datos, tecnología y riesgo.

Alcance	Tiempo orientativo	Incluye
Revisión rápida de una URL	15-30 min	estado, meta, CWV básico, HTTPS y errores principales
Web empresarial pequeña	2-6 h	muestra, SEO, CWV, accesibilidad, seguridad y UX
Sitio de contenidos o multilingüe	1-3 días	plantillas, indexación, hreflang, enlaces, datos y prioridades
Tienda online	3-7 días	categorías, productos, filtros, checkout, datos estructurados y rendimiento
Aplicación web	5-10+ días	roles, autorización, flujos, API, estados de error y pruebas manuales
Auditoría de seguridad de alto riesgo	alcance separado	modelado de amenazas, ASVS, aplicación e infraestructura

El coste aumenta menos por el número bruto de URL que por la cantidad de comportamientos distintos. Mil productos con una plantilla pueden ser más sencillos que una aplicación con diez roles y muchos estados.

¿Cómo priorizar las mejoras?

Utiliza un modelo simple: impacto × alcance × riesgo ÷ coste de implementación.

P0: corregir inmediatamente

• web o función crítica no disponible,
• secciones importantes bloqueadas para indexación,
• fuga de datos o bypass de autorización,
• certificado caducado o contenido mixto activo,
• migración con errores masivos y URL perdidas,
• formulario que no entrega solicitudes.

P1: prioridad alta

• CWV deficientes en plantillas principales,
• barreras graves de teclado y formularios,
• canonicales o hreflang incorrectos,
• oferta confusa y conversión difícil,
• dependencias críticas sin parchear,
• falta de monitorización de errores importantes.

P2: planificar para el próximo ciclo

• títulos duplicados y enlaces internos débiles,
• textos alternativos ausentes,
• imágenes pesadas fuera del primer viewport,
• datos estructurados inconsistentes,
• páginas 404 y estados vacíos poco trabajados,
• problemas en plantillas menos populares.

P3: optimización y crecimiento

• datos estructurados adicionales,
• reducción adicional de peso,
• experimentos con textos y CTA,
• ampliación de contenidos,
• limpieza de componentes y documentación.

Plan de mejoras a 30, 60 y 90 días

Primeros 30 días

Resuelve P0, indexación, redirecciones, HTTPS, formularios y riesgos de pérdida de datos. Establece una línea base.

Hasta el día 60

Trabaja las plantillas más importantes: Core Web Vitals, teclado, formularios, contenido, enlazado interno y seguridad de la aplicación. Implanta monitorización de regresiones.

Hasta el día 90

Mejora plantillas menos críticas, normaliza la publicación, añade pruebas automáticas a CI y programa auditorías recurrentes tras cambios importantes.

Checklist completa antes de cerrar la auditoría

SEO e indexación

• Los rastreadores pueden obtener páginas y recursos importantes.
• El sitemap XML está actualizado.
• Canonicales, redirecciones y enlaces son coherentes.
• No existe noindex accidental.
• Las páginas importantes tienen título, H1 y contenido únicos.
• Los enlaces internos llevan a páginas relevantes para el negocio.
• Las versiones lingüísticas usan hreflang correctamente.
• Los datos estructurados coinciden con el contenido visible.
• Los metadatos Open Graph están completos.

Rendimiento

• LCP, INP y CLS cumplen los umbrales en datos de campo.
• La imagen LCP tiene tamaño y prioridad adecuados.
• JavaScript no bloquea la interacción.
• Las imágenes tienen dimensiones y formato apropiados.
• Fuentes y recursos críticos no generan retrasos evitables.
• Los resultados se monitorizan tras el despliegue.

Accesibilidad

• La web funciona sin ratón.
• El foco es visible.
• Semántica y jerarquía de encabezados son lógicas.
• Los formularios tienen etiquetas y errores útiles.
• Contraste y reflow cumplen WCAG 2.2 AA.
• La interfaz se ha probado con lector de pantalla.

Seguridad y privacidad

• HTTPS funciona en todo el sitio y el certificado se monitoriza.
• Las cookies de sesión tienen atributos seguros.
• Los encabezados están adaptados a la aplicación.
• Los permisos se validan en el servidor.
• Dependencias y secretos están controlados.
• Registros y alertas permiten responder.
• Las copias de seguridad se han probado.
• Los scripts de seguimiento respetan el consentimiento.

UX y negocio

• La oferta se entiende sin leer toda la página.
• Los CTA conducen a la acción prevista.
• Formularios y checkout funcionan en móvil.
• Los estados de error ayudan a recuperarse.
• Eventos y conversiones se miden correctamente.
• Cada mejora tiene responsable, prioridad y fecha.

Cómo utilizar Estado del sitio web de POLPROG

Estado del sitio web permite iniciar una auditoría desde una URL y revisar SEO, rendimiento, accesibilidad, seguridad y buenas prácticas. Las pruebas se ejecutan en el servidor y no requieren registro.

Proceso recomendado:

1. Analiza la página de inicio y cada plantilla importante.
2. Anota errores críticos y patrones repetidos.
3. Confirma CWV con datos de usuarios reales.
4. Prueba manualmente teclado, formularios y recorridos clave.
5. Revisa por separado los encabezados de seguridad, DNS y SSL y Open Graph.
6. Prioriza el backlog por impacto y riesgo.
7. Repite las pruebas tras implementar y vigila regresiones.

Conclusión

La mejor auditoría web de 2026 no termina con un documento de cien avisos. Termina con una lista breve y ordenada de acciones que separa los problemas críticos de los cosméticos, asigna responsables y permite verificar el resultado después de implementar.

Primero asegúrate de que la web está disponible, es indexable y segura. Después mejora los recorridos principales, Core Web Vitals y accesibilidad. Solo entonces optimiza los detalles. Este orden suele generar más valor que perseguir una puntuación perfecta en un único escáner.