Cloudflare ya te pregunta si de verdad quieres usar Pages: qué implica el salto a Workers para un sitio Astro como el nuestro
Cloudflare no ha eliminado Pages, pero su documentación ahora abre con el aviso '¿Seguro que quieres usar Pages?' y el guía oficial de migración a Workers se actualizó el 22 de septiembre de 2026. Qué cambia de verdad para un sitio Astro estático, el párrafo de cuatro líneas que decide si tu middleware sigue funcionando, y el marco con el que decidimos si mover mintec.co.
Cloudflare ya te pregunta si de verdad quieres usar Pages: qué implica el salto a Workers para un sitio Astro como el nuestro
Cloudflare no ha matado a Pages, pero ya no finge que ahí va la plataforma. La documentación de Pages abre con un aviso que dice literalmente "¿Seguro que quieres usar Pages?" y te manda a Workers para los proyectos nuevos; la guía oficial de migración de Pages a Workers se actualizó el 22 de septiembre de 2026; y el 1 de octubre Cloudflare puso Artifacts, su propia plataforma Git, en beta abierta con facturación desde el 14 de octubre de 2026. Para un sitio Astro estático como mintec.co, la migración es un ejercicio de configuración, no una reescritura: _headers y _redirects se trasladan nativamente. El riesgo está en un párrafo de la guía sobre el orden de servido, y es la razón por la que estamos preparando la migración en lugar de ejecutarla.
La señal, con fechas
Tres datos de primera parte, porque "Cloudflare deprecó Pages" es de esas cosas que todo el mundo repite y nadie comprueba:
- 25 de agosto de 2026 — el aviso. La página principal de
developers.cloudflare.com/pages/ahora empieza con: "Are you sure you want to use Pages? Workers supports most Pages use cases and offers a broader feature set. It is Cloudflare's primary platform for building applications. Start new projects with Workers." No es un comentario de foro: es la puerta de entrada del producto. - 22 de septiembre de 2026 — la guía. La documentación Migrate from Pages to Workers se actualizó ese día y recorre frameworks, configuración del proyecto, builds, previsualizaciones, cabeceras, redirecciones, dominios
pages.dev, dominios personalizados y una matriz de compatibilidad función por función. - 1 de octubre de 2026 — el entorno alrededor de Pages también se mueve. Artifacts, la plataforma de repositorios de Cloudflare, entró en beta abierta, disponible en el plan Workers Paid. La documentación dice que la facturación empieza el 14 de octubre; el post oficial del blog dice el 15. Sus dos páginas se contradicen por un día, y eso también dice a qué velocidad se mueve esto.
Ninguno de los tres es un anuncio de fin de vida. Los proyectos de Pages siguen desplegándose, y la propia guía de Cloudflare afirma que las peticiones de assets estáticos en Workers son gratis y que las invocaciones de Pages Functions se cobran como las de Workers: "estructura de costes similar" es la posición oficial. El mensaje es sobre dirección, y contra la dirección es contra lo que se planifica.
Nosotros ya tenemos piel en el juego: migramos mintec.co de Next.js en Vercel a Astro en Cloudflare Pages en julio y escribimos públicamente que Pages era "más que suficiente" para un sitio de contenidos. Esa respuesta sigue siendo cierta hoy. Solo que ya no es toda la pregunta — y seis meses después de que Cloudflare adquiriera al equipo de Astro, ya no tratamos la capa de hosting como tubería neutra.
Lo que Pages adivinaba por ti, y lo que Workers te obliga a decir
La migración es tan breve que se lee de una sentada. Casi todo el trabajo consiste en reemplazar la vieja costumbre de Cloudflare de inferir tu intención:
| Comportamiento en Pages | Lo que exige Workers | Por qué importa |
|---|---|---|
pages_build_output_dir en el dashboard o en la config | assets.directory en un wrangler.jsonc / wrangler.toml, más name y compatibility_date obligatorios | Ahora eres dueño del archivo de configuración; ya no hay un valor por defecto del dashboard detrás del cual esconderte |
Infiera SPA o 404 propio a partir de index.html / 404.html | Valor explícito assets.not_found_handling: single-page-application o 404-page | Un valor mal elegido en silencio = respuesta equivocada en cada URL inexistente |
Excluye automáticamente node_modules, .git, .DS_Store | Creas un archivo .assetsignore en el directorio de assets | Si lo olvidas, subes basura en cada despliegue |
Subdominio pages.dev automático | workers_dev: true y un subdominio workers.dev | Las URLs de previsualización cambian de host: actualiza enlaces y comprobaciones |
| Sirve las Pages Functions antes que los assets estáticos | Sirve los assets estáticos antes que tu Worker salvo que assets.run_worker_first: true | El único cambio que puede romper el enrutado en silencio |
La última fila es donde la guía deja de ser una lista de verificación y se convierte en una decisión de arquitectura.
El párrafo de cuatro líneas que decide si tu sitio sigue funcionando
La sección de la guía sobre _routes.json y el middleware de Pages Functions lo dice claro: Pages ejecutaba tus funciones antes que los assets estáticos, y _routes.json más el middleware te dejaban personalizar eso. Workers hace lo contrario por defecto: primero se sirven los assets estáticos y tu Worker solo se ejecuta si pones assets.run_worker_first: true.
Abrimos nuestro propio repositorio en lugar de razonar en abstracto, y la inversión cae justo encima de cómo está construido mintec.co:
public/_routes.jsontiene 17 líneas:include: ["/*"], excluyendo/_astro/*,/images/*, favicons,robots.txt,llms.txt,rss.xmly los sitemaps. En Pages, eso significaba que la capa de funciones veía prácticamente cada petición HTML.functions/_middleware.tsno es decorativo: resuelve rutas heredadas y devuelve410 Goneo un301que arrastra los parámetrosutm_*ygclidpara que la atribución sobreviva al salto. Si ese middleware deja de ejecutarse en las rutas que veía antes, los enlaces de campañas antiguas mueren en silencio.- Junto a él hay cinco endpoints:
contact-lead,project-intake,maia-lead,geo.json(leerequest.cf.country) y un ayudante de conversiones de Meta, máspublic/_headerscon reglas de caché que asumen que los assets se sirven sin tocar ninguna función: HTML conmax-age=0, must-revalidate,/assets/*inmutable por un año,/images/*una semana constale-while-revalidate,/api/*enno-store. public/_redirectstiene 1.000 líneas y 82 KB, autogenerado en cada build desderedirects_map.jsonporscripts/sync-redirects.mjs.
Dos de esos archivos se trasladan limpios: la guía confirma explícitamente que _headers y _redirects son compatibles de forma nativa en Workers con static assets, siempre que estén en el directorio de assets — y los nuestros viven en public/, que Astro copia a dist/ en cada build. Lo que no se traslada es el supuesto sobre quién corre primero. Con run_worker_first: true, cada imagen y cada asset con hash también entran en el Worker, que es justo lo que nuestras reglas de caché buscaban evitar. Con el defecto, el middleware solo salta donde falla el asset estático — probablemente bien para URLs heredadas que ya no existen como archivo, pero "probablemente" no es un criterio de corte para un sitio con 1.000 redirecciones.
Qué se traslada limpio y qué no
Un repaso rápido del resto de la guía contra nuestra propia infraestructura:
- Dominios personalizados: sin problema. Workers no acepta dominios cuyos nameservers no estén gestionados por Cloudflare. Comprobamos:
mintec.coresuelve ajacob.ns.cloudflare.comygrace.ns.cloudflare.com, así que este bloqueo habitual no aplica. Si tu DNS vive en otro registrador, ese será tu bloqueo duro: planifícalo antes que nada. - Despliegues: un ajuste. El repo no tiene
.github/workflows/; los despliegues van por la integración Git de Cloudflare. La guía indica conectar el repositorio a Workers Builds y luego desactivar los despliegues automáticos del proyecto de Pages. - Pages Functions: cambio de marco, no reescritura. Nuestras funciones ya son manejadores estándar
Request/Response, que es exactamente lo que espera Workers — la misma lógica detrás de que Cloudflare hiciera por defecto la capa de compatibilidad con Node.js. Cambia la estructura de archivos; la lógica no. - Previsualizaciones: configuración, no funciones. Las URLs por rama pasan a ser
preview_urls: truemás un bloquepreviews, con los builds de preview activados en Workers Builds (los proyectos nuevos usanwrangler previewpor defecto). - Rendimiento: sin cambios, si el orden de servido se mantiene honesto. Optimizamos contra datos de campo — nuestras lecturas de BEACON sobre tráfico real de Cloudflare son la razón por la que mantenemos
/images/*y/_astro/*fuera de la capa de funciones.
El marco que usamos para decidir
| Pregunta | Si la respuesta es sí | Si la respuesta es no |
|---|---|---|
| ¿Tus nameservers están fuera de Cloudflare? | Bloqueo. Mueve el DNS primero o quédate en Pages | Sácalo de la decisión |
| ¿Necesitas una función exclusiva de Workers (Cron Triggers, Durable Objects, Workers Logs, Logpush, despliegues graduales)? | Migrate — Pages nunca te la va a dar | No hay urgencia |
| ¿Dependes de una función exclusiva de Pages (Early Hints es la real)? | Quédate, o acepta la alternativa | No hay motivo para quedarte por eso |
¿El middleware o _routes.json controlan el enrutado en URLs vivas? | Presupuesta tiempo de verificación; ahí está el coste real del cambio | La migración es sobre todo configuración |
| ¿El sitio es solo contenidos, estático y despliega bien hoy? | Prepara la config ahora, corta después | — |
Nuestra llamada: prepararla, no cortarla. Nada de lo que ejecutamos hoy necesita Cron Triggers ni Durable Objects, así que no hay retorno para asumir esta ventana de verificación de enrutado este trimestre. Pero la dirección es inequívoca, y un wrangler.jsonc que exista en una rama y compile en CI cuesta casi nada mantener. El disparador para ejecutarla será o una función que de verdad necesitemos o una fecha que ponga Cloudflare — no el aviso.
Esa es la versión honesta de esta decisión para la mayoría de los sitios de contenidos: la migración es real, es pequeña, y lo único caro es el párrafo que vas a tener tentación de saltarte.
Preguntas Frecuentes
¿Cloudflare Pages está obsoleto?
No. Cloudflare no ha anunciado fecha de fin de vida, las peticiones de assets estáticos siguen siendo gratis y los proyectos existentes siguen desplegándose. Lo que cambió es la dirección: la documentación de Pages (actualizada el 25 de agosto de 2026) abre con el aviso '¿Seguro que quieres usar Pages?' y redirige los proyectos nuevos a Workers, y Cloudflare publica una guía oficial de migración de Pages a Workers (actualizada el 22 de septiembre de 2026). Trata Pages como una plataforma en mantenimiento, no como una plataforma muerta.
¿Qué se rompe al mover un sitio estático de Pages a Workers?
Para un sitio puramente estático, poco: Workers con static assets admite nativamente los archivos _headers y _redirects siempre que estén dentro del directorio de assets. Lo que tienes que configurar a mano son las cosas que Pages adivinaba: el directorio de build pasa a ser assets.directory, el comportamiento SPA o 404 pasa a ser un valor explícito de assets.not_found_handling, los archivos excluidos pasan a ser un .assetsignore, y las previsualizaciones por rama pasan a ser preview_urls más Workers Builds.
¿Importa run_worker_first en un sitio Astro estático?
Sí, si usas Pages Functions o un archivo _routes.json. Pages ejecutaba las funciones antes que los assets estáticos; Workers sirve los assets estáticos antes que tu Worker salvo que pongas assets.run_worker_first: true. Para un sitio que solo necesita sus funciones en unas pocas rutas de API, dejar el defecto es más barato y más rápido. Para un sitio cuyo middleware emite redirecciones o respuestas 410 en rutas arbitrarias, hay que decidir explícitamente qué capa manda y verificarlo.
¿Cuándo conviene quedarse en Cloudflare Pages?
Cuando funciona, no necesitas ninguna función exclusiva de Workers y tienes motivos para evitar ventanas de cambio. Las funciones que Pages tiene y Workers no son pocas (Early Hints es la principal). Las que Workers tiene y Pages no incluyen despliegues graduales, Workers Logs, Logpush, Cron Triggers, Durable Objects y el plugin de Cloudflare Vite. Migra cuando necesites una de ellas, o cuando Cloudflare ponga una fecha real a Pages, y no antes.
