Auditoría de una tienda online heredada: checklist técnico para WooCommerce y PrestaShop

Heredar una tienda online es una de las situaciones más incómodas del desarrollo web. Un cliente cambia de proveedor, un socio se va, una empresa compra otra, o simplemente el desarrollador original desapareció hace tres años y nadie sabe muy bien qué hay dentro. Lo que queda es una plataforma que factura todos los días, que nadie se atreve a tocar y de la que no existe documentación. La primera reacción suele ser una de dos: reescribirlo todo o no tocar nada. Ambas son malas.

La respuesta razonable es una auditoría de tienda online: un trabajo acotado, con método y con entregables, que responde a tres preguntas concretas. ¿Qué tengo exactamente? ¿Qué riesgo estoy asumiendo hoy? ¿Qué me cuesta ponerlo en un estado mantenible? No es un informe de buenas intenciones ni un listado de avisos de un escáner online: es un inventario técnico con hallazgos priorizados, estimaciones y un plan de trabajo que la dirección pueda aprobar.

En este artículo desarrollamos el checklist completo que aplicamos en Keliam cuando nos entregan un ecommerce heredado, con foco en las dos plataformas más habituales en el mercado español: WooCommerce y PrestaShop. Verás qué pedir antes de empezar, qué revisar en cada capa, qué comandos y herramientas usar, qué señales indican que el proyecto está peor de lo que parece y cómo convertir los hallazgos en un plan que se pueda vender internamente. Al final incluimos una sección de preguntas frecuentes con las dudas que salen en casi todas las reuniones de arranque.

1. Qué significa realmente «tienda heredada» (y por qué importa)

Una tienda heredada no es necesariamente una tienda vieja. Es una tienda de la que el equipo actual no tiene modelo mental. Puede tener dos años y ser completamente opaca, o tener nueve y estar impecablemente documentada. Lo que define el problema es la asimetría de información: alguien tomó decisiones que hoy nadie sabe explicar, y esas decisiones siguen ejecutándose en producción cada vez que un cliente pulsa «Comprar».

Esa opacidad tiene un coste medible. Cada cambio se vuelve caro porque hay que investigar antes de tocar. Cada incidencia tarda más en resolverse porque no hay hipótesis previa. Y, sobre todo, el riesgo es desconocido: no sabes si mañana la pasarela de pago va a dejar de funcionar por un cambio de API, si tienes datos personales expuestos en un endpoint olvidado o si el backup que llevas dos años pagando no restaura.

1.1 Los tres perfiles de tienda heredada

En la práctica nos encontramos tres arquetipos, y conviene identificar cuál tienes delante porque el esfuerzo de auditoría cambia bastante:

• La tienda «estándar acumulada». Core actualizado o casi, pero con 40-70 plugins o módulos, la mitad de ellos redundantes, algunos abandonados por su autor. El código propio es mínimo. Aquí la auditoría es sobre todo inventario, dependencias y rendimiento.
• La tienda «a medida sobre plataforma». Un tema hijo enorme, decenas de overrides, lógica de negocio metida en hooks y funciones sueltas. Funciona, pero está anclada a una versión concreta. El grueso del trabajo es leer código y trazar la lógica.
• La tienda «con el core tocado». El peor escenario: alguien editó archivos del núcleo para resolver algo rápido. La tienda no se puede actualizar sin romperse, y probablemente lleva años sin parches de seguridad. Aquí la auditoría tiene que cuantificar el coste de volver a un core limpio.

Distinguirlos es rápido si sabes dónde mirar, y lo veremos en la sección de código. Pero antes hay una fase previa que mucha gente se salta y que suele ser la que más tiempo ahorra.

2. Fase 0: accesos, inventario y contexto de negocio

Ninguna auditoría técnica seria empieza abriendo el código. Empieza pidiendo cosas y comprobando que existen. Es habitual que en esta fase ya aparezca el primer hallazgo grave: nadie tiene las credenciales del DNS, o el hosting está a nombre de una persona que ya no trabaja en la empresa.

2.1 La lista de accesos mínima

Antes de estimar nada, pide y verifica uno por uno:

• Panel de administración de la tienda con un usuario de rol administrador propio (no compartido).
• Acceso SSH o, como mínimo, SFTP al servidor de producción, y a un entorno de staging si existe.
• Acceso al panel de hosting o al proveedor cloud, con visibilidad de recursos, versiones y logs.
• Repositorio de código: URL, historial y ramas. Si no hay repositorio, eso ya es un hallazgo de primer nivel.
• Credenciales del registrador de dominio y del proveedor de DNS.
• Accesos a las herramientas de terceros: pasarela de pago, ERP, transportistas, CDN, correo transaccional, analítica y Search Console.
• Documentación existente, aunque sean cuatro correos y una hoja de cálculo.

Verificar cada acceso, no solo recibirlo. Una credencial que no funciona es lo mismo que no tenerla, y descubrirlo a mitad de un incidente es la peor forma de enterarse.

2.2 El contexto de negocio que cambia las prioridades

La misma tienda con 30 pedidos al mes y con 3.000 no se audita igual. Necesitas cifras antes de decidir qué es urgente:

• Volumen: pedidos y facturación mensual, ticket medio, número de referencias en catálogo y de combinaciones.
• Estacionalidad: cuándo son los picos y cuánto multiplican al tráfico normal.
• Modelo: B2C, B2B, mixto, con precios por cliente, con stock sincronizado, con multi-idioma o multi-tienda.
• Roadmap: qué quiere hacer el negocio en los próximos 12 meses. Auditar sin saberlo es entregar un informe que nadie usará.
• Quién mantiene qué hoy: agencia, freelance, interno, o nadie.

Con esto ya puedes calibrar. Una tienda B2B con integración de ERP y precios por cliente exige mirar los flujos de datos con lupa; una tienda B2C con picos brutales en campaña exige mirar caché e infraestructura antes que nada.

3. Capa plataforma: versiones, soporte y superficie instalada

El primer bloque técnico es el más mecánico y el que más sorpresas da. Se trata de saber qué software está corriendo y en qué estado de soporte se encuentra.

3.1 WooCommerce y WordPress

Empieza por las versiones y por la coherencia entre ellas:

• Versión de WordPress y de WooCommerce, y distancia respecto a la última estable. Una diferencia de dos versiones mayores de Woo suele implicar cambios de plantillas y de estructura de datos.
• Versión de PHP en el servidor. Ejecutar sobre una rama sin soporte de seguridad es un hallazgo crítico por sí solo, independientemente de que «funcione».
• Estado de HPOS (High Performance Order Storage). Si la tienda sigue guardando pedidos como custom post types y tiene volumen, es una de las palancas de rendimiento más rentables; lo desarrollamos en la guía sobre la migración a HPOS en WooCommerce.
• Inventario de plugins con wp plugin list --format=csv: cuántos hay, cuáles están activos, cuáles tienen actualización pendiente y cuáles llevan más de un año sin release. Los abandonados son deuda y riesgo a la vez.
• Plugins duplicados en función: dos plugins de caché, dos de SEO, tres de formularios. Es señal clásica de rotación de proveedores.
• Plugins nulled o con licencia caducada: no reciben parches y a veces incluyen código añadido. Búscalos comparando checksums con el repositorio oficial cuando sea posible.

Un criterio útil para separar el ruido: no todos los plugins pesan igual. Los que tocan checkout, pagos, precios, stock o datos de cliente van al bloque crítico; el resto puede esperar. Si necesitas una referencia de qué stack es razonable mantener, en el artículo sobre los plugins imprescindibles de WooCommerce desglosamos qué merece estar instalado y qué se puede sustituir por código propio.

3.2 PrestaShop

En PrestaShop el mapa es distinto pero la lógica es la misma:

• Rama y versión exacta: 1.6, 1.7.x, 8.x o 9.x. Las diferencias entre ramas no son cosméticas, afectan a arquitectura, a Symfony y a la compatibilidad de módulos.
• Compatibilidad PHP de la rama instalada. En tiendas antiguas es frecuente encontrar el techo de PHP como bloqueo real para actualizar.
• Módulos instalados frente a módulos activos, y cuáles proceden de marketplace, cuáles son a medida y cuáles son «de un desarrollador que ya no está».
• Presencia de override/ con contenido: cada override es una promesa de conflicto en la próxima actualización.
• Estado del multitienda y de los contextos, si está activado. Suele ser fuente de comportamientos difíciles de reproducir.
• Configuración de debug mode, perfiles y caché de Smarty en producción. Encontrar el debug activo en producción es más común de lo que debería.

3.3 Cómo puntuar esta capa

Para no entregar una lista plana, puntúa cada elemento con tres etiquetas: soportado, en riesgo (fin de soporte a menos de 12 meses o sin releases recientes) y fuera de soporte. Todo lo que caiga en la tercera categoría y toque pagos o datos personales entra directamente en el bloque de acciones inmediatas.

4. Capa código: temas, módulos a medida y hacks al core

Aquí es donde una auditoría se diferencia de un escaneo automático. El objetivo no es contar líneas, sino entender dónde vive la lógica de negocio y cuánto cuesta modificarla sin romper nada.

4.1 Detectar si el core está tocado

Es la comprobación más rentable de toda la auditoría y se hace en minutos. En WordPress, wp core verify-checksums y wp plugin verify-checksums --all te dicen qué archivos difieren del original. En PrestaShop, compara el árbol de classes/, controllers/ y src/ contra una copia limpia de la misma versión con un diff -r. Si el repositorio existe, el historial de Git suele contar la historia completa.

Cualquier modificación en el núcleo se documenta con tres datos: qué archivo, qué hace el cambio y qué problema pretendía resolver. Ese tercer dato es el que permite proponer una alternativa limpia (un hook, un override bien hecho, un plugin propio) en lugar de simplemente decir «hay que quitarlo».

4.2 Revisión del tema y del código propio

El tema es el sumidero habitual de lógica que no debería estar ahí. Busca de forma sistemática:

• Consultas SQL directas dentro de plantillas. Suelen ser el origen de páginas lentas y de problemas de escalado.
• Llamadas HTTP síncronas a servicios externos en el renderizado de página. Si el ERP tarda, la tienda tarda.
• Credenciales, claves de API o tokens escritos en el código. Es un hallazgo crítico y frecuente.
• Plantillas de checkout y de correo sobrescritas: son las que más se rompen al actualizar y las que más impacto tienen en conversión.
• Funciones duplicadas con nombres tipo custom_, tmp_, nuevo_: síntoma de capas sucesivas de mantenimiento sin limpieza.
• Código muerto: archivos .bak, .old, carpetas _antiguo o copias completas del tema dentro del propio tema.

Complementa la lectura manual con análisis estático. PHPStan o Psalm sobre el código propio, y PHP_CodeSniffer con el estándar de la plataforma, dan en una tarde una foto objetiva del nivel de calidad. No los uses como veredicto, sino como termómetro y como argumento cuantitativo en el informe. Este trabajo es exactamente el que describimos en detalle en el artículo sobre qué se analiza en una auditoría técnica de software, aplicado aquí al contexto de ecommerce.

4.3 Traducir hallazgos a deuda técnica

Un listado de problemas de código no convence a nadie que no programe. Lo que sí convence es expresarlo como coste: cuántas horas al mes se pierden por esta situación, cuánto encarece cada nueva funcionalidad y qué probabilidad hay de incidente. Ese lenguaje es el que permite negociar presupuesto de refactor, y lo tratamos a fondo en el artículo sobre cómo detectar, medir y reducir la deuda técnica.

5. Capa datos y rendimiento: dónde se esconde la deuda cara

En un ecommerce heredado la base de datos es un registro arqueológico. Cada proveedor que pasó dejó tablas, metadatos y opciones que ya nadie lee, y todo eso se paga en cada consulta.

5.1 Revisión del esquema

• Tamaño total y por tabla. En WooCommerce, revisa wp_options (y el peso de las autoloaded options), wp_postmeta y las tablas de sesiones y de acciones programadas. En PrestaShop, mira ps_connections, ps_guest, ps_search_word y ps_search_index, que crecen sin control si nadie las purga.
• Tablas huérfanas de plugins o módulos ya desinstalados.
• Motor de almacenamiento y juego de caracteres: encontrar tablas MyISAM o latin1 en una tienda actual es señal de migraciones mal hechas.
• Índices ausentes en columnas que se usan para filtrar o unir. Es la causa número uno de listados de pedidos que tardan diez segundos en el back office.

5.2 Consultas lentas y rendimiento real

Activa el slow query log durante unos días de tráfico normal y ordena por tiempo acumulado, no por tiempo máximo: lo que mata una tienda no es la consulta de 8 segundos que se ejecuta una vez al día, sino la de 300 milisegundos que se ejecuta cuarenta veces por página. Con Query Monitor en WordPress o el profiler de PrestaShop obtienes el desglose por petición.

Después, mide lo que ve el usuario: TTFB en portada, categoría, ficha de producto y checkout, con y sin caché; Core Web Vitals con datos de campo si hay tráfico suficiente; y comportamiento con el carrito lleno, que es precisamente donde la caché de página deja de ayudar. La metodología completa de medición está en la guía de auditoría de rendimiento web: herramientas y métricas clave.

5.3 Caché y cola de tareas

Comprueba qué capas de caché existen y si se pisan entre ellas: caché de página, de objetos (Redis o Memcached), de opcode y CDN. Un error clásico en tiendas heredadas es tener caché de página cacheando URLs con parámetros de carrito o de sesión, con el resultado divertido de que un cliente ve el carrito de otro.

Revisa también el sistema de tareas programadas. En WooCommerce, una tabla de Action Scheduler con cientos de miles de acciones pendientes o fallidas indica procesos rotos que llevan meses sin que nadie mire. En PrestaShop, revisa los cron de módulos y si realmente se ejecutan.

6. Capa seguridad y datos personales

Una tienda heredada acumula riesgo de seguridad de forma silenciosa. La auditoría no pretende sustituir un pentest, pero sí levantar los indicadores que obligan a actuar.

6.1 Checklist de seguridad aplicada

• Usuarios y roles: cuántos administradores hay, cuántos corresponden a personas que ya no están, si hay cuentas compartidas y si hay segundo factor. Revisa también los usuarios de base de datos y sus privilegios.
• Secretos: claves de API, credenciales de ERP y tokens en el código o en archivos de configuración accesibles por web. Comprueba que .env, .git y los backups no sean descargables desde el navegador.
• Superficie expuesta: instaladores olvidados, phpMyAdmin sin restricción, endpoints de API abiertos, listados de directorio.
• Cabeceras y transporte: HTTPS en todo el sitio y sin contenido mixto, HSTS, Content-Security-Policy, cookies con Secure, HttpOnly y SameSite.
• Pagos: que los datos de tarjeta no toquen tu servidor. Si la tienda captura el PAN en su propio formulario, el alcance PCI DSS se dispara y eso es un hallazgo de máxima prioridad.
• Datos personales: qué se guarda, durante cuánto tiempo, si hay exportaciones en CSV olvidadas en el servidor y si los backups viajan cifrados. La política de retención suele no existir.
• Registro y detección: si hay logs de acceso, durante cuánto se conservan y si alguien los mira. Sin logs no hay investigación posible tras un incidente.

Todo lo relacionado con explotabilidad real conviene tratarlo aparte, con un alcance y unas reglas propias; el enfoque y las fases están descritos en el artículo sobre auditoría de seguridad y pentesting en ecommerce.

6.2 La pregunta que nadie hace: ¿el backup restaura?

Un backup no verificado no es un backup. En la auditoría, no basta con comprobar que existe una copia: hay que restaurarla en un entorno aislado y comprobar que la tienda arranca, que el catálogo está completo y que los pedidos recientes aparecen. Es habitual descubrir que la copia lleva meses guardando solo archivos y no la base de datos, o al revés. Este punto solo tiene dos resultados posibles en el informe: verificado o no verificado.

7. Capa integraciones: el mapa invisible

En una tienda con recorrido, la mitad de la complejidad no está en la tienda, sino en lo que la rodea. Documentar ese mapa suele ser el entregable que más agradece el cliente porque nadie lo tenía escrito.

Para cada integración —ERP, pasarela de pago, transportistas, marketplaces, feeds de producto, correo transaccional, CRM, facturación— registra siete campos: qué sistema, en qué dirección fluyen los datos, con qué frecuencia, con qué mecanismo (API, cron, webhook, fichero), quién es el propietario del sistema al otro lado, qué pasa si falla y si alguien se entera cuando falla.

Esa última columna es la reveladora. En la mayoría de tiendas heredadas hay al menos una integración que falla en silencio: pedidos que no llegan al ERP, stock que no se sincroniza durante horas, correos de confirmación que caen en spam desde hace meses. Como no hay alertas, el problema solo aparece cuando un cliente reclama.

Revisa también los puntos de fricción con la conversión: si el checkout depende de una llamada síncrona a un servicio externo, cualquier latencia se traduce en carritos abandonados. Es uno de los factores que analizamos en la guía sobre cómo optimizar el checkout de un ecommerce.

8. Capa infraestructura, entornos y despliegue

La forma en que se pone código en producción dice más de la salud de un proyecto que casi cualquier otra cosa. Revisa:

• Hosting: tipo (compartido, VPS, cloud gestionado), recursos, versiones de servidor web, PHP y base de datos, y si hay alguien responsable de aplicar parches del sistema operativo.
• Entornos: si existe staging, si es una copia fiel de producción y si se refresca. Muchas tiendas heredadas se desarrollan directamente en producción; eso hay que decirlo en el informe con todas las letras.
• Control de versiones: si hay repositorio, si el contenido del servidor coincide con la rama principal y cuántos cambios se hicieron «a mano» por FTP. Un git status con cincuenta archivos modificados en producción es un diagnóstico completo por sí solo.
• Despliegue: manual, script o pipeline. Y sobre todo, si existe procedimiento de vuelta atrás.
• Monitorización: uptime, errores de aplicación, alertas de espacio en disco y de certificados a punto de caducar. Si la única monitorización es que llame un cliente, es un hallazgo.
• Certificados y DNS: fechas de caducidad, renovación automática, registros de correo (SPF, DKIM, DMARC) y quién controla la zona.

9. Capa SEO e indexación: no romper lo que ya funciona

Una auditoría técnica de ecommerce que ignore el SEO puede provocar un desastre en la fase de corrección. Antes de proponer cambios estructurales, deja registrado el estado actual:

• Número de URLs indexadas frente a productos y categorías reales, y qué porcentaje del catálogo está fuera del índice.
• Estructura de URLs y si hay redirecciones históricas encadenadas de migraciones anteriores. Las cadenas largas son deuda acumulada de cada cambio de plataforma.
• Gestión de facetas y filtros: si generan URLs indexables sin control, es una fuente clásica de contenido duplicado masivo.
• Canónicas, paginación, hreflang si hay varios idiomas, y datos estructurados de producto con precio y disponibilidad.
• Productos descatalogados: qué se hace con ellos (404, 410, redirección o página con alternativas).
• Sitemaps: que existan, que estén actualizados y que no incluyan URLs bloqueadas o con noindex.

El objetivo de esta capa no es proponer una estrategia SEO, sino inventariar lo que hay para que ninguna corrección técnica destruya tráfico que hoy factura.

10. De los hallazgos al plan: cómo se entrega una auditoría útil

Una auditoría que termina en un PDF de ochenta páginas que nadie lee ha fracasado, por muy bueno que sea el trabajo técnico. El entregable tiene que servir para tomar decisiones esta semana.

10.1 Estructura del informe

• Resumen ejecutivo (1-2 páginas). Estado general, los cinco riesgos que hay que atacar ya, y la cifra global de esfuerzo estimado. Escrito para dirección, sin jerga.
• Inventario. Plataforma, versiones, plugins o módulos, integraciones e infraestructura. Es el documento que se consultará durante meses.
• Hallazgos. Cada uno con identificador, evidencia reproducible, impacto de negocio, severidad, esfuerzo estimado y recomendación concreta. Sin evidencia no hay hallazgo.
• Plan por fases. Qué se hace en 30, 90 y 180 días, con dependencias explícitas.
• Anexos. Salidas de herramientas, capturas, consultas y scripts usados, para que el trabajo sea reproducible por otro equipo.

10.2 Priorizar sin discusiones estériles

La matriz de impacto y esfuerzo de la imagen anterior evita el debate infinito sobre qué es más importante. Los criterios que aplicamos:

• Bloque inmediato: todo lo que tenga riesgo de pérdida de datos, de brecha de seguridad o de caída de ventas. Backups no verificados, versiones sin soporte en componentes de pago, secretos expuestos, integraciones que fallan en silencio.
• Bloque 30-90 días: estabilización. Poner el código bajo control de versiones, montar staging, actualizar lo actualizable, resolver las consultas lentas más caras.
• Bloque 90-180 días: lo estructural. Salir de un core modificado, migrar de versión mayor, reescribir las integraciones frágiles, revisar arquitectura.
• Registrado pero no planificado: lo que no aporta y solo consumiría presupuesto. Decirlo explícitamente da credibilidad al resto del informe.

10.3 Cuándo la recomendación es replataformar

A veces la conclusión honesta es que arreglar cuesta más que rehacer. Las señales que apuntan en esa dirección son acumulativas, no aisladas: core modificado sin posibilidad de revertir, plataforma en rama sin soporte, ausencia total de repositorio y de entornos, integraciones no documentadas con sistemas críticos y un roadmap de negocio que la plataforma actual no puede soportar. Con tres o más de estas señales, el informe debe presentar la comparativa de costes entre estabilizar y migrar, incluyendo el riesgo SEO y de conversión de una migración. Si estás en ese punto, la comparativa entre Shopify, WooCommerce y PrestaShop te ayuda a acotar el destino antes de estimar.

11. Preguntas frecuentes sobre la auditoría de una tienda online

¿Cuánto dura una auditoría de tienda online?

Para una tienda estándar con pocos desarrollos propios, entre una y dos semanas de trabajo efectivo. Para una tienda a medida con integraciones y varios miles de referencias, de tres a cinco semanas. El factor que más alarga el proceso no es el tamaño del catálogo, sino la cantidad de código propio sin documentar y el tiempo que tarda el cliente en facilitar los accesos.

¿Se puede auditar sin acceso al servidor?

Parcialmente. Con acceso solo al panel de administración puedes inventariar plugins, revisar configuración y medir rendimiento desde fuera, pero no puedes verificar checksums del core, revisar el esquema de base de datos, comprobar logs ni validar backups. El resultado es un diagnóstico incompleto, y conviene decirlo en el informe en lugar de disimularlo.

¿La auditoría interrumpe la tienda?

No debería. El grueso del trabajo es de lectura y análisis. Las pruebas que puedan tener impacto —restauración de backup, pruebas de carga, comprobaciones de seguridad activas— se hacen en una copia aislada y con ventana acordada. Nunca se prueban restauraciones sobre producción.

¿Merece la pena auditar una tienda que «funciona bien»?

Sí, y es el mejor momento para hacerlo. Auditar en calma cuesta menos y permite planificar; auditar durante un incidente o en plena campaña obliga a decidir con prisa y con peor información. Además, el inventario resultante reduce el coste de cualquier trabajo futuro sobre la plataforma.

¿Qué diferencia hay entre esta auditoría y un pentest?

La auditoría técnica cubre el estado global del ecommerce: plataforma, código, datos, rendimiento, integraciones e infraestructura, con la seguridad como una capa más. El pentest busca activamente vulnerabilidades explotables con técnicas ofensivas y un alcance formal acordado. Son complementarios: lo habitual es auditar primero para entender qué hay y decidir después si el pentest tiene sentido y sobre qué perímetro.

Conclusión

Heredar una tienda online no es un problema técnico, es un problema de información. La auditoría es el mecanismo que convierte una plataforma opaca en un activo comprensible: sabes qué versiones corres, dónde vive la lógica, qué integraciones te sostienen, qué riesgos aceptas y cuánto cuesta cada mejora. A partir de ahí, las decisiones dejan de ser apuestas.

El orden importa. Primero accesos y contexto de negocio, porque sin eso todo lo demás se prioriza mal. Después las capas técnicas, de la más superficial a la más profunda. Y siempre terminar con hallazgos priorizados por impacto y esfuerzo, no por gusto técnico. Un informe que propone actualizar cuarenta plugins el mismo día que descubre que los backups no restauran ha ordenado mal sus prioridades.

Y una última recomendación: la auditoría no es un evento único. En una tienda que evoluciona, conviene repetir una revisión ligera cada seis o doce meses —versiones, dependencias, rendimiento, backups y accesos— para que la deuda no vuelva a acumularse en silencio. Es mucho más barato que volver a encontrarse, dentro de tres años, con otra tienda heredada que nadie sabe explicar.