Empiece por los recorridos críticos, no por un escaneo gigante
Elija de cinco a diez URLs y defina el resultado esperado para cada una: una página de confirmación, recibo, registro en el CRM o entrega a un proveedor. Incluya páginas públicas y acciones que generen ingresos, confianza, demanda de soporte o una obligación legal. Pruebe como visitante en una ventana del navegador sin iniciar sesión y en un teléfono.
Si un tercero controla un paso crítico, mapee la transferencia y el contacto de soporte. Puede probar su transición, pero no puede certificar al proveedor. Clasifique los hallazgos como bloqueador, degradación material o mejora para que el trabajo cosmético no oculte un recorrido roto.
Cubra rutas que generen ingresos, confianza, demanda de soporte u obligaciones legales.
Cada hallazgo material necesita un responsable nombrado y una fecha objetivo.
Compruebe el uso accesible además de la apariencia
Accesibilidad significa que las personas pueden percibir y operar el sitio con distintos métodos de entrada y tecnología asistiva. En las páginas seleccionadas, use la tecla Tab para navegar por menús, controles y formularios. Compruebe el foco visible del teclado, la operación sin ratón de controles esenciales y una ruta al contenido principal. Easy Checks de W3C identifica el foco del teclado y un enlace de salto (skip link) como elementos útiles para una primera revisión.
Inspeccione textos alternativos significativos de imágenes, títulos de página, encabezados, contraste, comportamiento al hacer zoom, alternativas de medios cuando sean necesarias, etiquetas de formulario, campos obligatorios y errores comprensibles. Envíe una prueba no sensible. Esto no es una auditoría de conformidad: W3C advierte que las páginas pueden pasar comprobaciones rápidas y aun así contener barreras significativas. Use evaluación cualificada para trabajos de mayor riesgo, rediseños o problemas conocidos.
Pruebe etiquetas, instrucciones, errores y la ruta real hasta la confirmación.
El texto alternativo debe comunicar el propósito de la imagen; los encabezados deben organizar la página.
Revise la encontrabilidad sin prometer posiciones (rankings)
El SEO ayuda a los motores de búsqueda a comprender el contenido y a las personas a decidir si visitar desde la búsqueda. Para cada página prioritaria, lea el título, el encabezado principal, el texto de apertura, la URL y los enlaces internos como si fuera un recién llegado. Deben indicar el propósito y conducir a pasos útiles siguientes. Google recomienda URLs descriptivas, contenido útil y texto de enlace descriptivo.
Si usa Google Search Console, inspeccione las URLs clave tras un cambio material. Google indica que URL Inspection puede ayudar a comprobar cómo su rastreador ve una página y si puede acceder a recursos importantes. Corrija el bloqueo accidental, enlaces internos rotos o caminos poco claros y permita tiempo para el recrawl. Google no garantiza indexación ni posicionamiento.
Abra enlaces internos sin iniciar sesión y registre páginas 404, bucles y destinos irrelevantes.
Observe la entrega donde la siente el visitante
La entrega incluye respuesta del servidor, imágenes, fuentes, scripts, cachés y terceros. Ejecute una comprobación de rendimiento desde el navegador en las páginas prioritarias y luego repita la tarea principal en un teléfono real. Anote contenido primario tardío, controles lentos, saltos de diseño, recursos fallidos o banners que bloqueen la tarea. Core Web Vitals es un marco de experiencia de usuario de web.dev; use las mediciones para enfocar la investigación, no para sustituir la prueba de recorridos.
Revise nuevas etiquetas, widgets, embeds, fuentes y cambios de imágenes con quien los implementó. Las cachés HTTP reutilizan respuestas previas. MDN explica que Cache-Control comunica instrucciones de caché y que las respuestas en caché pueden ser fresh o stale (frescas o caducadas). Tras un lanzamiento, compare sesiones de navegador comunes y frescas, y pida al responsable técnico que examine cabeceras y reglas del CDN. Evite cambios masivos de caché sin entender efectos sobre privacidad y despliegue.
Registre si aparece el contenido principal, si la página se mantiene estable y si los controles esenciales responden.
MDN señala que una cookie por sí sola no convierte una respuesta en privada; pida al responsable técnico revisar el cacheo personalizado.
Confirme la línea base de seguridad y proteja los cambios de pago
Una comprobación por parte del propietario puede detectar brechas visibles; no es una prueba de penetración. Abra el sitio público por HTTPS e intente HTTP. OWASP recomienda TLS para todas las páginas y describe redirigir tráfico HTTP público a HTTPS como un enfoque común. Escale advertencias de certificado o de contenido mixto, dominios inesperados y páginas HTTP que sirven contenido en lugar de redirigir de forma segura.
Confirme la titularidad actual de publicación, dominio, DNS, pago, plugins y acceso a copias de seguridad. Un profesional cualificado o proveedor debe revisar la configuración TLS, parches, autenticación, configuración del servidor y registros. Para pagos, use solo un método de prueba autorizado por el proveedor o un entorno no productivo seguro. Nunca introduzca datos reales de tarjeta o credenciales en una prueba informal ni afirme que una revisión visual demuestra conformidad PCI.
Trate una advertencia de certificado, advertencia de contenido inseguro o redirección inesperada como un problema que detiene el lanzamiento hasta investigarlo.
Remita sospechas de compromiso, requisitos de seguridad y dudas sobre cumplimiento de pagos a revisores cualificados.
Demuestre la recuperación y cierre el ciclo
Enumere qué reconstruye el recorrido prioritario: versión de la aplicación, base de datos, medios subidos, ubicaciones de configuración, acceso a DNS y dominio, ajustes de integraciones y contactos de proveedores. CISA aconseja identificar datos críticos, proteger bases de datos del sitio y operativas, asegurar copias de seguridad y probar la recuperación. Pregunte cuándo se probó una restauración, qué restauró, cuánto tardó y quién puede autorizarla. Ensaye con seguridad cuando sea práctico.
Antes de un lanzamiento, identifique la versión anterior, el disparador de reversión, el aprobador y el manejo para DNS, caché, esquema de base de datos y cambios de terceros. Una copia de seguridad no es una solución instantánea, y el rollback puede no revertir datos externos o eventos de pago. Mantenga un registro del hallazgo, la evidencia, el responsable, la fecha y el resultado del retest.
Un registro de alcance, fecha, resultado y carencias es más sólido que «las copias de seguridad se ejecutan».
Verifique la ruta que falló originalmente después de una corrección en el entorno relevante.