Antes de rediseñar, antes de migrar, antes de reescribir módulos, antes de meter Verifactu: auditoría. La diferencia entre un presupuesto de 5.000 € y uno de 25.000 € para la misma tienda está casi siempre en que uno viene con auditoría previa y el otro no.
Este es el checklist exacto que recorro en una auditoría de PrestaShop de 290 €, cinco días hábiles, informe por escrito. No está pensado para recorrerlo en solitario (algunos puntos requieren acceso a logs, base de datos y configuración del servidor), pero sí para saber qué debería incluir cualquier auditoría honesta y qué preguntas hacer a quien la venda.
Los 45 puntos están agrupados en nueve bloques. Una "auditoría" de 48 horas por 50 € cubre tres o cuatro de estos puntos, no 45.
Bloque 1. Entorno técnico y versiones (puntos 1 a 5)
1. Versión de PrestaShop exacta. Rama (1.6, 1.7.8.x, 8.0, 8.1, 8.2, 9.0) y número de build. En 1.6 y 1.7 antiguo el checklist cambia radicalmente respecto a 8.x.
2. Versión de PHP. 7.4, 8.0, 8.1, 8.2 o 8.3. PrestaShop 8.2 funciona en 8.1 y 8.2; 9.0 requiere 8.2 o superior. Un 1.6 corriendo en 7.4 ya es un riesgo nombrado.
3. Versión de MySQL o MariaDB. 5.6, 5.7, 8.0, 10.x de MariaDB. Compatibilidad con la rama de PrestaShop en uso.
4. Servidor web y configuración. Nginx o Apache, cache de página activa, HTTP/2 o HTTP/3, compresión Brotli o Gzip, versión de SSL.
5. Hosting. Dedicado, VPS, compartido, cloud. Recursos reales (RAM, CPU, disco). Backup automatizado. Entorno de staging disponible o no.
Bloque 2. Catálogo y datos (puntos 6 a 10)
6. Número de productos activos y totales. Un catálogo con 20.000 productos de los cuales 2.000 están activos es un problema distinto a 500 activos de 500.
7. Número de combinaciones. Las combinaciones (talla, color, variante) impactan rendimiento. Más de 50.000 combinaciones empieza a notarse.
8. Características, atributos y árbol de categorías. Profundidad de categorías anidadas, uso real de características vs atributos, limpieza de taxonomía.
9. Imágenes. Peso medio por imagen, uso de WebP o AVIF, generación de miniaturas, imágenes huérfanas en /img/p/. Las miniaturas no regeneradas son una de las causas más comunes de problemas de rendimiento.
10. Páginas CMS, bloques y categorías de blog. Qué existe, qué está activo, qué está indexado por Google.
Bloque 3. Módulos (puntos 11 a 16)
11. Listado completo de módulos instalados. Activos, inactivos, instalados pero sin usar.
12. Módulos oficiales de PrestaShop Addons. Cuáles están actualizados a la última versión, cuáles no.
13. Módulos de terceros con licencia. Vigencia de licencia, soporte vigente, última actualización publicada por el fabricante.
14. Módulos de pasarela de pago. Redsys, PS_Checkout, Stripe, PayPal, Bizum. Versión instalada, cuál es la versión actual, incidencias conocidas.
15. Módulo de facturación. El que genera las facturas de los pedidos. Punto crítico para Verifactu (ver la guía Verifactu).
16. Módulos que modifican la base de datos. Añaden tablas o columnas custom. Afectan directamente a cualquier migración futura.
Bloque 4. Tema y front (puntos 17 a 22)
17. Tema activo. Classic, tema de marketplace o tema custom. Versión del tema, última actualización.
18. Compatibilidad del tema con la versión de PrestaShop. Un tema construido para 1.7.6 corriendo con parches en 8.1 es una fuente de fallos silenciosos.
19. Hooks personalizados usados por el tema. Mapeo real de qué hooks dispara qué pieza del tema.
20. Rendimiento del tema. CSS y JS minificados, cache activo, assets agrupados, uso de CDN para estáticos.
21. Responsive real. Pruebas en móviles reales, no solo DevTools. Tap targets, legibilidad, formularios en pantallas pequeñas.
22. Núcleo del tema vs child. Si hay sobreescritura directa de ficheros core del tema vs uso correcto del sistema de child theme.
Bloque 5. SEO técnico (puntos 23 a 29)
23. Estructura de URL amigable. Formato real (con o sin ID, con o sin categoría padre, con o sin extensión .html). Consistencia a lo largo del catálogo.
24. Mapa del sitio XML. Generación automática, inclusión correcta de productos, categorías y páginas CMS. Fecha de última actualización.
25. robots.txt. Reglas correctas, exclusiones de áreas de administración y de parámetros no indexables (filtros facetados), referencias a sitemaps. Reglas para rastreadores de IA (OpenAI, Perplexity, Google Extended).
26. Canonical y hreflang. Canonical correcto en producto, categoría y paginación. Hreflang si hay versión multi-idioma.
27. Schema.org en JSON-LD. Marcado de Product, Offer, Organization, BreadcrumbList, AggregateRating. Validación con la herramienta de resultados enriquecidos de Google.
28. Open Graph y Twitter Cards. Correctos para que compartir en redes muestre bien la ficha.
29. Estado en Google Search Console. Cobertura, páginas indexadas, errores, Core Web Vitals, acciones manuales.
Bloque 6. Core Web Vitals y rendimiento (puntos 30 a 33)
30. LCP (Largest Contentful Paint). Objetivo bajo 2,5 s. Diagnóstico de qué elemento es el LCP y por qué tarda.
31. CLS (Cumulative Layout Shift). Objetivo bajo 0,1. Imágenes sin dimensiones, banners que se cargan tarde, fuentes que empujan contenido.
32. INP (Interaction to Next Paint). Sustituye a FID desde 2024. Objetivo bajo 200 ms. JS pesado bloqueando interacción.
33. TTFB. Time to First Byte. Objetivo bajo 600 ms. Depende de hosting, cache y lógica de generación de página.
Bloque 7. Checkout y pasarela (puntos 34 a 37)
34. Flujo de checkout. Pasos, abandono por paso, formulario de dirección, campos obligatorios, invitado vs registro.
35. Pasarela de pago. Configuración real, modo producción vs sandbox, soporte 3D Secure PSD2, tasa de rechazos en los últimos tres meses.
36. Transportistas. SEUR, MRW, Correos Express, Nacex, GLS. Reglas de precio por peso o importe, zonas, umbrales de envío gratuito. Cálculo correcto en checkout.
37. Impuestos. IVA por tipo de producto, zonas fiscales UE y resto del mundo, umbrales OSS si la tienda vende fuera de España.
Bloque 8. Seguridad y mantenimiento (puntos 38 a 42)
38. Última actualización del core. Fecha de última aplicación de parche de seguridad. Vulnerabilidades conocidas sin parchear.
39. Overrides en /override/. Inventario completo de clases, controladores y módulos sobrescritos. Documentación de qué resuelve cada uno.
40. Modificaciones directas a core. El antipatrón más grave en 1.6: tocar ficheros directamente. En 8.x y 9.0 es casi imposible por accidente, pero conviene verificar.
41. Credenciales administrativas. Cuentas de admin existentes, usuarios huérfanos, uso de 2FA, política de contraseña.
42. Backup real. Qué se respalda, con qué frecuencia, dónde se almacena, cuándo fue la última restauración de prueba exitosa. "Hay backup" no basta: hay que haberlo restaurado.
Bloque 9. Cumplimiento normativo (puntos 43 a 45)
43. RGPD. Aviso de cookies con rechazo tan accesible como aceptar, política de privacidad actualizada, registro de actividades de tratamiento, formulario de contacto con base legal, acceso y borrado de cuenta por usuario.
44. LSSI-CE. Aviso legal con datos del titular, condiciones generales de contratación, política de cookies, política de devoluciones conforme a la normativa de consumo.
45. Verifactu. Software de facturación en uso, declaración responsable del fabricante disponible, modo Verifactu vs modo no Verifactu elegido, pruebas de envío a AEAT si procede. Punto crítico desde 01/01/2026 (sociedades) y 01/07/2026 (autónomos).
Qué sale del informe
El informe final de la auditoría (típicamente 15 a 25 páginas en PDF) incluye el resultado de cada uno de los 45 puntos con nivel de criticidad (verde, ámbar, rojo), un resumen ejecutivo de dos páginas con los cinco problemas prioritarios, recomendación concreta sobre tres caminos posibles (parchar en sitio, modernizar en PrestaShop, cambiar de plataforma), presupuesto estimado de cada camino con rangos realistas, y una lista de riesgos nombrados que no requieren acción inmediata pero conviene vigilar.
El objetivo no es vender el camino más caro. El objetivo es que el propietario pueda pedir presupuestos a quien quiera, a mí o a otros, con un documento objetivo detrás.
Qué no es la auditoría
No es una revisión de código línea a línea. Para eso hace falta un audit de desarrollo específico y es otro trabajo distinto.
No es un pentest. No se intenta explotar vulnerabilidades. Se identifican riesgos conocidos y configuración defectuosa; no se busca romper nada.
No es consultoría de marketing. No miro conversion rate, embudo de ventas, email marketing ni posicionamiento comercial. Me ciño a lo técnico y normativo.
No es un diagnóstico de rendimiento aislado. El rendimiento está dentro del alcance (puntos 30–33), pero una auditoría de rendimiento pura con WebPageTest + perfilado y propuesta de optimización va aparte.
Cuándo tiene sentido pedir la auditoría
Antes de pedir presupuesto para un rediseño, para evitar los "diagnósticos gratuitos" de agencias que luego traducen todo a su servicio estándar. Antes de decidir migrar a Shopify o rehacer en PrestaShop; el marco de decisión está en la guía de Shopify. Antes de implantar Verifactu si la tienda es la que emite la factura. Al cambiar de agencia y necesitar documentación objetiva de lo que va a entregarse. Al comprar una tienda, como due diligence técnica mínima. Después de dos años sin tocar la tienda, cuando ya no se sabe en qué estado está.
Preguntas frecuentes
¿Se puede pedir solo parte del checklist? Sí. Si interesan solo los bloques de SEO y rendimiento, por ejemplo, se puede acotar y el precio baja. 290 € es la auditoría completa.
¿Hace falta dar acceso al servidor? Lectura de ficheros, acceso al backoffice y acceso de solo lectura a base de datos. No se modifica nada; se documenta todo.
Si aparece algo crítico, ¿qué pasa? Se nombra en el informe con nivel rojo y recomendación de actuación inmediata. Si el propietario quiere que lo arregle yo, presupuesto fijo aparte. Si prefiere otro desarrollador, el informe también le vale.
¿La auditoría descuenta del presupuesto si se contrata el trabajo? No. La auditoría es independiente del trabajo posterior; se cobra por el valor del diagnóstico, no como gancho comercial. Si al final no se hace nada con el informe, también vale lo que vale.
¿Cuánto tarda? Cinco días hábiles desde el acceso al entorno. En casos complejos (1.6 con muchos módulos custom), puede ir a diez.
¿Para qué versiones de PrestaShop sirve? 1.6, 1.7.x, 8.x y 9.0. El checklist se adapta a la versión; algunos puntos no aplican en 1.6 (por ejemplo, hooks modernos) y otros aparecen solo en 8.x y posteriores (Twig en backoffice).
Qué hacemos nosotros
Oficio eCommerce es una consulta especializada en PrestaShop, OpenCart, Magento 1 y 2, y osCommerce, con PrestaShop como foco principal. La auditoría de 290 € es la puerta de entrada estándar. Soy Serhii Bulak y llevo desde 2009 trabajando con tiendas en PHP; este checklist es el que he ido depurando durante estos años, no una plantilla sacada de un curso.
Cuando una PrestaShop lleva más de cinco años en producción sin auditoría independiente, lo que sale suele sorprender. Diagnóstico primero, decisiones después.