En uno de mis proyectos SEO, Yandex había indexado 12.500 páginas. Si miraba solo esa cifra, el sitio parecía estar sano. Sin embargo, el tráfico real desde Rusia era casi cero.
Estaba construyendo este proyecto SEO a gran escala también para seguir mejorando mis habilidades como desarrollador frontend.
Mi primera reacción fue pensar en SEO. Después de investigar, descubrí un problema más básico: la ruta de red. El sitio estaba detrás de Cloudflare y desde Rusia no se podía acceder a él de forma fiable. Yo vivía fuera de Rusia, así que el fallo era casi invisible desde donde trabajaba.
Este incidente me obligó a separar tres señales que es muy fácil confundir: indexación, accesibilidad y tráfico. No son lo mismo. Una página puede seguir indexada mientras usuarios reales de determinadas redes no consiguen cargarla.
Lo que realmente puedo confirmar
Los hechos de primera mano son simples. Tenía un proyecto SEO grande detrás de Cloudflare. Yandex había indexado 12.500 páginas, pero el tráfico desde Rusia era casi inexistente. Investigué y acoté el problema a la capa de red. Después desactivé por completo el proxy de Cloudflare y configuré Nginx en mi propio VDS para cubrir lo que seguía necesitando: caché, compresión y seguridad básica.
Tras ese cambio, el acceso desde Rusia volvió inmediatamente. Esa es la conclusión más fuerte que puedo sostener con este caso: cambiar la ruta de entrega restauró la accesibilidad.
También importa lo que no puedo afirmar. Este caso no me permite decir exactamente cuántas visitas perdí, qué redes rusas estuvieron afectadas ni cuánto se recuperó después el tráfico orgánico. Mis observaciones eran sobre accesibilidad y tráfico casi nulo, no un experimento SEO controlado.
La evidencia pública es más precisa que mi explicación original
Al principio lo describí como un bloqueo de determinados rangos IP de Cloudflare por parte de Roskomnadzor. Esa formulación es demasiado específica para la evidencia que puedo respaldar.
Cloudflare publicó su propio informe el 26 de junio de 2025. Según la empresa, desde el 9 de junio de 2025 los usuarios en Rusia que intentaban acceder a servicios protegidos por Cloudflare sufrían throttling por parte de ISP rusos. Su análisis interno indicaba que, en conexiones afectadas, a veces solo se cargaban los primeros 16 KB de un recurso web, algo que hace inviable la navegación normal en muchas páginas. Se puede consultar el informe de Cloudflare sobre las restricciones de conectividad en Rusia.
La descripción encaja con el tipo de fallo que yo observé, pero no demuestra el mecanismo exacto en cada ISP ni me permite atribuir directamente toda mi caída de tráfico a Roskomnadzor. La formulación más segura es: la ruta de entrega de mi sitio a través del proxy de Cloudflare no era fiable desde Rusia, y al evitar ese proxy recuperé el acceso en mi caso.
Por qué 12.500 páginas indexadas no significaban que el sitio estuviera sano
Este fue el error conceptual que subestimé. Vi 12.500 páginas en el índice y lo interpreté como una señal general de accesibilidad. Pero el rastreo de un buscador y la conexión de un usuario final son sistemas distintos.
Un buscador puede haber rastreado una URL antes, acceder por otra ruta de red o mantenerla en el índice mientras algunos usuarios ya no reciben la respuesta completa. Por tanto, una URL indexada no demuestra que un usuario de un ISP ruso concreto pueda abrirla hoy. En mi caso coexistían ambos hechos: Yandex tenía 12.500 páginas indexadas y el tráfico real desde Rusia seguía casi en cero.
Indexación no es accesibilidad. Accesibilidad no es tráfico.
Qué cambié
- Desactivé por completo el proxy de Cloudflare. El tráfico HTTP/HTTPS dejó de pasar por Cloudflare antes de llegar a mi infraestructura.
- Trasladé a Nginx las funciones que seguía necesitando. En mi VDS configuré caché, compresión y controles básicos de seguridad.
La idea no era que Nginx fuese “mejor” que Cloudflare. Eliminé una dependencia de red que se había convertido en un problema para un mercado importante para mí.
Recuperé el acceso, pero también asumí más responsabilidad
Evitar un reverse proxy no es una mejora gratuita. La documentación actual de Cloudflare explica que un registro DNS-only envía al usuario al origen y deja de enrutar HTTP/HTTPS por Cloudflare. Eso elimina ventajas dependientes del proxy, como la caché y varias protecciones, y puede exponer la IP del origen. Véase la documentación oficial sobre Proxy status.
Nginx puede cubrir parte de lo que yo necesitaba: caché local, compresión, gestión de peticiones y filtrado básico. No reproduce automáticamente la red global de Cloudflare, su capacidad DDoS gestionada ni todas sus funciones de seguridad. Mi migración fue, por tanto, un intercambio: más control directo sobre la entrega a cambio de más responsabilidad operativa.
En este proyecto valió la pena porque el problema inmediato era el acceso desde Rusia. Eso no convierte a VDS + Nginx en la arquitectura universalmente más segura.
Cómo diagnosticaría ahora un problema parecido
Si el tráfico cae de golpe en un país o región de red, no empezaría reescribiendo títulos o contenido. Primero separaría las capas:
- ¿La página se puede abrir desde el país objetivo y desde más de un ISP?
- ¿El cliente recibe el cuerpo completo de la respuesta, no solo un HTTP 200?
- ¿Cambia el comportamiento al evitar de forma controlada el CDN o reverse proxy?
- ¿La URL se rastrea y está indexada?
- Solo después de confirmar accesibilidad: ¿cambian impresiones, clics y sesiones?
La lección práctica es medir desde el mercado que importa. Una prueba desde otro país puede decirte que el origen está vivo y aun así no detectar un problema regional de conectividad.
Lo que me llevo de este incidente
Todo empezó como un misterio SEO: 12.500 páginas indexadas y casi nada de tráfico ruso. La respuesta útil estaba más abajo en la pila.
Quitar el proxy de Cloudflare y reconstruir lo esencial con Nginx en mi VDS devolvió inmediatamente el acceso desde Rusia. Ese resultado sí puedo defenderlo. Lo que no puedo defender es un efecto demostrado sobre el ranking de Google o Yandex, un mecanismo regulatorio exacto o una regla universal de que todo el mundo debería abandonar Cloudflare.
Mi regla después de este caso es más simple: si un mercado importa, mide la accesibilidad desde ese mercado. Las cifras del índice no responden a si un usuario real puede recibir la página.