Cloudflare ya te pregunta si de verdad quieres usar Pages: qué implica el salto a Workers para un sitio Astro como el nuestro
La documentación de Pages ya abre preguntando si estás seguro. Qué cambia de verdad el salto a Workers en un sitio Astro estático y el párrafo que lo decide.
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, 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 ese párrafo es lo que verificas antes de cortar.
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 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.
Abre tu propio repositorio en lugar de razonar en abstracto, y la inversión cae sobre cuatro cosas que casi todo proyecto de Pages tiene en común:
- Un archivo de rutas que acota dónde corren las funciones — normalmente un catch-all con los prefijos de assets excluidos — que en Pages hacía que la capa de funciones viera prácticamente cada petición HTML.
- Un middleware que no es decorativo: resuelve rutas heredadas y devuelve
410 Goneo un301que arrastra los parámetros de campaña para que la atribución sobreviva al salto. Si deja de ejecutarse en las rutas que veía antes, los enlaces de campañas antiguas mueren en silencio. - Unos pocos endpoints de API más un archivo de cabeceras cuyas reglas de caché asumen que los assets se sirven sin tocar ninguna función: bundles con hash inmutables, una ventana corta en imágenes y
no-storeen las rutas de API. - Un archivo de redirecciones generado en el build, que en un sitio maduro suele ser el archivo más grande del repositorio.
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 Astro copia public/ 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 esas 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 cuando tus redirecciones sostienen el sitio.
Qué se traslada limpio y qué no
Un repaso rápido del resto de la guía contra una configuración típica de Pages:
- Dominios personalizados: revísalo primero. Workers no acepta dominios cuyos nameservers no estén gestionados por Cloudflare. Si tu DNS vive en otro registrador, ese será tu bloqueo duro: planifícalo antes que nada.
- Despliegues: un ajuste. Si tus 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. Es un ajuste, no una reescritura del pipeline.
- Pages Functions: cambio de marco, no reescritura. Si tus funciones ya son manejadores estándar
Request/Response— que es exactamente lo que espera Workers — cambia la estructura de archivos y la lógica no. La misma lógica está detrás de que Cloudflare hiciera por defecto la capa de compatibilidad con Node.js. - 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. Optimizas contra datos de campo, y mantener los assets con hash y las imágenes fuera de la capa de funciones es lo que protege las reglas de caché que ya escribiste.
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)? | Migra — 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 cuando aparezca un disparador | — |
El disparador del corte debe ser una capacidad o una fecha, no un aviso. Si nada de lo que ejecutas necesita Cron Triggers ni Durable Objects, no hay retorno en asumir esta ventana de verificación de enrutado este trimestre — pero la dirección es inequívoca, y un wrangler.jsonc que vive en una rama y compila en CI cuesta casi nada mantener. Ejecuta cuando necesites una función que solo Workers tiene, o cuando Cloudflare ponga una fecha real a Pages.
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.
