Every rule is evaluated automatically on each analysis. Free rules are included at no cost; Pro rules are activated with the paid plan.
9 Free rules · 8 Pro rules · 30% of score
Verifica que la versión instalada no ha alcanzado el fin de soporte (EOL) según el calendario oficial de Adobe. Las versiones EOL dejan de recibir parches de seguridad: cualquier vulnerabilidad descubierta a partir de esa fecha queda permanentemente sin corregir, convirtiendo la tienda en un objetivo fácil para exploits públicos.
Actualiza Magento a la última versión con soporte activo. Consulta el calendario oficial en el Adobe Experience League.
Compara el nivel de parche instalado (ej. 2.4.7-p2) con el último publicado para esa rama según las releases oficiales de Adobe. Cada parche de seguridad corrige vulnerabilidades con CVE publicado: operar un parche por detrás significa que el exploit ya es público y tu tienda está expuesta.
Aplica los parches pendientes: descárgalos desde el portal de Adobe Commerce o instálalos vía Composer actualizando el paquete afectado.
Detecta si el panel de administración es accesible en rutas predecibles: /admin (por defecto) y otras 11 rutas habituales como /backend, /manage, /panel, /adminhtml, etc. Bots automatizados rastrean estas rutas constantemente: si el login es accesible en cualquiera de ellas, cualquier atacante puede llegar al formulario de autenticación sin conocimiento previo de la tienda.
En Admin → Stores → Configuration → Advanced → Admin → Admin Base URL, activa "Use Custom Admin URL" y define una ruta aleatoria.
Verifica que hay autenticación de doble factor activa en el admin. El agente detecta el módulo nativo de Magento (comprueba que cada admin tiene al menos un proveedor configurado) y también módulos de terceros reconocidos como Amasty, Magezon o Mageplaza TwoFactorAuth. Sin 2FA, una sola contraseña comprometida —por phishing, reutilización o fuerza bruta— da acceso total al panel sin ninguna barrera adicional.
En Admin → System → Two Factor Auth, activa 2FA. Los administradores indicados en el detalle deben configurarlo en su próximo acceso.
Comprueba que la política del admin tiene umbrales razonables: contraseña mínima de 12 caracteres, bloqueo de cuenta tras ≤5 intentos fallidos, duración del bloqueo ≥10 minutos y cuentas no compartidas entre usuarios. Una política débil facilita ataques de fuerza bruta que, con tiempo, acaban obteniendo acceso.
En Admin → Stores → Configuration → Advanced → Admin → Security: establece contraseña mínima de 12 caracteres, bloqueo tras ≤5 intentos y duración ≥10 min.
Confirma que el servidor redirige HTTP a HTTPS y que Magento tiene forzado el uso de URLs seguras en frontend y admin. Sin HTTPS forzado, credenciales, tokens de sesión y datos de pago pueden viajar en texto plano e interceptarse en cualquier punto de la red.
En Admin → Stores → Configuration → Web, activa "Use Secure URLs in Frontend" y "Use Secure URLs in Admin" a Yes.
Verifica que el servidor rechaza conexiones TLS 1.0 y TLS 1.1. Estos protocolos tienen vulnerabilidades documentadas (POODLE, BEAST) que permiten a un atacante en la misma red descifrar el tráfico capturado, aunque el certificado SSL sea válido.
Deshabilita TLS 1.0 y 1.1 en Nginx (`ssl_protocols TLSv1.2 TLSv1.3;`) o en Apache (`SSLProtocol -all +TLSv1.2 +TLSv1.3`).
Analiza todas las dependencias del composer.lock —core de Magento y paquetes de terceros— buscando CVEs activos en la base de datos de Packagist. Un paquete vulnerable puede ser el vector de entrada de un ataque aunque Magento en sí esté actualizado.
Actualiza los paquetes afectados con `composer update`. Revisa el advisory referenciado en el detalle para confirmar la versión que incluye el fix.
Comprueba que el formulario de login del admin está protegido por CAPTCHA o reCAPTCHA. Sin esta protección, scripts automatizados pueden probar miles de combinaciones de credenciales continuamente sin ninguna fricción.
En Admin → Stores → Configuration → Advanced → Admin → CAPTCHA, activa el CAPTCHA y habilita el formulario "Admin Login".
Verifica que la homepage y el checkout incluyen los headers X-Frame-Options (o CSP frame-ancestors), X-Content-Type-Options y Referrer-Policy.
Available in ProDetecta cuentas de administrador activas sin login en los últimos 90 días, incluyendo cuentas que nunca han sido usadas desde su creación.
Available in ProComprueba que los ficheros de configuración críticos (app/etc/env.php y config.php) tienen permisos restrictivos.
Available in ProIntenta acceder por HTTP a rutas sensibles: .git/config, .env, composer.json, app/etc/config.php, phpinfo.php y volcados SQL.
Available in ProVerifica que el header HSTS está presente con max-age ≥ 1 año e includeSubDomains.
Available in ProComprueba que los headers de respuesta no revelan versión del servidor (Server, X-Powered-By) ni headers de debug de Magento (X-Magento-Cache-Debug, X-Magen…
Available in ProAnaliza el HTML de la homepage, el checkout y una ficha de producto buscando patrones de ofuscación JavaScript propios de skimmers Magecart: eval(atob(...))…
Available in ProVerifica que los endpoints sensibles de la API REST (/customers/search y /orders) no devuelven datos reales sin autenticación.
Available in Pro9 Free rules · 5 Pro rules · 25% of score
Confirma que Magento está en modo producción, no en developer ni default. Cualquier otro modo deshabilita optimizaciones críticas —compilación de DI, merge de assets, cachés de plantillas— y puede hacer la tienda hasta 5 veces más lenta. Además el modo developer muestra errores detallados al usuario, exponiendo información interna.
Activa el modo producción: `php bin/magento deploy:mode:set production`. Antes despliega el contenido estático: `php bin/magento setup:static-content:deploy -f`.
Verifica que todas las cachés de Magento (config, layout, block_html, full_page, etc.) están habilitadas. Una caché desactivada —habitualmente olvidada tras un flush de desarrollo— fuerza a Magento a regenerar ese tipo de contenido en cada petición, con un impacto directo en el tiempo de respuesta.
Habilita todas las cachés: `php bin/magento cache:enable`. Consulta el estado actual con `php bin/magento cache:status`.
Comprueba que el Full Page Cache (FPC) está activo. Sin FPC, Magento genera el HTML completo de cada página en cada visita ejecutando decenas de queries y bloques de layout. Con Varnish configurado el TTFB puede bajar de 2-3 segundos a menos de 100ms para páginas cacheadas.
Activa el FPC nativo en Admin → Stores → Configuration → Advanced → System → Full Page Cache, o instala y configura Varnish para mayor rendimiento.
Verifica que Redis gestiona sesiones y caché de objetos. El almacenamiento de sesiones en ficheros no escala horizontalmente y bloquea procesos bajo carga concurrente; usar MySQL como caché añade queries innecesarias en cada petición. Redis elimina ambos cuellos de botella.
Configura Redis como backend de caché y sesiones en app/etc/env.php. Consulta la guía oficial de Magento 2 para la configuración de Redis.
Verifica que OPCache está habilitado con al menos 512 MB de memoria y ≥60 000 ficheros acelerados, y que los parámetros de realpath_cache están optimizados. Sin OPCache, PHP recompila cada fichero en cada petición; con memoria insuficiente, el caché se invalida constantemente bajo la carga de los miles de ficheros PHP de Magento.
Aplica los valores recomendados por Adobe en php.ini (o en el pool de PHP-FPM) y reinicia PHP-FPM: opcache.memory_consumption=512 · opcache.max_accelerated_files=60000 · opcache.validate_timestamps=0 · opcache.enable_cli=1 · realpath_cache_size=10M · realpath_cache_ttl=7200. Referencia completa: https://experienceleague.adobe.com/en/docs/commerce-operations/performance-best-practices/software
Verifica que la versión de PHP instalada (actualmente 8.1–8.3 para Magento 2.4.x) está dentro del rango soportado. Una versión fuera de rango puede causar errores silenciosos, incompatibilidades de extensiones o comportamiento inesperado; y las versiones PHP EOL no reciben parches de seguridad.
Actualiza PHP a la versión 8.1, 8.2 o 8.3. Consulta la matriz de compatibilidad oficial de Adobe para tu versión de Magento.
Comprueba que el motor de búsqueda (Elasticsearch u OpenSearch) está configurado y responde. MySQL como motor de búsqueda está deprecado desde Magento 2.4 y eliminado en 2.4.6+. Un motor caído o mal configurado deja la búsqueda del catálogo completamente inoperativa, afectando directamente a las conversiones.
Comprueba que el servicio está activo (`systemctl status elasticsearch` u `opensearch`). Verifica la configuración en Admin → Stores → Configuration → Catalog → Catalog Search.
Verifica que todos los indexadores están en estado Ready. Un indexador inválido significa que los datos de precios, stock, categorías o búsqueda que ve el cliente están desactualizados. Un proceso de reindex atascado durante horas suele indicar que el cron de Magento no está corriendo.
Reindexia los indexadores fallidos: `php bin/magento indexer:reindex`. Asegúrate de que el cron de Magento (OPS-01) está activo para la reindexación automática.
Comprueba que el contenido estático (JS, CSS, fuentes, imágenes compiladas) está desplegado en pub/static/. Sin despliegue previo en modo producción, Magento intenta generarlos en tiempo real en cada primera visita, causando latencias de cientos de milisegundos por fichero y carga innecesaria al servidor.
Despliega el contenido estático: `php bin/magento setup:static-content:deploy -f es_ES en_US` (ajusta los locales). Necesario en modo producción.
Mide el Time to First Byte de la homepage desde múltiples puntos geográficos.
Available in ProMide el Largest Contentful Paint (LCP) móvil vía Google PageSpeed Insights.
Available in ProVerifica que las imágenes de la homepage y categoría se sirven en WebP o AVIF y que las imágenes below-the-fold tienen loading="lazy".
Available in ProComprueba que el servidor comprime las respuestas HTTP con Gzip o Brotli.
Available in ProVerifica que los scripts RequireJS de la homepage se sirven con el sufijo .min.js, indicando que la minificación JS está activa y los estáticos se han red…
Available in Pro5 Free rules · 6 Pro rules · 18% of score
Verifica que al menos el 95% de los productos activos tienen meta description definida. Magento usa el nombre del producto como fallback para el meta title, pero la meta description no tiene fallback: sin ella, Google genera su propio fragmento desde el texto de la página, que suele ser de menor calidad y reduce el CTR en resultados de búsqueda.
Rellena las meta descriptions de los productos que las tienen vacías: Admin → Catalog → Products → (editar) → Search Engine Optimization. Para hacerlo en masa usa importación CSV.
Comprueba que el sitemap XML es accesible públicamente: busca la URL en el robots.txt (directiva Sitemap:) o prueba /sitemap.xml directamente como fallback. Sin sitemap accesible, Google depende exclusivamente del rastreo de enlaces para descubrir páginas nuevas o actualizadas, lo que puede retrasar semanas la indexación de productos.
Regenera el sitemap en Admin → Marketing → SEO & Search → Site Map → Generate. Configura la generación automática diaria en Admin → Stores → Configuration → Catalog → XML Sitemap.
Descarga robots.txt y verifica que existe y que no contiene Disallow: / para User-agent: *. Un bloqueo total es el error SEO más grave: desindexará toda la tienda silenciosamente y suele ocurrir al promover a producción una configuración que venía del entorno de staging.
Revisa el contenido de robots.txt en Admin → Content → Design → Configuration → (editar store) → Search Engine Robots. Elimina cualquier directiva `Disallow: /`.
Verifica que al menos el 80% de las PDPs analizadas incluyen markup Schema.org de tipo Product con el campo name (JSON-LD, microdata o RDFa). El marcado estructurado permite a Google mostrar rich results (precio, disponibilidad, valoraciones) directamente en los resultados de búsqueda, aumentando el CTR sin necesidad de subir posiciones.
Verifica que el tema incluye el JSON-LD de Schema.org en las PDPs. Si no, instala un módulo de Rich Snippets o añade el markup manualmente en el template de producto.
Verifica que la homepage tiene un <title> con texto y un <meta name=description> con contenido. Si alguno falta, Google genera su propia versión desde el texto de la página, ignorando el mensaje de marca. La homepage es la página más enlazada externamente y un meta description bien escrito mejora directamente el CTR en resultados de búsqueda.
Configura el meta title y description de la homepage en Admin → Content → Pages → Home Page → Meta Data.
En tiendas con múltiples store views de idiomas distintos, verifica que la homepage incluye etiquetas hreflang apuntando a cada variante.
Available in ProComprueba la homepage y hasta 5 PDPs siguiendo redirecciones desde HTTP para detectar cadenas completas.
Available in ProVerifica que al menos el 90% de las imágenes de producto (rutas catalog/product o media/catalog) en una muestra de PDPs tienen atributo alt con texto no vac…
Available in ProComprueba que la homepage y una muestra de PDPs tienen etiqueta canonical presente y apuntando al mismo dominio.
Available in ProComprueba que las páginas de producto incluyen al menos una etiqueta Open Graph (og:title, og:description, og:image).
Available in ProVerifica que la homepage no expone parámetros internos (?id=, ?cat=, ?product=) en la URL final tras seguir redirecciones.
Available in Pro4 Free rules · 4 Pro rules · 15% of score
Comprueba una muestra de 15 ficheros críticos del core (autenticación, cifrado, checkout, pagos) comparando sus hashes con los oficiales de la versión instalada. Modificar el core es el anti-pattern más grave: oculta backdoors difíciles de detectar, impide que los parches de seguridad de Adobe se apliquen correctamente y pierde los cambios en cada actualización.
No modifiques ficheros de vendor/ directamente. Usa plugins, preferences o patches (cweagans/composer-patches) para personalizar el comportamiento del core sin tocar el original.
Cruza los paquetes de tipo magento2-module instalados vía Composer contra la base de datos de advisories de seguridad de Packagist. A diferencia de SEC-08, que evalúa librerías PHP genéricas, esta regla se centra en módulos Magento de terceros: extensiones de pago, integraciones ERP, mejoras de rendimiento. Un CVE sin parchear en cualquiera de ellos puede comprometer datos de clientes o permitir ejecución remota de código.
Actualiza los módulos afectados: `composer update vendor/paquete`. Si no hay versión corregida, valora reemplazarlo o aplica un patch temporal mientras esperas el fix del autor.
Comprueba que el fichero composer.lock está presente en el servidor. Sin él, cada `composer install` puede instalar versiones distintas de dependencias entre entornos, causando comportamientos distintos en staging y producción e impidiendo reproducir exactamente el estado en el que ocurre un bug.
Genera el composer.lock con `composer install` y commitéalo al repositorio. Asegúrate de que NO está en .gitignore.
Detecta errores JavaScript del frontend (registrados vía snippet JS del módulo) que superan 10 ocurrencias en 7 días. Un error JS recurrente puede romper el checkout o la navegación de los clientes.
Revisa los errores JS listados en el detalle. Suelen ser conflictos entre scripts o módulos de terceros con errores. Abre la consola del navegador en la página afectada para reproducirlos.
Detecta módulos Magento de terceros (type: magento2-module) sin actividad: paquetes con más de 2 años sin release o marcados explícitamente como abandona…
Available in ProCuenta las excepciones PHP en var/log/exception.log de los últimos 7 días.
Available in ProEjecuta PHP_CodeSniffer con el estándar PSR-12 sobre app/code/.
Available in ProEjecuta PHP_CodeSniffer con los estándares de Magento 2 sobre app/code/.
Available in Pro7 Free rules · 1 Pro rules · 12% of score
Verifica que el cron de Magento ejecutó un job exitoso en los últimos 5 minutos. El cron es responsable de reindexación, emails transaccionales, generación de sitemaps, reglas de precio y decenas de tareas críticas. Un cron detenido suele pasar desapercibido y causar fallos en cascada que tardan horas en manifestarse.
Verifica el cron con `crontab -l -u www-data`. Si no existe, añade la entrada de Magento: `* * * * * php /ruta/magento/bin/magento cron:run >> /dev/null 2>&1`.
Comprueba que hay consumidores activos procesando la cola cuando existen mensajes pendientes (se omite si la tienda no usa Message Queue). Sin consumidores activos, operaciones asíncronas como confirmaciones de pedido, actualizaciones de stock e integraciones con ERP quedan bloqueadas indefinidamente.
Levanta los consumers con `php bin/magento queue:consumers:start <consumer>`. Usa Supervisor para mantenerlos activos de forma permanente.
Verifica que ningún volumen de disco supera el 80% de uso. Magento acumula datos en var/, var/log y pub/media/; un disco lleno impide escribir sesiones, logs y nuevas imágenes de producto, y puede causar errores fatales en cualquier operación que requiera I/O.
Libera espacio limpiando cachés (`php bin/magento cache:flush`), rotando logs (`truncate -s 0 var/log/*.log`) y eliminando pub/static antiguo.
Comprueba que el certificado SSL no expira en menos de 30 días, con alertas escalonadas a 30, 14 y 7 días. Un certificado expirado hace que todos los navegadores bloqueen el acceso a la tienda con un error de seguridad —equivale a caída total de la tienda— y es uno de los fallos más costosos y más fáciles de evitar.
Renueva el certificado SSL. Si usas Let's Encrypt: `certbot renew`. Si es un certificado de pago, contacta con tu proveedor para renovarlo.
Autoevaluación del módulo agente: confirma que está habilitado en Magento, que su cron interno se ejecutó recientemente y que la tabla de logs JS no tiene fuga de datos. Si el agente está degradado, todos los checks que dependen de datos del servidor pierden cobertura silenciosamente sin que Ticpan pueda detectarlo.
Comprueba que el módulo está habilitado: `php bin/magento module:status W2e_Ticpan`. Si el cron interno falla, verifica que el cron de Magento (OPS-01) está activo.
Comprueba la disponibilidad de la tienda. En Free es un check puntual; en Pro acumula probes cada 5 minutos durante 24h y falla si el uptime cae por debajo del 99% o si los últimos 3 checks consecutivos están caídos (≈15 min de caída continua).
El sitio no responde. Comprueba el servidor web (`systemctl status nginx`) y PHP-FPM. Revisa /var/log/nginx/error.log y /var/log/php-fpm.log para identificar el problema.
Mide el tiempo de respuesta total de la homepage (hasta recibir el último byte) desde el cloud. Superar 2000ms indica un problema serio de backend —PHP lento, queries pesadas o transferencia de datos lenta— más allá del tiempo de generación del primer byte medido por PERF-10.
El tiempo de respuesta elevado puede indicar PHP-FPM saturado o consultas lentas a base de datos. Revisa los slow logs de MySQL (`slow_query_log`) y el estado de PHP-FPM.
Verifica los registros DNS del dominio de envío: SPF autoriza el servidor, DKIM permite firmar emails y DMARC define la política ante fallos.
Available in Pro0 Free rules · 5 Pro rules · opt-in Pro
Detecta productos activos sin ninguna imagen asignada.
Available in ProDetecta productos activos con descripción vacía o con menos de 50 caracteres de texto plano (sin contar etiquetas HTML).
Available in ProVerifica que el checkout para invitados está habilitado.
Available in ProDetecta productos activos marcados como "en stock" en Magento pero con qty ≤ 0 y sin backorders habilitados.
Available in ProDetecta posibles conflictos entre reglas de precio activas.
Available in ProReady to analyse your store?
The Free plan includes 34 rules with no credit card required.
Start for free