Cómo convertir un diseño en WordPress sin retrabajos: flujo de trabajo para agencias
La fase de producción WordPress es donde se pierde el margen en la mayoría de los proyectos de agencia. No por falta de talento técnico, sino por falta de proceso. Un diseño que llega tarde al maquetador, un entorno de desarrollo montado de forma distinta en cada proyecto, un responsive que se revisa «cuando hay tiempo» y un QA que consiste en mirar la web en el propio ordenador antes de enviarla.
El resultado es predecible: correcciones post-entrega, reuniones de crisis con el cliente y tiempo no facturable que erosiona el margen del proyecto.
Esta guía describe el flujo de trabajo que permite a una agencia producir sitios WordPress de forma sistemática, sin caos y sin retrabajos, tanto si la producción es interna como si se externaliza a un partner especializado.
Por qué la mayoría de los retrasos no ocurren durante la maquetación
El error más frecuente en la gestión de producción WordPress es asumir que los retrasos son técnicos. La realidad es que la mayoría de los retrasos ocurren antes de que el maquetador abra WordPress.
Según los datos internos de producción de Kalyma Studio de 2025, el 60% de los proyectos que superan el plazo acordado tienen como causa raíz un brief incompleto o un diseño que llegó a producción sin estar listo. El maquetador no puede producir a velocidad máxima con un archivo Figma sin organizar, tipografías en formato incorrecto o breakpoints no definidos.
Esto tiene una implicación práctica: el tiempo invertido en preparar correctamente el diseño antes de pasarlo a producción reduce el tiempo total del proyecto más que cualquier optimización del proceso de maquetación.
Fase 1 — Auditoría del diseño antes de abrir WordPress
El primer paso del flujo no ocurre en WordPress. Ocurre en el archivo de diseño.
Un diseño listo para producción cumple estos criterios:
Estructura del archivo:
- Capas nombradas y organizadas por secciones
- Componentes reutilizables definidos (botones, cards, formularios, iconos)
- Estilos de texto unificados con tipografías identificadas
- Paleta de colores definida con códigos hexadecimales exactos
Tipografías:
- Disponibles en Google Fonts o exportadas en formato .woff2
- Pesos utilizados identificados por sección (regular, medium, bold)
Breakpoints:
- Versión móvil diseñada explícitamente (no es suficiente con «adaptar» el desktop)
- Breakpoints definidos: mínimo 375px (móvil), 768px (tablet), 1280px (escritorio)
- Reordenaciones de elementos en móvil documentadas
Interacciones:
- Animaciones descritas o documentadas (tipo, duración, trigger)
- Estados hover definidos en elementos interactivos
- Comportamiento de formularios especificado
Si el diseño no cumple estos criterios, la opción correcta es devolver el archivo al diseñador con una lista de lo que falta. No es una obstrucción del proceso: es evitar que el maquetador tome decisiones que no le corresponden.
Fase 2 — Preparación del entorno de desarrollo
El segundo paso es preparar el entorno de staging antes de empezar a maquetar. Un entorno configurado de forma estándar, igual en todos los proyectos, permite que cualquier miembro del equipo retome el trabajo de otro sin tiempo de adaptación.
El entorno estándar para producción WordPress incluye:
Instalación base:
- WordPress en su versión estable más reciente
- Tema base ligero (Hello Theme de Elementor es el más común para stacks con Elementor Pro)
- Sin plugins innecesarios instalados — solo los del proyecto
Constructor configurado:
- Estilos globales cargados: tipografías, colores, espaciados
- Plantillas de página vacías con la estructura del menú del proyecto
- Kit de componentes del diseño creados antes de empezar la maquetación página por página
Rendimiento desde el inicio:
- Imágenes optimizadas antes de subirlas (WebP, dimensiones correctas)
- Plugin de caché configurado
- PHP en versión con soporte activo
Montar el entorno correctamente tarda entre 30 y 60 minutos. Montar un entorno caótico cuesta horas de trabajo posterior.
Fase 3 — Maquetación por componentes, no por páginas
El error más habitual en maquetación es empezar por la página de inicio y construir todo desde cero en cada página. Ese enfoque no escala.
El enfoque correcto es pensar en componentes antes que en páginas.
Paso 1: Identificar los componentes del diseño
Hero, sección de servicios, cards de testimonios, bloques de texto con imagen, formularios de contacto, footer. Un sitio de 5 páginas suele tener entre 8 y 15 componentes distintos.
Paso 2: Construir cada componente una sola vez
Crear cada componente en Elementor como plantilla o bloque reutilizable antes de empezar a ensamblar páginas. Un componente bien construido se reutiliza en todas las páginas donde aparece sin duplicar trabajo.
Paso 3: Ensamblar páginas con componentes
La maquetación de cada página se convierte en un proceso de ensamblaje, no de construcción desde cero. El tiempo de maquetación de las páginas interiores se reduce entre un 40% y un 60% respecto al enfoque página por página.
Paso 4: Ajustar contenido, no estructura
Cada instancia de un componente ajusta el contenido específico de esa página, pero la estructura y los estilos son los mismos. Eso garantiza consistencia visual sin esfuerzo adicional.
Fase 4 — Responsive como fase independiente
El responsive no es un ajuste que se hace «de paso» mientras se maqueta el desktop. Es una fase completa con su propio tiempo asignado.
Maquetar en desktop y ajustar el responsive al mismo tiempo multiplica el retrabajo porque cualquier cambio en el desktop puede romper los ajustes de móvil ya hechos.
El proceso correcto:
- Terminar la maquetación desktop al 100% antes de abrir las vistas de móvil y tablet
- Revisar la versión tablet: reordenaciones de columnas, ajustes de tipografía, espaciados
- Revisar la versión móvil: es la que más ajustes requiere y donde más se rompen los diseños
- Verificar en dispositivos reales, no solo en el simulador del navegador
- Comprobar formularios en móvil: campos, botones y teclado virtual
Una sesión de revisión responsive bien ejecutada tarda entre 1 y 3 horas dependiendo de la complejidad del diseño. Hacerlo de forma fragmentada durante la maquetación puede costar el doble.
Fase 5 — QA técnico antes de la entrega
El QA es la fase que más se acelera cuando hay presión de tiempo y la que genera más correcciones post-entrega cuando se omite.
El checklist de QA mínimo antes de entregar un sitio WordPress:
Visual:
- El diseño se respeta en los tres breakpoints: sin elementos desbordados, sin tipografías que no corresponden, sin imágenes mal recortadas
- Los colores coinciden con los del diseño (verificar con cuentagotas, no a ojo)
- Los espaciados entre secciones son consistentes en toda la web
Funcional:
- Todos los enlaces funcionan y apuntan a la URL correcta
- Los formularios se envían correctamente y llegan al destino acordado
- El menú funciona en móvil y los submenús se despliegan correctamente
- Las animaciones funcionan en los navegadores principales (Chrome, Firefox, Safari)
Rendimiento:
- Score de PageSpeed en móvil medido con Google Lighthouse
- El umbral mínimo recomendado es 85/100. Por debajo de ese score, el sitio puede tener problemas de posicionamiento orgánico
- Imágenes sin optimizar, scripts de terceros sin cargar de forma diferida y plugins innecesarios son las causas más frecuentes de score bajo
Contenido:
- Los textos corresponden a la versión aprobada por el cliente
- No hay texto de relleno (Lorem Ipsum) en páginas que se van a publicar
- Las imágenes tienen atributo alt descriptivo
Pre-publicación:
- Los accesos y credenciales están documentados
- El staging está configurado para no ser indexado por Google hasta que se migre a producción
Cuándo tiene sentido externalizar la producción
Un flujo de producción bien montado funciona con equipo interno. Pero hay situaciones en las que la externalización a un partner especializado es más eficiente:
Volumen variable. Si la agencia tiene semanas con 3 proyectos y semanas con 10, mantener un equipo interno dimensionado para el pico implica tener capacidad ociosa en los valles. Un partner externo absorbe los picos sin coste fijo.
Ausencia de stack técnico propio. Si el equipo de la agencia es de diseño y estrategia pero no de desarrollo, montar un flujo de producción interno requiere contratación, formación y gestión. Externalizar elimina ese coste estructural.
Proyectos con requisitos técnicos específicos. WooCommerce, integraciones con CRMs, accesibilidad WCAG, rendimiento WPO. Si el proyecto requiere competencias técnicas que el equipo interno no tiene de forma regular, un partner especializado las tiene de forma permanente.
En todos esos casos, el flujo de trabajo descrito en este artículo sigue siendo relevante: la agencia necesita saber preparar un brief técnico correcto, revisar el entregable del partner y gestionar la relación con el cliente final. Lo que cambia es quién ejecuta la maquetación.
Si quieres ver cómo aplica este proceso en la práctica con un partner externo, el flujo de trabajo interno de Kalyma Studio describe el proceso completo desde la recepción del brief hasta la entrega documentada.
Fecha de modificación: 16 de junio 2026