bunnycdn wordpress
Actualizado en marzo de 2026 14 min de lectura Equipo de RemarkableCloud

Caché de página completa con BunnyCDN para WordPress: guía de configuración completa

El caché HTML completo con BunnyCDN convierte tu sitio WordPress en una máquina de velocidad estática. Tus páginas se sirven directamente desde la red global de edge de BunnyCDN, sin pasar por tu servidor de origen en cada solicitud cacheada. El resultado: tiempos de carga notablemente más rápidos, menor carga en el servidor y un CDN que gestiona 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 funcionar el caché de página completa correctamente sin romper los inicios de sesión, el acceso al admin ni el contenido dinámico.

Lo que necesitas antes de empezar
  • Una cuenta de BunnyCDN — gratuita en bunny.net
  • Acceso a tu registrador de dominio (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 de alto rendimiento. Usarlo junto con tu pull zone te ofrece rendimiento de CDN y DNS en un mismo panel. 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 panel de BunnyCDN, ve a DNS y haz clic en Add DNS Zone. Introduce tu nombre de dominio (p. ej., example.com) y confirma. BunnyCDN te asignará dos nameservers — anótalos.
2
Actualiza los nameservers de tu registrador
Inicia sesión en tu registrador de dominio (GoDaddy, Namecheap, Cloudflare, etc.) y reemplaza los nameservers actuales por los dos servidores BunnyDNS del paso 1. La propagación del DNS suele tardar entre 30 minutos y unas pocas horas.
3
Añade un registro A para tu origen
De vuelta en la zona DNS de BunnyCDN, añade un registro A que apunte a la dirección IP de tu servidor de origen. Esto mantiene el acceso directo al servidor mientras configuras el CDN.
Panel de creación de zona DNS en BunnyCDN

Creando una zona DNS en el panel de BunnyCDN

Nameservers de BunnyCDN DNS asignados al dominio

BunnyCDN asigna dos nameservers — actualízalos en tu registrador

Gestión de registros DNS en BunnyCDN

Zona DNS con registros A y 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 gestiona la entrega desde nodos de edge en todo el mundo.

1
Añade 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 bien). BunnyCDN añade .b-cdn.net automáticamente.
2
Define el tipo de origen y la URL
Establece el tipo de origen como Origin URL e introduce la URL de tu sitio (https://example.com). Es desde aquí donde BunnyCDN obtiene el contenido cuando el caché está vacío.
3
Elige el Standard Tier
El Standard Tier cubre la mayoría de los sitios WordPress de forma óptima. Equilibra cobertura global, velocidad y costo. Los sitios de alto volumen o con requisitos de regiones específicas pueden evaluar el Volume Tier más adelante.
4
Añade un hostname personalizado
En la configuración de la pull zone, bajo Custom Hostnames, añade tu dominio (p. ej., www.example.com). Esto es lo que los visitantes ven 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, añade un registro CNAME: nombre www (o tu subdominio), el valor es la dirección .b-cdn.net de tu pull zone. Esto enruta el tráfico de tu dominio a través del CDN.
Añadiendo una pull zone en BunnyCDN

Creando una nueva pull zone — define el tipo de origen como Origin URL

Instrucciones de configuración de la pull zone en BunnyCDN

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

Gestión de la configuración de la pull zone en BunnyCDN

Gestión de la pull zone — añade tu hostname personalizado aquí

Paso 3: Añade certificados SSL

BunnyCDN puede generar automáticamente un certificado SSL gratuito para tu hostname personalizado, o puedes cargar el tuyo propio.

1
Genera un certificado gratuito
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 Let's Encrypt automáticamente para tu hostname personalizado.
2
Activa Force SSL
Una vez que el certificado esté activo, habilita Force SSL en el mismo panel de Security. Esto garantiza que todo el tráfico HTTP se redirija a HTTPS en el edge del CDN antes de llegar a tu servidor.
3
Activa HSTS (opcional)
Para mayor seguridad, habilita HSTS (HTTP Strict Transport Security). Esto indica a los navegadores que siempre usen HTTPS para tu dominio. Actívalo solo después de confirmar que HTTPS funciona correctamente.
Configuración del certificado SSL en la pull zone de BunnyCDN

Ajustes SSL en la pull zone — genera el certificado gratuito y habilita Force SSL

Paso 4: Configura LiteSpeed Cache para BunnyCDN

LiteSpeed Cache tiene integración nativa con BunnyCDN. Conectar ambos permite que LiteSpeed purgue el caché del CDN automáticamente cuando publicas o actualizas contenido.

1
Obtén tu API key de BunnyCDN y el ID de la pull zone
En BunnyCDN, ve a Account Settings para encontrar tu API key. 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 la configuración de LiteSpeed Cache, luego a CDN. Habilita CDN, establece el CDN Type como BunnyCDN e introduce tu API key y el ID de la pull zone. LiteSpeed verificará la conexión.
3
Define la CDN URL
En la configuración de CDN de LiteSpeed Cache, establece la CDN URL como tu hostname personalizado de BunnyCDN (p. ej., https://www.example.com o tu subdominio de CDN). Los recursos estáticos — imágenes, CSS, JS — se servirán desde la CDN URL.

Paso 5: Ajusta la configuración de caché

Antes de añadir reglas de edge, configura correctamente el caché básico en los ajustes de la pull zone de BunnyCDN.

  • Browser Cache TTL: Establécelo en 30 días (2592000 segundos) para recursos estáticos. Los navegadores los cachean localmente y evitan volver a solicitarlos en visitas posteriores.
  • Origin Cache TTL: Establécelo en 1 día (86400 segundos) para páginas HTML. Las reglas de edge lo sobreescriben por ruta.
  • Vary Cache: Habilita Vary Cache by Cookie si tu sitio sirve contenido diferente a usuarios que han iniciado sesión. Esto evita que las páginas cacheadas de usuarios autenticados se sirvan a visitantes.
  • Ignore Query Strings: Desactívalo — WordPress usa query strings para el cache-busting (p. ej., ?ver=6.4). Ignorarlas serviría CSS y JS desactualizados.
  • Activa Gzip/Brotli: Habilita ambos. BunnyCDN comprime las respuestas en el edge antes de la entrega, reduciendo el tamaño de transferencia entre un 60-80% para contenido de texto.
Configuración de caché en BunnyCDN

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 se configura realmente el caché HTML de página completa. Estas 7 reglas funcionan en conjunto: las reglas 1 y 2 aplican URLs canónicas, la regla 3 omite el caché para rutas sensibles, las reglas 4 y 5 establecen TTLs largos en recursos estáticos, y las reglas 6 y 7 controlan el caché del lado del navegador. Aplícalas en este orden.

Configuración de reglas de edge en BunnyCDN

Panel de reglas de edge en BunnyCDN — añade cada regla en orden

Condiciones y acciones de una regla de edge en BunnyCDN

Configuración de condiciones y acciones para una regla de edge individual

Caché HTML
Regla 1: Establecer Canonical Header (aplicar HTTPS + www)

Garantiza que cada página se sirva con una URL canónica consistente, evitando problemas de contenido duplicado en el nivel del CDN.

Condición: El Hostname no coincide con www.example.com
Acción: Redirigir URL a https://www.example.com{Path}{QueryString} con estado 301

Reemplaza example.com con tu dominio real en todas las reglas de edge.
Caché HTML
Regla 2: Establecer redirección www (simplificar la estructura de URL)

Redirige el tráfico sin www hacia www en el edge, antes de que llegue a tu servidor de origen. Es consistente con la Regla 1 pero captura variaciones adicionales de URL.

Condición: La URL de solicitud coincide con ^http://example.com/ (regex)
Acción: Redirigir URL a https://www.example.com{Path}{QueryString} con estado 301

Omitir Caché
Regla 3: Deshabilitar el caché para áreas sensibles

Omite el caché del CDN para el admin de WordPress, el inicio de sesión, el checkout, el carrito y cualquier ruta que nunca deba servir respuestas cacheadas. Esta es la regla más importante — si se configura mal, las sesiones de admin autenticadas sirven páginas cacheadas.

Condición: Cualquiera de las siguientes rutas URL coincide:

/wp-admin/* /wp-login.php /cart/* /checkout/* /my-account/* /wp-cron.php /xmlrpc.php

Acción: Override Cache Time = 0 (no cachear)

Añade cualquier otra ruta que sea específica del usuario o dependiente de la sesión. Los sitios WooCommerce también deben añadir /store/* y las rutas de plugins de carrito o lista de deseos.
Recursos Estáticos
Regla 4: Caché de servidor para CSS y JS (TTL largo)

Establece un TTL de caché largo en el servidor para archivos CSS y JavaScript. Estos cambian con poca frecuencia y deben cachearse de forma agresiva en el edge.

Condición: La extensión coincide con css O js
Acción: Override Cache Time = 2592000 (30 días en segundos)

Recursos Estáticos
Regla 5: Caché de servidor para imágenes, videos y fuentes

Establece un TTL de caché aún más largo en el servidor para archivos multimedia. Las imágenes y fuentes rara vez cambian y se benefician de un caché extendido en el edge.

Condición: La extensión 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: Headers de caché del navegador para CSS y JS

Establece headers Cache-Control que instruyen a los navegadores a cachear CSS y JS localmente. Los visitantes que regresan a tu sitio evitan volver a descargar estos archivos en cada carga de página.

Condición: La extensión coincide con css O js
Acción: Establecer Response Header = Cache-Control: public, max-age=2592000, immutable

Caché del Navegador
Regla 7: Sobreescribir caché del navegador para archivos estáticos

Aplica headers de caché del navegador consistentes a todos los tipos de recursos estáticos, asegurando que las imágenes, fuentes y archivos multimedia sean cacheados por el navegador entre sesiones.

Condición: La extensión coincide con jpg O jpeg O png O gif O webp O svg O woff O woff2
Acción: Establecer 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 headers de respuesta. Busca x-bunny-cache: HIT en solicitudes repetidas:

curl -I https://www.example.com

En la primera solicitud verás x-bunny-cache: MISS (obteniendo desde el origen). En la segunda solicitud a la misma URL deberías ver x-bunny-cache: HIT (servido desde el edge). Si sigues viendo MISS tras múltiples solicitudes, verifica que la Regla 3 no esté aplicando una coincidencia demasiado amplia en tus rutas.

Prueba con tu navegador

Abre DevTools (F12), ve a la pestaña Network y recarga tu página principal. Revisa los headers de respuesta en la solicitud del documento HTML. Busca el header x-bunny-cache y confirma que la CDN URL está sirviendo tus recursos (las imágenes, CSS y JS deben mostrar tu hostname del CDN en el initiator).

Prueba el acceso al admin

Inicia sesión en el admin de WordPress y confirma que el panel carga correctamente. Si la Regla 3 está bien configurada, /wp-admin/* debe omitir el caché por completo y deberías ver una interfaz de administración funcional y actualizada. Si ves una página desactualizada o te desconecta, revisa la coincidencia de rutas en la Regla 3.

Prueba una vista de página con sesión iniciada

Inicia sesión como usuario regular y navega por el frontend. La barra de herramientas debería aparecer. Si se sirve una página cacheada a un usuario autenticado sin la barra de herramientas, el ajuste Vary Cache by Cookie no está activo o el nombre de la cookie de inicio de sesión no está configurado correctamente.

Ejecutar esto en un VPS administrado de RemarkableCloud significa que LiteSpeed está preconfigurado y las purgas de caché de BunnyCDN ocurren automáticamente al publicar. El lado del servidor se gestiona solo.

Ver qué está incluido →

Un sitio WordPress rápido empieza con un servidor rápido y administrado

El VPS administrado de RemarkableCloud incluye LiteSpeed, monitoreo proactivo, backup diario y un gateway de correo gratuito en todos los planes. BunnyCDN se encarga del edge; nosotros nos encargamos de todo lo demás. Desde $2 tu primer mes.

Ver planes de VPS administrado
Sin contratos · Migración gratuita · SLA 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 omitir el caché para /cart/*, /checkout/* y /my-account/* como mínimo. WooCommerce también establece cookies (woocommerce_cart_hash, wp_woocommerce_session) que indican un carrito no vacío — configura Vary Cache by Cookie para servir respuestas sin caché a usuarios con estas cookies activas. Prueba el flujo de checkout a fondo después de la configuración.
¿Cuál es la diferencia entre una pull zone de BunnyCDN y un reverse proxy?
Una pull zone obtiene contenido de tu origen y lo cachea en el edge de BunnyCDN. Los visitantes solicitan el contenido desde el nodo de edge más cercano, no desde tu servidor. Un reverse proxy pasa todas las solicitudes a tu origen (con caché opcional). La pull zone de BunnyCDN es una arquitectura CDN — es más efectiva para contenido que puede cachearse, como recursos estáticos y páginas HTML completas. El contenido dinámico y específico del usuario omite el caché mediante tus reglas de edge.
¿Cómo limpio el caché de BunnyCDN después de publicar contenido nuevo?
Si has conectado LiteSpeed Cache a BunnyCDN usando tu API key y el ID de la pull zone, las purgas de caché ocurren automáticamente al publicar o actualizar contenido. Para purgas manuales, ve a tu pull zone en el panel de BunnyCDN y haz clic en Purge Cache. Puedes purgar por URL (una página) o purgar toda la zona. Purgar la zona completa es rápido, pero úsalo con moderación en sitios de alto tráfico — una purga total hace que tu origen sirva todas las solicitudes mientras el edge se recarga.
¿Por qué mi caché muestra MISS en cada solicitud?
Un MISS de caché persistente suele deberse a una de tres causas: la Regla 3 está aplicando una coincidencia demasiado amplia y omite el caché para todas las rutas, tu origen está enviando headers Cache-Control: no-cache o no-store (BunnyCDN los respeta), o las cookies están activando Vary Cache y cada solicitud se trata como única. Revisa los headers Cache-Control de respuesta de tu origen con curl -I y busca headers que impidan el caché. Los ajustes de CDN en LiteSpeed Cache deben estar configurados para enviar headers cacheables para las páginas del frontend.
¿BunnyCDN funciona con la función CDN integrada de LiteSpeed Cache?
Sí. LiteSpeed Cache tiene una integración dedicada con BunnyCDN en sus ajustes de CDN. Introduce tu API key de BunnyCDN y el ID de la pull zone, y LiteSpeed Cache gestiona la purga automática al publicar, actualizar o limpiar la caché manualmente. Esta es la forma recomendada de integrar ambos en un servidor con LiteSpeed — te ofrece caché a nivel de servidor más caché de edge del CDN trabajando juntos.

Tabla de contenidos

vibe-coding
Articles
Remarkable-Guille
Cómo hacer vibe coding en proyectos complejos para principiantes

El vibe coding colapsa en el momento en que pides la segunda funcionalidad. El código se contradice, nada está documentado, la IA olvidó lo que construyó en la sesión anterior. Pero no tiene por qué funcionar así. Existe un método para desarrollar software genuinamente complejo con la IA como motor, donde el resultado es de nivel productivo y mantenible, sin necesidad de ser programador. Requiere tres roles separados (un arquitecto que planifica, un coder que ejecuta y un repositorio que registra todo), seis documentos que sobreviven a cualquier sesión de chat individual, e instrucciones de salida de emergencia que convierten las suposiciones silenciosas de la IA en decisiones que tú tomas. Este es el método completo.

Read More »
plugin de traducción WordPress multilingüe SEO
Articles
Remarkable-Guille
Por qué tu plugin de traducción podría estar destruyendo tu SEO en silencio (lo descubrimos en nuestro propio sitio)

Durante meses, nuestro tráfico multilingüe había estado cayendo en silencio. Lo atribuimos a la estacionalidad. A los cambios en el algoritmo de Google. Al mercado. Ninguna de esas era la respuesta. Cuando finalmente auditamos nuestra propia configuración multilingüe, encontramos cinco problemas específicos que nuestro plugin de traducción había estado causando silenciosamente en cada página traducida del sitio: nombres de marca apareciendo traducidos en los datos estructurados, declaraciones hreflang duplicadas y rotas, páginas de inicio traducidas marcadas como Article en lugar de Website, inconsistencia en barras finales que dividía la autoridad de las URLs, y enlaces de migas de pan que enviaban a los visitantes al idioma incorrecto. Llevamos 25 años gestionando sitios web y aun así nos pasamos los cinco por alto. Porque el daño está en las partes de la página que los visitantes nunca ven. Aquí te explicamos exactamente qué revisar en tu propio sitio en 15 minutos, sin más herramientas que un navegador y ver-código-fuente.

Read More »
Seguridad de cPanel
Articles
Remarkable-Guille
Vulnerabilidad crítica de omisión de autenticación en cPanel: qué ocurrió, qué significa y cómo respondió RemarkableCloud

A las 19:39 UTC del 28 de abril de 2026, cPanel publicó un aviso crítico que revela una omisión de autenticación que afecta a todas las versiones con soporte activo. No hay parche disponible. El proveedor recomienda dos mitigaciones: bloquear los puertos de cPanel Y deshabilitar los Subdominios de Servicio. La mayoría de la cobertura pública solo mencionó la primera. La ruta del subdominio proxy corre a través de Apache en el puerto 443 y accede al mismo código vulnerable independientemente de las reglas del firewall. Este artículo explica por qué ambas mitigaciones son necesarias, el plan de mitigación completo y cómo RemarkableCloud protegió a todos sus clientes en minutos sin que ninguno tuviera que hacer nada.

Read More »
entregabilidad de correo SPF DKIM DMARC
Articles
Remarkable-Guille
Entregabilidad del correo explicada: SPF, DKIM, DMARC, y por qué la reputación de tu servidor importa más que tu contenido

La mayoría de las decisiones sobre entregabilidad del correo ocurren antes de que se lea una sola palabra de tu mensaje: suceden en la capa de autenticación del servidor, donde los servidores de correo receptores deciden si tu servidor de envío es confiable. SPF, DKIM y DMARC son los tres registros DNS que gobiernan esa decisión. Pero incluso con los tres superando la verificación, una IP de salida compartida en lista negra por un vecino puede arruinar tu entregabilidad. Este artículo explica qué hace cada registro, por qué la reputación de IP importa tanto como la autenticación, y qué incluye RemarkableCloud en cada Cloud Cube: MailChannels como SMTP de salida, antispam colaborativo de entrada, y SPF, DKIM y DMARC configurados por defecto para cada dominio.

Read More »
Facebook
Twitter
LinkedIn