|

Bug silencioso de soft 404 Cloudflare Pages y SEO

En pocas palabras: Cloudflare Pages devuelve un HTTP 200 con el contenido de la home para cualquier URL inexistente que no tenga un 404.html personalizado. Esto genera contenido duplicado masivo y Google lo detecta como soft 404, diluyendo tu ranking sin mostrar errores visibles en el panel.

A un desarrollador le pasó lo que a muchos: armó un verificador de enlaces rotos para detectar justamente estos problemas, y lo que encontró fue un soft 404 silencioso en Cloudflare Pages que le estaba drenando el SEO sin que se diera cuenta. El bug no es nuevo, pero la falta de advertencias claras lo convierte en una trampa perfecta para sitios estáticos que confían ciegamente en la plataforma.

En resumen

  • Cloudflare Pages devuelve un código 200 con el contenido de la home en URLs inexistentes si no configuraste un archivo 404.html personalizado. No es un error de tu código, es el patrón de fallback para SPAs.
  • Google lo interpreta como contenido duplicado a escala masiva y puede marcar todo tu sitio como sospechoso, diluyendo el ranking de la home y de cualquier página legítima que comparta ese mismo HTML.
  • Ethan documentó el hallazgo mientras construía un verificador de enlaces rotos después de que una URL de prueba inexistente pasara su script de verificación con estado 200.
  • La solución directa es crear una página 404.html, deployarla a producción y verificar con curl que la respuesta sea 404. Sin eso, Cloudflare no muestra ninguna advertencia y el daño al tráfico orgánico es silencioso hasta que Google te penaliza.

¿Qué es un soft 404 en Cloudflare Pages y cómo afecta al SEO?

Un soft 404 es una página que debería devolver un error “no encontrado” (código HTTP 404) pero que en cambio responde con un código 200 exitoso y contenido duplicado de otra sección del sitio (por lo general la homepage). En el contexto puntual de Cloudflare Pages, el problema aparece cuando no configurás un archivo 404.html: la plataforma asume que tu proyecto es una Single Page Application y resuelve cualquier ruta no coincidente sirviendo el index.html con estado 200, lo que genera un soft 404 a nivel de protocolo.

Google detecta estos patrones de forma explícita. Si tu sitio devuelve el mismo HTML para decenas o cientos de URLs distintas, el algoritmo interpreta que estás generando contenido duplicado de manera artificial. Lo peligroso no es solo que la página rota no indexe bien: es que la señal de duplicación rebota sobre la URL canónica legítima, diluyendo su autoridad. Y si la proporción de soft 404s es alta, Google puede clasificar el sitio entero como de baja calidad, incluso si el contenido original es impecable.

¿Cómo funciona el bug silencioso de Cloudflare Pages que genera soft 404?

soft 404 Cloudflare Pages diagrama explicativo

Cloudflare Pages tiene un mecanismo de fallback para rutas no resueltas. La lógica es la siguiente: si un usuario solicita /tools/herramienta-que-ya-no-existe y el servidor no encuentra un archivo ni una función que maneje esa ruta, en vez de devolver 404 redirige la petición al index.html con un código 200. Esto está pensado para Single Page Applications con enrutamiento del lado del cliente (React, Vue, Svelte), donde el framework JavaScript toma el control apenas carga la página y resuelve la ruta internamente.

El problema —acá viene lo bueno— es que Cloudflare Pages aplica ese mismo comportamiento a cualquier proyecto que no tenga una página 404 explícita, sin preguntar si es una SPA o un sitio estático, y sin mostrar ninguna alerta en el dashboard. Si armaste tres HTMLs para un portfolio, un blog o una landing de un SaaS, la plataforma asume que querés el mismo comportamiento. No hay toggle, no hay advertencia. Solo silencio. Esto se conecta con lo que analizamos en nuestra guía sobre hreflang para SEO internacional.

Ethan, el desarrollador que documentó el bug, lo descubrió mientras construía un verificador de enlaces rotos para un sitio de herramientas de desarrollo gratuito. El script recorría cada URL del sitemap con curl y marcaba las que no devolvían 200. Para probarlo, metió una URL deliberadamente rota en un sitio deployado en Cloudflare Pages, corrió el chequeo… y la URL rota pasó la validación con un 200 limpio. “Fue un momento de puteada y después de alivio”, diría cualquiera que haya debuggeado en producción un viernes a la tarde. El script no estaba mal: era el servidor mintiendo educadamente.

¿Por qué Cloudflare Pages devuelve soft 404 sin que me dé cuenta?

Porque el diseño original priorizó la experiencia de desarrollo para SPAs por sobre la necesidad de proteger sitios estáticos simples. Cloudflare Pages no distingue entre un proyecto hecho con create-react-app y uno armado con tres archivos HTML a mano. Si en la configuración de tu deploy no hay un 404.html, el servicio aplica el patrón de fallback único que tiene programado: devolver 200 con la home. Es una decisión de producto que funciona bárbaro para el 70% de los casos (React, Vue) y te deja a gamba en el 30% restante (HTML estático, sitios Jamstack sin cliente router).

Lo peor es la falta de visibilidad. El dashboard de Cloudflare no muestra una alerta del tipo “Ojo, estás sirviendo contenido duplicado en rutas inexistentes”. El único indicio —y solo si estás mirando— es que Google Search Console empieza a reportar un aumento de páginas indexadas o una caída en la proporción de páginas válidas, pero para cuando eso pasa el daño ya está hecho.

¿Cómo afecta este bug a tu posicionamiento web?

Te lo pongo con números. Si tenés una página de ventas con 10 URLs legítimas y generaste 30 enlaces rotos entre cambios de versión, artículos viejos que no redirigiste o typos en backlinks externos, cada una de esas 30 URLs inexistentes responde con el HTML exacto de la home. Google ve 31 páginas con el mismo contenido y detecta el patrón de soft 404. ¿La consecuencia? Diluye la señal de la URL original y puede marcar todo el conjunto como duplicado, bajando la posición de todas en el ranking. Sobre eso hablamos en el SEO para startups fintech en 2026.

Además, Googlebot asigna un “presupuesto de rastreo” a cada sitio. Si el crawler gasta tiempo indexando páginas fantasma con contenido duplicado, deja de rastrear las URLs que sí importan porque se va por las ramas (y nosotros acá preocupados porque no indexa el último artículo). Es un combo: menos rastreo útil + señal de baja calidad = caída de tráfico orgánico sin un solo error visible en la consola de deploy.

Dato concreto: el patrón site-wide de soft 404 que detecta Google no se limita a la URL individual. Si el crawler identifica que varias URLs devuelven el mismo contenido, puede extender la penalización a todo el dominio y no solo a las afectadas. Ethan lo explica en su artículo con un dato demoledor: “Every broken/mistyped/old link pointing at your site becomes a duplicate-content page in Google’s eyes, all serving the same homepage.”

¿Cómo solucionar el soft 404 en Cloudflare Pages paso a paso?

El fix es directo pero tenés que hacerlo a conciencia: crear un archivo 404.html en la raíz de tu proyecto, deployarlo y verificar que cualquier ruta inexistente devuelva efectivamente un código 404. Si estás en un sitio estático puro (HTML, CSS, JS vanilla), el proceso es así:

  • Creá 404.html en la raíz del directorio de deploy. El archivo tiene que estar en el mismo nivel que tu index.html. Metele un mensaje claro y un enlace a la home. No hace falta que sea una obra de arte: una frase como “La página que buscás no existe” con un link al inicio ya alcanza.
  • Verificá en local que el HTML es válido. Un error común es dejar el archivo vacío o con un meta refresh que genera un loop. Guardalo limpio, con un h1 y un párrafo.
  • Hacé deploy a Cloudflare Pages. Si usás Git, pusheá el cambio a la rama de producción. Cloudflare lo levanta automáticamente.
  • Probá con curl después del deploy. Abrí la terminal y ejecutá curl -I https://tu-dominio.com/ruta-que-no-existe. La primera línea de la respuesta DEBE decir HTTP/2 404. Si ves HTTP/2 200, algo falló (el archivo no está en la raíz o el deploy no se completó).
  • Si usás framework (React, Vue, Svelte), el manejo es distinto. En estos casos el router del cliente maneja las rutas no coincidentes, así que necesitás una ruta catch-all en el router mismo junto con un componente de página no encontrada. La diferencia es que con SPA el 404.html no alcanza porque el problema es a nivel Javascript, no de servidor.

Ojo con las redirecciones. Si ya tenés un montón de soft 404s acumulados, agregar solo la página 404.html corrige el problema de ahora en adelante, pero las URLs viejas que ya devolvieron contenido duplicado siguen flotando en el índice de Google. Vas a tener que gestionarlas con redirecciones 301 a contenido relevante o, si no hay equivalente, asumir que van a figurar como 404s reales (que es lo correcto). Más contexto en nuestra guía práctica de SEO desde cero.

¿Qué herramientas usar para detectar soft 404s?

No dependas de una sola herramienta. El soft 404 es justamente silencioso y requiere un enfoque de múltiples capas para pescarlo a tiempo:

  • Google Search Console: El informe “Páginas no encontradas” (dentro de Indexación) te muestra las URLs que Google detectó como soft 404. Usalo como radar temprano. Si ves varios soft 404s para un sitio chico, encendé las alarmas.
  • Screaming Frog SEO Spider: Configuralo para rastrear tu sitio con la opción “Always follow redirects” desactivada. Filtrá por status 200 y compará el contenido de las páginas. Si varias URLs tienen exactamente el mismo HTML, hay soft 404.
  • Script ad-hoc con curl: El enfoque que usó Ethan. Agarrá tu sitemap, pasalo por curl -I para cada URL y marcá respuestas 200. Después, con un diff entre el contenido de una URL legítima y una rota, confirmá si son idénticas. Lleva 20 minutos armarlo y te da control total.
  • Verificador de enlaces rotos (el script de Ethan): Detecta enlaces rotos y, de paso, te señala URLs con status inesperado como los soft 404.

¿Qué hacer si Google ya indexó soft 404 de mi sitio en Cloudflare Pages?

Primero, no entres en pánico. El daño es reversible pero requiere orden. Después de haber deployado la página 404.html y verificado que las URLs inexistentes devuelven 404 real, seguí esta secuencia:

  • Reenviá el sitemap a Google Search Console. Forzá un rastreo manual de las URLs que sabés que son válidas. Esto acelera la recrawleada.
  • Solicitá la eliminación temporal de las URLs duplicadas desde la herramienta de eliminaciones de Google. No es permanente, pero frena la indexación de contenido duplicado mientras el crawler actualiza.
  • Monitoreá el informe de “Páginas no encontradas” durante dos semanas. El número debería bajar progresivamente.
  • Revisá backlinks entrantes. Si enlazaron a URLs que ahora tiran 404 real, contactá al webmaster o configurá redirecciones 301 a contenido equivalente (nunca a la home, porque genera otro soft 404).

El proceso de limpieza completo lleva entre una y tres semanas dependiendo de la frecuencia con que Google rastrea tu sitio. Asegurate de mantener el 404.html en cada deploy futuro y de no borrarlo por error en una limpieza de repositorio (sí, he visto equipos que lo borran sin querer y reintroducen el bug).

¿Qué está confirmado y qué no?

  • Confirmado: Cloudflare Pages aplica el patrón de fallback SPA a sitios estáticos sin página 404 personalizada. Ethan lo documentó con un script de verificación y pruebas concretas. El comportamiento es consistente con la documentación oficial de Cloudflare sobre comportamiento para rutas no encontradas, que menciona el fallback al index.html pero no enfatiza el riesgo de soft 404 para sitios estáticos.
  • Confirmado: Google detecta soft 404s y los trata como señales negativas. La documentación de Google sobre errores de red lo explica.
  • No confirmado: Si Cloudflare planea cambiar este comportamiento en futuras versiones o agregar una alerta en el dashboard para sitios sin 404.html. Hasta ahora no hay anuncio oficial ni hoja de ruta pública que mencione este ajuste.
  • Pendiente: La magnitud del impacto SEO a largo plazo para sitios que corrigieron el bug. Los datos de recuperación dependen de cada caso y no hay un estudio amplio publicado.

Errores comunes al intentar arreglar el soft 404

  • Creer que con un redirect 301 a la home solucionás el problema. Redirigir URLs rotas a la home genera otro soft 404 soft, porque Google espera contenido específico para la URL original y recibe la home. Solo usá 301 si tenés una página equivalente en contenido. Caso contrario, dejá que tire 404.
  • Subir el 404.html a una subcarpeta en lugar de la raíz. Cloudflare Pages busca el 404.html en el root del deploy. Si lo metiste en /assets/404.html o en /public/404.html, no lo va a encontrar y el fallback sigue activo.
  • No verificar con curl después del deploy. Mucha gente asume que con crear el archivo alcanza. Probá siempre con curl, porque si el archivo tiene un error interno o un problema de encoding, Cloudflare puede ignorarlo y devolver la home igual.
  • Dejar rutas de API o endpoints capturadas por el catch-all. Si tenés un worker o una API en el mismo proyecto, asegurate de que las rutas del backend no sean interceptadas por el patrón de fallback. Configurá _routes.json con las exclusiones necesarias.

Preguntas Frecuentes

¿Qué es un soft 404 en Cloudflare Pages?

Es una respuesta con código HTTP 200 y contenido duplicado de la homepage para URLs que no existen en tu sitio, producto del mecanismo de fallback SPA que Cloudflare Pages aplica por defecto cuando no configurás una página 404 personalizada. Google lo interpreta como contenido duplicado y puede penalizar el sitio. Ya lo cubrimos antes en la comparativa de CI/CD pipelines en 2026.

¿Cómo detectar si mi sitio tiene el bug de soft 404 en Cloudflare Pages?

Tirale un curl a una URL que seguro no exista: curl -I https://tu-dominio.com/test-404-2026. Si la respuesta empieza con HTTP/2 200 en vez de HTTP/2 404, tenés el problema. También podés revisar Google Search Console en el informe de Páginas no encontradas.

¿Cómo solucionar el soft 404 en Cloudflare Pages paso a paso?

Creá un archivo 404.html en la raíz de tu proyecto, deployalo a producción y verificá con curl que cualquier ruta inexistente devuelva 404. Si usás React o Vue, lo que necesitás es una ruta catch-all en el router de la app junto con un componente de página no encontrada, no solo el HTML estático.

¿Cloudflare Pages tiene algún costo adicional por corregir soft 404?

No. Agregar un 404.html no consume ancho de banda extra ni requiere un plan pago. Es un archivo estático más que deployás en el mismo bucket de tu proyecto. La corrección es completamente gratuita y no afecta los límites de build ni de requests.

¿Qué diferencia hay entre un soft 404 y un error 404 real en Cloudflare Pages?

El error 404 real ocurre cuando Cloudflare encuentra un 404.html en la raíz y responde con código HTTP 404 para rutas inexistentes; el soft 404 se da cuando ese archivo no existe y la plataforma responde con 200 sirviendo el index.html. El primero le dice a Google “esta página no existe”, el segundo le miente con “sí, existe y tiene el mismo contenido que la home”.

Conclusión

El bug silencioso de Cloudflare Pages no es un agujero de seguridad ni un error de código de tu parte, es una brecha entre la configuración por defecto y lo que un sitio estático necesita para mantener la higiene SEO. La buena noticia es que la solución es ridículamente simple: un archivo 404.html bien puesto y un curl de verificación alcanzan. La mala es que Cloudflare no te avisa, y para cuando Google te pegue el tirón de orejas, ya perdiste semanas de tráfico orgánico.

Si deployás en Cloudflare Pages, agregar la página 404 es tan obligatorio como poner un favicon. No lo dejes para después. Y si ya tenés sospechas, corré el script de curl esta misma tarde; es preferible encontrar el problema vos a que lo encuentre Googlebot.

Fuentes

Te puede interesar...