Quando o Refresh do Teu Website É Na Realidade Uma Reconstrução Disfarçada

O projeto que muda de âmbito a meio do voo

Há uma conversa reconhecível em chamadas de descoberta de projetos de website. O cliente chega querendo um “refresh”. design atualizado, nova fotografia, talvez algumas descrições de serviço atualizadas. O brief é claro. O orçamento está definido. O prazo é 6-8 semanas.

Depois as perguntas técnicas começam. O site corre numa versão PHP que não tem suporte há dois anos. O page builder está tão depreciado que atualizações de tema quebram páginas existentes. A pontuação mobile no PageSpeed Insights é 23. O hosting é partilhado, o que significa que o site compete com centenas de outros sites no mesmo servidor por recursos.

Cada um destes problemas é individualmente endereçável em isolamento. Juntos, descrevem uma arquitetura que não pode ser significativamente refrescada, apenas reconstruída. A conversa sobre orçamento e prazo tem que mudar, normalmente a meio do projeto quando o âmbito real se torna inevitável.

A avaliação técnica que determina o âmbito

Os dados do HTTP Archive sobre o estado global da web mostram que a dívida técnica do website médio aumenta com a idade, cada ano sem manutenção deliberada, o gap entre a tecnologia do site e os padrões atuais alarga-se. Um site construído em 2018 num popular page builder WordPress e nunca substancialmente atualizado acumulou tipicamente 4-6 anos deste gap.

Os sinais específicos que indicam reconstrução em vez de refresh:

Pontuação mobile PageSpeed abaixo de 50. Um score abaixo de 50 no mobile significa que o site está a falhar os Core Web Vitals, LCP acima de 4 segundos, CLS significativo, INP fraco. Estas falhas são quase sempre causadas por problemas arquiteturais: scripts render-blocking, imagens não otimizadas servidas sem atributos de tamanho, bundles JavaScript que executam sincronamente durante o carregamento da página. Refrescar o design visual não corrige estes; requerem mudanças arquiteturais na forma como o site carrega. A documentação do Google sobre experiência de página especifica o que cada modo de falha indica.

Stack de tecnologia em versões end-of-life. Sites WordPress ainda a correr em PHP 7.x estão em software sem suporte com vulnerabilidades de segurança conhecidas que não recebem patches. Atualizar a versão PHP num site construído com plugins depreciados frequentemente quebra funcionalidade.

Estrutura de URL com parâmetros significativos ou nesting profundo. Um site onde as páginas de serviço vivem em /servicos/categoria/sub-categoria/nome-servico/pagina/?lang=pt&ref=nav tem um problema de arquitetura de informação que o redesign visual não pode endereçar.

Autonomia do editor de conteúdo quebrada. Um site onde a equipa de marketing não consegue atualizar texto hero, adicionar uma descrição de serviço, ou publicar uma notícia sem envolvimento do developer tem um problema de arquitetura editorial. Corrigi-lo pode requerer mudar o CMS.

O custo oculto da reconstrução adiada

O argumento para escolher um refresh em vez de uma reconstrução é quase sempre orientado pelo orçamento. A reconstrução custa mais. O timing não está certo. O negócio vai fazê-la “para o próximo ano.”

O cálculo que normalmente falta desta decisão: o custo contínuo de manter uma arquitetura inferior. Um site com pontuação PageSpeed de 23 que converte a 1.2% vs. um site reconstruído a 85 que converte a 3.8% (para um negócio a fazer €30.000 por mês em receita de website) representa um gap de taxa de conversão de €78.000 por ano. A reconstrução a €15.000 paga-se em 70 dias de conversão melhorada. Cada mês de atraso é €6.500 em conversão perdida.

A investigação da Moz sobre o que afeta os rankings de pesquisa mostra que a qualidade da arquitetura é um preditor primário da eficácia de um refresh. Um site rápido e bem estruturado que recebe conteúdo refrescado e design atualizado sinaliza aos motores de busca que o site está ativamente mantido. Um site lento e arquiteturalmente fraco que recebe o mesmo tratamento continua a ter desempenho inferior.

O serviço de website de alta performance do x078 começa cada projeto com uma avaliação técnica que produz um veredicto documentado: refresh ou reconstrução, com evidências específicas para a recomendação. Para marcas de e-commerce e negócios de serviços B2B onde a conversão do website impulsiona diretamente a receita, a questão reconstrução/refresh não é uma preferência de design. É um cálculo financeiro.

Uma avaliação com PageSpeed Insights demora dez minutos e produz evidências. A decisão de reconstrução feita antes do scoping poupa o projeto do resultado mais caro: um refresh que se torna uma reconstrução com orçamento de refresh, entregue atrasado, com uma relação com o cliente tensionada por mudanças de âmbito que eram previsíveis desde o primeiro olhar técnico.

A pergunta correcta

Antes de gastar orçamento num “refresh”, confirma se o que precisas é realmente um refresh ou uma reconstrução. Um refresh num site com problemas estruturais é pintar uma parede com infiltrações. Parece melhor durante um mês.

A auditoria técnica que distingue os dois cenários custa uma fracção do orçamento da reconstrução e evita o erro mais comum: gastar dinheiro na solução errada.