| Sinal observado | Causa raiz provável | Ação corretiva imediata |
|---|---|---|
| Tela vermelha "site enganoso" | Malware ou phishing detectado pelo Safe Browsing | Isolar o site e escanear o core e o wp-content |
| Aviso "este site pode prejudicar" | Download malicioso servido por plugin comprometido | Auditar plugins desatualizados e remover injeções |
| Queda de tráfego sem aviso visível | Cloaking: conteúdo spam só para o Googlebot | Inspecionar a URL no Search Console com renderização |
| Redirecionamentos suspeitos | Pharma hack no .htaccess ou no banco de dados | Limpar redirecionamentos e revisar usuários admin |
Legenda: o aviso do Safe Browsing é o sintoma visível da blacklist do Google WordPress, e some quando a reanálise confirma o site limpo.
--- ## Blacklist do Google WordPress não é penalidade de ranking Cair na blacklist do Google WordPress derruba o tráfego em até 95% num só dia, mas a causa é segurança, não SEO: o navegador bloqueia o acesso antes da página carregar. Uma penalidade de ranking, ao contrário, rebaixa posições aos poucos e aparece como ação manual no Search Console. A confusão custa caro porque o dono tenta "melhorar o SEO" enquanto o problema real é um arquivo PHP injetado servindo phishing. A reanálise do Safe Browsing trata só a segurança; a recuperação de posições vem depois, quando o Googlebot recrawleia o site limpo. Tratar os dois como o mesmo problema é o erro número um que a gente vê no suporte da FULL. A separação importa para o crawl budget: enquanto o site está marcado, o Googlebot reduz o rastreio e atrasa a recuperação, mesmo depois da limpeza. --- ## Vulnerabilidades reais por trás da blacklist do Google WordPress A maioria das marcações na blacklist do Google WordPress começa em um plugin desatualizado: um único CVE crítico sem patch vira porta de entrada para a injeção que o Safe Browsing detecta. Os números abaixo são reais, do perfil público do WPVulnerability cruzado com o NVD. O Contact Form 7 acumulou a CVE-2020-35489, CVSS 10.0, um upload irrestrito que permitia subir scripts maliciosos antes da versão 5.3.2, hoje corrigida. No All in One Security, a CVE-2016-10887, CVSS 9.8, expunha dados antes da 4.0.9. Ambas já têm patch, o que reforça: rodar a versão atual fecha a porta. É esse tipo de catalogação que a FULL faz como a única CNA (CVE Numbering Authority) brasileira sob a CISA desde maio de 2022. --- ## Risco atual versus risco histórico de cves Distinguir risco atual de risco histórico evita o alarme falso: um plugin com 44 CVEs todos corrigidos, como o All in One Security, sinaliza manutenção ativa, não fragilidade. O risco real é o CVE sem patch rodando hoje no seu site, não a falha já resolvida há anos. Quem escreve sobre vulnerabilidade aqui literalmente atribui IDs CVE oficiais, então o enquadramento é técnico, não comercial. Manter o Wordfence e o All in One Security atualizados, com o firewall ativo, corta a maior parte dos vetores que terminam em blacklist do Google WordPress. A leitura honesta do histórico de um plugin é mais útil que o número bruto de CVEs: o que importa é quantos seguem abertos.Legenda: o relatório "Problemas de segurança" do Search Console aponta as URLs afetadas pela blacklist do Google WordPress.
--- ## Passo a passo: Como remover a blacklist do Google WordPress Sair da blacklist do Google WordPress segue uma ordem técnica sem atalho: limpar antes de pedir revisão. Solicitar reanálise com o malware ativo só renova o bloqueio. Os cinco passos abaixo levam de 1 a 3 dias somando a análise do Google, e cada um tem um check de validação objetivo antes de avançar. ### Passo 1: Confirme a marcação no Search Console Abra o relatório "Problemas de segurança" no Google Search Console e identifique o tipo exato: malware, conteúdo enganoso ou download nocivo. O relatório lista URLs de exemplo afetadas, que servem de mapa para a limpeza. Cruze isso com o Google Search Central, que documenta como o Safe Browsing classifica cada categoria. ### Passo 2: Isole o site e faça backup antes de limpar Coloque o site em manutenção e gere um backup completo do estado infectado antes de qualquer alteração. O backup do estado sujo é forense: permite comparar arquivos e entender o vetor. Em seguida, revise os usuários administradores e troque todas as senhas, porque uma conta admin fantasma reinfecta o site horas depois. ### Passo 3: Remova o malware na origem Escaneie o core, os plugins e a pasta wp-content em busca de código injetado, comparando com os arquivos originais. O processo de remoção de malware precisa cobrir o banco de dados e o .htaccess, não só os PHP. Um firewall de aplicação ativo durante a limpeza impede a reinfecção pelo mesmo vetor. ### Passo 4: Valide que o site está realmente limpo Antes de chamar o Google, prove que o site está limpo: rescaneie, verifique se os redirecionamentos sumiram e confirme que nenhum arquivo voltou a ser modificado. O cuidado para não perder posicionamento entra aqui, evitando derrubar conteúdo legítimo junto com o código malicioso. ### Passo 5: Solicite a reanálise ao Google Com o site comprovadamente limpo, peça a revisão pelo botão "Solicitar revisão" no relatório de segurança. Descreva o que foi removido e como fechou a brecha. A análise leva de 1 a 3 dias úteis; durante esse período, não altere o site. Aprovada a revisão, o aviso vermelho some e o tráfego retorna conforme o Googlebot recrawleia. --- ## Como manter o site fora da blacklist do Google WordPress Manter o site fora da blacklist do Google WordPress custa menos que a limpeza emergencial, e o número justifica: segundo o Cloudflare Radar, nos últimos 28 dias, 16,4% dos ataques de aplicação mitigados no Brasil foram bloqueados por WAF. Essa é a fatia que um firewall corta antes de virar injeção. Atualização automática de plugins, firewall ativo, backup diário e monitoramento contínuo formam a barreira de quatro camadas que evita a reincidência. O monitoramento é a camada mais esquecida: um site pode ser reinfectado dias depois por uma backdoor despercebida, e sem monitoramento de malware você só descobre quando o aviso volta. Configurar alertas de integridade de arquivo torna a defesa proativa. --- ## Ferramentas e plano para automatizar a defesa Automatizar a defesa contra a blacklist do Google WordPress reduz o tempo de exposição, e quatro ferramentas reais cobrem o ciclo: o Wordfence faz varredura e firewall; o All in One Security adiciona hardening de login; o Google Search Console monitora o status e dispara a revisão; o UpdraftPlus garante o backup para restaurar em minutos. No plano PRO da FULL (R$849), o All in One Security e o UpdraftPlus já vêm no bundle, e o custo por site fica em torno de R$85 quando você gerencia múltiplos projetos. A gente vê no suporte da FULL que sites com firewall e backup automático raramente voltam à blacklist do Google WordPress. Conheça os planos da FULL para ativar a defesa em um clique, ou escaneie agora com o FULL Scan e consulte o repositório de vulnerabilidades da FULL. ---De 1 a 3 dias úteis após o pedido de reanálise, desde que o site esteja realmente limpo. O Safe Browsing reprocessa a solicitação e remove o aviso vermelho quando confirma a ausência de malware. Pedir revisão com o código ainda ativo só renova o bloqueio e atrasa a saída. A limpeza na origem precede sempre o pedido.
Não de forma confiável. O Google pode recrawlear e limpar a marcação sozinho com o tempo, mas isso leva dias ou semanas a mais. O botão "Solicitar revisão" no relatório de Problemas de segurança do Search Console acelera o processo para a janela de 1 a 3 dias. Sem o pedido ativo, você perde uma fatia relevante de tráfego enquanto espera.
Porque a backdoor ou o usuário admin fantasma não foi removido junto. Uma reinfecção típica vem de um arquivo PHP oculto no wp-content ou de uma conta administradora criada pelo invasor. Sem trocar todas as senhas, revisar usuários e manter um firewall ativo, o mesmo vetor reabre em horas. A varredura precisa cobrir banco de dados e .htaccess, não só os arquivos do core.
Indiretamente. A blacklist é um bloqueio de segurança no navegador, não uma penalidade de ranking, mas a queda de tráfego de até 95% e a redução do crawl budget afetam o desempenho. Quando o site é limpo e a revisão aprovada, as posições tendem a se recompor à medida que o Googlebot recrawleia. SEO e segurança são problemas separados que aparecem juntos neste caso.
Plugins com CVEs críticos sem patch são os principais vetores. Casos históricos como o CVE-2020-35489 do Contact Form 7, CVSS 10.0, e o CVE-2016-10887 do All in One Security, CVSS 9.8, mostram o padrão: uma falha de upload ou exposição de dados vira porta de injeção. Ambos já têm correção, o que reforça que rodar a versão atual fecha a brecha. Atualizar é a defesa mais barata.