Caché de Página Completa con BunnyCDN para WordPress: Guía Completa de Configuración
Actualizado marzo 2026 14 min de lectura Equipo RemarkableCloud
Caché de página completa con BunnyCDN para WordPress: guía completa de configuración
El caché completo de HTML con BunnyCDN convierte tu sitio WordPress en una máquina de velocidad estática. Tus páginas se sirven directamente desde la red edge global de BunnyCDN, evitando tu servidor de origen en cada solicitud cacheada. El resultado: tiempos de carga dramáticamente más rápidos, menor carga del servidor, y un CDN que maneja los picos de tráfico sin tocar tu servidor.
Esta guía cubre la configuración completa: zona DNS, pull zone, SSL, integración con LiteSpeed Cache, y las 7 reglas de edge que hacen que el caché de página completa funcione correctamente sin romper los logins, el acceso al admin ni el contenido dinámico.
Qué necesitas antes de empezar
- Una cuenta de BunnyCDN: gratis en bunny.net
- Acceso a tu registrador de dominios (para actualizar los nameservers)
- El plugin LiteSpeed Cache instalado y activo en tu sitio WordPress
- La dirección IP de tu servidor de origen
Paso 1: Configura el DNS de BunnyCDN
El DNS de BunnyCDN es una red DNS anycast rápida. Usarlo junto a tu pull zone te da rendimiento de CDN y de DNS en un solo tablero. Este paso crea una zona DNS para tu dominio y actualiza tu registrador para apuntar a los nameservers de BunnyCDN.
1
Crea una zona DNS
En tu tablero de BunnyCDN, ve a DNS y haz clic en Add DNS Zone. Ingresa tu nombre de dominio (por ejemplo, ejemplo.com) y confirma. BunnyCDN te asigna dos nameservers: anótalos.
2
Actualiza los nameservers en tu registrador
Inicia sesión en tu registrador de dominios (GoDaddy, Namecheap, Cloudflare, etc.) y reemplaza los nameservers actuales con los dos servidores de BunnyDNS del paso 1. La propagación de DNS típicamente toma de 30 minutos a unas horas.
3
Agrega un registro A para tu origen
De vuelta en la zona DNS de BunnyCDN, agrega un registro A apuntando a la dirección IP de tu servidor de origen. Esto mantiene el acceso directo al servidor funcionando mientras configuras el CDN.

Creando una zona DNS en el tablero de BunnyCDN

BunnyCDN asigna dos nameservers: actualízalos en tu registrador

Zona DNS con registro A y registros CNAME configurados
Paso 2: Crea una pull zone
Una pull zone es lo que BunnyCDN usa para obtener y cachear tu contenido. La creas una vez, la apuntas a tu servidor de origen, y BunnyCDN maneja la entrega desde nodos edge en todo el mundo.
1
Agrega una pull zone
En BunnyCDN, ve a CDN y haz clic en Add Pull Zone. Dale un nombre descriptivo (el nombre de tu sitio funciona). BunnyCDN agrega .b-cdn.net automáticamente.
2
Configura el tipo de origen y la URL
Configura Origin Type como Origin URL e ingresa la URL de tu sitio (https://ejemplo.com). De aquí es donde BunnyCDN obtiene el contenido cuando el caché está frío.
3
Elige el Standard Tier
El Standard Tier cubre bien la mayoría de los sitios WordPress. Balancea cobertura global, velocidad y costo. Los sitios de alto volumen o los que requieren regiones específicas pueden evaluar el Volume Tier después.
4
Agrega un hostname personalizado
En Settings de la pull zone, bajo Custom Hostnames, agrega tu dominio (por ejemplo, www.ejemplo.com). Esto es lo que los visitantes ven realmente en la URL: no la dirección .b-cdn.net.
5
Crea un registro CNAME en el DNS de BunnyCDN
De vuelta en tu zona DNS, agrega un registro CNAME: nombre www (o tu subdominio), valor la dirección .b-cdn.net de tu pull zone. Esto enruta el tráfico de tu dominio a través del CDN.

Creando una pull zone nueva: configura el tipo de origen como Origin URL

Pull zone creada: anota el hostname .b-cdn.net para tu registro CNAME

Administración de la pull zone: agrega tu hostname personalizado aquí
Paso 3: Agrega los certificados SSL
BunnyCDN puede autogenerar un certificado SSL gratis para tu hostname personalizado, o puedes subir el tuyo.
1
Genera un certificado gratis
En tu pull zone, ve a Security y haz clic en la sección SSL. Haz clic en Generate Free Certificate. BunnyCDN emite un certificado de Let’s Encrypt automáticamente para tu hostname personalizado.
2
Habilita Force SSL
Una vez que el certificado esté activo, habilita Force SSL en el mismo panel de Security. Esto asegura que todo el tráfico HTTP redirija a HTTPS en el edge del CDN antes de siquiera llegar a tu servidor.
3
Habilita HSTS (opcional)
Para seguridad adicional, habilita HSTS (HTTP Strict Transport Security). Esto le indica a los navegadores usar siempre HTTPS para tu dominio. Habilítalo solo después de confirmar que HTTPS funciona por completo.

Ajustes de SSL en la pull zone: genera el certificado gratis y habilita Force SSL
Paso 4: Configura LiteSpeed Cache para BunnyCDN
LiteSpeed Cache tiene integración nativa con BunnyCDN. Conectar los dos significa que LiteSpeed puede purgar el caché del CDN automáticamente cuando publicas o actualizas contenido.
1
Obtén tu clave API de BunnyCDN y el ID de la pull zone
En BunnyCDN, ve a Account Settings para encontrar tu clave API. El ID de tu pull zone está en la URL de la pull zone (bunny.net/cdn/pullzone/[ID]).
2
Configura en LiteSpeed Cache
En WordPress, ve a los ajustes de LiteSpeed Cache, luego CDN. Habilita CDN, configura CDN Type como BunnyCDN, e ingresa tu clave API y el ID de la pull zone. LiteSpeed verificará la conexión.
3
Configura la URL del CDN
En los ajustes de CDN de LiteSpeed Cache, configura la CDN URL con tu hostname personalizado de BunnyCDN (por ejemplo, https://www.ejemplo.com o tu subdominio de CDN). Los assets estáticos: imágenes, CSS, JS: se servirán desde la URL del CDN.
Paso 5: Afina los ajustes de caché
Antes de agregar las reglas de edge, deja bien la configuración básica de caché en los ajustes de la pull zone de BunnyCDN.
- Browser Cache TTL: Configúralo a 30 días (2592000 segundos) para los assets estáticos. Los navegadores los cachean localmente y evitan volver a pedirlos en las visitas de retorno.
- Origin Cache TTL: Configúralo a 1 día (86400 segundos) para las páginas HTML. Esto se sobreescribe por ruta con tus reglas de edge.
- Vary Cache: Habilita Vary Cache by Cookie si tu sitio sirve contenido distinto a usuarios con sesión. Esto evita que páginas cacheadas de usuarios con sesión se sirvan a los invitados.
- Ignore Query Strings: Deshabilítalo: WordPress usa query strings para romper caché (por ejemplo, ?ver=6.4). Ignorarlas serviría CSS y JS viejos.
- Habilita Gzip/Brotli: Habilita ambos. BunnyCDN comprime las respuestas en el edge antes de entregarlas, reduciendo el tamaño de transferencia 60-80% para contenido de texto.

Ajustes de caché de la pull zone: TTL, Vary Cache y opciones de compresión
Paso 6: Las 7 reglas de edge para el caché de página completa
Las reglas de edge son donde el caché completo de HTML se configura en realidad. Estas 7 reglas trabajan juntas: las reglas 1 y 2 aplican URLs canónicas, la regla 3 evita el caché para las rutas sensibles, las reglas 4 y 5 ponen TTLs largos a los assets estáticos, y las reglas 6 y 7 controlan el caché del lado del navegador. Aplícalas en este orden.

Panel de reglas de edge en BunnyCDN: agrega cada regla en orden

Configurando condiciones y acciones de una regla de edge individual
Caché de HTML
Regla 1: Set Canonical Header (aplicar HTTPS + www)
Asegura que cada página se sirva con una URL canónica consistente, evitando problemas de contenido duplicado a nivel de CDN.
Condición: Hostname no coincide con www.ejemplo.com
Acción: Redirect URL a https://www.ejemplo.com{Path}{QueryString} con estado 301
Reemplaza ejemplo.com con tu dominio real en todas las reglas de edge.
Caché de HTML
Regla 2: Set www Redirect (unificar la estructura de URL)
Redirige el tráfico sin www hacia www en el edge, antes de que llegue a tu servidor de origen. Consistente con la Regla 1 pero atrapa variaciones adicionales de URL.
Condición: Request URL coincide con ^http://ejemplo.com/ (regex)
Acción: Redirect URL a https://www.ejemplo.com{Path}{QueryString} con estado 301
Evitar caché
Regla 3: Deshabilitar el caché para las áreas sensibles
Evita el caché del CDN para el admin de WordPress, el login, el checkout, el carrito y cualquier ruta que nunca deba servir respuestas cacheadas. Esta es la regla más importante: hazla mal y las sesiones de admin con sesión sirven páginas cacheadas.
Condición: Cualquiera de las siguientes rutas de URL coincide:
/wp-admin/* /wp-login.php /cart/* /checkout/* /my-account/* /wp-cron.php /xmlrpc.php
Acción: Override Cache Time = 0 (no cachear)
Agrega cualquier otra ruta que sea específica de usuario o dependiente de sesión. Los sitios WooCommerce también deberían agregar /store/* y las rutas de cualquier plugin de carrito o lista de deseos.
Assets estáticos
Regla 4: Caché de servidor para CSS y JS (TTL largo)
Pone un TTL largo de caché del lado del servidor para los archivos CSS y JavaScript. Cambian con poca frecuencia y deberían cachearse agresivamente en el edge.
Condición: Extension coincide con css O js
Acción: Override Cache Time = 2592000 (30 días en segundos)
Assets estáticos
Regla 5: Caché de servidor para imágenes, videos y fuentes
Pone un TTL de caché del lado del servidor aún más largo para los archivos multimedia. Las imágenes y las fuentes rara vez cambian y se benefician del caché extendido en el edge.
Condición: Extension coincide con jpg O jpeg O png O gif O webp O svg O woff O woff2 O mp4
Acción: Override Cache Time = 31536000 (1 año en segundos)
Caché del navegador
Regla 6: Encabezados de caché del navegador para CSS y JS
Configura encabezados Cache-Control que le indican a los navegadores cachear el CSS y el JS localmente. Los visitantes que regresan a tu sitio se saltan la re-descarga de esos archivos en cada carga de página.
Condición: Extension coincide con css O js
Acción: Set Response Header = Cache-Control: public, max-age=2592000, immutable
Caché del navegador
Regla 7: Sobreescribir el caché del navegador para archivos estáticos
Aplica encabezados de caché del navegador consistentes a todos los tipos de assets estáticos, asegurando que las imágenes, las fuentes y los archivos multimedia se cacheen en el navegador entre sesiones.
Condición: Extension coincide con jpg O jpeg O png O gif O webp O svg O woff O woff2
Acción: Set Response Header = Cache-Control: public, max-age=31536000, immutable
Paso 7: Verifica la configuración
Una vez guardadas todas las reglas, prueba el caché antes de darlo por terminado.
Prueba con curl
La forma más rápida de confirmar que BunnyCDN está sirviendo respuestas cacheadas es revisar los encabezados de respuesta. Busca x-bunny-cache: HIT en las solicitudes repetidas:
curl -I https://www.ejemplo.com
En la primera solicitud verás x-bunny-cache: MISS (obteniendo del origen). En la segunda solicitud a la misma URL deberías ver x-bunny-cache: HIT (servida desde el edge). Si sigues viendo MISS después de múltiples solicitudes, revisa que la Regla 3 no esté empatando de más tus rutas.
Prueba con tu navegador
Abre las DevTools (F12), ve a la pestaña Network y recarga tu página de inicio. Revisa los encabezados de respuesta en la solicitud del documento HTML. Busca el encabezado x-bunny-cache y confirma que la URL del CDN está sirviendo tus assets (imágenes, CSS, JS deberían mostrar tu hostname de CDN en el initiator).
Prueba el acceso al admin
Inicia sesión en el admin de WordPress y confirma que el tablero carga correctamente. Si la Regla 3 está bien configurada, /wp-admin/* debería evitar el caché por completo y deberías ver una interfaz de admin fresca y funcional. Si ves una página vieja o te saca la sesión, revisa el matching de rutas de la Regla 3.
Prueba una vista de página con sesión
Inicia sesión como usuario normal y navega el front-end. La barra de herramientas debería aparecer. Si a un usuario con sesión se le sirve una página cacheada sin la barra, tu ajuste de Vary Cache by Cookie no está activo o el nombre de tu cookie de login no está bien configurado.
Correr esto en un VPS administrado de RemarkableCloud significa que LiteSpeed viene preconfigurado y el caché de BunnyCDN se purga al publicar automáticamente. El lado del servidor se maneja solo.
Un sitio WordPress rápido empieza con un servidor rápido y administrado
El VPS administrado de RemarkableCloud incluye LiteSpeed, monitoreo proactivo, respaldos diarios y una pasarela de correo gratis en cada plan. BunnyCDN maneja el edge; nosotros manejamos todo lo de abajo.
Ver planes de VPS administrado
Sin contratos · Migración gratuita · SLA del 500%
Preguntas frecuentes
¿El caché de página completa con BunnyCDN funciona con WooCommerce?
Sí, con una configuración cuidadosa de las reglas de edge. La Regla 3 debe evitar el caché para /cart/*, /checkout/* y /my-account/* como mínimo. WooCommerce también pone cookies (woocommerce_cart_hash, wp_woocommerce_session) que indican un carrito con contenido: configura Vary Cache by Cookie para servir respuestas sin caché a los usuarios con esas cookies activas. Prueba el flujo de checkout a fondo después de la configuración.
¿Cuál es la diferencia entre la pull zone de BunnyCDN y un proxy inverso?
Una pull zone obtiene el contenido de tu origen y lo cachea en el edge de BunnyCDN. Los visitantes piden el contenido al nodo edge más cercano, no a tu servidor. Un proxy inverso pasa todas las solicitudes hacia tu origen (con caché opcional). La pull zone de BunnyCDN es una arquitectura de CDN: es más efectiva para el contenido que puede cachearse, como los assets estáticos y las páginas HTML completas. El contenido dinámico y específico de usuario evita el caché vía tus reglas de edge.
¿Cómo limpio el caché de BunnyCDN después de publicar contenido nuevo?
Si conectaste LiteSpeed Cache con BunnyCDN usando tu clave API y el ID de la pull zone, las purgas de caché ocurren automáticamente cuando publicas o actualizas contenido. Para purgas manuales, ve a tu pull zone en el tablero de BunnyCDN y haz clic en Purge Cache. Puedes purgar por URL (una sola página) o purgar la zona entera. Purgar la zona completa es rápido pero úsalo con moderación en sitios de alto tráfico: una purga total significa que tu origen sirve todas las solicitudes mientras el edge se rellena.
¿Por qué mi caché muestra MISS en cada solicitud?
Un MISS persistente usualmente significa una de tres cosas: la Regla 3 está empatando demasiado amplio y evitando el caché para todas las rutas, tu origen está enviando encabezados Cache-Control: no-cache o no-store (BunnyCDN los respeta), o las cookies están activando el Vary Cache y cada solicitud se trata como única. Revisa los encabezados Cache-Control de respuesta de tu origen con curl -I y busca encabezados que impidan el caché. Los ajustes de CDN de LiteSpeed Cache deberían estar configurados para enviar encabezados cacheables en las páginas del front-end.
¿BunnyCDN funciona con la función de CDN integrada de LiteSpeed Cache?
Sí. LiteSpeed Cache tiene una integración dedicada de BunnyCDN en sus ajustes de CDN. Ingresa tu clave API de BunnyCDN y el ID de la pull zone y LiteSpeed Cache maneja la purga automática al publicar, actualizar o limpiar el caché manualmente. Esta es la forma recomendada de integrar los dos en un servidor con LiteSpeed: te da caché a nivel de servidor más caché de edge del CDN trabajando juntos.