Checklist: o que verificar antes de entregares um site a um cliente
A checklist de entrega de site que evita os telefonemas dos primeiros três meses. Trinta minutos de trabalho, organizados pelo que costuma partir primeiro.
O site está pronto, o cliente aprovou, e a vontade de fechar o assunto é enorme. É precisamente aí que se perdem os trinta minutos que evitam os três telefonemas seguintes.
Esta checklist de entrega de site está organizada pelo que costuma partir primeiro — e não pela ordem em que seria bonito verificar. Quase tudo aqui é rápido; o que não é está assinalado.
Antes de dizer que está pronto.
O que expira
Nada nesta secção falha hoje. Tudo nesta secção falha numa data que já está marcada, e é essa a razão para estar em primeiro lugar.
- Certificado TLS válido e a cobrir o domínio certo. Inclui a versão com
e sem
www. Um certificado que cobreexemplo.ptmas nãowww.exemplo.ptfunciona até alguém escrever o endereço com as três letras. - Cadeia de certificação completa. Uma cadeia incompleta funciona no teu browser (que já tem o intermédio em cache) e falha no telemóvel de outra pessoa. É um dos erros mais desagradáveis porque parece resolvido do teu lado.
- Renovação automática confirmada — e não presumida. Se é Let’s Encrypt, força uma renovação de teste. Noventa dias passam depressa e a falha é silenciosa.
- Data de expiração do domínio anotada, com o registo em nome de quem deve. Um domínio registado na conta pessoal de quem já não trabalha lá é uma bomba com temporizador.
O que os motores de pesquisa vêem
- Uma só versão do site responde.
httpredirecciona parahttps, e uma das versões (com ou semwww) redirecciona para a outra. Quatro variantes a servir o mesmo conteúdo é o erro de SEO mais comum na entrega. -
robots.txtsem oDisallow: /de desenvolvimento. Acontece mais do que se admite. -
noindexremovido de todo o lado. No WordPress é uma caixa nas definições de leitura e continua ligada em mais entregas do que devia. - Sitemap gerado e acessível.
- Uma página 404 a sério, que devolva mesmo o código 404 e não um 200 com uma mensagem bonita.
O que o cliente vai testar no primeiro dia
- O formulário de contacto envia — e o email chega mesmo. Não é a mesma coisa. Testa com uma caixa de correio externa, não com a tua. Confirma que não cai no lixo.
- O email sai de um domínio autenticado. Sem SPF e DKIM configurados, as mensagens do site vão para o spam de metade dos destinatários, e o cliente vai concluir que o formulário não funciona.
- Os telefones e moradas estão certos. Parece básico. É a correcção número um da primeira semana.
- O site abre bem no telemóvel de alguém que não és tu. Idealmente num Android antigo.
O que se degrada em silêncio
- Cópias de segurança automáticas ligadas e testadas com um restauro. Uma cópia de segurança nunca restaurada não é uma cópia de segurança, é uma esperança.
- As tarefas agendadas correm mesmo. No WordPress, confirma se o WP-Cron está a ser disparado por um cron a sério — num site com pouco tráfego, a versão de origem só corre quando alguém visita, e as tarefas nocturnas simplesmente não acontecem.
- As actualizações automáticas estão como querem estar. Ligadas em tudo é uma decisão; desligadas em tudo é outra. Não decidir é a pior.
- O tempo de resposta da página inicial anotado, com um número. Daqui a seis meses, quando o cliente disser que “o site está lento”, vais querer saber com o que estás a comparar.
O que resolve as discussões futuras
- Acessos entregues e em nome do cliente. Alojamento, domínio, painel de administração. Se o domínio está na tua conta por conveniência, escreve-o num email para haver registo.
- Está escrito o que a manutenção inclui e o que não inclui. Sobretudo: inclui vigiar se o site está de pé? Se não incluir, diz-se agora, não no dia em que ele cair.
- Está definido a quem se liga e a partir de que ponto, se algo correr mal.
O item que quase nunca está na lista.
Falta um, e é o que decide a experiência dos meses seguintes: quem é que dá por isso quando o site cair.
Se a resposta for “o cliente”, já sabes como vai correr — vais receber uma mensagem ao fim da tarde a dizer que o site está em baixo e vais responder que não sabias. Se a resposta for “eu, por um alerta”, a mesma falha transforma-se numa mensagem escrita por ti com a hora e o estado.
Custa cinco minutos a configurar e é a diferença entre a manutenção parecer um serviço e parecer uma factura. Nem que seja com uma ferramenta gratuita a verificar de cinco em cinco minutos.
Enquanto estás na entrega, faz também a verificação avulsa: o “Está em baixo, ou és só tu?” dá-te o código de estado e o tempo de resposta a partir de um servidor em Portugal, e o verificador de certificado confirma a validade e a cadeia em segundos. Nenhum dos dois pede conta.
O que esta checklist não cobre.
Não cobre acessibilidade, que merece uma lista própria e mais longa. Não cobre desempenho para lá do número de referência — optimizar é outro trabalho e raramente cabe na entrega. E não cobre conformidade com o RGPD para lá do óbvio: se o site recolhe dados, essa conversa é jurídica e não técnica.
Também não te protege da falha mais comum de todas nos primeiros meses, que é o cliente mexer no site e partir alguma coisa. Para isso não há checklist — há cópias de segurança que funcionam e alguém a dar por isso a tempo. É esse segundo trabalho que a monitorização de uptime faz — e é a única parte da entrega que continua a acontecer depois de a entregares.