Voltar ao blog
14 de novembro de 2025Sergei Solod6 min de leitura

O Yandex tinha indexado 12.500 páginas, mas eu quase não recebia tráfego da Rússia: o problema do Cloudflare que eu não vi

O Yandex havia indexado 12.500 páginas, mas o tráfego da Rússia era quase zero. Isolei o problema na rota de rede, desativei o proxy do Cloudflare, levei cache, compressão e proteção básica para o Nginx no meu VDS e restaurei a acessibilidade.

DevOpsSEONginxCloudflareRedesInfraestrutura

Em um dos meus projetos de SEO, o Yandex havia indexado 12.500 páginas. Se eu olhasse apenas para esse número, o site parecia saudável. Mesmo assim, o tráfego real vindo da Rússia era quase zero.

Eu também estava construindo esse projeto de SEO em grande escala para continuar aprimorando minhas habilidades como desenvolvedor frontend.

Minha primeira reação foi pensar em SEO. Depois de investigar, porém, encontrei um problema mais básico: a rota de rede. O site estava atrás do Cloudflare e não podia ser acessado de forma confiável a partir da Rússia. Como eu morava fora do país, a falha era quase invisível do lugar de onde eu trabalhava.

Esse incidente me obrigou a separar três sinais que é fácil tratar como se fossem a mesma coisa: indexação, acessibilidade e tráfego. Não são. Uma página pode continuar indexada enquanto usuários reais em determinadas redes não conseguem carregá-la.

O que eu realmente posso confirmar

Os fatos de primeira mão são simples. Eu mantinha um grande projeto de SEO atrás do Cloudflare. O Yandex havia indexado 12.500 páginas, mas o tráfego da Rússia era quase inexistente. Investiguei e restrinigi o problema à camada de rede. Depois desativei completamente o proxy do Cloudflare e configurei Nginx no meu próprio VDS para assumir o que eu ainda precisava: cache, compressão e segurança básica.

Depois dessa mudança, o acesso a partir da Rússia voltou imediatamente. Esse é o resultado mais forte que posso sustentar: alterar o caminho de entrega restaurou a acessibilidade.

É igualmente importante dizer o que esse caso não prova. Ele não me permite informar o número exato de visitas perdidas, todas as redes russas afetadas ou quanto o tráfego orgânico se recuperou depois. Minhas observações eram sobre acessibilidade e tráfego quase zero, não um experimento controlado de SEO.

As evidências públicas são mais precisas do que minha explicação original

Inicialmente eu descrevi o caso como se o Roskomnadzor tivesse bloqueado intervalos específicos de IP do Cloudflare. Essa formulação é específica demais para as evidências que consigo sustentar.

Em 26 de junho de 2025, o Cloudflare publicou seu próprio relato. A empresa afirmou que, desde 9 de junho de 2025, usuários na Rússia que acessavam serviços protegidos pelo Cloudflare estavam sofrendo throttling por parte de ISPs russos. Segundo a análise interna do Cloudflare, em conexões afetadas apenas os primeiros 16 KB de um recurso web podiam ser carregados, o que inviabilizaria a navegação normal em muitas páginas. Os detalhes estão no relatório do Cloudflare sobre as restrições de conectividade na Rússia.

A descrição é compatível com o tipo de falha que eu vi, mas não prova o mecanismo exato em cada ISP nem me permite atribuir diretamente toda a queda de tráfego ao Roskomnadzor. A afirmação mais segura é: o caminho de entrega do meu site através do proxy do Cloudflare não era confiável a partir da Rússia e, no meu caso, contornar esse proxy restaurou o acesso.

Por que 12.500 páginas indexadas não significavam que o site estava saudável

Esse foi o erro conceitual que eu subestimei. Eu via 12.500 páginas no índice e tratava isso como um sinal geral de acessibilidade. Mas o crawling de um buscador e a conexão de um usuário final são sistemas separados.

Um mecanismo de busca pode ter rastreado uma URL antes, alcançá-la por outra rota de rede ou mantê-la no índice mesmo quando alguns usuários já não recebem a resposta completa. Portanto, uma URL indexada não prova que um usuário de um ISP russo específico consiga abri-la hoje. No meu caso, os dois fatos coexistiam: 12.500 páginas estavam indexadas no Yandex e o tráfego real da Rússia continuava quase zero.

Indexação não é acessibilidade. Acessibilidade não é tráfego.

O que eu mudei

  1. Desativei completamente o proxy do Cloudflare. O tráfego HTTP/HTTPS deixou de passar pelo Cloudflare antes de chegar à minha infraestrutura.
  2. Levei para o Nginx as funções que eu ainda precisava. No meu VDS configurei cache, compressão e controles básicos de segurança.

O ponto não era que o Nginx fosse “melhor” que o Cloudflare. Eu removi uma dependência de rede que havia se tornado um problema para um mercado importante para mim.

O acesso voltou, mas a responsabilidade também

Contornar um reverse proxy não é uma melhoria gratuita. A documentação atual do Cloudflare explica que, com DNS-only, o usuário vai até a origem e o tráfego HTTP/HTTPS deixa de passar pelo proxy do Cloudflare. Com isso, benefícios dependentes do proxy, como cache e várias proteções, deixam de ficar à frente da origem, e o IP de origem pode ser exposto. Veja a documentação oficial de Proxy status.

O Nginx pode cobrir parte do que eu precisava: cache local, compressão, tratamento de requisições e filtragem básica. Ele não reproduz automaticamente a rede global do Cloudflare, a capacidade gerenciada contra DDoS ou todos os recursos de segurança. A migração foi, portanto, uma troca: mais controle direto sobre o caminho de entrega em troca de mais responsabilidade operacional.

Para este projeto, valeu a pena porque o problema imediato era o acesso a partir da Rússia. Isso não torna VDS + Nginx a arquitetura universalmente mais segura.

Como eu diagnosticaria um problema parecido hoje

Se o tráfego despencasse em um país ou região de rede, eu não começaria reescrevendo títulos ou conteúdo. Primeiro separaria as camadas:

  1. A página abre a partir do país alvo e de mais de um ISP?
  2. O cliente recebe o corpo completo da resposta, e não apenas HTTP 200?
  3. O comportamento muda quando CDN ou reverse proxy são contornados em um teste controlado?
  4. A URL é rastreada e está indexada?
  5. Só depois de confirmar a acessibilidade: impressões, cliques e sessões estão mudando?

A lição prática é medir a partir do mercado que importa. Um teste feito em outro país pode mostrar que a origem está no ar e ainda assim não detectar uma falha regional de conectividade.

O que eu aprendi com este incidente

Tudo começou como um mistério de SEO: 12.500 páginas indexadas e quase nenhum tráfego russo. A resposta útil estava mais abaixo na stack.

Remover o proxy do Cloudflare e reconstruir o essencial com Nginx no meu VDS restaurou imediatamente o acesso a partir da Rússia. Esse resultado eu posso defender. O que não posso defender é transformá-lo em prova de efeito de ranking no Google ou Yandex, em um mecanismo regulatório exato ou numa regra universal de que todos deveriam abandonar o Cloudflare.

Minha regra depois desse caso é simples: se um mercado é importante, meça a acessibilidade a partir desse mercado. O número de páginas indexadas não responde se um usuário real consegue receber a página.