Verificação de site WordPress sem autenticação

A ferramenta abaixo obtém a versão pública de um endereço e diz o que daí resulta. Não se autentica, não faz varrimento de rede e não adivinha. Lê o mesmo que o navegador do seu visitante: o código de estado depois dos redireccionamentos, os cabeçalhos, o HTML e os ficheiros que esse HTML manda buscar antes da primeira pintura. Esses ficheiros são mesmo transferidos e pesados, em vez de estimados.

#O que a verificação mede de facto

A primeira camada são pedidos HTTP nossos a partir de um ponto da rede Cloudflare: tempo até ao primeiro byte, código de estado depois de resolvidos os redireccionamentos, cabeçalhos de segurança, cabeçalhos de cache e compressão. A segunda camada é o próprio HTML, de onde saem o título, a descrição, o canónico, o número de títulos de primeiro nível, os blocos JSON-LD, o atributo de idioma e a forma como as imagens estão declaradas.

A terceira camada é o peso do arranque da página e é a que costuma mudar a conversa. A verificação recolhe do head todas as folhas de estilo e todos os scripts sem defer, ou seja, exactamente aquilo que um navegador tem de acabar de transferir antes de conseguir desenhar seja o que for. Depois vai buscá-los e indica o número real de kilobytes, separado entre CSS e JavaScript, com o tempo do mais lento e a lista de domínios externos de onde vêm.

No WordPress juntam-se algumas coisas públicas por desenho que ainda assim apanham os donos de surpresa. Os caminhos dos ficheiros de plugins e temas revelam o que está instalado e em que versão, porque o número de versão costuma estar no endereço da folha de estilo. O ponto REST com a lista de utilizadores responde sem autenticação se ninguém o fechou. O ficheiro xmlrpc.php continua muitas vezes a responder, apesar de a maioria das instalações já não precisar dele para nada.

#Porque não existe aqui uma pontuação

Isto é uma decisão e não uma falha. Uma pontuação convida a exactamente uma pergunta seguinte, o que fazer com ela, e a resposta honesta a essa pergunta é outra auditoria. O peso não tem esse problema. Dezanove pedidos bloqueantes é um número que se vê descer. Um megabyte de JavaScript antes da primeira pintura aponta para um plugin concreto. Onze pedidos vindos de dois domínios externos apontam quase sempre para um serviço de tipos de letra e um gestor de etiquetas, e ambos foram decisões de alguém que podem ser revertidas.

A camada tem um tecto e o tecto merece ser dito. Medimos peso e tempo de resposta, não a experiência dos seus utilizadores. Isto não é uma medição de Core Web Vitals nem substitui nenhuma. Os dados de campo são recolhidos dos seus visitantes reais ao longo de vinte e oito dias e já lhe pertencem, gratuitamente, na Google Search Console, no relatório de Core Web Vitals. Se quer saber como é a finalização de compra num telemóvel com rede fraca em Braga, aquele relatório é o único que responde. Os nossos números dizem que parte da página está por trás do que ele mostra.

#O que a verificação não consegue ver

A lista do que fica fora de alcance é curta e vale a pena conhecê-la antes de tomar o resultado por um retrato completo. A verificação nunca entra na área de administração, por isso não sabe nada sobre contas, papéis, nem sobre quem entrou pela última vez a partir de um endereço desconhecido. Não vê a base de dados, por isso não diz se as tabelas estão a inchar com transients abandonados. Não verifica cópias de segurança, porque as cópias não são públicas por definição. Não compara as versões de plugins detectadas com uma base de dados de vulnerabilidades, por isso uma versão lida é um facto e não uma avaliação de risco. E verifica exactamente o endereço que indicou, não o site inteiro.

A vista autenticada é uma lacuna à parte. O WordPress serve aos utilizadores autenticados um conjunto de consultas completamente diferente e costuma desligar a cache de página para eles. Uma loja que responde a um visitante em algumas centenas de milissegundos pode demorar várias vezes mais com um cliente autenticado e carrinho cheio. Uma verificação de fora não mostra isso, e nenhuma ferramenta sem acesso à conta o mostra.

#Como ler cada classe de resultado

Os resultados de gravidade alta custam dinheiro ou segurança de imediato. Falta de HTTPS no endereço final, um noindex numa página que devia ser indexada, um ponto aberto com a lista de utilizadores, quatro ou mais dos cinco cabeçalhos de segurança em falta, um primeiro byte lento. Também cai aqui o arranque pesado: quinze ou mais pedidos bloqueantes, ou mais de meio megabyte antes da primeira pintura. Cada um tem uma solução concreta, quase sempre na configuração do servidor ou num plugin que já tem instalado.

Os resultados de gravidade média descrevem um estado que se aguenta um ano sem avaria enquanto a vantagem se vai perdendo. HTML sem cache, ficheiros bloqueantes servidos sem compressão, tipos de letra carregados dos servidores da Google em vez do seu domínio, descrição em falta, nenhum bloco de dados estruturados, imagens sem dimensões, sitemap ausente. Quem tem tráfego estável agenda isto para a revisão seguinte. Quem tem loja em época alta leva primeiro a compressão, a cache e as imagens, porque são as que chegam mais depressa ao carrinho.

Os resultados de gravidade baixa são sobretudo rastos que a pilha tecnológica deixa: a versão do WordPress no gerador meta, o nome e a versão do servidor num cabeçalho, vários títulos de primeiro nível na mesma página, tempos de cache curtos em ficheiros estáticos, imagens sem carregamento diferido. Nada disto derruba um site. Arrumam-se ao lado de outro trabalho, não em vez dele.

As confirmações ficam à parte. Quando a ferramenta diz que os cabeçalhos de segurança estão completos, que o HTML veio da cache, que há dados estruturados e que o arranque é leve, isso não é enchimento. Responde à pergunta que os donos de sites fazem mais vezes, que é se a equipa anterior fez o trabalho.

#Quando a resposta honesta é que não é preciso fazer nada

Acontece mais vezes do que o mercado de ferramentas de diagnóstico sugere. Um site institucional num alojamento decente, com WordPress actual, cabeçalhos completos, cache sensata e arranque leve, não precisa de nada nosso. Se o relatório mostra apenas resultados de gravidade baixa e confirmações, é este o caso. Feche o separador e volte daqui a seis meses.

Há também um estado intermédio em que o melhor é esperar. Se mudou de tema ou de alojamento na semana passada, os nossos números já descrevem a versão nova enquanto a Search Console continua a descrever a antiga durante mais um mês. Não encomende trabalho com base em duas fontes que descrevem dois sites diferentes. Deixe primeiro a janela avançar.

E um terceiro caso: um resultado real que não é seu para resolver. Um cabeçalho de segurança em falta, falta de compressão ou HTML sem cache são muitas vezes configuração do alojamento e não do site. Uma mensagem ao apoio técnico do alojamento resolve isso mais barato do que qualquer projeto.

#O que fazemos com o endereço que indicar

Obtemos páginas públicas no endereço que submeter, não nos autenticamos em lado nenhum e não guardamos nada além de um contador anónimo de execuções. O relatório não vai para nenhuma lista de distribuição, porque nunca pedimos um e-mail. Se seguir para o contacto, o formulário chega preenchido com o endereço e os três resultados mais graves, e vê o texto todo antes de enviar seja o que for.

#Para onde ir se o relatório mostrou algo real

Resultados de gravidade média que se repetem costumam significar falta de acompanhamento e não uma coisa partida, e a resposta a isso é a manutenção de sites WordPress. Arranque pesado e primeiro byte lento levam a acelerar um site WordPress. Ponto de utilizadores aberto, xmlrpc.php a responder e cabeçalhos ausentes são material para uma auditoria de segurança WordPress, porque estas três não compensam resolver uma de cada vez.