← Blog

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 cobre exemplo.pt mas não www.exemplo.pt funciona 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. http redirecciona para https, e uma das versões (com ou sem www) redirecciona para a outra. Quatro variantes a servir o mesmo conteúdo é o erro de SEO mais comum na entrega.
  • robots.txt sem o Disallow: / de desenvolvimento. Acontece mais do que se admite.
  • noindex removido 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.