Evaluar un desarrollo WooCommerce antes de aceptarlo

Guía práctica para evaluar un desarrollo WooCommerce antes de aceptar la entrega: criterios técnicos, señales de alerta y checklist real.

Por qué necesitas saber evaluar un desarrollo WooCommerce

Recibes la entrega de tu tienda WooCommerce. Visualmente parece correcta, los productos cargan, el checkout funciona. Aceptas el proyecto y pagas la factura. Tres meses después empiezan los problemas: velocidad degradada, errores en pedidos puntuales, incompatibilidades con actualizaciones. ¿Te suena?

Saber evaluar un desarrollo WooCommerce antes de dar el visto bueno no es un lujo técnico: es la diferencia entre un proyecto que escala y uno que acumula deuda técnica desde el primer día. Esta guía te da un marco concreto — con criterios verificables — para que puedas revisar cualquier entrega con confianza, seas propietario de la tienda o una agencia que subcontrata desarrollo.

No vamos a hablar de sensaciones ni de «se ve bien». Vamos a hablar de métricas, herramientas y señales reales que cualquier persona con acceso al backend puede comprobar.

El problema de aceptar entregas sin criterios claros

Según un análisis de deuda técnica, el coste de corregir problemas detectados en producción puede ser entre 5 y 15 veces mayor que detectarlos antes de la aceptación. En el ecosistema WooCommerce, esto se traduce en cifras concretas:

• Un problema de rendimiento no detectado puede reducir la tasa de conversión un 7% por cada segundo adicional de carga (datos de Google Web Vitals).
• Un error en la lógica de impuestos o envíos puede generar reclamaciones durante semanas antes de identificarse.
• Código no estándar que funciona «ahora» romperá con la siguiente actualización mayor de WooCommerce.

La mayoría de agencias y propietarios aceptan entregas basándose en un recorrido visual: «navego la tienda, parece que funciona, apruebo». Eso es como comprar un coche probando solo el color de la pintura. Necesitas abrir el capó.

Criterios técnicos para evaluar la calidad del código

Estándares de codificación WordPress

WordPress tiene unas guías de codificación oficiales (WordPress Coding Standards). Un desarrollo profesional debería seguirlas. ¿Cómo comprobarlo sin ser desarrollador?

• Pregunta directamente: «¿El código sigue los WordPress Coding Standards?» Un desarrollador competente responderá con seguridad y podrá demostrarlo.
• Revisa el tema hijo: si se ha creado un tema hijo (child theme), comprueba que el archivo functions.php no sea un volcado caótico de funciones sin organización. Debe tener comentarios, funciones con prefijos coherentes y uso de hooks.
• Plugins personalizados: cualquier funcionalidad custom debería estar encapsulada en un plugin propio, no inyectada directamente en el tema. Esto es un indicador clave de calidad.

Uso correcto de hooks y filtros

Un buen desarrollo WooCommerce usa el sistema de hooks de WordPress para modificar comportamientos en lugar de editar archivos del core o del tema padre. Si ves archivos del tema padre modificados directamente o archivos core de WooCommerce alterados, es una señal de alarma seria. Esas modificaciones se perderán con la primera actualización.

Consultas a base de datos

Abre la herramienta Query Monitor (plugin gratuito) y navega por las páginas principales de la tienda: portada, archivo de productos, ficha de producto, carrito y checkout. Anota:

• Número de consultas SQL: una ficha de producto bien optimizada no debería superar las 80-100 consultas. Si ves 200+, hay un problema.
• Consultas lentas: Query Monitor marca en rojo las que superan cierto umbral. Cualquier consulta por encima de 0.05 segundos merece investigación.
• Consultas duplicadas: si la misma consulta aparece 10 veces, el código no está usando caché de objetos correctamente.

Rendimiento: métricas que debes pedir antes de aceptar

Evaluar un desarrollo WooCommerce sin medir rendimiento es incompleto. No necesitas herramientas caras — las gratuitas son suficientes para una evaluación inicial sólida.

Google PageSpeed Insights

Pasa las cinco páginas clave (inicio, categoría, producto, carrito, checkout) por PageSpeed Insights. Los umbrales mínimos aceptables para una tienda WooCommerce son:

• LCP (Largest Contentful Paint): inferior a 2.5 segundos.
• CLS (Cumulative Layout Shift): inferior a 0.1.
• INP (Interaction to Next Paint): inferior a 200ms.

Si alguna de estas métricas está en rojo en móvil, el desarrollo necesita trabajo antes de aceptarlo. Un desarrollador profesional debería entregar con estos valores al menos en amarillo.

Tiempo de respuesta del servidor (TTFB)

El Time To First Byte debería estar por debajo de 600ms sin caché. Con caché activo, por debajo de 200ms. Si el TTFB supera 1 segundo, hay un problema de backend — puede ser código ineficiente, servidor inadecuado o ambos. Herramientas como GTmetrix o WebPageTest te lo muestran gratis.

Peso de página y peticiones

Una ficha de producto no debería superar los 2MB de peso total ni las 60-70 peticiones HTTP. Si ves 4-5MB y más de 100 peticiones, hay recursos sin optimizar: imágenes sin comprimir, CSS/JS sin minificar o plugins que cargan assets en páginas donde no se necesitan.

Revisión funcional: más allá de «se ve bien»

El checklist de flujo completo

Antes de aceptar cualquier entrega, realiza al menos un pedido completo de prueba — idealmente tres, con estas variaciones:

1. Producto simple + envío estándar + pago con tarjeta: el flujo más básico. Verifica que el email de confirmación llegue correctamente al cliente y al administrador.
2. Producto variable + cupón de descuento + envío gratuito: comprueba que las variaciones calculen bien el precio, que el cupón se aplique correctamente y que las condiciones de envío gratuito funcionen.
3. Producto con impuestos especiales (si aplica) + dirección de envío diferente a facturación: los errores en cálculo de IVA intracomunitario o IGIC (Canarias) son frecuentes y caros de corregir después.

Emails transaccionales

Revisa cada email que WooCommerce envía: confirmación de pedido, procesando, completado, reembolso. Verifica:

• Que lleguen (no caigan en spam).
• Que el contenido sea correcto (nombre del producto, precio, dirección).
• Que el diseño sea coherente con la marca.
• Que los enlaces dentro del email funcionen.

Responsividad real

No basta con redimensionar el navegador. Prueba en un dispositivo móvil real. Presta atención especial al checkout en móvil: botones que no se pulsan bien, campos de formulario que se superponen o pasos que requieren scroll horizontal son errores inaceptables en 2026, cuando más del 65% de las compras online se inician desde móvil.

Seguridad: verificaciones esenciales en la entrega

Evaluar un desarrollo WooCommerce sin revisar seguridad es dejar la puerta abierta. Estos son los puntos mínimos:

• Certificado SSL activo: toda la tienda debe servirse por HTTPS, sin contenido mixto. Herramientas como Why No Padlock detectan recursos inseguros en segundos.
• Permisos de archivos: los archivos deben tener permisos 644 y los directorios 755. Permisos 777 en cualquier carpeta es un fallo de seguridad grave.
• wp-config.php protegido: el archivo de configuración no debería ser accesible desde el navegador. Prueba accediendo a tudominio.com/wp-config.php — debería devolver un error 403 o una página en blanco, nunca el contenido del archivo.
• Prefijo de base de datos: si sigue siendo wp_ (el valor por defecto), es un indicador de que no se prestó atención a la seguridad básica durante la instalación.
• Usuarios administradores: no debería existir un usuario llamado «admin». Y la cuenta del desarrollador debería estar documentada o eliminada tras la entrega.

Documentación y entregables: lo que deberías recibir

Un desarrollo sin documentación es un desarrollo a medias. Al evaluar la entrega, exige como mínimo:

Documentación técnica

• Lista de plugins instalados con versión y propósito de cada uno.
• Descripción de cualquier código personalizado: qué hace, dónde está y por qué se implementó así.
• Credenciales de todos los servicios configurados (pasarela de pago, SMTP, CDN, etc.) — en un gestor de contraseñas o documento cifrado, nunca en texto plano por email.

Documentación de usuario

• Guía básica para gestionar productos, pedidos y configuraciones habituales.
• Procedimiento de actualización recomendado (qué actualizar primero, en qué orden, cuándo hacer backup).
• Contacto o canal de soporte para incidencias post-entrega.

Si el desarrollador no entrega documentación y responde «ya te explico si surge algo», estás asumiendo un riesgo de dependencia total. La documentación es parte del entregable, no un extra.

Señales de alerta que justifican no aceptar la entrega

Después de aplicar los criterios anteriores, estas son las señales que deberían hacerte pausar la aceptación:

1. Más de 25 plugins activos sin justificación clara para cada uno. Cada plugin añade superficie de ataque y potencial de conflicto.
2. Plugins premium con licencias «nulled» (piratas). Además del riesgo legal, son el vector de malware más común en WordPress.
3. Sin tema hijo: si las personalizaciones están directamente en el tema padre, se perderán con la primera actualización.
4. Sin sistema de backups configurado: la tienda debería tener copias de seguridad automáticas funcionando desde el primer día.
5. Core o plugins desactualizados en la entrega: si te entregan un proyecto con WordPress 6.4 cuando la versión actual es 6.7, el desarrollador no ha mantenido el entorno durante el desarrollo.
6. Datos de prueba sin eliminar: productos de ejemplo, pedidos de test, usuarios ficticios. Parece menor, pero indica falta de rigor en el proceso de entrega.
7. Sin staging o entorno de pruebas: si todo el desarrollo se hizo directamente en producción, cualquier problema durante el proceso ha afectado al sitio en vivo.

Un framework práctico: la matriz de evaluación

Para sistematizar la revisión, te propongo una matriz simple con cuatro categorías y tres niveles de cumplimiento:

Cualquier celda en rojo debería detener la aceptación hasta que se corrija. Las amarillas pueden aceptarse con un compromiso de corrección en plazo definido, pero documentado por escrito.

Qué hacer si la evaluación revela problemas

Si al evaluar un desarrollo WooCommerce encuentras problemas serios, el paso correcto no es rechazar y buscar otro proveedor inmediatamente. La secuencia recomendada es:

1. Documenta cada problema con capturas, URLs y descripción específica.
2. Clasifica por severidad usando la matriz anterior.
3. Presenta la lista al desarrollador y establece un plazo razonable para correcciones (normalmente 1-2 semanas para problemas no críticos).
4. Re-evalúa tras las correcciones usando los mismos criterios.
5. Si los problemas persisten tras dos rondas de correcciones, entonces sí tiene sentido considerar una auditoría externa o un cambio de proveedor.

Este proceso protege a ambas partes: al cliente le da criterios objetivos, y al desarrollador le da la oportunidad de corregir con información concreta en lugar de quejas vagas.

Si necesitas un desarrollo WooCommerce con entregables claros y criterios de calidad definidos desde el inicio, puedes consultar mis servicios de desarrollo WordPress.

// Sobre el autor

fernandodomecq

Desarrollador WordPress freelance especializado en WooCommerce, integraciones e IA. Escribo sobre proyectos web, agencias y buenas prácticas técnicas.

Ver todos los artículos →