Depois de migrar o WordPress, o texto abre normalmente, mas fotos, capas ou imagens de produtos não aparecem? Imagens quebradas no WordPress após migração podem ter causas diferentes: URL antiga, arquivo não transferido, miniatura ausente, bloqueio no servidor ou cache desatualizado. Antes de instalar um plugin ou trocar endereços em massa, investigue uma página e uma imagem afetadas.
Se você ainda precisa conferir a transferência do site como um todo, comece pelo guia de migração do WordPress para outro servidor. Aqui o foco é descobrir por que a mídia não carrega.
Antes de corrigir: acesso, backup e ambiente de teste
Tenha acesso autorizado ao painel, às ferramentas de desenvolvedor do navegador e, para conferir arquivos, ao gerenciador da hospedagem/SFTP ou ao suporte. Anote o domínio antigo, o domínio pretendido e se há CDN, cache ou armazenamento externo de mídia.
Antes de alterar URLs, arquivos, configurações, miniaturas ou limpar caches amplos, tenha um backup recuperável dos arquivos, especialmente das mídias, e do banco de dados. Verifique se consegue restaurar uma amostra e planeje a reversão. Em loja ou site que recebe leads, restaurar uma cópia antiga do banco em produção pode apagar dados novos. Para intervenções amplas, use um ambiente de staging isolado e não sincronize dados de teste cegamente para o site ativo.
Passo 1: identifique a URL da imagem que falhou
- Abra uma página afetada em janela sem login e escolha uma imagem específica. Veja se o problema também ocorre para visitantes.
- Abra as ferramentas do navegador, acesse Rede/Network, filtre por imagens e recarregue a página. Anote a URL solicitada, o código HTTP e mensagens no Console. Se não houver requisição, role a página para disparar carregamento tardio e confira se o HTML, o tema ou um plugin de lazy load inclui a imagem.
- Abra a URL exata da requisição em outra aba. Ela pode ser diferente do atributo
src: o navegador pode escolher outra variante desrcset, e plugins/CDNs podem servir formatos alternativos. Não compartilhe URLs privadas ou assinadas.
Por exemplo, https://exemplo.com/wp-content/uploads/2025/03/foto.jpg ilustra um caminho comum, não uma regra. O diretório e a URL de uploads podem ser personalizados; subpastas de ano/mês podem estar desativadas, e algumas mídias são servidas externamente.
| Sinal observado | O que conferir em seguida |
|---|---|
| 404 na URL da imagem | Compare URL, nome e caminho com o arquivo no destino; verifique também regras do servidor e da CDN. O 404 não prova que o original foi perdido. |
| 403 | Peça ao suporte para investigar regras de acesso, hotlink, CDN e permissões. Não abra permissões indiscriminadamente. |
| Domínio antigo na requisição | Identifique onde a referência foi gerada: conteúdo, dados da mídia, tema/plugin, configuração de CDN ou cache. |
| Aviso de mixed content/HTTPS | Veja no Console e na Rede se o navegador tentou HTTPS, bloqueou a requisição ou recebeu erro. Uma imagem HTTP em página HTTPS não é necessariamente bloqueada de imediato; confira o guia de mixed content no WordPress. |
| 200, mas imagem invisível | Confira se a resposta é realmente uma imagem válida, a variante pedida, regras de CSS/lazy load, Console e cache/CDN. Um status 200 não basta. |
Passo 2: confira o arquivo e o caminho de uploads
No painel, abra Mídia > Biblioteca e localize o anexo, se houver. A URL exibida nos detalhes é uma pista, não prova de que o arquivo físico esteja presente. Compare-a com a URL que falhou na página. Imagens inseridas diretamente por tema, construtor ou URL externa podem nem ter um anexo correspondente na Biblioteca.
Com acesso autorizado aos arquivos, ou com ajuda do suporte, procure o original no local de uploads configurado para aquele site. Em instalações convencionais, ele costuma ficar em wp-content/uploads, às vezes em pastas de ano/mês. Confira também letras maiúsculas/minúsculas e extensão do nome. Se faltar, verifique se o backup da origem contém o arquivo, restaure primeiro em staging e planeje a transferência específica. Mudar uma URL não recria uma mídia ausente.
Se o arquivo existe, mas a URL devolve 403 ou 404, compare o caminho publicado com o diretório servido pela hospedagem e peça avaliação das regras de acesso. Em sites com offload ou CDN, o arquivo pode estar em armazenamento externo: não conclua que está ausente apenas por não encontrá-lo no disco local.
Passo 3: descubra de onde vem a URL antiga
Compare a URL solicitada na página, a URL da mídia no painel (se houver) e o endereço público planejado após a migração. Em instalação de site único, você pode consultar, sem editar, os campos Endereço do WordPress (URL) e Endereço do site (URL) em Configurações > Geral. O primeiro indica onde ficam os arquivos centrais da instalação; o segundo, o endereço público do site. Em algumas instalações esses campos são definidos por configuração e não podem ser alterados no painel. Não os troque por tentativa: um erro pode impedir o acesso.
Se só alguns posts apontam para o domínio anterior enquanto a Biblioteca aponta para o atual, procure a referência no conteúdo, blocos, construtor, tema ou plugin. Se o problema é generalizado, avalie a URL/base de uploads e a configuração da CDN ou do armazenamento externo. Compare o HTML servido para visitantes com o que foi salvo: cache de página pode manter referências antigas mesmo depois de uma correção na origem.
Quando uma substituição de URLs faz sentido?
Apenas se você confirmar que a mudança de domínio exige essa troca, que os arquivos estão acessíveis no destino e qual trecho exato da URL deve mudar. Com backup testado, um responsável técnico pode simular a mudança em staging e conferir uma amostra de posts, imagens e dados de plugins. O wp search-replace do WP-CLI entende dados serializados e permite --dry-run; ao definir o escopo, preserve a coluna GUID, conforme a orientação de migração do WordPress. Multisite, construtores e dados de plugins exigem avaliação própria.
Não execute SQL bruto de substituição, não troque todo http por https e não faça alteração global sem escopo. Se não tem acesso e experiência para testar e reverter, entregue o diagnóstico ao suporte; não mude o endereço público por causa de uma imagem isolada.
Passo 4: só as miniaturas estão quebradas?
Abra a URL do original e a da variante solicitada na listagem, galeria ou versão móvel. Se o original abre, mas uma miniatura não, pode faltar um arquivo derivado, ter mudado o tamanho gerado pelo tema/plugin ou persistir uma referência antiga. Os metadados de um anexo registram o arquivo e seus tamanhos, mas registros não garantem presença física.
Após confirmar o original, backup, espaço e recursos disponíveis, teste a regeneração de um único anexo em staging com uma ferramenta compatível. O wp media regenerate aceita IDs específicos e regenera miniaturas, mas não recupera o original não migrado nem corrige automaticamente URLs antigas gravadas no conteúdo. Só amplie o procedimento após verificar impacto nas páginas. Se a imagem carrega, mas pesa demais, isso é outro problema: veja como otimizar imagens no WordPress sem confundir desempenho com erro 404.
Passo 5: faça uma correção pequena e valide
Depois de identificar a causa, experimente em staging uma intervenção delimitada: recuperar um arquivo realmente ausente, corrigir uma referência específica com ferramenta segura ou tratar o cache da camada identificada. Leve a mudança para produção somente com backup e plano de reversão. Limpar toda a CDN é mais amplo que invalidar uma página ou recurso e não repõe arquivos ausentes.
Em janela sem login, teste no computador e no celular:
- a URL anteriormente quebrada e a resposta na aba Rede;
- o original e as variantes mostradas em posts, listagens, galerias e imagens destacadas;
- uma página antiga e uma recente; em loja, um produto e sua galeria;
- o Console e o HTML, procurando novos erros e referências antigas inesperadas;
- as camadas de cache/CDN relevantes, sem confundir HTML antigo em cache com arquivo ausente.
Quando parar e chamar o suporte: multisite, várias origens de mídia, CDN/offload, restrições de acesso persistentes ou uploads ausentes também no backup. Forneça uma página de exemplo, a URL do recurso sem credenciais, o código HTTP, o horário do teste e o resultado da conferência do arquivo. Isso permite investigar sem fazer mudanças em massa às cegas.
