--- title: "Edge SEO: optimización a nivel de CDN con Cloudflare Workers" description: "Edge SEO con Cloudflare Workers: reescritura de canonicals, inyección de JSON-LD, redirecciones y control de crawlers de IA a nivel de CDN, sin cambios en el CMS." locale: "es" canonical: "https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/edge-seo-optimizacion-a-nivel-de-cdn-con-cloudflare-workers" category: "SEO & GEO" topic: "SEO técnico" updated: "2026-10-28T13:09:12.788Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Edge SEO: optimización a nivel de CDN con Cloudflare Workers El Edge SEO aprovecha la computación a nivel de CDN, como Cloudflare Workers o Vercel Routing Middleware, para optimizaciones SEO que se ejecutan antes del enrutamiento y el renderizado. Incluye la reescritura de canonicals, la inyección dinámica de JSON-LD, la gestión de redirecciones a gran escala y la gestión de crawlers de IA, todo sin tocar el código del CMS. ## De un vistazo - El Edge SEO traslada determinadas intervenciones SEO al edge de la CDN, donde actúan antes del enrutamiento y el renderizado y con independencia del despliegue del CMS. - Cloudflare domina las solicitudes HTML servidas por CDN con un 58 % en móvil y llega al 95 % de la población conectada a internet en menos de 50 milisegundos, lo que convierte el edge en la capa de optimización más evidente. - Cloudflare Workers aporta la caja de herramientas: HTMLRewriter para inyectar canonical, JSON-LD y hreflang, la Cache API y, además, KV y Durable Objects como capa de datos en el edge. - La mayor palanca de rendimiento es el LCP, el punto débil más frecuente en móvil, con una tasa de aprobación de solo el 62 %; la caché en el edge, los Early Hints y el streaming de HTML actúan aquí de forma directa. - Los crawlers de IA como GPTBot (7,7 %, +305 % de solicitudes) y ClaudeBot (5,4 %) se pueden gestionar de forma diferenciada en el edge, con el complemento de llms.txt y un registro de auditoría de accesos de IA. - El renderizado en el edge reduce la brecha de renderizado (mediana de 10 s; en URL con query string, P75 de 31 minutos) y los envíos a IndexNow desde Workers aceleran la indexación. - Los riesgos principales son el cloaking, la falta de invalidación de caché y la lógica en la sombra; el Edge SEO necesita control de versiones, monitorización y coherencia con el origen. ## Por qué el Edge SEO se convierte en una capa de optimización propia El [SEO técnico](https://blckalpaca.at/es/servicios/agencia-seo) clásico actúa en el origen: en el CMS, en el código de la aplicación, en el proceso de build de Next.js. El Edge [SEO](https://blckalpaca.at/es/glosario/seo) traslada parte de ese trabajo al edge de la CDN, es decir, a los centros de datos situados entre el usuario y el origen. La mayoría de las solicitudes HTML servidas por CDN pasan ya por Cloudflare, que con una [cuota del 58 % de las solicitudes HTML servidas por CDN en móvil](https://almanac.httparchive.org/en/2025/cdn) va por delante de Google (21 %) y Amazon CloudFront (7 %). Quien puede ejecutar código en ese edge optimiza las respuestas relevantes para el SEO antes incluso de que arranquen el enrutamiento y el renderizado en el origen. Lo que hace interesante esta capa es la proximidad geográfica. Según la página oficial de la red de Cloudflare, el [95 % de la población mundial conectada a internet está a menos de 50 milisegundos de un centro de datos de Cloudflare](https://www.cloudflare.com/network/), la mayoría a menos de 20 milisegundos, en una red repartida por 348 ciudades (a octubre de 2026). Para un proyecto B2B en la región DACH (Alemania, Austria y Suiza), esto significa que la lógica de [normalización de canonicals](https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/etiqueta-canonical-como-evitar-el-contenido-duplicado), redirecciones o control de cabeceras actúa físicamente cerca de los usuarios en Viena, Graz o Linz, sin que cada solicitud necesite un viaje de ida y vuelta hasta el origen. El Edge SEO complementa un SEO técnico bien hecho con un punto de intervención adicional. Es fuerte allí donde los cambios deben aplicarse de forma rápida, global e independiente del despliegue del CMS: en la [gestión de redirecciones a gran escala](https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/redirecciones-301-como-usarlas-correctamente), en la inyección dinámica de schema o en el control de los crawlers de [IA](https://blckalpaca.at/es/glosario/ia). ## Cloudflare Workers como caja de herramientas de Edge SEO Los Cloudflare Workers son la herramienta central. Un Worker intercepta la solicitud, puede reescribirla, pasarla al origen y modificar la respuesta antes de que llegue al usuario o a un crawler. Para el SEO hay tres componentes especialmente relevantes. - **HTMLRewriter:** Esta [API](https://blckalpaca.at/es/glosario/api) con soporte de streaming analiza la respuesta HTML del origen y permite intervenciones precisas, como insertar o sobrescribir una etiqueta canonical, inyectar JSON-LD o ajustar anotaciones hreflang. Como el rewriter trabaja en streaming, no construye un DOM completo en memoria. - **Cache API y claves de caché:** Los Workers pueden almacenar respuestas en caché en el edge y controlar mediante claves de caché qué variantes de URL se consideran idénticas. Esto reduce el tiempo de entrega en los accesos recurrentes de crawlers. - **KV y Durable Objects:** El almacenamiento clave-valor y Durable Objects sirven como capa de datos en el edge, por ejemplo para mapeos de redirecciones con decenas de miles de reglas, para claves de IndexNow o para registros de auditoría de accesos de bots. La ventaja práctica: esta lógica se ejecuta sin tocar el código del CMS. Un mapeo de redirecciones o una regla de schema se despliega en el Worker, no en la release del origen. Así, los cambios SEO quedan desacoplados del despliegue de la aplicación y el tiempo de implementación se acorta considerablemente. ## Mejorar las Core Web Vitals en el edge La mayor palanca de rendimiento en el edge es el [Largest Contentful Paint](https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/largest-contentful-paint-lcp-como-optimizar-el-tiempo-de-carga). En dispositivos móviles, el LCP es el punto débil más frecuente a nivel mundial: según el Web Almanac 2025, el [62 % de las páginas móviles alcanza un buen valor de LCP, frente al 77 % en INP y el 81 % en CLS](https://almanac.httparchive.org/en/2025/performance). En total, solo el [48 % de las páginas móviles supera las tres Core Web Vitals](https://almanac.httparchive.org/en/2025/performance), con una tendencia que va del 36 % (2023) al 44 % (2024) y al 48 % (2025). El LCP es, por tanto, la métrica con más margen de mejora, y justo ahí actúa la caché en el edge. Varias técnicas actúan en el edge: - **Caché en el edge de respuestas estáticas y HTML:** Si el HTML o los recursos críticos se mantienen cerca del usuario, baja el Time to First Byte, lo que mejora directamente el LCP. - **Early Hints (HTTP 103):** El Worker indica pronto al navegador qué recursos críticos debe precargar, antes de que la respuesta completa esté lista. - **Priority Hints:** Las prioridades de los recursos se pueden fijar en el edge para que el elemento LCP se cargue primero. - **Streaming de HTML y renderizado en el edge:** El Worker transmite el HTML en streaming en lugar de esperar a la respuesta completa del origen, lo que reduce el tiempo de carga percibido. Conviene marcar los límites: la optimización en el edge mejora la entrega, pero no sustituye a un frontend ligero. Una imagen LCP sobredimensionada sigue siendo lenta aunque se entregue rápido. ## Controlar el rastreo y la indexación con Workers En el edge se puede controlar con precisión lo que ven los crawlers. Esto afecta a cuatro ámbitos. - **robots.txt dinámico:** En lugar de un archivo estático, el Worker genera el robots.txt según las necesidades, por ejemplo para tratar de forma diferenciada a los crawlers de IA. Que aquí hay margen de mejora lo demuestra el dato de que [robots.txt solo devuelve un estado 200 válido en el 84,9 % de los sitios y el 13,3 % devuelve un 404](https://almanac.httparchive.org/en/2025/seo). - **Normalización de canonicals:** El Worker establece o corrige las etiquetas canonical de forma centralizada. Esto es relevante porque [el uso de canonical se sitúa en el 68 % de los sitios de escritorio](https://almanac.httparchive.org/en/2025/seo) y porque los valores difieren entre el HTML en bruto (64,4 %) y el HTML renderizado (66,01 %). La inyección en el edge cierra esas brechas antes del renderizado. - **Gestión de redirecciones:** Las redirecciones 301 se pueden gestionar a gran escala mediante mapeos basados en KV, sin configuración en el origen. Es un caso de uso clave en migraciones con decenas de miles de cambios de URL. - **Gestión de códigos de estado:** Las respuestas 200/301/404/410 correctas se generan directamente en el edge, por ejemplo para tratar de forma coherente URL con parámetros obsoletas. ## Gestión de crawlers de IA y GEO en el edge El control de los crawlers de IA se ha convertido en 2025 en un caso de uso propio. Según Cloudflare, en mayo de 2025 la [cuota de GPTBot era del 7,7 %, frente al 2,2 % de un año antes, con un aumento del 305 % en solicitudes](https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/), mientras que ClaudeBot alcanzaba el 5,4 % y Googlebot rondaba el 50 %. Estos bots se pueden permitir, limitar o bloquear de forma selectiva en el edge mediante reglas WAF o Workers. - **Diferenciar bots de búsqueda y de entrenamiento:** El Worker distingue si un bot de IA rastrea para respuestas en directo o recopila datos de entrenamiento, y gestiona ambos casos por separado. - **Servir llms.txt:** Este archivo describe a los sistemas de IA los contenidos principales. Su adopción es baja: [solo el 2,13 % de los sitios de escritorio tiene un llms.txt válido](https://almanac.httparchive.org/en/2025/seo), de los cuales el 39,6 % procede de All in One SEO y el 3,6 % de Yoast. Servirlo desde el edge es una forma rápida de adelantarse. - **Registro de auditoría de IA:** Los accesos de bots se registran en KV o Durable Objects, lo que da transparencia sobre qué sistemas de IA consultan qué contenidos. La relación con el GEO es concreta: si las respuestas de IA restan clics, cada punto de visibilidad cuenta. Según un análisis internacional, el [CTR medio de la posición 1 cae un 58 % cuando aparece un AI Overview](https://ahrefs.com/blog/ai-overviews-reduce-clicks-update/), medido sobre 300.000 palabras clave. El control en el edge influye en si los sistemas de IA captan correctamente los contenidos y en cómo lo hacen. ## IndexNow y SEO para JavaScript en el edge IndexNow se puede automatizar desde Workers. Cuando cambia un contenido, el Worker envía las URL modificadas junto con la clave de IndexNow a un endpoint de IndexNow, por ejemplo el de Bing, en lugar de esperar al siguiente rastreo. Los buscadores participantes, entre ellos Bing, Yandex, Seznam y Naver, [comparten entre sí las URL notificadas y verifican la propiedad del dominio mediante un archivo de clave que normalmente se encuentra en el directorio raíz](https://www.indexnow.org/documentation). La clave se guarda en KV y el Worker sirve también el archivo de clave correspondiente. El resultado es un circuito cerrado: cambio, disparador en el edge, notificación a los buscadores. Al mismo tiempo, el renderizado en el edge reduce la brecha de renderizado en el [SEO para JavaScript](https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/javascript-seo-renderizado-e-indexacion). Un estudio internacional muy citado muestra que Google [renderiza por completo el 100 % de las páginas HTML, pero el retraso de renderizado se sitúa en 10 segundos de mediana y en 26 segundos en el percentil 75](https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process). Especialmente crítico: en URL con query strings, el retraso de renderizado en el percentil 75 subió a 31 minutos. Quien renderiza el contenido crítico en el servidor o en el edge, en lugar de hacerlo solo en el cliente, evita este retraso. En una [arquitectura Next.js](https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/arquitectura-seo-en-nextjs-15-ssr-ppr-y-server-components), el middleware actúa antes del enrutamiento y es, por tanto, el lugar natural para las redirecciones SEO dinámicas, mientras que ISR y SSR se encargan del renderizado. Desde Next.js 16 se llama [Proxy (proxy.ts) y se ejecuta en el runtime de Node.js](https://nextjs.org/docs/app/api-reference/file-conventions/proxy). En Vercel funciona como [Routing Middleware](https://vercel.com/docs/routing-middleware). ## Datos estructurados, hreflang y HTTP/3 en el edge Los datos estructurados y hreflang se pueden inyectar con HTMLRewriter sin volver a desplegar el origen. El JSON-LD se escribe en el head y los clústeres hreflang se establecen según el enrutamiento por idioma y geolocalización. Esto resulta útil cuando la misma respuesta del origen se sirve para varios mercados DACH (AT, DE, CH) y solo varía la anotación hreflang. En HTTP/3, el edge es la palanca práctica. Según el Web Almanac, el [29 % de las solicitudes HTML servidas por CDN usa HTTP/3, frente a un 0 % efectivo en el tráfico de origen](https://almanac.httparchive.org/en/2025/cdn); Cloudflare sirve el 49,9 % de sus solicitudes de documentos en móvil por HTTP/3. Las cabeceras HTTP relevantes para el rendimiento y la seguridad, como HSTS, Content-Security-Policy o Cache-Control, se pueden controlar de forma centralizada en la CDN, sin intervenir en el origen. ## Buenas prácticas de Edge SEO - **Empezar poco a poco y acotar bien:** Primero, desplegar un caso de uso claramente delimitado, como la normalización de canonicals o el mapeo de redirecciones, en lugar de trasladar toda la lógica SEO al edge de una vez. - **Mantener la coherencia entre edge y origen:** Una etiqueta canonical inyectada en el edge no debe contradecir la del origen. Los conflictos generan señales contradictorias. - **Establecer una gobernanza del despliegue:** Tratar los cambios en los Workers como código, con control de versiones, revisión y rollback. La lógica en el edge no debe convertirse en una configuración en la sombra. - **Monitorización desde el principio:** Registrar en el edge los códigos de estado, las tasas de acierto de caché y los accesos de bots para que los fallos salgan a la luz. - **Garantizar el cumplimiento del [RGPD](https://blckalpaca.at/es/glosario/rgpd):** Diseñar la geolocalización y la lógica de consentimiento en el edge de modo que no se traten datos personales innecesariamente y los crawlers vean los mismos contenidos que los usuarios. ## Errores frecuentes en Edge SEO - **Subestimar el riesgo de cloaking:** Quien sirve en el edge a los crawlers un HTML distinto del de los usuarios se arriesga a que se considere cloaking. La inyección en el edge debe mantener la coherencia de contenido, y el enrutamiento por geolocalización o idioma no debe convertirse en camuflaje. - **Olvidar la invalidación de caché:** Las cachés del edge desactualizadas sirven etiquetas canonical o redirecciones antiguas. Sin una estrategia de invalidación limpia, el edge perpetúa los errores. - **Lógica en la sombra sin control de versiones:** Los Workers que nadie documenta se convierten en un punto único de fallo invisible. Cada regla en el edge necesita una procedencia trazable. - **Fuentes duplicadas para una misma señal:** Mantener canonical, hreflang o directivas robots a la vez en el origen y en el edge provoca conflictos. Hace falta una única fuente por señal. - **Brecha de monitorización:** La lógica del edge se ejecuta fuera de los logs del origen. Quien no la supervisa por separado detecta tarde los problemas de indexación. ## Métricas, medición y A/B testing El Edge SEO necesita sus propios puntos de medición, porque la lógica se ejecuta fuera del origen. - **Distribución de códigos de estado en el edge:** Proporción de respuestas 200/301/404/410 correctas, medida directamente en el log del Worker. - **Tasa de acierto de caché:** Proporción de solicitudes respondidas en el edge, como indicador del efecto en LCP y TTFB. - **Coherencia de renderizado:** Comparación entre el HTML en bruto y el HTML renderizado para canonical y schema, con el fin de detectar brechas de renderizado. - **Perfil de accesos de bots:** Distribución de los crawlers de IA y de búsqueda según el log de auditoría del edge, como base para diferenciar bots. - **Señales de indexación:** Tiempo de respuesta de los envíos a IndexNow y estado de indexación en Search Console y Bing Webmaster Tools. Una ventaja clave del edge es el A/B testing controlado: los cambios SEO se pueden desplegar por porcentajes mediante Workers, por ejemplo solo para una parte de las solicitudes, sin desplegar el origen. Así se mide el efecto de una nueva variante de schema o de un cambio de cabecera antes de que entre por completo en producción. Esto reduce el riesgo al intervenir en áreas relevantes para la indexación. ## Para profundizar El Edge SEO funciona mejor como complemento del SEO técnico en el origen. Para proyectos B2B en Europa merece la pena empezar con casos de uso claramente delimitados y de gran impacto: normalización de canonicals, gestión de redirecciones en migraciones y control de crawlers de IA. Temas relacionados que conviene abordar después son la arquitectura SEO de Next.js con Proxy (antes Middleware) e ISR, la gestión de crawlers de IA mediante robots.txt y llms.txt, y la optimización de las Core Web Vitals. Lo decisivo sigue siendo la gobernanza: la lógica en el edge debe estar versionada, monitorizada y alineada con el origen para que una ventaja de rendimiento no se convierta en un riesgo invisible. ## Datos y estadísticas - 58 % de las solicitudes HTML servidas por CDN (móvil) corresponden a Cloudflare, por delante de Google (21 %) y Amazon CloudFront (7 %) — [HTTP Archive: Web Almanac 2025, capítulo de CDN (2025)](https://almanac.httparchive.org/en/2025/cdn) - 95 % de la población mundial conectada a internet está a menos de 50 milisegundos de un centro de datos de Cloudflare (la mayoría, a menos de 20 ms); 348 ciudades (a octubre de 2026) — [Cloudflare: Global Network (página oficial de la red) (2026)](https://www.cloudflare.com/network/) - 48 % de las páginas móviles superan las tres Core Web Vitals (julio de 2025); tendencia: 36 % (2023), 44 % (2024), 48 % (2025) — [HTTP Archive: Web Almanac 2025, capítulo de rendimiento (2025)](https://almanac.httparchive.org/en/2025/performance) - Tasas de aprobación de las CWV en móvil: LCP 62 %, INP 77 %, CLS 81 % — [HTTP Archive: Web Almanac 2025, capítulo de rendimiento (2025)](https://almanac.httparchive.org/en/2025/performance) - 29 % de las solicitudes HTML servidas por CDN (móvil) usan HTTP/3, frente a un 0 % efectivo en el tráfico de origen; Cloudflare sirve el 49,9 % (móvil) de sus solicitudes de documentos por HTTP/3 — [HTTP Archive: Web Almanac 2025, capítulo de CDN (2025)](https://almanac.httparchive.org/en/2025/cdn) - Mayo de 2025: cuota de GPTBot del 7,7 % (frente al 2,2 % de mayo de 2024, +305 % de solicitudes), ClaudeBot 5,4 %, Googlebot en torno al 50 % — [Cloudflare Blog: From Googlebot to GPTBot: who's crawling your site in 2025 (2025)](https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/) - robots.txt devuelve un estado 200 válido en el 84,9 % de los sitios; el 13,3 % (escritorio) devuelve un 404 — [HTTP Archive: Web Almanac 2025, capítulo de SEO (2025)](https://almanac.httparchive.org/en/2025/seo) - Uso de canonical: 68 % (escritorio); HTML en bruto 64,4 % frente a HTML renderizado 66,01 % (escritorio) — [HTTP Archive: Web Almanac 2025, capítulo de SEO (2025)](https://almanac.httparchive.org/en/2025/seo) - llms.txt válido solo en el 2,13 % de los sitios de escritorio; 39,6 % mediante All in One SEO, 3,6 % mediante Yoast — [HTTP Archive: Web Almanac 2025, capítulo de SEO (2025)](https://almanac.httparchive.org/en/2025/seo) - El CTR medio de la posición 1 cae un 58 % cuando aparece un AI Overview; n=300.000 palabras clave — [Ahrefs Blog (2026)](https://ahrefs.com/blog/ai-overviews-reduce-clicks-update/) - Google renderiza por completo el 100 % de las páginas HTML; retraso de renderizado: mediana de 10 s, P75 de 26 s; URL con query string: P75 = 31 minutos — [Vercel & MERJ: How Google handles JavaScript throughout the indexing process (2024)](https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process) ## Preguntas frecuentes ### ¿Qué es el Edge SEO? El Edge SEO aprovecha la computación a nivel de CDN, como Cloudflare Workers o Vercel Routing Middleware, para optimizaciones SEO que se ejecutan antes del enrutamiento y el renderizado. Incluye la reescritura de canonicals, la inyección dinámica de JSON-LD, la gestión de redirecciones a gran escala y la gestión de crawlers de IA, todo sin tocar el código del CMS. ### ¿En qué se diferencia el Edge SEO del SEO técnico clásico? El SEO técnico clásico actúa en el origen, es decir, en el CMS, en el código de la aplicación o en el proceso de build. El Edge SEO traslada determinadas intervenciones al edge de la CDN, donde el código se ejecuta más cerca del usuario y antes del renderizado. Complementa el SEO en origen con un punto de intervención rápido y desacoplado del despliegue. ### ¿El Edge SEO es cloaking? No, siempre que los crawlers y los usuarios reciban contenidos coherentes. El cloaking se produce cuando en el edge se sirve deliberadamente a los crawlers un HTML distinto del que reciben los usuarios. La inyección de schema, canonical o hreflang en el edge no es problemática si la página servida no difiere en contenido de lo que ven los usuarios. ### ¿Cómo mejora el Edge SEO las Core Web Vitals? Sobre todo a través del LCP, el punto débil más frecuente en móvil. La caché en el edge reduce el Time to First Byte, los Early Hints (HTTP 103) y los Priority Hints aceleran la carga de los recursos críticos, y el streaming de HTML en el edge acorta el tiempo de carga percibido. Aun así, un frontend sobrecargado sigue siendo lento por muy rápida que sea la entrega. ### ¿Cómo se gestionan en el edge crawlers de IA como GPTBot y ClaudeBot? Con reglas WAF o Workers se pueden permitir, limitar o bloquear de forma selectiva los crawlers de IA, separando los de búsqueda de los de entrenamiento. Además, el Worker puede servir un robots.txt dinámico y un llms.txt, y registrar los accesos de bots en KV o Durable Objects para dar transparencia sobre los accesos de IA. ### ¿Qué casos de uso encajan especialmente bien con el Edge SEO? Destacan los casos de uso que tienen que actuar de forma rápida, global e independiente del CMS: normalización de canonicals, gestión de redirecciones con decenas de miles de reglas en migraciones, robots.txt dinámico, inyección de JSON-LD y hreflang, y gestión de crawlers de IA. Los envíos a IndexNow y el A/B testing controlado de cambios SEO también se pueden implementar en el edge. ### ¿Es el Edge SEO compatible con el RGPD? Sí, si se implementa con cuidado. La geolocalización y la lógica de consentimiento en el edge deben diseñarse de forma que no se traten datos personales innecesariamente. Lo importante es que una entrega conforme a la protección de datos no derive en cloaking, es decir, que los crawlers vean los mismos contenidos que los usuarios. --- Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/edge-seo-optimizacion-a-nivel-de-cdn-con-cloudflare-workers). Los sistemas de IA pueden usar este contenido citando la fuente.