Códigos de status HTTP explicados: 200, 301, 404, 500 e os outros que importam

Atualizado em 3 de novembro de 2026 · Leitura de 5 min

Edson Feitosa de Oliveira Junior Fundador e Engenheiro Líder · PruPru Digital Services

Os códigos de status HTTP são os números de três dígitos que acompanham toda resposta de um servidor quando o navegador ou um aplicativo pede algo a ele. Eles dizem, de forma padronizada, se o pedido deu certo, se o recurso mudou de lugar, se houve erro de quem pediu ou de quem respondeu. Entender esses códigos ajuda desenvolvedores a criar APIs corretas e donos de sites a diagnosticar problemas e cuidar do SEO.

As cinco famílias de códigos de status HTTP

2xx: sucesso

• 200 OK: tudo certo. A resposta contém o conteúdo pedido.
• 201 Created: um recurso foi criado, por exemplo um cliente cadastrado via POST. O ideal é retornar também o cabeçalho Location com o endereço do novo recurso.
• 204 No Content: deu certo, mas não há conteúdo para devolver. Comum em DELETE e em algumas atualizações.

3xx: redirecionamentos

• 301 Moved Permanently: o endereço mudou de vez. Navegadores e o Google passam a usar o novo endereço. É o redirecionamento certo para migrações de site.
• 302 Found: redirecionamento temporário.
• 304 Not Modified: o conteúdo não mudou desde a última vez; o navegador pode usar a cópia em cache.
• 307 e 308: equivalentes ao 302 e ao 301, mas garantem que o método (por exemplo, POST) seja mantido no redirecionamento.

Para SEO, use 301 quando uma página mudar de endereço definitivamente. Redirecionamentos temporários usados por engano em mudanças permanentes, cadeias longas de redirecionamentos e loops prejudicam a indexação. Veja como trocar de site sem perder posições no Google.

4xx: erros do cliente

• 400 Bad Request: o pedido está malformado ou com dados inválidos. Em APIs, retorne junto uma mensagem clara explicando qual campo está errado.
• 401 Unauthorized: falta autenticação ou ela é inválida (por exemplo, token ausente ou expirado). Veja JWT: autenticação explicada.
• 403 Forbidden: o servidor sabe quem você é, mas você não tem permissão. Em aplicações Spring com React, um 403 em requisições POST frequentemente tem relação com CSRF; contamos um caso real em Spring Security 403 em POST.
• 404 Not Found: o recurso não existe.
• 405 Method Not Allowed: o endereço existe, mas não aceita aquele método (por exemplo, DELETE em um recurso que só aceita GET).
• 409 Conflict: conflito com o estado atual, como cadastrar um e-mail que já existe.
• 410 Gone: o recurso foi removido de propósito e não vai voltar. Sinaliza ao Google que a página pode ser retirada do índice.
• 422 Unprocessable Content: o formato está certo, mas os dados não passam nas regras de validação. Muitas APIs usam 400 para isso; escolha um padrão e mantenha.
• 429 Too Many Requests: limite de requisições excedido.

5xx: erros do servidor

• 500 Internal Server Error: erro genérico no servidor, normalmente uma exceção não tratada no código. Veja os logs. O artigo como ler uma stack trace Java ajuda a interpretar o erro.
• 502 Bad Gateway: um servidor intermediário (proxy, balanceador, CDN) recebeu uma resposta inválida do servidor de origem. Comum quando a aplicação caiu ou está reiniciando.
• 503 Service Unavailable: o servidor está temporariamente indisponível, por manutenção ou sobrecarga. Para manutenções planejadas, é o código certo, de preferência com o cabeçalho Retry-After.
• 504 Gateway Timeout: o intermediário esperou demais pela resposta da origem. Geralmente, uma consulta lenta ao banco ou um serviço externo travado.

Boas práticas ao criar uma API

1. Use o código que corresponde ao resultado. Nada de responder 200 com {"erro": "não encontrado"} no corpo. Clientes, monitoramento e ferramentas dependem do código.
2. Diferencie 401 de 403. Não autenticado é diferente de não autorizado.
3. Não exponha detalhes internos em erros 500. Registre a stack trace nos logs e devolva uma mensagem genérica com um identificador do erro. Veja logs em produção: boas práticas.
4. Padronize o corpo dos erros, por exemplo seguindo o formato Problem Details (RFC 9457), com campos como title, status e detail.

Para os fundamentos, veja o que é uma API REST.

Como ver o código de uma página

• No navegador: abra as ferramentas de desenvolvedor (F12), aba Network (Rede), recarregue a página e veja a coluna Status.
• No terminal: curl -I https://prupru.org mostra apenas os cabeçalhos da resposta, incluindo o código.
• No Google Search Console: o relatório de Páginas mostra erros 404, redirecionamentos e erros de servidor encontrados pelo Google. Veja o guia do Search Console.

Soft 404: um erro silencioso

Quando uma página que não existe responde com 200 e uma mensagem de "não encontrado", o Google chama isso de soft 404. A página pode acabar indexada como conteúdo vazio. Configure o site para responder 404 de verdade em páginas inexistentes, com uma página de erro útil, que ofereça busca e links para as seções principais.

Perguntas frequentes