Páginas 404 personalizadas e soft 404: sirva a página de erro com o status de erro

O que é

A documentação de solução de problemas do Google define um soft 404 como uma URL que devolve uma página informando ao usuário que a página não existe, mas ao mesmo tempo devolve o status 200. Entre as causas, lista um arquivo de include ausente, uma conexão quebrada com o banco de dados, uma página de resultados de busca vazia ou um arquivo JavaScript ausente; essas páginas são excluídas da Pesquisa. A mesma documentação recomenda devolver 404 ou 410 para conteúdo que deixou de existir e descreve uma boa página 404 personalizada como aquela que diz com clareza que a página não foi encontrada, mantém o visual e a navegação do site, tem links para páginas populares e para a página inicial e oferece uma forma de reportar um link quebrado. A documentação sobre códigos de status acrescenta que o conteúdo de respostas 4xx não é usado e que uma URL usada anteriormente que passa a devolver 4xx é descartada com o tempo, com a frequência de rastreamento diminuindo.

No servidor, o error_page do nginx define, por meio de um redirecionamento interno, o URI exibido para determinados erros, com o método alterado para GET nas requisições que não são GET. A mesma diretiva pode alterar o status com =response; o exemplo da própria documentação, error_page 404 =200 /empty.gif;, mostra como um 404 vira 200. Single-page applications que servem index.html para qualquer caminho produzem o mesmo efeito por design.

Por que importa

Um soft 404 desperdiça requisições de rastreamento, mantém URLs mortas nos índices, esconde links quebrados do monitoramento (tudo é 200) e confunde ferramentas que tratam os códigos de status como verdade. Já um 404 verdadeiro com uma página de servidor genérica faz o visitante ir embora.

Como aplicar

• Configure a página de erro (error_page 404 /404.html;) sem =200 e confirme com curl -I https://example.com/no-such-page que a linha de status indica 404 e que o corpo é a sua página.
• Em single-page applications, devolva 404 a partir do servidor para os caminhos que o roteador não conhece ou faça a aplicação renderizar um estado de erro e, quando o framework permitir, defina o status na resposta renderizada no servidor.
• Torne a página autossuficiente: coloque inline os estilos críticos ou referencie assets com fingerprint por caminho absoluto, pois a URL que falhou pode estar num diretório profundo.
• Registre os 404 em log com o referrer e revise-os; os mais frequentes merecem um redirecionamento, e os demais, uma correção na página que contém o link.
• Use 410 para remoções deliberadas se quiser declarar que são permanentes; a pergunta em aberto vinculada discute como os clientes tratam esse código.

Armadilhas

Redirecionar todas as URLs desconhecidas para a página inicial (um soft 404 com 302). Páginas de erro que carregam recursos por caminho relativo e quebram em subdiretórios. Páginas de erro que elas mesmas devolvem 404 para seus assets, ou 500 porque um template precisa de dados que uma requisição de não encontrado não tem.

Single-page applications sem tabela de rotas no servidor

A maioria das single-page applications não consegue devolver 404 a partir do servidor para rotas desconhecidas, porque o servidor não possui a tabela de rotas e rotas parametrizadas exigem uma consulta a dados. A documentação de SEO para JavaScript do Google apresenta duas alternativas que o seu crawler respeita: redirecionar via JavaScript para uma URL que o servidor responde com 404 (por exemplo /not-found) ou adicionar <meta name="robots" content="noindex"> ao documento via JavaScript quando a aplicação determina que a página não existe. Ambas mantêm a página fora do índice; nenhuma fornece um código de status ao monitoramento. Por isso, prefira prerendering ou renderização no servidor do estado de não encontrado com um 404 real, quando o framework permitir, e use os métodos em JavaScript para o resto.