Modernização de sites corporativos antigos com WordPress

Em 2026, um site antigo (legacy site) é mais do que apenas um design desatualizado. É um passivo financeiro e de segurança.

Representa dívida técnica acumulada, uma vulnerabilidade de segurança à espera de ser explorada e um obstáculo que impede a sua equipa de marketing de reagir ao mercado. As grandes empresas mantêm frequentemente estes sistemas porque a ideia de migrar soa a um “transplante de coração digital”. No entanto, o risco de ficar é agora maior do que o risco de mudar.

O Drupal 7 deixou de receber atualizações de segurança a 5 de janeiro de 2025, as plataformas licenciadas continuam a faturar todos os anos e o WordPress mantido dá ao novo site um conjunto documentado de ferramentas para importação, redirecionamentos e integrações.

Neste guia, percorremos as fases estratégicas e técnicas da modernização de um site corporativo antigo com WordPress.

#Como auditar um site antigo antes da migração

O primeiro passo da modernização não é construir; é o inventário.

• Dívida de conteúdo: a sua empresa precisa mesmo daqueles posts de notícias de 2011? Usamos IA para analisar o tráfego histórico e decidir o que migrar, arquivar ou apagar.
• Dívida técnica: mapear integrações personalizadas em que ninguém mexe há cinco anos.
• Capital de SEO: identificar os URLs de alta performance que devem ser protegidos durante a migração para evitar uma queda abrupta de tráfego.

#Sinais de que o site corporativo precisa de ser reconstruído

• O CMS já não recebe atualizações de segurança. O Drupal 7 chegou ao fim de vida a 5 de janeiro de 2025, como anunciou a equipa de segurança do Drupal, e muitos sites corporativos ainda correm nele.
• Publicar uma nova landing page exige um pedido a um programador em vez de dez minutos livres de um editor.
• O marketing quer ligar analytics, um CRM ou automação de marketing, e a plataforma não consegue comunicar com nenhum deles.

#Lista de inventário antes da migração do site

Do lado do conteúdo: cada página e o seu URL, o arquivo de notícias, a biblioteca de media incluindo PDFs, cada formulário, funcionalidades especiais como pesquisa ou configuradores, e cada integração com CRM, ERP ou analytics. Do lado técnico: a stack, as Core Web Vitals, o tráfego orgânico e os backlinks por URL, as vulnerabilidades conhecidas e a conformidade com as WCAG.

Submissões antigas de formulários e listas de newsletter costumam conter dados pessoais. Decida ao abrigo do RGPD o que é efetivamente migrado e o que é apagado, em vez de copiar a base de dados inteira por defeito.

#Que plugins WordPress substituem as funcionalidades de um CMS antigo

Tudo o que não tem linha nesta tabela é desenvolvimento à medida, e é a parte do projeto cujo âmbito deve ser definido com mais cuidado.

#WordPress headless ou monolítico para sites corporativos

Modernizar nem sempre significa uma substituição 1:1.

• Abordagem monolítica: melhor para equipas que querem facilidade de uso máxima com o editor Gutenberg.
• Abordagem desacoplada (headless): ideal para empresas que exigem segurança máxima e querem servir conteúdo a apps, quiosques e sites a partir de um único “cérebro” WordPress.

#Que arquitetura WordPress se adequa à dimensão do site

Um site com algumas centenas de páginas é normalmente bem servido por WordPress gerido (tema de blocos, ACF Pro, Redis como object cache, Cloudflare ou Bunny.net à frente de um alojamento como Kinsta ou WP Engine). Muitos milhares de URLs, ou conteúdo que também alimenta apps, apontam para headless: WPGraphQL com um frontend em Astro ou Next.js. Grupos multilingues escolhem muitas vezes Multisite com WPML ou Polylang, tema do nosso guia de estratégia global de conteúdo em WordPress.

#Requisitos de servidor do WordPress numa migração corporativa em 2026

O contrato de alojamento do novo site costuma ser assinado antes de existir o primeiro template, por isso o ambiente de execução tem de ser especificado cedo. A página oficial de requisitos do WordPress recomenda PHP 8.3 ou superior, MySQL 8.0 ou superior ou MariaDB 10.11 ou superior, e suporte para HTTPS. O WordPress ainda corre em PHP 7.4 e MySQL 5.5.5, mas a mesma página avisa que estas versões chegaram ao fim de vida e podem expor o site a vulnerabilidades.

O ramo do PHP decide quanto tempo a nova plataforma funciona até à primeira atualização forçada. As datas vêm da página de versões suportadas do PHP:

Um site lançado em 2026 em PHP 8.2 perde as correções de segurança no fim do mesmo ano. Inclua PHP 8.3 ou 8.4 na especificação do alojamento, e o caminho de atualização para o ramo seguinte no contrato de manutenção, para que o problema do sistema antigo não recomece na nova plataforma.

Se o site a substituir já for uma instalação antiga de WordPress e não outro CMS, o trabalho está sobretudo no código (tema, plugins, base de dados), e o nosso guia de modernização de bases de código WordPress legado cobre esse caminho.

#Como migrar conteúdo de um CMS legado para WordPress

Migrar dados de um CMS antigo e proprietário para o WordPress era trabalho manual. Hoje é um processo de mapeamento por scripts.

• Normalização de campos: transformamos conteúdo não estruturado em blocos WordPress estruturados.
• Migração de ativos: mover milhares de imagens e PDFs mantendo as suas ligações internas e metadados de SEO.

#Como importar conteúdo de um CMS antigo com WP-CLI

O WordPress não tem importador para Sitecore, para um portal .NET à medida nem para a maioria dos sistemas proprietários. O caminho habitual é exportar da plataforma antiga com um script próprio, gravar o resultado como ficheiro WXR (o formato XML que o próprio WordPress exporta) e importar esse ficheiro pela linha de comandos.

• wp import é a interface de linha de comandos do plugin WordPress Importer. A opção --authors aceita create, mapping.csv ou skip, por isso as contas de autores do sistema antigo podem ser associadas a contas de editores existentes através de um CSV, em vez de serem criadas uma a uma.
• wp media import cria anexos a partir de ficheiros locais ou URLs. Aceita --post_id para associar o ficheiro à página certa, --alt para o texto alternativo e --preserve-filetime para manter a data original do ficheiro como data de publicação.
• wp search-replace reescreve caminhos e domínios antigos em toda a base de dados. Trata corretamente dados PHP serializados, e --dry-run mostra cada alteração sem gravar, que é a execução a rever antes da real.

Corra a importação em staging, compare o número de páginas por template com o inventário e só depois repita-a como importação diferencial final pouco antes do lançamento.

#Fases da migração de um site passo a passo

1. Preparação. Congele a lista de URLs com o tráfego de cada um, prepare o rascunho do mapa de redirecionamentos, escreva scripts de exportação para o CMS antigo e configure um ambiente de staging.
2. Construção. Desenvolva o frontend, implemente o mapa de funcionalidades, ligue as integrações e depois corra a importação por scripts.
3. Testes. QA funcional em vários dispositivos e browsers, QA de conteúdo face ao inventário, QA de SEO dos redirecionamentos, metadados, sitemaps e dados estruturados, uma revisão das Core Web Vitals, uma auditoria de segurança WordPress completa e uma verificação WCAG 2.2.
4. Lançamento. Acorde primeiro um procedimento escrito de reversão, depois mude o DNS, ative os redirecionamentos, submeta o novo sitemap no Google Search Console e acompanhe de perto tráfego, erros e desempenho nas primeiras 48 horas.
5. Pós-lançamento. Compare o tráfego orgânico com o período anterior à migração, corrija os 404 perdidos e forme os editores.

#Como manter os rankings no Google durante a migração de um site

Um projeto de modernização é um fracasso se perder os seus rankings de pesquisa.

• Mapeamento de URL: criamos um mapa 1:1 de URLs antigos para novos. Se o site antigo usava extensões .aspx ou .cgi, garantimos que apontam diretamente para os novos slugs WordPress amigáveis para SEO.
• Preservação de metadados: extraímos todos os title tags e meta descriptions do sistema antigo para garantir continuidade aos olhos do Google.

O melhor redirecionamento é aquele de que nunca precisa, por isso mantenha os URLs inalterados sempre que a nova estrutura o permita. Além de títulos e descrições, transfira as tags canonical, o hreflang, as ligações internas e os dados estruturados.

Se o tráfego orgânico não mostrar sinais de recuperação cerca de quatro semanas após o lançamento, verifique por esta ordem: redirecionamentos em falta ou errados, o relatório de indexação de páginas no Search Console, recursos bloqueados à renderização e tags canonical que ainda apontam para URLs antigos.

#O que a Google recomenda numa mudança de site com alteração de URLs

A Google documenta exatamente este cenário no guia sobre mudanças de site com alteração de URLs. Os pontos que mudam o plano de uma migração corporativa:

• Use redirecionamentos permanentes do lado do servidor (301 ou 308) de cada URL antigo para o novo endereço, e mantenha-os o máximo de tempo possível, em regra pelo menos um ano.
• As páginas que retira de propósito devem responder com 404 ou 410 no novo site, em vez de redirecionarem para a página inicial.
• Atualize as ligações internas para os novos URLs do mapa e garanta que todos os sitemaps listam os novos URLs.
• Remova as tags noindex e os bloqueios no robots.txt que só existiam para a fase de staging. É o erro mais comum no dia do lançamento, porque o staging está corretamente oculto e a definição passa para produção juntamente com a base de dados.
• A ferramenta de alteração de endereço do Search Console serve apenas para mudar para outro domínio ou subdomínio. Uma reconstrução no mesmo domínio não precisa dela.

A Google refere ainda que, num site de dimensão média, podem passar algumas semanas ou mais até os novos URLs aparecerem na pesquisa, e mais tempo em sites grandes. Planeie os relatórios à administração em função dessa janela, em vez de avaliar a migração pela primeira semana.

#Como proteger um site WordPress empresarial

Um CMS sem atualizações é um alvo fácil, porque as suas vulnerabilidades conhecidas são públicas e nunca são corrigidas. Passar para um WordPress mantido permite:

• Mudar para um alojamento com trilho de auditoria: escolha um fornecedor gerido que entregue à sua equipa de segurança o relatório SOC 2 ou ISO 27001, em vez de um servidor que ninguém atualiza desde que a agência original saiu.
• Ligar os editores ao SSO corporativo: autenticação através de Okta ou Microsoft Entra ID por SAML ou OpenID Connect, para que remover um colaborador do diretório também lhe retire o acesso ao wp-admin.

#Como ligar o WordPress aos sistemas da empresa por API

As antigas ligações à base de dados que “falavam” com o site antigo são substituídas por camadas de API modernas. O WordPress funciona como camada de apresentação e comunica com os sistemas de backend através de endpoints JSON seguros, o que torna o site mais rápido e resiliente.

#Como autenticar integrações na REST API do WordPress

Um CRM, ERP ou PIM que escreve conteúdo no WordPress precisa das suas próprias credenciais. Segundo o manual de autenticação da REST API, o WordPress inclui palavras-passe de aplicação (Application Passwords) desde a versão 5.6. São geradas na página de edição do utilizador e enviadas com Basic Auth em pedidos servidos por HTTPS.

Crie um utilizador WordPress dedicado para cada integração, atribua-lhe a função mais baixa que permita a tarefa e gere-lhe uma palavra-passe de aplicação própria. Quando termina o contrato com um fornecedor, revogar essa única palavra-passe corta o acesso sem mexer em nenhuma conta de editor. Os pedidos feitos no browser numa sessão iniciada usam autenticação por cookie, e esses têm de levar um nonce wp_rest, caso contrário o WordPress trata-os como não autenticados.

#Como melhorar as Core Web Vitals depois de migrar para WordPress

Os sites antigos são quase sempre lentos. Modernizar para WordPress traz:

• Formatos de imagem modernos: desde o WordPress 6.5 é possível carregar e usar imagens AVIF como JPEG ou PNG, desde que a biblioteca Imagick ou GD do servidor suporte AVIF. A conversão automática dos ficheiros existentes precisa de um filtro, por isso planeie-a como parte da importação de media.
• Cache na periferia da rede: servir o site corporativo a partir de localizações CDN próximas dos visitantes em vez de um único servidor de origem.

#Como calcular o ROI da migração de um site

Não existe um número universal de ROI. O que se repete de projeto para projeto é a estrutura do cálculo.

Os dois pontos de partida mais comuns comportam-se de forma diferente. Vindo do Drupal 7, não há licença para cancelar, o ponto de equilíbrio chega mais tarde e o argumento mais forte é o risco: uma plataforma sem atualizações de segurança é um incidente à espera de data. Vindo de um CMS proprietário licenciado como o Sitecore, desaparece a maior linha do orçamento anual, e o período de retorno é aproximadamente o custo do projeto dividido pela poupança anual.

Acrescente também uma coluna de conformidade. O Ato Europeu de Acessibilidade (EAA) aplica-se desde 28 de junho de 2025 a muitos serviços digitais dirigidos a consumidores na UE, e em Portugal os organismos públicos já estão obrigados pelo Decreto-Lei n.º 83/2018 à acessibilidade dos seus sites e aplicações móveis. O projeto de modernização é orçamentado individualmente depois da auditoria.

#Agência WordPress para migração de sites corporativos antigos

Na WPPoland, o trabalho de migração de sistemas antigos assenta em três coisas.

1. Especialistas em migração: já lidámos com transferências do Sitecore, Drupal 7 e portais .NET personalizados.
2. Defesa de SEO: cada migração começa com um inventário de URLs congelado e um mapa de redirecionamentos testado, e termina com uma verificação de 404, indexação e tráfego orgânico face à base anterior à migração.
3. Construções à prova de futuro: não nos limitamos a “corrigir” o site antigo; criamos a base para o seu crescimento em 2027 e 2028.

#Quando modernizar um site corporativo antigo com WordPress

Um site corporativo antigo raramente precisa de ser deitado fora, precisa de ser reconstruído por partes, com o conteúdo e os URL preservados para não perder o que já rankeia. É esse tipo de reconstrução que fazemos em projetos de desenvolvimento WordPress.

A tecnologia antiga não fica obsoleta de um dia para o outro, mas o custo do atraso acumula-se. Se o site corporativo ainda corre numa stack frágil de 2018, o fraco desempenho, o risco de segurança e o atrito editorial vão continuar a aparecer. Uma modernização estruturada com WordPress pode preservar o que funciona e substituir as partes que bloqueiam o negócio.

Se um site antigo está a atrasar a equipa, anote a stack atual, as integrações de risco e as páginas que mais importam. Isso basta para começar um briefing de modernização útil.

#O que decidir antes da migração de um site

Três decisões moldam o calendário. A primeira é o veredicto sobre o conteúdo: cada página antiga é marcada como migrar, arquivar ou apagar durante a auditoria, e os URLs com melhor desempenho entram numa lista protegida. Essa lista torna-se o mapa de 301, incluindo endereços antigos .aspx ou .cgi que têm de chegar aos novos slugs WordPress.

A segunda é a arquitetura. Um build monolítico com Gutenberg serve uma equipa de marketing que edita todos os dias, enquanto uma configuração desacoplada serve uma empresa que também alimenta apps móveis ou quiosques com o mesmo conteúdo. Mudar isto a meio do projeto significa refazer os templates.

A terceira são as integrações. Liste cada sistema de backend com que o site antigo comunica, como o SAP ou um CRM proprietário, e decida quais recebem uma camada de API e quais se retiram com a plataforma antiga. Inclua o SSO nessa lista, para que o acesso dos colaboradores ao site siga o seu fornecedor de identidade.

Com estas três decisões tomadas, os prazos das perguntas frequentes, cerca de 3 a 5 meses para um site corporativo de dimensão média e 6 a 12 para uma rede global, passam a ser algo com que se pode planear. Faça a migração em paralelo e a mudança blue-green só depois de o mapa de redirecionamentos estar fechado.