Blog · 2026-08-30

Seu site pode estar queimando orçamento de rastreamento à toa: soft 404 e a armadilha do SPA fallback do Cloudflare Pages

Devolver 200 mais uma home inteira para toda URL quebrada não é "pelo menos tem alguma coisa ali", é o rastreador gastando a cota dele em URLs lixo. Um único 404.html resolve, e o conserto ainda revela um lote de problemas que você não conseguia ver.

A indexação do site novo não sobe e você acha que o conteúdo não está bom o bastante. Existe outra possibilidade: todas as URLs que não existem, backlinks antigos quebrados, links internos digitados errado, caminhos que um scanner fica testando, devolvem 200 no seu site e ainda entregam uma cópia completa da home. O rastreador vem todo dia e gasta a cota inteira nesse lixo, enquanto as páginas que importam nunca entram na fila.

O sintoma: dê um curl em um caminho que não existe e veja o que volta

Temos nas mãos um site de conteúdo de pouco mais de 60 páginas que sofria há tempos com rastreamento insuficiente. No check-up, demos curl em alguns caminhos que com certeza não existem: /random-xyz, /rss.xml, /llms.txt. Todos devolveram HTTP 200, com o HTML completo da home no corpo, 87KB, canonical apontando para /.

Isso é um soft 404: a URL não existe e o servidor diz que existe. Ele tem duas propriedades traiçoeiras:

• O monitoramento fica todo verde. Checagens de uptime e testes de clique recebem 200, então nada nunca alerta.
• Ele engana até você. Você quer confirmar se o site tem um llms.txt, o curl devolve 200, e você conclui que existe. O que chegou foi a home. Caímos nessa uma vez, de verdade.

A causa é simples: quando não existe um 404.html na raiz da saída do build, o Cloudflare Pages cai automaticamente em modo single-page application, devolvendo index.html com 200 para qualquer caminho sem correspondência. Para uma SPA de verdade isso é recurso. Para um site estático de várias páginas é desastre, e um padrão silencioso.

Por que isso queima orçamento de rastreamento

"A canonical da home aponta para /, então as URLs quebradas não vão ser indexadas como conteúdo duplicado. Qual é o problema?"

A indexação está de fato bloqueada. O rastreamento não. A tag canonical mora dentro do HTML, então o Googlebot precisa baixar os 87KB inteiros da home antes de conseguir lê-la. Cada URL quebrada é um download completo. E URLs quebradas vêm de mais lugares do que você imagina: links externos que alguém digitou errado, caminhos antigos que sobraram de uma reformulação, e os /feed e /.env da vida que os scanners sempre testam.

Pior: devolver 200 diz ao buscador que "esta URL está viva", então ela fica na fila e é rastreada de novo repetidamente, enquanto um 404 real vai sendo rastreado cada vez com menos frequência. O guia de gestão de orçamento de rastreamento do Google lista soft 404 explicitamente entre as coisas que desperdiçam recurso de rastreamento. Em um site grande isso é ruído. Em um site que já tem pouca capacidade de rastreamento, é despejar no ralo a cota que poderia salvá-lo.

A correção: coloque um 404.html e faça a plataforma sair do modo SPA

O conserto é desproporcionalmente barato: coloque um 404.html de verdade na raiz da saída do build, o Cloudflare Pages detecta e volta para o modo de site estático, e os caminhos sem correspondência passam a devolver um HTTP 404 genuíno.

Construímos a página 404 dentro do gerador em vez de escrever um arquivo órfão à mão: mesmo CSS e mesma navegação do site, com links para as páginas principais, para que a pessoa real que cair ali tenha para onde ir.

Resultado medido:

• URLs quebradas: 200 / 87KB → 404 / 34KB
• As 67 páginas reais do site seguem devolvendo 200, zero dano colateral
• Repetimos a rodada com o user agent do Googlebot e recebemos o mesmo 404

A verificação cobre três frentes: as URLs quebradas agora dão 404, as URLs boas não quebraram junto, e a identidade de rastreador vê o mesmo que você. Checar só a primeira e dar por encerrado é aposta.

No dia seguinte ao conserto, os links mortos apareceram

No dia seguinte ao soft 404 ser corrigido, gente da própria casa clicou na barra de navegação e bateu num 404. Rastreando, achamos dois links mortos antigos na navegação da home: um apontava para uma página que nunca chegou a ser feita, o outro tinha um nível de diretório a mais, com o caminho correto sendo /how-to-pick/ e o link escrito como /guide/how-to-pick/.

Por que ninguém tinha notado? Porque na era do soft 404, clicar neles devolvia 200 e a home, o que parece "meio esquisito, mas funciona". Corrigido o 404, esses links apareceram como 404 de verdade diante de olhos humanos pela primeira vez. A causa raiz também é típica: a home era mantida à mão e a navegação das páginas internas era gerada, e as duas foram se distanciando conforme evoluíam.

Então não trate o 404 corrigido como caso encerrado. Ele é o começo da aparição de problemas antigos. Nos dias seguintes, espere dragar um lote de links quebrados até então invisíveis.

Transforme a checagem em gate de deploy, e prove antes que ela dispara

Problema que o olho humano não pega não deveria continuar dependendo do olho humano. Colocamos um gate de links mortos no pipeline de deploy: ele varre cada href interno na saída do build, e se algum não aponta para arquivo nenhum e nenhuma regra de redirecionamento o segura, o deploy é bloqueado ali mesmo.

O ponto central é o teste negativo: coloque de propósito um link morto conhecido de volta e confirme que o gate realmente bloqueia. Gate que você nunca viu barrar nada é só enfeite para as pessoas dormirem tranquilas.

A mesma varredura do site inteiro pescou outro problema invisível a olho nu: 27 títulos de página passavam de 30 caracteres de largura completa (incluindo a home, com 33,5), sendo que no mercado taiwanês a página de resultados em chinês tradicional corta por volta de 28 a 30 caracteres, então tudo o que passa disso foi escrito à toa. Comprimimos página a página para menos de 30 caracteres, preservando a marca e a frase-chave central e cortando só o excesso do final, o que zerou a contagem de títulos fora do limite.

Fechamento

O que torna o soft 404 difícil não é o conserto, um 404.html dá conta, é o fato de ele ser assintomático do começo ao fim: monitoramento verde, clique que abre página, e até o seu comando de diagnóstico sendo enganado. Se o seu site roda em Cloudflare Pages ou em qualquer plataforma com SPA fallback, dê um curl agora mesmo em um caminho que não existe e veja o que volta. Se vier 200, você achou um dos motivos de a indexação não sair do lugar. Depois de corrigir, transforme a varredura de links mortos em gate de deploy e use um teste negativo para provar que ela funciona. Já tratamos vários desses problemas do tipo "parece que não está quebrado, então ninguém conserta". Se quer saber o que ainda está escondido no seu site, fale com a gente.

Esse tipo de dívida técnica, transformamos em serviço

Um soft 404 não derruba o seu site. Ele queima o seu orçamento de rastreamento em silêncio, até o dia em que você percebe que as páginas novas nunca são indexadas.

• Arquitetura de site e SEO técnico: códigos de status, canonical, sitemap e robots alinhados de uma vez
• Monitoramento de indexação: status de indexação página a página, identificando as páginas rastreadas mas não indexadas
• Produção de conteúdo: gastar o orçamento de rastreamento nas páginas que têm conteúdo

As especificações estão em Serviço de criação de site iGaming SEO.