Arquitecturas web modernas: usando WordPress como backend y webflow como frontend
La arquitectura headless ha pasado de ser una curiosidad experimental a convertirse en un patrón listo para producción. Cada vez más agencias y equipos internos optan por configuraciones desacopladas donde la capa de gestión de contenido está completamente separada de la capa de presentación — y una de las combinaciones más prácticas disponibles hoy en día es WordPress gestionando el backend mientras Webflow impulsa la experiencia en el frontend.
Esto no es un ejercicio teórico. Es una arquitectura que werun.dev ha implementado para clientes que necesitan el poder editorial y la extensibilidad de WordPress sin sacrificar la flexibilidad de diseño y la velocidad de desarrollo visual que ofrece Webflow. Entender cuándo y cómo construir correctamente este stack es lo que diferencia un sistema limpio y mantenible de una integración frágil que genera más problemas de los que resuelve.
Por Qué Combinar WordPress y Webflow
Antes de comprometerse con cualquier arquitectura desacoplada, hay que hacerse la pregunta: ¿qué problema resuelve esto en realidad? La respuesta depende en gran medida de la estructura del equipo y los requisitos de negocio del proyecto.
WordPress impulsa más del 43% de la web por una razón. Su modelo de datos es maduro, su REST API está bien documentada y su ecosistema de plugins cubre prácticamente todos los requisitos de contenido y comercio imaginables. Cuando se necesitan tipos de publicaciones personalizadas, taxonomías complejas, catálogos de productos en WooCommerce, lógica de membresías o integraciones profundas con CRMs y ERPs, WordPress es la herramienta adecuada. Ofrece a los equipos editoriales una interfaz familiar y probada, y a los desarrolladores un conjunto robusto de APIs sobre las cuales construir.
Webflow, por otro lado, sobresale en la capa de presentación. Su lienzo visual permite a los diseñadores producir layouts con precisión de píxel sin escribir CSS manualmente, y su motor de interacciones gestiona animaciones y transiciones que de otro modo requerirían un tiempo considerable de desarrollo en JavaScript. Para sitios con fuerte componente de marketing, landing pages o experiencias centradas en la marca, la velocidad de diseño de Webflow es genuinamente difícil de igualar.
El problema es que cada plataforma tiene un techo. Los temas de WordPress — incluso los temas de bloques modernos construidos para Full Site Editing — requieren la intervención de un desarrollador para superar los patrones de layout estándar. El CMS nativo de Webflow es poderoso para estructuras de contenido sencillas, pero encuentra límites importantes con datos relacionales, filtrado complejo y cualquier modelo de contenido que requiera lógica programática en lugar de entrada editorial manual.
El enfoque desacoplado elimina ambos techos simultáneamente. WordPress gestiona los datos, la lógica de negocio, la autenticación de usuarios y las integraciones. Webflow renderiza la experiencia. Los dos sistemas se comunican a través de la REST API de WordPress, y cada equipo — los desarrolladores trabajando en WordPress, los diseñadores trabajando en Webflow — opera en el entorno donde son más productivos.
Cuándo Tiene Sentido Esta Arquitectura
Este stack no es la elección correcta para todos los proyectos. Introduce complejidad adicional en forma de llamadas a la API, sincronización de datos, estrategia de caché y coordinación de despliegues. Tiene sentido cuando:
- El modelo de contenido es demasiado complejo para el CMS de Webflow por sí solo (datos profundamente relacionales, generación programática de contenido, datos de productos de WooCommerce)
- Los requisitos de diseño superan lo que los temas de WordPress pueden entregar sin un esfuerzo de desarrollo frontend desproporcionado
- El equipo del cliente incluye tanto editores no técnicos que necesitan un CMS familiar como diseñadores que trabajan nativamente en Webflow
- El proyecto requiere lógica de backend — reglas de precios, control de acceso, gestión de suscripciones — que WordPress maneja mejor que cualquier solución nativa de Webflow
- El rendimiento y el SEO son críticos, y el equipo quiere control total sobre el renderizado y el caché en la capa de la API
Construyendo el Backend en WordPress: La REST API como Fundamento
El lado de WordPress en esta arquitectura es donde reside el trabajo de ingeniería. El objetivo es construir una capa de API limpia y bien estructurada que Webflow — o cualquier frontend — pueda consumir de manera confiable. Esto implica ir mucho más allá de los endpoints predeterminados de la REST API que vienen con el núcleo de WordPress.
En werun.dev, cada build de WordPress sigue los mismos estándares de codificación: uso adecuado de hooks y filters, verificaciones de capacidades en cada endpoint, verificación de nonce para solicitudes autenticadas, y sanitización y escape completo de todos los datos. Cuando la REST API es la interfaz principal entre sistemas, estos estándares no son opcionales — un endpoint de API mal asegurado es una puerta abierta.
Endpoints Personalizados de la REST API
La REST API predeterminada de WordPress expone publicaciones, páginas y taxonomías estándar, pero un proyecto real requiere endpoints personalizados diseñados en torno al modelo de datos real. Construirlos correctamente implica registrar rutas con register_rest_route(), definir callbacks de permisos que apliquen las verificaciones de capacidades adecuadas, y devolver JSON estructurado con el que el equipo de frontend pueda trabajar de manera predecible.
add_action( 'rest_api_init', function() {
register_rest_route( 'werun/v1', '/products/featured', array(
'methods' => WP_REST_Server::READABLE,
'callback' => 'werun_get_featured_products',
'permission_callback' => '__return_true',
'args' => array(
'limit' => array(
'default' => 6,
'sanitize_callback' => 'absint',
),
),
) );
} );
function werun_get_featured_products( WP_REST_Request $request ) {
$limit = $request->get_param( 'limit' );
$query = new WP_Query( array(
'post_type' => 'product',
'posts_per_page' => $limit,
'meta_key' => '_featured',
'meta_value' => 'yes',
) );
$products = array();
foreach ( $query->posts as $post ) {
$products[] = array(
'id' => $post->ID,
'title' => get_the_title( $post ),
'price' => get_post_meta( $post->ID, '_price', true ),
'image' => get_the_post_thumbnail_url( $post, 'large' ),
'slug' => $post->post_slug,
);
}
return rest_ensure_response( $products );
}Este patrón — un namespace versionado, argumentos tipados con callbacks de sanitización y datos de respuesta estructurados — es la línea base para cada endpoint personalizado en un build de WordPress headless.
Tipos de Publicaciones Personalizadas y Modelado de Datos
El CMS de Webflow tiene un modelo de contenido fijo. WordPress no. Cuando el proyecto requiere tipos de contenido que van más allá de lo que Webflow puede representar nativamente — eventos con reglas de recurrencia complejas, productos con niveles de precios mayoristas, cursos con relaciones de prerrequisitos — los tipos de publicaciones personalizadas y las taxonomías personalizadas de WordPress gestionan el modelado de datos, y la REST API expone esos datos en la forma que el frontend necesite.
Para proyectos impulsados por WooCommerce, el catálogo de productos, el inventario, las reglas de precios y la lógica de checkout residen en WordPress. El frontend de Webflow puede mostrar listados y detalles de productos consumiendo los endpoints de la REST API de WooCommerce, mientras que el flujo real del carrito y el checkout redirige a una página alojada en WordPress o utiliza las capacidades headless de WooCommerce con una UI de checkout personalizada.
Autenticación y Datos Protegidos
No todos los datos de la API son públicos. El contenido exclusivo para miembros, el historial de pedidos, los detalles de la cuenta y cualquier experiencia personalizada requieren solicitudes de API autenticadas. El enfoque estándar en una configuración desacoplada de WordPress-Webflow es la autenticación JWT utilizando un plugin como wp-jwt-auth o una implementación personalizada, combinada con las capacidades de código personalizado de Webflow para gestionar el almacenamiento de tokens y los encabezados de las solicitudes.
Para casos más simples donde Webflow solo consume contenido público — un blog, un catálogo de productos, un directorio de equipo — no se necesita ninguna capa de autenticación y la arquitectura se mantiene sencilla.
Conectando Webflow a la API de WordPress
Con la capa de la API de WordPress en su lugar, el lado de Webflow de la integración utiliza JavaScript personalizado embebido en la configuración de páginas de Webflow o en el código personalizado a nivel de sitio para obtener datos y renderizarlos en la página. Aquí es donde la arquitectura requiere una planificación cuidadosa en torno al rendimiento, el caché y la experiencia del usuario durante la carga de datos.
Obteniendo y Renderizando Datos en Webflow
Webflow no tiene un mecanismo nativo de obtención de datos para APIs externas. La integración depende de JavaScript ejecutándose en el navegador — típicamente usando la API fetch — para recuperar datos de WordPress e inyectarlos en componentes de layout de Webflow preconstruidos.
El patrón estándar implica construir el layout visual en Webflow usando elementos de marcador de posición con IDs específicos o atributos de datos, y luego usar JavaScript para poblar esos elementos con datos reales provenientes de la API de WordPress.
async function loadFeaturedProducts() {
const container = document.getElementById('featured-products-grid');
if ( !container ) return;
try {
const response = await fetch(
'https://api.yourdomain.com/wp-json/werun/v1/products/featured?limit=6'
);
if ( !response.ok ) throw new Error( 'API request failed' );
const products = await response.json();
container.innerHTML = products.map( product => `
<div class="product-card" data-id="${product.id}">
<img src="${product.image}" alt="${product.title}" loading="lazy" />
<h3 class="product-title">${product.title}</h3>
<span class="product-price">$${product.price}</span>
<a href="/products/${product.slug}" class="product-link">View Product</a>
</div>
` ).join('');
} catch ( error ) {
console.error( 'Failed to load products:', error );
container.innerHTML = '<p class="error-message">Products temporarily unavailable.</p>';
}
}
document.addEventListener( 'DOMContentLoaded', loadFeaturedProducts );Este enfoque funciona bien para contenido que no necesita ser indexado por los motores de búsqueda. Para contenido crítico en términos de SEO, se requiere una estrategia diferente.
Consideraciones de SEO y Estrategia de Renderizado
El renderizado del lado del cliente de datos de la API crea un desafío real de SEO. Googlebot puede ejecutar JavaScript e indexar contenido renderizado dinámicamente, pero el proceso es más lento y menos confiable que indexar HTML estático. Para contenido que necesita posicionarse — publicaciones de blog, páginas de productos, páginas de servicios — depender completamente del fetching del lado del cliente no es recomendable.
Las soluciones prácticas en una arquitectura WordPress-Webflow son:
- Usar el CMS de Webflow para contenido crítico en SEO: Sincronizar datos de WordPress al CMS de Webflow usando Make (anteriormente Integromat), Zapier o un script de sincronización personalizado basado en webhooks. Webflow renderiza entonces este contenido como HTML estático en el momento de la compilación, preservando todo el valor SEO.
- Renderizado híbrido: Usar el CMS de Webflow para el contenido principal de la página y el fetching del lado del cliente para datos dinámicos complementarios (productos relacionados, contenido específico del usuario, inventario en tiempo real).
- WordPress como fuente canónica con Webflow como capa de visualización: Para el contenido del blog específicamente, WordPress gestiona la URL canónica y el renderizado completo, mientras Webflow gestiona el sitio de marketing. Un patrón de subdominio (
blog.yourdomain.comen WordPress,yourdomain.comen Webflow) mantiene la arquitectura limpia.
Automatizando la Sincronización de Datos Entre Sistemas
Para proyectos donde el CMS de Webflow necesita mantenerse sincronizado con el contenido de WordPress, las herramientas de automatización eliminan el trabajo manual. Un plugin de WordPress con un webhook personalizado que se activa en save_post puede enviar el contenido actualizado a la API del CMS de Webflow cada vez que un editor publica o actualiza una publicación. Esto crea una sincronización casi en tiempo real sin requerir que el frontend realice llamadas a la API en el momento de carga de la página.
El script de sincronización gestiona el mapeo de campos entre el meta de publicaciones de WordPress y los campos del CMS de Webflow, la traducción de URLs de imágenes y la API de publicación de Webflow para activar una reconstrucción del sitio cuando el contenido cambia. Este es un trabajo de desarrollo personalizado — no existe un plugin listo para usar que gestione la sincronización completa de manera confiable para modelos de contenido complejos — pero el resultado es un sistema donde los equipos editoriales trabajan completamente en WordPress mientras el sitio público siempre está actualizado.
Rendimiento, Caché y Consideraciones de Infraestructura
Una arquitectura desacoplada introduce solicitudes de red adicionales y potencial latencia que un sitio monolítico tradicional de WordPress o Webflow no tiene. Lograr un buen rendimiento requiere decisiones deliberadas a nivel de infraestructura, no solo optimización de código.
Caché de la REST API de WordPress
Por defecto, las respuestas de la REST API de WordPress no se almacenan en caché. Cada solicitud impacta PHP y la base de datos. Con cualquier nivel de tráfico significativo, esto representa un problema. La solución es el caché de objetos a nivel de WordPress usando Redis o Memcached (disponible en hosts administrados como WP Engine, con quien werun.dev tiene alianza), combinado con caché basado en transients para consultas costosas.
function werun_get_featured_products( WP_REST_Request $request ) {
$limit = $request->get_param( 'limit' );
$cache_key = 'werun_featured_products_' . $limit;
$cached = get_transient( $cache_key );
if ( false !== $cached ) {
return rest_ensure_response( $cached );
}
// ... query logic ...
set_transient( $cache_key, $products, HOUR_IN_SECONDS );
return rest_ensure_response( $products );
}Para escenarios de alto tráfico, una capa CDN frente a la API de WordPress — Cloudflare con reglas de caché apropiadas, por ejemplo — puede servir respuestas de API en caché globalmente con latencia mínima, eliminando la base de datos por completo de la ruta crítica para endpoints con alta carga de lectura.
Configuración de CORS
Las páginas de Webflow se sirven desde el CDN de Webflow. La API de WordPress está alojada en un dominio separado. Esta configuración de origen cruzado requiere encabezados CORS correctos en el lado de WordPress, o el navegador bloqueará las solicitudes a la API por completo.
add_action( 'rest_api_init', function() {
remove_filter( 'rest_pre_serve_request', 'rest_send_cors_headers' );
add_filter( 'rest_pre_serve_request', function( $value ) {
$allowed_origins = array(
'https://www.yourdomain.com',
'https://yourdomain.webflow.io',
);
$origin = $_SERVER['HTTP_ORIGIN'] ?? '';
if ( in_array( $origin, $allowed_origins, true ) ) {
header( 'Access-Control-Allow-Origin: ' . $origin );
header( 'Access-Control-Allow-Methods: GET, POST, OPTIONS' );
header( 'Access-Control-Allow-Credentials: true' );
}
return $value;
} );
}, 15 );Esta configuración incluye en la lista blanca orígenes específicos en lugar de usar un comodín, lo cual es el enfoque correcto para cualquier API que sirva datos autenticados u opere en un entorno de producción.
Arquitectura de Hosting y Despliegue
El backend de WordPress en esta arquitectura debe tratarse como infraestructura, no simplemente como un sitio web. Necesita un tiempo de actividad confiable, tiempos de respuesta rápidos y un proceso de despliegue que no introduzca tiempo de inactividad durante las actualizaciones. El hosting administrado de WordPress — WP Engine o SiteGround, ambos partners de werun.dev — proporciona las optimizaciones a nivel de servidor, los entornos de staging y las copias de seguridad automatizadas que un backend headless requiere.
Para el código base de WordPress en sí, todos los plugins y temas personalizados deben estar versionados en Git y desplegados a través de un pipeline de CI/CD en lugar de hacerlo a través del administrador de WordPress o FTP manual. Esta es la práctica estándar en werun.dev: cada plugin se entrega con un repositorio en GitHub, y las actualizaciones se envían a través de GitHub releases con el sistema de actualización automática que garantiza que los sitios en producción reciban los cambios sin intervención manual.
Webflow gestiona su propio hosting y CDN, lo cual es una de las ventajas genuinas de esta arquitectura. La infraestructura del frontend está completamente administrada, distribuida globalmente y no requiere ningún trabajo de DevOps por parte del equipo de desarrollo. El esfuerzo de ingeniería se concentra completamente en el backend de WordPress y en la capa de integración entre los dos sistemas.