O que você pode perguntar à sua IA

Somente-leitura, encontrou um skimmer de cartão, um backdoor com execução remota, o jQuery do core adulterado e 3 administradores fantasma — e te deixou o plano de limpeza exato.

Cruza a evidência: um PHP «suspeito» de 0 bytes era falso positivo, e um spam de apostas dado como «resolvido» seguia injetado, com cloaking, em 3 pontos.

Confirmou o falso positivo (bot score 0, URLs de admin legítimas) e deixou pronta a whitelist do IP.

Reconstrói a linha do tempo a partir de usuários e logs — e quando o host já rotacionou os logs, te avisa em vez de inventar um vetor.

Lê um por um: separa os benignos (restos de um plugin, módulos do core) dos realmente perigosos, com prova de cada um.

Recebia mais de 100 envios por mês mas não havia webhook, a licença não trazia o add-on e 2 snippets estavam em rascunho — não precisava rebuild, só a ponte.

Encontra cada página, shortcode e template de Elementor onde ele aparece — sem procurar na mão.

Inventaria tudo: qual form está ativo, seus destinatários e webhooks (um ia ao Salesforce, outro a um CRM) — desenrola o setup.

Lê as entradas e te dá a proporção real (ativas vs spam do Akismet) e de quais páginas vem cada uma.

Causa raiz: uma mudança de TTL de cache (28 dias → 10 min) dobrou os renders em PHP e saturou os workers — não foi ataque, foi config.

Mediu a cobertura real (12% do CSS usado, YouTube no início) e, por ser Agency, escreveu o mu-plugin do fix e o deixou ativável com 1 clique.

Um pico de scrapers batendo em paths sem cache, sem Redis, mais uma credencial velha martelando o site — com a mitigação exata.

A auto-investigação junta sozinha os fatais, 5xx, brute-force e mudanças recentes e infere a causa provável — antes de você perguntar.

Encontrou 587 MB de tabelas de staging duplicadas, mais de mil revisões e tabelas órfãs de um plugin — pesando em cada request.

Encontrou três camadas de cache servindo o velho (edge do host, um 304 eterno e o TTL) e montou o purge-on-publish.

Re-traçou 130 redirects ao vivo, separou os seus de uma camada externa e deixou os seus 25/25 a um único salto.

Verificou: produção estava limpa (139/139 páginas), o alegado era a URL de staging — não aceitou o claim às cegas.

Monta um 410 Gone genuíno e a tira do sitemap, sem noindex nem bloquear robots — verificado em staging.

Causa: uma regressão do plugin do Stripe 10.9.0 que travava o sheet de pagamento — o fix era atualizar para 10.9.1, verificado.

Não — descartado com evidência: só o Stripe renderiza o botão, os wrappers do WooPayments estavam vazios.

Um bug de expiry/sync com o Stripe (não do plugin de membros) — 238 assinantes resincronizados, o flapping parado, 0 erros.

Reconciliou conta por conta: 458 com assinatura ativa, 38 a triar — com a lista exata para revisar.

Não era bug: a loja enviava só para os EUA; um endereço de fora falhava, um dos EUA dava «Free shipping» OK.

Um script apagava utm_source ao carregar a página — ~$2.500/semana em ads perdendo atribuição. Localizado, com o fix.

Instalou o A/B testing via GTM (sobrevive aos push de staging a prod) com a meta atada ao submit do form, verificado.

Um defeito de roteamento por nível — corrigido para os free irem à lista free, verificado na config.

Reativou o logger de crawlers LLM (estava desligado em prod) e verificou que registra — para você ver quem faz scraping.

O serviço de email não tinha API key válida — milhares de envios falhando desde uma data exata; nova key, verificado sem falhas.

Verifica o alinhamento de SPF / DKIM / DMARC e o serviço de envio, e diz o que falta para chegar à caixa de entrada.

Lê a config de notificações do form: para qual email vai, a confirmação e se falta um webhook ao CRM.

Mediu um CLS de 1.95 — o logo sem dimensões e as fontes carregando tarde. Por ser Agency, escreveu o mu-plugin com os preloads e o aspect-ratio e deixou ativável com 1 clique → CLS 0.07.

A imagem do hero no celular era um JPG de 337 KB e o CDN servia a cópia de desktop aos telefones. WebP leve + preload por dispositivo, ativável com 1 clique.

A versão de tablet era um JPG de 252 KB enquanto as outras já eram WebP. Trocou para WebP e purgou o cache — ativável com 1 clique.

Mede um por um — GTM 515 KB / 920 ms, Facebook, o challenge do CDN — e diz quanto você ganha removendo ou adiando cada um.

Inventariou os plugins, o tema e até os snippets de código guardados no banco, e diz o que é e o que não é compatível antes de tocar em nada.

Ele abriu: só deixava uma tag de Analytics morta no HTML — risco zero, mas pronto para remover.

Leu cada snippet ativo direto do banco de dados e confirmou que o código é moderno e compatível.

Encontrou WP_DEBUG e WP_DEBUG_LOG em true no wp-config — vazando erros e um log crescendo. Preparou a mudança para false com backup do arquivo.

Um plugin escrevia «Migrating…» em cada request. Desenganchou e truncou o log num mu-plugin one-time — ativável com 1 clique.

Não: eram arquivos da plataforma do host gerenciado (um auto_prepend e um checksum comparado com a versão errada). Dois falsos positivos, com a prova.

Viu os hooks de wp_head que rodam no front-end (os que um scanner externo não vê) e determinou que era a integração em runtime de um terceiro, não algo colado no banco.

Não era bug do tema: era o focus ring do navegador no link de cada card. Entregou o CSS exato para suavizar sem perder acessibilidade.

Um script de terceiros carregava tarde e bloqueava o render no iOS; adiantá-lo no <head> resolveu — verificado num iPhone real.

Detectou 2 saltos ao sitemap e deixou a linha corrigida em 0 saltos — e avisa quando a visão antiga é só cache do CDN, não o arquivo real.