Redirecionamentos e 404s

Quando uma URL do seu site retorna 404, normalmente é uma destas coisas: o conteúdo não está publicado (ou não está publicado ainda), o modo de URL ou o roteamento de idioma mudou, um redirecionamento não consegue fazer seu trabalho, ou a requisição foi por algo propositalmente excluído da sua saída estática. Esta página percorre cada caso e quando corrigir no admin versus na configuração do servidor.

O conteúdo não é construído até estar na hora

Somente o conteúdo publicado e não excluído é gerado. Se uma página agenda a publicação no futuro, ou uma data de unpublish já passou, a página simplesmente não é construída, logo sua URL é um 404 até o próximo build depois que ela se tornar elegível. Após mudar o estado de publicação ou uma janela de agendamento, faça rebuild.

Discrepâncias de roteamento de idioma

O comportamento das URLs depende do Language URL Mode (Settings → Permalinks), que também é onde começa uma classe comum de 404s:

• Se você configurar none (sem segmentos de idioma) mas tiver mais de um idioma, o gerador o substitui pelo modo path e avisa no log do build. Se você está vendo caminhos inesperados no estilo /en/…, verifique esta configuração.
• No modo subdomain, URLs são subdomínios de idioma (como es.yourdomain.com), mas os arquivos ainda são construídos em diretórios output/{lang}/. Seu servidor precisa rotear cada subdomínio ao seu diretório de idioma; esquecer isso faz o subdomínio dar 404 ou servir o idioma errado.
• Um modo de URL obsoleto em um site monolíngue (por exemplo, modo path quando só existe um idioma) produz 404s para os caminhos padrão. Limpe o modo (ou defina o modo correto) e faça rebuild.

O gerador imprime avisos e notas sobre exatamente essas situações na saída do build, então abra o log do build primeiro quando as URLs de idioma estiverem se comportando de forma estranha.

A URL raiz redireciona para uma página errada

O ponto para o qual a raiz do domínio aponta é definido por home_redirect (Settings → Permalinks). Se o slug que você nomeou não for uma página publicada, o log do build avisa "no published page with this slug found.", e o redirecionamento da raiz para de funcionar corretamente. Corrija a configuração ou publique/restaure a página alvo, então faça rebuild.

Redirecionamentos que silenciosamente não se aplicam

Os redirecionamentos se aplicam apenas a caminhos antigos que ainda não contenham conteúdo publicado. Se uma página ou post ainda vive no slug antigo, ela continua servindo 200 para aquela URL e o redirecionamento é ignorado; o log do build ainda marca isso com o aviso "old slug is still active" que o admin mostra ao criar tal redirecionamento. Para fazer um redirecionamento vencer, despublique ou exclua a página antiga primeiro (ou mantenha o redirecionamento e o conteúdo não publicado alternando o estado de publicação).

Redirecionamentos precisam estar ativos (o checkbox de ativo na tela de redirects). Apenas redirects ativos geram saída de redirecionamento na hora do build; um redirect desativado desaparece da saída estática até você ativá-lo (ativar dispara um build).

Formatos restritivos vencem: redirects simples usam o código 301/302/307 que você escolheu e são aplicados na configuração de redirecionamento gerada do servidor; redirects de padrão (slug antigo terminando em * com substituição $1 no destino) funcionam apenas como páginas HTML de redirecionamento no build estático, e são ignorados pelas configurações geradas no servidor.

Quando o próprio 404 está quebrado

O site estático vem com uma página 404 construída. Se essa página falha ao renderizar em um build, o log do build registra uma linha de erro para ela mas continua: o site fica de pé, enquanto uma 404 personalizada ausente deixa em comando a resposta simples "Page not found" do seu servidor até o próximo build bom.

Probes não são servidos com o 404 normal

A configuração de servidor padrão encaminha caminhos comuns de probes de ataque (arquivos de configuração, caminhos de controle de versão, URLs de admin de outras plataformas) por um proxy que não tem nada a ver com sua saída estática, em vez de servir sua página 404 normal. Se você vê 404s registrados exatamente para esses caminhos, são probes, não links quebrados.

Por que um 404 pode passar brevemente durante deploys

A publicação troca a saída atomicamente. Quando a localização do conteúdo ao vivo é um symlink, a ativação é um rename atômico único: zero downtime. Caso contrário, é um rename em duas etapas no mesmo filesystem, com uma breve lacuna entre os dois renames durante a qual uma requisição poderia atingir um diretório ausente. De qualquer forma, uma troca ou se completa integralmente ou a saída anterior permanece no lugar: nunca um site parcialmente escrito.

Para onde ir depois

Assim que você souber que uma URL deveria existir mas dá 404, despublique ou exclua a página antiga, publique a nova e crie um redirecionamento a partir do caminho registrado usando o link por linha Create redirect do monitor de 404s ou a seleção em massa (Admin → Health → aba 404s). O log de 404 registra caminhos ausentes com contagens de hits e URLs de referência para você priorizar as correções.