Por qué Cloudflare no cachea HTML en plan Free
Cloudflare no cachea HTML por defecto, y eso incluye el plan Free aunque tengas configurado Cache-Control: s-maxage=31536000 en el origen. Cache Rules te deja crear reglas, Edge TTL, Browser TTL, filtros por path, todo prolijo, y aún así Cloudflare sigue tirando cada request al servidor. La solución está en Page Rules con “Cache Level: Cache Everything”, y tarda 10 segundos en activarse.
En 30 segundos
- Cloudflare excluye HTML y JSON del caché por defecto en todos los planes, incluido Free, sin importar los headers del origen.
- Cache Rules (la herramienta nueva) no cachea HTML en el plan Free aunque configures Edge Cache TTL: el comportamiento por defecto de no cachear HTML tiene más precedencia.
- Page Rules con “Cache Level: Cache Everything” sí funciona y en el caso real de DooDoo.Love bajó el TTFB de 660ms a 210ms (68% de reducción) en 10 segundos.
- Google indexó solo el 18.6% de 6.725 URLs de ese sitio porque Googlebot pagaba TTFB completo desde el origen en cada región, consumiendo crawl budget en overhead de protocolo.
- Page Rules está marcada como “legacy” pero sigue funcionando y, por ahora, es la única forma efectiva de cachear HTML en el plan Free.
Cloudflare es una plataforma de red de distribución de contenidos (CDN) y servicios de seguridad web desarrollada por Cloudflare Inc. Proporciona caché, protección contra ataques DDoS y optimización de rendimiento para sitios web.
El problema: por qué Cloudflare no cachea HTML
Cloudflare Cache es un sistema de CDN proxy reverso que almacena copias de los recursos de tu servidor para servirlos desde sus edge nodes, reduciendo latencia y carga en el origen. El punto clave, que la documentación oficial menciona pero no enfatiza suficiente, es que por defecto Cloudflare solo cachea recursos estáticos: imágenes, CSS, JS, fuentes, PDFs. HTML y JSON quedan explícitamente excluidos del comportamiento de caché automático, sin importar lo que diga el header Cache-Control de tu servidor.
El equipo de DooDoo.Love lo descubrió de la peor manera. Tienen un portal de juegos HTML5 con 6.800 páginas detrás de Cloudflare en el plan Free. La auditoría SEO les mostró que Google había indexado solo 1.250 de sus 6.725 URLs del sitemap (18.6%) y que el origen devolvía Cache-Control: s-maxage=31536000 sin que Cloudflare lo respetara. El header estaba ahí. Cloudflare lo ignoraba.
Noventa minutos de debugging después, con outputs de curl que mostraban consistentemente cf-cache-status: DYNAMIC (es decir, nunca cacheado), quedó claro que el problema no era la configuración: era el diseño del sistema.
Limitaciones del plan Free con Cache Rules
Cache Rules es la herramienta moderna de Cloudflare para gestionar el caché, y tiene bastante potencial: podés crear expresiones con matching por path, hostname, cookies, headers, métodos HTTP. En el plan Free el TTL mínimo por Edge es 2 horas y el tamaño máximo de archivo cacheado es 512MB, lo que está bien para la mayoría de los casos.
El problema específico es este: aunque configures en Cache Rules una regla con “Eligible for cache: yes” y un Edge Cache TTL para todos tus paths HTML, el comportamiento por defecto de Cloudflare de excluir HTML tiene más precedencia que esa configuración en el plan Free. Configurás Edge TTL, Browser TTL, expresiones que cubren ocho patrones de path distintos, y Cloudflare igual responde cf-cache-status: DYNAMIC.
¿Por qué pasa esto? La documentación de Cache Rules explica que las reglas de caché se aplican a contenido “eligible for cache”, pero no documenta de forma prominente que HTML sigue siendo considerado “non-cacheable” por defecto en el plan Free incluso cuando la regla lo marque como elegible. El comportamiento varía según el plan: en planes pagos (Pro, Business, Enterprise) hay más control sobre esta precedencia.
Page Rules: la solución que sí funciona
Page Rules es la herramienta “legacy” de Cloudflare (la están deprecando gradualmente a favor de Cache Rules, Redirect Rules, y otras), pero tiene un comportamiento diferente cuando configurás “Cache Level: Cache Everything”: cachea todo, incluido HTML, sin que el comportamiento por defecto de exclusión interfiera. Más contexto en optimización SEO en sitios multiidioma.
La configuración es directa. Vas a Page Rules en el dashboard, creás una nueva regla con el patrón de URL que querés cubrir (por ejemplo, tudominio.com/*), seleccionás “Cache Level” y elegís “Cache Everything”. Guardás. En el caso de DooDoo.Love, a los 10 segundos el segundo request ya mostraba age: 1 en los headers, confirmando que el caché estaba activo.
El impacto fue inmediato: TTFB bajó de 660ms a 210ms en conexiones keep-alive, una reducción del 68%. En conexiones frías desde regiones lejanas, el delta es mayor (desde Tokyo el TTFB al origen era de 1.800ms, según el reporte del equipo).
Eso sí: si usás esta configuración con wildcard, acordate de excluir rutas sensibles. /login, /admin, /checkout, /cart, cualquier path con contenido personalizado por usuario. Si cacheás esas páginas, el usuario A puede ver la sesión del usuario B. No es un escenario hipotético.
Impacto en SEO y crawl budget de Google
El TTFB no es solo un número de performance. Googlebot tiene un crawl budget finito para cada sitio, y cuando paga latencia completa de origen en cada request, ese presupuesto se gasta en overhead de protocolo en lugar de en páginas nuevas.
El caso de DooDoo.Love lo ilustra con datos concretos: Googlebot llegaba desde Tokyo con 1.800ms de TTFB solo para empezar a recibir HTML. Con un portal de 6.800 páginas, eso significa que Google estaba descartando la mayoría de las URLs por tiempo de respuesta. El resultado: 18.6% de indexación (1.250 de 6.725 URLs del sitemap). Complementá con caching efectivo para tiendas WooCommerce.
Con HTML cacheado en el edge, Googlebot recibe respuesta desde el nodo de Cloudflare más cercano a su crawler. El TTFB baja a 150-210ms dependiendo de la región. Ese delta multiplica la cantidad de páginas que Google puede crawlear en el mismo presupuesto.
¿Cuánto mejora la indexación con esto? Todavía no hay datos definitivos del caso DooDoo.Love post-implementación (el artículo fue publicado el 7 de mayo de 2026 y los efectos de indexación tardan semanas en verse), pero la lógica es sólida y documentada por el propio equipo de Search de Google: crawl speed y TTFB afectan directamente el crawl rate.
Métricas de rendimiento reales: TTFB antes y después
Los números que reportó el equipo de DooDoo.Love, con outputs reales de curl:
- TTFB con Cache Rules (no cacheando HTML): 660ms en keep-alive, ~1.800ms desde regiones remotas como Tokyo
- TTFB con Page Rules + Cache Everything: 210ms en keep-alive, reducción del 68%
- Tiempo para ver el efecto: 10 segundos después de guardar la Page Rule
- Indicador de confirmación: header
age:incrementando en requests sucesivos (si age está en 0 siempre, el caché no funciona)
El header cf-cache-status es tu mejor diagnóstico. Los valores que vas a ver:
HIT: sirvió desde caché de Cloudflare, perfectoMISS: fue al origen pero va a cachear la respuestaDYNAMIC: no está cacheando, nunca va a cachear con la configuración actualBYPASS: las reglas le indicaron explícitamente que no cacheeEXPIRED: tenía caché pero venció el TTL
Si ves DYNAMIC en requests HTML después de configurar Cache Rules, ese es exactamente el síntoma del problema que describe este artículo. Page Rules es la salida. Relacionado: acelerar sitios construidos con page builders.
Configuración paso a paso con Page Rules
Esto es lo que tenés que hacer:
- Paso 1: Abrí el dashboard de Cloudflare, seleccioná tu dominio y andá a “Rules” > “Page Rules”
- Paso 2: Hacé clic en “Create Page Rule”
- Paso 3: En el campo de URL, ingresá el patrón. Para cachear todo el sitio:
tudominio.com/*. Para solo una sección:tudominio.com/blog/* - Paso 4: En “Pick a Setting”, seleccioná “Cache Level” y elegí “Cache Everything”
- Paso 5 (opcional pero recomendado): Agregá otra configuración en la misma regla: “Edge Cache TTL” con el valor que necesites (mínimo 2 horas en Free)
- Paso 6: Guardá y desplegá
Para excluir rutas que no deben cachearse, creá Page Rules separadas con mayor prioridad (se ordenan por número) usando “Cache Level: Bypass” para tudominio.com/login*, tudominio.com/admin/*, etc. Las Page Rules se evalúan en orden y gana la primera que matchea.
Si tu sitio usa cookies de sesión o WordPress con usuarios logueados, considerá agregar también “Bypass Cache on Cookie” con el patrón de cookie de sesión (wordpress_logged_in_.* para WP). Si tenés hosting en donweb.com, los paneles de control y la mayoría de los plans con Cloudflare incluido ya tienen guías de configuración para esto en la documentación de soporte.
Cache Rules vs Page Rules: diferencias clave
| Criterio | Cache Rules | Page Rules |
|---|---|---|
| Estado actual | Herramienta activa (recomendada por Cloudflare) | Legacy (en proceso de deprecación) |
| Cachea HTML en plan Free | No (HTML sigue siendo DYNAMIC) | Sí, con “Cache Everything” |
| Lenguaje de expresiones | Wirefence (flexible, soporta regex, headers, cookies) | Glob simple con wildcards |
| Número de reglas en Free | Sin límite documentado específico | 3 reglas máximo |
| Edge Cache TTL mínimo (Free) | 2 horas | 2 horas |
| Precedencia cuando conflictan | Depende del orden de evaluación | Orden numérico (1 = mayor prioridad) |
| Recomendación para HTML | No funciona en Free para HTML | Funciona, pero usá con cuidado en sitios dinámicos |
La ironía es que Cloudflare lanzó Cache Rules como el reemplazo moderno de Page Rules, pero en el plan Free no resuelve el caso de uso más común: cachear HTML. Page Rules, la herramienta que están deprecando, es la que funciona. Habría que ver cuándo (o si) Cloudflare iguala este comportamiento en Cache Rules para el plan Free antes de eliminar Page Rules definitivamente.
Errores comunes al configurar caché de HTML en Cloudflare
Confiar en que Cache-Control del origen alcanza
El error más frecuente. Configurás s-maxage=31536000 en tu servidor, ves que el header llega correctamente, y asumís que Cloudflare lo va a respetar. No lo hace para HTML en el plan Free. Cloudflare toma decisiones de caché según su propia lógica de tipos de contenido, y el header del origen es solo uno de los inputs, no el definitivo.
Crear Cache Rules cada vez más complejas esperando que “alguna funcione”
Ponele que creás ocho reglas diferentes cubriendo distintos patrones de path, agregás Edge TTL, Browser TTL, marcás “Eligible for cache” en todas. El resultado sigue siendo DYNAMIC. Agregar más reglas de Cache Rules no cambia el comportamiento fundamental de que HTML no se cachea en Free. Es tiempo perdido. El diagnóstico correcto llega mirando cf-cache-status: DYNAMIC y entendiendo lo que significa, no sumando capas de configuración.
Aplicar Cache Everything sin excluir rutas dinámicas
El error del lado opuesto: activar Page Rules con tudominio.com/* y “Cache Everything” sin pensar en qué rutas tienen contenido personalizado. Un carrito de compras cacheado, una página de perfil, o un formulario con token CSRF pueden servir respuestas de un usuario a otro. Si tu sitio tiene autenticación, definí primero las exclusiones y después activá el wildcard.
Preguntas Frecuentes
¿Por qué Cloudflare no cachea HTML con Cache Rules en el plan Free?
El comportamiento por defecto de Cloudflare excluye HTML del caché automático, y en el plan Free ese comportamiento tiene mayor precedencia que las reglas configuradas en Cache Rules. Aunque marques un path como “Eligible for cache” y establezcas Edge TTL, Cloudflare sigue respondiendo cf-cache-status: DYNAMIC para HTML. En planes pagos (Pro o superior) hay más control sobre esta precedencia. Cubrimos ese tema en detalle en compatibilidad entre caché y seguridad.
¿Page Rules está deprecado? ¿Puedo seguir usándolo?
Page Rules está marcado como “legacy” y Cloudflare recomienda migrar a Cache Rules, Redirect Rules y Transform Rules según el caso de uso. Pero sigue funcionando en mayo de 2026 y no hay fecha oficial de desactivación para usuarios existentes. Para cachear HTML en el plan Free, Page Rules con “Cache Everything” es la única opción que funciona actualmente.
¿Cómo reducir el TTFB con caché de HTML en Cloudflare?
Configurá una Page Rule con el patrón de tu sitio (tudominio.com/*) y “Cache Level: Cache Everything”. Después de guardar, verificá con curl -I tudominio.com/tu-pagina que el header cf-cache-status muestre HIT en el segundo request y que el header age: incremente. En el caso documentado de DooDoo.Love, el TTFB bajó de 660ms a 210ms (68%) en 10 segundos.
¿Cuántas Page Rules tengo disponibles en el plan Free de Cloudflare?
El plan Free incluye 3 Page Rules. Si necesitás una para cache de HTML, una para excluir /admin, y otra para excluir /login, ya llegaste al límite. Planificá bien qué excluir con comodines amplios (/admin* cubre /admin, /admin/, /admin/settings) para usar la menor cantidad de reglas posible.
¿Cachear HTML en Cloudflare afecta el contenido dinámico de WordPress?
Sí, potencialmente. Si activás “Cache Everything” sin configurar bypass para usuarios logueados, Cloudflare puede servir una página cacheada de un usuario a otro. Para WordPress, agregá en la misma Page Rule la configuración “Bypass Cache on Cookie” con el patrón wordpress_logged_in_.*|wp-settings-.*. Así los visitantes anónimos ven el caché y los usuarios logueados siempre van al origen.
Conclusión
El problema de Cloudflare no cacheando HTML es un caso clásico de documentación que asume que el usuario sabe más de lo que sabe. La exclusión de HTML del caché automático está documentada, pero está enterrada, y el comportamiento de Cache Rules en el plan Free contradice lo que cualquier persona esperaría al configurar “Edge Cache TTL” explícitamente.
El resultado práctico es que miles de sitios en el plan Free creen que tienen HTML cacheado y no lo tienen. Los 90 minutos de debugging de DooDoo.Love (con ocho reglas de Cache Rules distintas y ninguna que funcionara) son un buen ejemplo de cuánto tiempo se puede perder hasta llegar a la solución correcta.
La solución existe y funciona: Page Rules con “Cache Everything” activa el caché de HTML en segundos, el TTFB baja considerablemente, y los crawlers como Googlebot pueden indexar más páginas con el mismo presupuesto. Mientras Cloudflare no iguale este comportamiento en Cache Rules para el plan Free, Page Rules sigue siendo la herramienta correcta para este caso de uso, deprecación o no.
