A página inicial funciona, mas vários posts publicados mostram “não encontrado”? No caso de erro 404 em todos os posts WordPress, comece pelas respostas HTTP e pelas URLs finais. Depois confira as regras de links permanentes e o servidor. Não mude a estrutura pública de endereços nem crie redirecionamentos em massa antes de identificar a causa.
Uma tela com aparência de erro não comprova uma resposta HTTP 404. O código 404 indica que o recurso solicitado não foi encontrado, mas, sozinho, não revela se a resposta veio do WordPress, do servidor ou de uma camada intermediária. Se só uma URL antiga que mudou de endereço falha, veja o guia de redirecionamento 301 no WordPress. O procedimento abaixo trata de falhas em vários endereços atuais de posts.
Antes de começar: reúna evidências e prepare o backup
Tenha acesso autorizado ao painel, o endereço atual de dois ou três posts publicados afetados e uma URL que funciona. Para cada requisição, anote o horário, a URL digitada, eventuais redirecionamentos, a URL final e o status HTTP final; a aba Rede (Network) das ferramentas do navegador ajuda nessa leitura. Teste também uma página e um arquivo de mídia que você sabe existir. Assim você distingue falha de posts de falha mais ampla, sem alterar nada.
Antes de abrir a tela de Links permanentes, salvar configurações ou modificar regras, faça um backup restaurável de arquivos e banco e registre a estrutura atual. Preserve também uma cópia de .htaccess, se houver Apache, ou da configuração do servidor com ajuda da hospedagem. A própria visita à tela de permalinks pode atualizar regras internas, portanto ela não é uma verificação estritamente de leitura.
Faça mudanças primeiro em um staging WordPress protegido que reproduza, tanto quanto possível, o roteamento de produção. Se ele usa outro servidor ou outra configuração, um teste bem-sucedido ali não prova que a produção está corrigida. Planeje a reversão da mudança pontual; em loja ou site com novos cadastros, restaurar todo o banco de uma cópia antiga pode apagar dados recentes.
1. Confirme se os posts falham no endereço atual
Em janela sem login, se o conteúdo é público, abra a home e as URLs de posts. No painel, confira o endereço indicado para cada post publicado. Anote se houve troca de slug, migração ou alteração de cache/CDN pouco antes do incidente. Se o navegador mostra “404” mas o status final é 200, registre essa diferença: a aparência da página não permite classificar a resposta.
Para um mesmo post publicado, conhecer o ID permite testar no ambiente apropriado a forma simples https://exemplo.com.br/?p=123 (troque 123 pelo ID real). O WordPress documenta permalinks simples e amigáveis. Compare o status e o destino final: se o endereço simples redirecionar para a URL amigável que falha, ele não demonstrou que o post abre. Se o conteúdo realmente abre pela forma simples, enquanto a URL amigável do mesmo post retorna 404, há uma pista de falha no roteamento; não é prova de uma causa específica nem motivo para adotar a URL simples como substituta.
2. Confira a estrutura de Links permanentes sem trocá-la
Com backup e staging preparados, abra Configurações → Links permanentes e anote a opção selecionada, a estrutura personalizada e as bases opcionais, se usadas. Segundo a documentação oficial da tela, visitá-la já dispara uma atualização das regras de reescrita do WordPress; não é necessário clicar em “Salvar alterações” apenas para isso. Compare novamente os exemplos de posts e seus status HTTP. Esse comportamento pode variar na prática com plugins, hospedagem e arquitetura; confirme o resultado, não presuma a correção.
Não alterne para “Simples” ou “Nome do post” para tentar corrigir: escolher outra estrutura pode mudar as URLs públicas. Se um responsável técnico decidir salvar a mesma estrutura para tentar atualizar regras de arquivo em uma instalação Apache, faça o teste controlado com cópias prévias e verifique as mensagens do painel. Arquivo .htaccess não gravável ou configuração do servidor inadequada pode impedir que o roteamento passe a funcionar. Não repita o salvamento em série: o flush de regras é uma operação custosa.
3. Descubra onde a reescrita está falhando
Apache na origem
No Apache, o WordPress pode usar .htaccess para encaminhar URLs amigáveis ao index.php (handbook oficial). Peça à hospedagem ou ao administrador que compare as regras atuais com a cópia preservada e com a instalação real (raiz, subdiretório ou multisite). Também é preciso conferir se o servidor aceita essas diretivas: a documentação do Apache sobre AllowOverride explica quando regras em .htaccess são ignoradas.
Não substitua o arquivo inteiro por um modelo genérico. Ele pode conter regras necessárias da hospedagem, de plugins ou de segurança; o responsável técnico deve localizar a causa nos logs e corrigir só o trecho pertinente.
Nginx na origem ou como proxy
Em Nginx standalone, .htaccess não controla o roteamento. As regras de encaminhamento para o WordPress ficam na configuração do servidor; o guia oficial para Nginx traz um exemplo com try_files para um cenário específico, não um bloco para copiar sem adaptação. Peça à hospedagem que examine a configuração do site, a integração PHP e os logs da requisição afetada, considerando subdiretórios, multisite, proxy e cache.
Nginx também pode funcionar como proxy na frente de Apache. O cabeçalho Server: nginx não identifica, por si só, o servidor de origem. Se o erro começou depois de migrar WordPress de servidor, compare a stack antiga com a nova junto da hospedagem; não altere os endereços só porque o mecanismo de reescrita mudou.
O que cada resultado sugere
| Observação | Hipótese, não diagnóstico | Próximo passo |
|---|---|---|
Home responde 200, URLs amigáveis dos posts dão 404 e ?p=ID exibe o conteúdo sem terminar na URL com erro |
Roteamento de permalink ou camada intermediária | Compare regras internas, configuração da origem e logs. |
| Somente um endereço antigo falha, mas o post atual abre | Link desatualizado ou slug alterado | Descubra o destino correto; avalie um 301 apenas para o caso confirmado. |
| O endereço do post redireciona antes de devolver 404 | Regra de redirecionamento, proxy ou destino final | Guarde a cadeia e identifique a camada que produziu cada salto. |
| Home e posts respondem 500 | Outra classe de incidente | Siga o checklist de erro 500 no WordPress e acione o suporte. |
| Staging abre os posts, mas produção não | Diferença de ambiente possível | Compare servidor, proxy e cache antes de aplicar mudanças em produção. |
Se somente posts de um tipo personalizado falham, ou o site é multisite, delimite o problema antes de aplicar uma orientação feita para posts comuns de um site único.
4. Valide a correção e defina quando parar
Após uma alteração pontual e autorizada em staging, teste as mesmas URLs de posts, uma página, a home e uma URL que deve retornar 404. Compare URLs finais e status HTTP com os registros iniciais. Para aplicar em produção, use backup recente, janela de mudança e plano de rollback; verifique de fora do painel e considere o efeito do cache/CDN. Se aparecerem novos 404, loops ou erros 500, reverta a mudança específica com a configuração preservada e peça ajuda técnica, em vez de restaurar automaticamente o banco inteiro.
Sem acesso aos logs ou sem staging comparável, pare antes de editar regras. Envie à hospedagem URLs, horários, códigos, cadeia de redirecionamentos, servidor/proxy conhecido e mudanças recentes. Isso dá ao suporte condições de localizar a falha sem mascará-la com 301 em massa.
