Como Corrigir Erros 404 Depois de Publicar o Seu Site ou App

Se a sua app funciona localmente mas as páginas devolvem 404 depois de publicar, a causa mais comum é a falta de encaminhamento de aplicação de página única (SPA): o servidor procura um ficheiro chamado /dashboard que não existe, porque essa rota só existe em JavaScript. A solução é uma regra de fallback que serve o index.html para as rotas da app. Outras causas são ficheiros em falta no resultado do build, caminhos sensíveis a maiúsculas, diferenças na barra final, um caminho base incorreto e rotas de API que nunca foram publicadas.

Comece por anotar exatamente qual o URL que dá 404 e como lá chegou. O padrão aponta diretamente para a causa.

Passo 1: encontre o padrão

O que vê	Causa mais provável	Ir para
A página inicial funciona; clicar em ligações funciona; atualizar ou abrir uma ligação profunda dá 404	Falta o fallback SPA	Passo 2
Todas as páginas dão 404, incluindo a página inicial	Pasta errada publicada, ou o build não foi publicado	Passo 3
As páginas carregam, mas imagens, tipos de letra ou scripts dão 404	Ficheiros em falta no build, ou caminhos errados	Passo 4
Funciona com `/sobre/`, falha com `/sobre` (ou o contrário)	Tratamento da barra final	Passo 5
`/Sobre` falha mas `/sobre` funciona	Servidor sensível a maiúsculas	Passo 4
A página carrega, mas os pedidos de dados a `/api/...` dão 404	API não publicada ou sem rota	Passo 6
URLs antigos de um site anterior dão 404	Faltam redirecionamentos	Passo 7
Só num domínio personalizado	Configuração de DNS ou do domínio	Passo 8

Para ver o código de estado real, abra as ferramentas de programador (clique com o botão direito → Inspecionar), vá ao separador Rede, recarregue e veja o estado do primeiro pedido.

Passo 2: adicione o fallback SPA

Este é o caso clássico. Numa aplicação de página única em React, Vue ou Svelte, o servidor só tem alguns ficheiros reais: index.html e alguns ficheiros JavaScript e CSS. Rotas como /dashboard ou /projetos/42 são tratadas por um router no navegador.

Clicar numa ligação funciona: o router altera o URL e desenha a nova página sem pedir nada ao servidor.
Atualizar ou abrir uma ligação diretamente falha: o navegador pede ao servidor /dashboard, o servidor não tem esse ficheiro e devolve 404.

A solução é uma regra que diz: se o pedido não corresponder a um ficheiro real, sirva o index.html com estado 200 e deixe o router assumir. A forma de o adicionar depende do alojamento (consulte a documentação atual do seu alojamento, porque os detalhes mudam):

Alojamento	Regra de fallback típica
Netlify	Um ficheiro `_redirects` na pasta publicada com `/* /index.html 200`
Vercel	Uma reescrita no `vercel.json` de todos os caminhos para `/index.html` (os presets de frameworks costumam tratar disto)
Cloudflare Pages	Serve um fallback no estilo SPA por predefinição quando não existe um `404.html` na raiz
Nginx	`try_files $uri $uri/ /index.html;` no bloco `location /`
Apache	Uma regra de reescrita no `.htaccess` que envia os pedidos que não são ficheiros para `index.html`
GitHub Pages	Não tem reescritas do lado do servidor; as soluções alternativas comuns são o encaminhamento por hash ou um `404.html` que redireciona

Certifique-se de que a regra não engole ficheiros reais: os pedidos a /assets/app.js têm de continuar a devolver o ficheiro JavaScript. Se devolverem o index.html, obtém uma página em branco com um erro "Failed to load module script". Veja como corrigir uma página em branco.

Dê também ao router uma rota catch-all, para que os URLs que não correspondem a nenhuma página mostrem uma mensagem amigável de "Página não encontrada" em vez de nada.

Se não puder alterar as definições do servidor, o encaminhamento por hash (URLs como /#/dashboard) evita o problema, porque a parte após # nunca é enviada ao servidor. É uma solução alternativa, não a primeira escolha: os URLs são menos bonitos e menos amigáveis para os motores de pesquisa.

As frameworks que renderizam páginas no servidor ou as geram no momento do build (Next.js, Astro e semelhantes) costumam ter ficheiros reais ou rotas de servidor para cada página, por isso este problema específico é menos comum aí. O equivalente lá é uma página que nunca foi gerada no momento do build.

Passo 3: verifique o que foi realmente publicado

Se tudo der 404, o servidor provavelmente não está a servir a sua app compilada.

A pasta certa. O alojamento tem de publicar o resultado do build (normalmente dist para o Vite, build para o Create React App, out para uma exportação estática do Next.js), e não a raiz do projeto.
O build correu. Leia o registo de publicação. Se o build falhou, o alojamento pode não ter publicado nada, ou ter publicado uma versão antiga.
O index.html está no nível superior da pasta publicada, e não numa subpasta.
O caminho base corresponde. Se a app for servida em exemplo.com/app/, tem de ser compilada com essa base (base do Vite, basename do React Router), ou todas as rotas e recursos falham.

Passo 4: corrija ficheiros em falta e caminhos errados

Quando as páginas carregam mas os recursos dão 404:

Sensibilidade a maiúsculas. O macOS e o Windows normalmente tratam Logo.png e logo.png como o mesmo ficheiro. A maioria dos servidores Linux não. Faça com que cada referência corresponda exatamente ao nome real do ficheiro.
Ficheiros fora do build. No Vite, os ficheiros em public/ são copiados tal como estão e referenciados a partir da raiz (/logo.png). Os ficheiros importados no código são agrupados. Um ficheiro noutro sítio do projeto pode nem sequer ser publicado.
Caminhos relativos. images/foto.jpg é resolvido em relação ao URL atual, por isso falha em /blog/post-1. Use /images/foto.jpg.
Ficheiros carregados guardados no disco local. Se os carregamentos dos utilizadores foram escritos na pasta do próprio servidor, desaparecem quando é publicada uma nova versão. Use um armazenamento de ficheiros adequado.

Passo 5: trate as barras finais de forma consistente

/sobre e /sobre/ são URLs diferentes. Os alojamentos diferem na forma como acrescentam ou removem a barra, e uma incompatibilidade com as suas ligações ou com o router pode produzir 404 ou ciclos de redirecionamento. Escolha um estilo, faça com que as suas ligações o usem e configure o alojamento para redirecionar a outra forma para ele. A consistência também ajuda os motores de pesquisa, que de outra forma podem ver duas cópias de cada página.

Passo 6: corrija rotas de API que dão 404

Se a página carregar mas o separador Rede mostrar pedidos a /api/... a devolver 404:

O backend não está publicado. Um alojamento estático serve apenas ficheiros; um backend tem de correr algures.
O caminho é encaminhado de forma diferente em produção. Em desenvolvimento, um proxy pode ter encaminhado /api para um servidor separado. Em produção, o alojamento precisa de uma reescrita equivalente, ou o frontend tem de chamar o endereço real da API.
O fallback SPA apanhou o pedido. Um pedido à API que devolve index.html com estado 200 significa que a regra de fallback é demasiado ampla. Exclua /api/* dela.

Os pedidos da app publicada a /api/orders devolvem 404, mas funcionam na pré-visualização. Verifique como /api é encaminhado na pré-visualização e na app publicada, e faça com que o frontend publicado chegue ao backend da mesma forma.

Passo 7: redirecione URLs antigos

Se mudou de outro site ou reestruturou o seu, os URLs antigos que as pessoas e os motores de pesquisa ainda usam darão 404. Adicione um redirecionamento 301 (permanente) de cada URL antigo para o seu novo destino. Mantenha uma lista e teste uma amostra depois do lançamento. O nosso guia sobre como migrar um site WordPress explica como criar essa lista.

Passo 8: verifique o domínio

Se a app funcionar no endereço do alojamento mas der 404 no seu domínio personalizado, o domínio pode estar a apontar para o projeto errado, ou o alojamento pode ainda não ter o domínio associado ao seu site. Verifique os registos DNS e as definições de domínio do alojamento. Veja como ligar um domínio personalizado.

Torne a sua página 404 real útil

Alguns 404 estão corretos: alguém escreveu mal um URL. Faça com que essa página seja útil:

Uma mensagem curta e uma ligação para a página inicial e as secções principais
Uma caixa de pesquisa, se o site tiver pesquisa
O mesmo cabeçalho e navegação do resto do site

Sempre que a sua configuração o permitir, devolva um estado 404 real para as páginas que não existem. Uma mensagem de "não encontrado" devolvida com o estado 200 é o que os motores de pesquisa chamam um soft 404, e pode desperdiçar o tempo de rastreamento deles e confundir a indexação.

Erros comuns

Testar apenas clicando. Teste sempre colando URLs profundos num novo separador e atualizando.
Um fallback que apanha tudo. Os recursos e as rotas de API devolvem index.html, o que causa páginas em branco e erros de API confusos.
Maiúsculas e minúsculas trocadas que só falham no servidor.
Publicar a pasta de código-fonte em vez do resultado do build.
Reestruturar URLs sem redirecionamentos. Cada ligação antiga torna-se um 404.

404 na Mythex

Na Mythex publica a partir do espaço de trabalho, e as interfaces estáticas são publicadas como sites estáticos. Se uma página publicada der 404, dê ao agente o URL exato, se acontece ao atualizar ou ao clicar, e o que mostra o separador Rede, e peça-lhe que verifique o encaminhamento. Publique de novo depois da correção, porque a app em produção é um instantâneo até voltar a publicar. Se alterou o projeto há pouco tempo e o site em produção parece antigo, publique de novo e faça uma atualização forçada. Use Corrigir com IA no diálogo de publicação se o build falhar. Veja Como publicar e Resolução de problemas de publicação na documentação, e o nosso guia sobre como depurar uma app criada com IA.

Lista de verificação do 404

Anotou exatamente que URLs dão 404 e se ao clicar, ao atualizar ou em ambos os casos
O fallback SPA serve index.html para as rotas da app, com estado 200
O fallback exclui ficheiros reais e /api/*
O router tem uma rota catch-all de "não encontrado"
A pasta de resultado do build é a que está publicada, e o build teve sucesso
O caminho base corresponde ao sítio onde a app é servida
A maiúscula ou minúscula dos nomes dos ficheiros corresponde a todas as referências
Os caminhos dos recursos começam por /
Estilo consistente das barras finais
Rotas de API publicadas e encaminhadas em produção
Redirecionamentos 301 para os URLs antigos
Ligações profundas testadas colando-as num novo separador

Perguntas

Porque é que tenho um 404 quando atualizo uma página da minha app React?

Numa aplicação de página única, rotas como /dashboard existem apenas em JavaScript. Clicar numa ligação funciona porque o router a trata no navegador, mas uma atualização pede ao servidor um ficheiro /dashboard que não existe. A solução é uma regra de fallback que serve o index.html para as rotas da app.

Como adiciono um fallback SPA na Netlify, Vercel ou Nginx?

Na Netlify, adicione um ficheiro _redirects com /* /index.html 200. Na Vercel, adicione uma reescrita no vercel.json que envia todos os caminhos para /index.html. No Nginx, use try_files $uri $uri/ /index.html; no bloco location. Consulte a documentação do seu alojamento, porque as regras mudam.

Porque é que as minhas imagens ou ficheiros dão 404 depois de publicar?

Normalmente o ficheiro não está no resultado do build, a maiúscula ou minúscula do caminho não corresponde (os servidores costumam ser sensíveis a maiúsculas, ao contrário do seu portátil), ou o caminho é relativo quando devia começar por uma barra.

Uma página em falta deve devolver um estado 404 real?

Sim. Mostre uma página de não encontrado útil, mas com o estado 404 sempre que a sua configuração o permitir. Os motores de pesquisa tratam uma mensagem de "não encontrado" devolvida com o estado 200 como um soft 404, o que desperdiça tempo de rastreamento e pode confundir a indexação.