Redesign e modernização de websites WordPress
Sou Mariusz Szatkowski e trabalho com WordPress desde 2006. Num redesign, o design vem de si ou do seu designer; eu implemento-o como tema WordPress responsivo, migro os conteúdos, mapeio os redirecionamentos 301 e trato do desempenho e da acessibilidade no código. Trabalho sozinho, por isso o código que recebe é escrito por mim.
Quando compensa reconstruir um website?
Um site antigo costuma dar sinais técnicos antes de parecer antiquado. Se reconhece três ou mais destes, as correções pontuais já não chegam:
- LCP acima de 2,5 s depois de cache e imagens otimizadas: o problema está na arquitetura do tema, não no alojamento.
- PHP preso numa versão antiga: um tema feito à medida ou um plugin crítico não funciona em PHP 8, e os avisos do alojamento acumulam-se.
- Construtor de páginas que não sai: cada página é uma árvore de shortcodes do Elementor, Divi ou WPBakery; se a licença caducar ou o plugin falhar, o conteúdo aparece como texto entre parênteses retos.
- Plugins abandonados: dezenas de plugins ativos, alguns sem atualização há anos, e cada atualização do núcleo do WordPress passa a exigir meio dia de testes.
- Formulários e menus que falham com teclado ou leitor de ecrã: corrigir isto num tema antigo costuma custar mais do que fazê-lo de raiz.
- Checkout desatualizado: a loja não trata bem o IVA no regime OSS para consumidores noutros Estados-Membros, ou os métodos de pagamento locais (MB WAY, referência Multibanco) estão ligados por código que ninguém quer tocar.
Redesign, modernização ou site novo?
Três projetos diferentes acabam muitas vezes com o mesmo nome. Vale a pena perceber qual é o seu antes de pedir orçamento. Para um diagnóstico rápido, use a lista de verificação de prontidão para redesign.
| Critério | Redesign (renovação visual) | Modernização técnica | Site totalmente novo |
|---|---|---|---|
| Quando escolher | O aspeto já não corresponde à marca, mas o site funciona | Lentidão, plugins abandonados, PHP antigo | O negócio, a oferta ou o público mudaram |
| O que muda | Camada visual e modelos de página | Tema, plugins, PHP, base de dados, fluxo de trabalho | Estrutura, conteúdos, tecnologia e aspeto |
| De onde vem o design | Do cliente ou do seu designer | Mantém-se o atual | Do cliente ou do seu designer |
| Conteúdos | Mantêm-se | Mantêm-se, migrados e limpos | Novos, escritos pelo cliente |
| URLs | Mantêm-se | Mantêm-se ou ganham mapa 301 | Nova estrutura com mapa 301 completo |
| Risco para o SEO | Baixo | Médio, controlado com o mapa 301 | Mais alto, o mapa 301 é obrigatório |
Na prática, a maioria dos projetos junta redesign e modernização: um aspeto novo sobre um tema lento não melhora os Core Web Vitals. Se o caso pede um site de raiz, veja a criação de websites e lojas WordPress.
O que faço e o que vem de si
De si ou do seu designer: o design gráfico, os wireframes, a identidade visual e os textos. Se não tem wireframe, envio uma folha de cálculo onde marca, para cada vista, que elementos entram e por que ordem. Se tem um designer, recebo o ficheiro Figma.
Da minha parte:
- tema WordPress responsivo (tema de blocos com theme.json ou tema clássico, conforme o caso) a partir do design recebido;
- migração de páginas, artigos, produtos, campos ACF e imagens, com texto alternativo e datas de publicação;
- inventário de URLs e mapa de redirecionamentos 301 feito antes do lançamento;
- remoção do construtor de páginas e dos plugins redundantes;
- desempenho medido em dados reais de utilizadores (CrUX) e não num único teste Lighthouse;
- acessibilidade no código: HTML semântico, navegação por teclado, contraste, formulários com etiquetas;
- código num repositório Git privado, cada alteração visível em staging antes de ir para produção.
Não vendo alojamento. Trabalho no alojamento que escolher, ou ajudo a mudar se o atual não suportar uma versão recente de PHP.
O que pode partir durante um redesign WordPress?
O mapa de redirecionamentos. Um site com mil URLs precisa de uma folha com mil linhas, cada URL antigo emparelhado com o novo. Cada linha esquecida dá um 404. Faço este mapa no início do projeto, a partir do sitemap, do Search Console e de um rastreio completo do site atual.
Ligações internas. Um artigo antigo que aponta para /servicos/web-design/ continua a apontar para lá depois de o URL mudar. O redirecionamento apanha o clique, mas cadeias de redirecionamentos internos são desnecessárias. Corrijo as ligações na base de dados com WP-CLI, além de criar o ficheiro de redirecionamentos.
Migração de Joomla ou Drupal. Os plugins de importação perdem mais dados do que prometem: itens do K2 no Joomla, tipos de conteúdo do Drupal com campos sem equivalente direto no ACF, utilizadores com outro sistema de palavras-passe. Antes da migração faço um inventário do conteúdo; depois, comparo registo a registo.
Integrações de terceiros. O webhook do CRM espera um nome de campo de formulário específico, o GA4 dispara eventos em seletores que deixam de existir. Listo cada integração no início e volto a testá-las em staging.
Consentimento e RGPD. Um banner com botão de rejeição tão visível como o de aceitação, consentimento demonstrável (artigo 7.º, n.º 1, do RGPD), tipos de letra servidos localmente, mapas e vídeos carregados só depois do consentimento. Num redesign isto entra no tema de origem; acrescentado depois, custa mais.
Loja WooCommerce. Taxas de IVA por Estado-Membro no regime OSS, distinção entre clientes B2B e B2C, MB WAY e Multibanco através do prestador de pagamentos que já usa. Testo tudo em staging com contas de teste do prestador.
A equipa editorial. Quem conhecia o Elementor de cor passa a trabalhar no editor de blocos. Entrego um manual escrito com as tarefas mais comuns da sua equipa.
Acessibilidade: o que a lei portuguesa exige
O Decreto-Lei n.º 82/2022, de 6 de dezembro, transpõe a Diretiva (UE) 2019/882. Produz efeitos desde 28 de junho de 2025 para os serviços prestados a consumidores a partir dessa data (artigo 39.º), e entre os serviços abrangidos estão os serviços de comércio eletrónico (artigo 2.º, n.º 3, alínea g)). As microempresas que prestam esses serviços estão excluídas (artigo 2.º, n.º 5, alínea b)); a exclusão não abrange quem fabrica produtos.
Para organismos públicos aplica-se outro diploma, o Decreto-Lei n.º 83/2018, de 19 de outubro, que transpõe a Diretiva (UE) 2016/2102 sobre a acessibilidade dos sítios web e aplicações móveis do setor público.
Em cada redesign implemento WCAG 2.2 nível AA: estrutura de títulos lógica, navegação completa por teclado com foco visível, contraste mínimo de 4,5:1 no texto, formulários com etiquetas e mensagens de erro claras, texto alternativo. Verifico com axe-core antes de cada publicação e com NVDA e VoiceOver nos modelos principais. Se o design recebido tiver contrastes abaixo do mínimo, aviso o seu designer antes de codificar.
Proteção do SEO durante o redesign
- URLs: mantenho a estrutura sempre que possível; quando muda, cada URL antigo tem redirecionamento 301 para o equivalente novo.
- Metadados: títulos, descrições, etiquetas Open Graph e dados estruturados passam para o novo site, página a página.
- Sitemap: o sitemap novo é enviado ao Search Console no dia do lançamento.
- Depois do lançamento: acompanho no Search Console os erros de rastreio, os 404 e as páginas cujo tráfego cai, e corrijo os redirecionamentos em falta.
Mais sobre velocidade: como acelerar um site WordPress. Sobre segurança: guia de reforço da segurança do WordPress.
Reconstrução completa ou modernização por fases?
Quando o calendário o permite, prefiro modernizar por fases: primeiro o cabeçalho e a navegação, depois as páginas de serviço ou produto, depois o blog e o checkout no fim, porque é aí que entra a receita. Cada fase vai para produção, recebe tráfego real e só depois começa a seguinte. Demora mais no total, e o risco fica repartido.
A reconstrução de uma só vez justifica-se num rebranding, em que todas as páginas têm de mudar no mesmo dia, ou quando o site está tão preso a shortcodes de um construtor de páginas que cada correção mexe em tudo.
Como decorre um projeto de redesign
- Briefing escrito: envia-me o endereço do site, o que deve mudar e o design ou wireframe que tem. As dúvidas resolvo-as por email.
- Análise do site atual: versão de PHP, tema, plugins, integrações, inventário de URLs, dados do Search Console.
- Proposta: âmbito, pressupostos e prazo por escrito, antes de escrever código.
- Contrato: contrato B2B segundo a lei polaca, com fatura com o meu NIF intracomunitário PL7393037445 e autoliquidação do IVA; se eu tiver acesso a dados pessoais, acordo de subcontratação nos termos do artigo 28.º do RGPD.
- Implementação: tema, migração e redirecionamentos num repositório Git privado; cada alteração fica visível em staging com uma descrição escrita.
- Aprovação em staging: verifica e aprova no ambiente de testes.
- Lançamento: antes, testes com axe-core, Lighthouse e verificação manual nos navegadores atuais e em iOS e Android; depois, acompanhamento do Search Console.
Manutenção depois do lançamento
Se quiser, fico com a manutenção do site: monitorização de disponibilidade a cada 1 a 5 minutos, cópias de segurança guardadas pelo menos 30 dias em países da UE e atualizações testadas primeiro em staging. Não ofereço serviço 24/7 nem tempos de resposta garantidos.
Contacto
Envie-me pelo formulário de contacto o endereço do site atual, o que deve mudar e o design que tem. Recebe por escrito as próximas etapas e uma proposta com os pressupostos em que se baseia. Os preços de referência estão na lista de preços.
