Do WordPress para um site à medida: quando faz sentido e o que implica

Mude quando o trabalho o justificar

Um site à medida pode ser um bom investimento quando o site atual dificulta repetidamente algo que a empresa precisa de fazer. Talvez os editores introduzam a mesma informação em vários sítios. Talvez os pedidos devam chegar a equipas diferentes segundo regras cada vez mais difíceis de manter. Ou talvez o catálogo tenha crescido para além do que a organização das páginas permite.

Nestas situações, pode conceber o conteúdo, os ecrãs de edição e as ligações em função do trabalho que as pessoas realmente fazem. Um editor pode introduzir um evento uma única vez e a respetiva data aparecer corretamente em todo o site. A equipa pode receber um pedido já acompanhado dos dados relevantes do cliente. Também pode acordar quais são as próximas alterações importantes, em vez de adaptar todos os requisitos aos plugins disponíveis.

Essas melhorias têm de ser concebidas, desenvolvidas e testadas. Substituir o WordPress, por si só, não as produz. Um sistema à medida mal planeado pode deixá-lo com um editor menos capaz e custos de manutenção mais elevados.

Comece por descrever o problema em termos de negócio: o que as pessoas têm dificuldade em fazer, com que frequência acontece, quanto tempo ou trabalho custa e como seria um resultado satisfatório. Depois compare as formas de lá chegar. Escolha a opção menos exigente que cumpra o requisito e que alguém consiga continuar a operar.

De que tipo de mudança precisa?

As pessoas usam «site novo» para descrever projetos bastante diferentes. Esclareça o que vai contratar antes de comparar preços.

Mudar de fornecedor pode bastar se o site em si lhe servir e o problema estiver na forma como é operado. O nosso guia para mudar de fornecedor sem reconstruir o site aborda essa decisão em separado.

Usar o WordPress apenas para gerir conteúdo, uma opção conhecida como «headless WordPress», é uma possibilidade real: a API REST do WordPress permite que aplicações separadas trabalhem com o conteúdo de acordo com as permissões de acesso. Isso não significa que os dados ou o comportamento de todos os plugins estejam disponíveis nessa API. A nova interface pública pode continuar dependente da estrutura antiga do conteúdo e das regras dos plugins. Pergunte o que esta opção resolve, o que fica no WordPress e quem mantém a ligação.

Quando faz sentido manter o WordPress

Se a sua equipa consegue publicar com facilidade, as funções necessárias trabalham bem e as alterações são razoavelmente simples, manter o WordPress pode ser a escolha sensata. As necessidades normais de publicação não justificam, por si só, encomendar uma substituição.

Mesmo um site pouco prático pode ter um problema reparável. Páginas lentas podem exigir a análise das imagens, do alojamento, do trabalho da base de dados ou de uma função específica. Um editor difícil pode melhorar com uma estrutura de conteúdo mais clara ou melhor desenvolvimento no WordPress. Avalie os problemas e as suas consequências em vez de considerar o número de plugins um diagnóstico.

Compare também plataformas de mercado adequadas. Se uma delas já tratar bem as suas reservas, loja ou publicações, configurá-la e fazer uma mudança cuidadosa pode exigir menos trabalho contínuo do que um sistema à medida.

A sua capacidade também conta. Alguém tem de decidir o que um sistema à medida deve fazer, verificar se o faz e pagar a sua manutenção. Pode contratar o apoio técnico, mas a empresa continua a precisar de alguém que tome decisões e aceite o trabalho. Se essa capacidade não existir, uma plataforma já disponível e fácil de gerir pode ser mais adequada.

Descubra o que o site realmente faz

O número de páginas é um ponto de partida. O âmbito da migração depende do conteúdo, das relações e das tarefas que existem por trás dessas páginas.

Percorra o site com as pessoas que o utilizam e operam. Inclua as partes que os visitantes nunca veem:

• Conteúdo: páginas, artigos e outros tipos de conteúdo; categorias e etiquetas; autores e datas de publicação; traduções e ligações entre elas.
• Ficheiros: imagens originais e outros ficheiros, legendas, textos alternativos, anexos e locais onde cada elemento é utilizado.
• Encontrar informação: menus, pesquisa, filtros, padrões de URL, redirecionamentos existentes, títulos e descrições SEO e regras sobre as páginas que os motores de pesquisa devem indexar.
• Tarefas dos visitantes: formulários, confirmações, entrega de mensagens de correio eletrónico, início de sessão, acesso a contas e permissões.
• Trabalho ligado: sistemas de clientes ou contabilidade, ferramentas de envio de correio eletrónico, análise de dados, importações, exportações, tarefas agendadas e outros processos em segundo plano.

Decida se cada elemento deve ser mantido, substituído ou retirado. Registe quem pode tomar essa decisão e como vai saber que o resultado funciona. Um plugin abandonado pode ser removido; outro pode estar a enviar discretamente os pedidos de que a equipa comercial depende.

Se vende produtos, adesões ou reservas, defina esse trabalho num âmbito separado. Produtos, encomendas, direitos de acesso dos clientes, renovações, disponibilidade e fornecedores de serviços ligados exigem decisões explícitas. A migração de conteúdo não resolve como uma subscrição ativa ou uma reserva existente vai continuar. Os sistemas e fornecedores concretos têm de ser investigados antes de alguém prometer a sua transferência.

Conceba o editor com tanto cuidado como as páginas públicas

Pode continuar a ter um sistema de administração depois de deixar o WordPress. Defina o que este deve permitir à sua equipa fazer. Um desenvolvimento à medida não inclui automaticamente todas as funções a que os editores estão habituados.

Decida o que contém cada tipo de conteúdo. Um evento pode ter data, local, ligação para reservas e artigos relacionados. Um campo próprio para cada dado facilita a sua reutilização e validação. Também exige que se acordem as exceções: um evento de vários dias, um local ainda desconhecido ou uma ligação para reservas acrescentada mais tarde.

Acorde quem pode criar, aprovar e publicar conteúdo. Inclua rascunhos, agendamento, pré-visualização, histórico de revisões, gestão de ficheiros, menus, pesquisa e edição de redirecionamentos quando a sua equipa precisar destas funções. Decida como os editores corrigem um erro e se conseguem anular uma alteração.

Antes de aceitar o editor, peça a utilizadores reais que concluam tarefas representativas. Uma pessoa deve preparar um artigo, acrescentar uma imagem e o seu texto alternativo, ver a página num telemóvel, agendar a publicação, corrigir um erro e encontrar um item antigo. Observe onde precisa de ajuda. Uma demonstração bonita diz menos do que ver a sua equipa terminar uma tarefa normal.

O que pode ser transferido e o que tem de ser reconstruído?

O WordPress tem uma ferramenta de exportação. O seu formato de exportação WXR contém conteúdo documentado, como artigos, páginas, tipos personalizados, comentários, campos, categorias e etiquetas. Pode fornecer dados de origem valiosos. Não é uma cópia funcional de todo o site.

A equipa que faz a migração tem de examinar o que a sua instalação guarda realmente: a base de dados, os ficheiros carregados, as exportações, as respostas da API e os registos próprios dos plugins. Guarde uma cópia original segura antes de transformar seja o que for. Identifique onde está cada campo necessário e como os registos se relacionam.

Mapear dados significa decidir onde pertence cada valor antigo no sistema novo. O autor tem de continuar associado ao artigo certo. Uma categoria pode tornar-se um tema. Uma ligação para uma história relacionada tem de apontar para a nova versão dessa história. Acorde como tratar valores em falta e duplicados em vez de os deixar desaparecer sem aviso.

As imagens precisam de uma transferência e verificações próprias. Confirme que os ficheiros existem no novo local, continuam associados ao conteúdo certo e carregam em tamanhos adequados. Atualize os URL de imagens e de downloads incluídos no conteúdo quando necessário. Ver uma imagem numa página migrada não basta se continuar a ser servida pelo site antigo que pretende encerrar.

A disposição do conteúdo também precisa de ser analisada. O WordPress explica que os blocos podem guardar marcação e atributos, enquanto os blocos dinâmicos podem guardar apenas um marcador para conteúdo gerado mais tarde. Por isso, um artigo copiado pode conter instruções que o novo sistema não compreende. Os construtores visuais de páginas têm estruturas próprias e devem ser examinados à parte.

A solução pode passar por converter o conteúdo em componentes suportados, reconstruir disposições selecionadas ou simplificar páginas antigas com aprovação editorial. Copiar o HTML visível pode conservar a aparência em alguns casos, mas não prova que os editores conseguirão atualizar o resultado corretamente. Acorde tanto o resultado público como a forma de o editar.

Exemplo de uma pequena editora

Imagine uma editora a migrar um site WordPress. Este é um exemplo hipotético, não um resultado obtido para um cliente. O artigo de teste inclui um autor, uma imagem principal, duas notícias relacionadas e um formulário para pedidos sobre publicidade.

O título e o texto do artigo são importados corretamente. A equipa verifica depois se o autor e a data de publicação foram mantidos, se as notícias relacionadas levam às páginas certas e se a imagem foi transferida com a legenda e o texto alternativo. Um editor abre o artigo, altera a introdução e vê a pré-visualização. Assim são testados em conjunto o conteúdo e a forma de o editar.

O formulário é uma tarefa separada. O seu substituto tem de recolher os dados acordados, guardá-los ou enviá-los para o destino previsto e apresentar ao visitante uma confirmação útil. Alguém envia um pedido de teste e confirma que foi efetivamente recebido. O facto de o formulário existir na página antiga não significa que o seu funcionamento tenha sido transferido com o artigo.

A editora tem agora provas sobre quatro elementos: um artigo, a sua imagem, uma tarefa do editor e um pedido de um visitante. Repetir esta abordagem nas diferentes estruturas do site dá uma base muito melhor para definir o âmbito do que afirmar «conseguimos importar os artigos».

Mantenha os URL úteis e planeie as alterações

Ao substituir um sistema de conteúdos, muitas vezes pode manter o domínio e os endereços existentes das páginas. Peça-o expressamente quando esses endereços continuarem a ser úteis. Mudar de sistema de gestão de conteúdos não exige um domínio novo nem um novo padrão de URL.

Quando um endereço tiver de mudar, associe o antigo à substituição adequada e teste o redirecionamento. Evite enviar todas as páginas antigas para a página inicial. Um artigo retirado, um tema fundido e um produto deslocado exigem decisões que respeitem aquilo que o visitante procurava.

As orientações da Google para mudanças com alteração de URL abordam o mapeamento de endereços, os redirecionamentos permanentes e verificações de endereços canónicos, ligações internas, imagens, versões linguísticas e mapas do site. O endereço canónico indica aos motores de pesquisa qual a versão da página que prefere. Confirme que aponta para a nova página pública, e não para um site de teste ou endereço antigo.

Reveja títulos e descrições, regras de indexação, percursos das diferentes línguas e ligações em todo o conteúdo. No lançamento, trate corretamente as restrições do ambiente de teste: o site de teste deve continuar privado quando necessário, enquanto as páginas destinadas ao público têm de estar acessíveis e poder ser indexadas.

A ferramenta Alteração de endereço da Google diz respeito à mudança de domínio ou subdomínio. Substituir o WordPress mantendo os mesmos endereços não exige, por si só, a sua utilização.

As posições nos motores de pesquisa podem oscilar após alterações importantes. Acorde o que vai acompanhar, quem investiga páginas em falta ou mudanças inesperadas no tráfego e como serão feitas as correções. Ninguém pode transformar responsavelmente um plano de migração numa promessa de não perder posições ou de crescer automaticamente.

Acorde o que tem de funcionar antes do lançamento

Defina os testes de aceitação em torno das tarefas que o site tem de cumprir. Compare conteúdo, imagens e ligações, depois teste o funcionamento real. Um formulário deve entregar a mensagem no sítio certo. A pesquisa deve encontrar itens representativos. Um utilizador autorizado deve conseguir iniciar sessão e alguém sem permissão deve ser recusado. Os editores devem conseguir concluir as tarefas acordadas.

Se o âmbito incluir compras, reservas ou integrações, teste também esses percursos e as exceções importantes. Um ecrã que indica sucesso é apenas parte do resultado se um sistema ligado ainda tiver de receber o registo.

Use um ambiente de teste protegido para este trabalho. Limite o acesso a dados privados e impeça os testes de enviar mensagens reais a clientes ou desencadear ações indesejadas nos sistemas em produção. Acorde que dados podem ser utilizados e como serão tratadas as cópias de teste.

Planeie o que acontece às alterações feitas enquanto o novo site está a ser preparado. Pode parar brevemente as publicações e transferir as últimas mudanças, ou fazer uma transferência final dos registos acrescentados desde a primeira importação. Indique qual é o sistema com o registo válido em cada fase. Caso contrário, um editor pode corrigir uma notícia num sítio enquanto um visitante envia um pedido noutro.

O nosso guia sobre a operação simultânea dos sistemas antigo e novo durante uma substituição analisa mais detalhadamente estas decisões de responsabilidade e transição.

Acorde também um plano realista para voltar atrás. As orientações do WordPress sobre cópias de segurança distinguem a base de dados e os ficheiros necessários à recuperação. Ter cópias é um ponto de partida; a equipa ainda precisa de provar que consegue restabelecer o serviço necessário. O nosso artigo sobre o que uma cópia de segurança de um site deve realmente recuperar explica o que verificar.

Voltar atrás torna-se mais complicado quando o novo site já recebeu pedidos, encomendas ou alterações, ou enviou instruções a outro serviço. Esses registos e ações têm de ser conciliados. Não se pode presumir que restaurar a base de dados de ontem preserve o negócio de hoje. Defina as condições para voltar atrás e os responsáveis antes do lançamento.

O que determina o custo e o prazo?

A quantidade de conteúdo importa, mas a sua variedade pode importar tanto como ela. Milhares de artigos com a mesma estrutura podem ser mais previsíveis do que uma coleção menor de páginas feitas individualmente com comportamentos especiais.

Um orçamento comparável deve explicar os pressupostos do trabalho:

• Que estruturas de conteúdo, blocos personalizados e registos de plugins serão examinados e convertidos?
• Que integrações, contas, transações e línguas estão incluídas?
• Que alterações de design e limpeza de conteúdo estão previstas?
• Que funções de edição, permissões e formação são necessárias?
• Que testes, apoio ao lançamento, medidas de continuidade e acompanhamento estão incluídos?

Conte também com o tempo da sua equipa. As pessoas têm de fornecer acessos, responder a perguntas, decidir o que retirar, organizar o conteúdo, experimentar o editor e aceitar o resultado. Se quem decide não estiver disponível, o trabalho pode ficar parado mesmo que o desenvolvimento esteja pronto para continuar.

Peça aos fornecedores que separem o trabalho conhecido dos pontos que ainda precisam de investigação. Uma conversão de teste de uma página difícil ou de uma função dependente de um plugin pode esclarecer uma incerteza dispendiosa antes de se assumir toda a construção. Um preço fechado com base numa exportação não analisada pode esconder pressupostos muito diferentes entre fornecedores.

Compare o custo de operar cada opção, além do custo de a construir. Inclua alojamento, licenças, serviços externos, atualizações, cópias de segurança, monitorização, apoio e alterações futuras. Manter o WordPress tem custos; o software à medida também. A comparação útil é o que cada caminho oferece durante o período em que espera utilizá-lo, com as responsabilidades definidas.

Quem cuidará do sistema à medida?

Acorde isto ao escolher a solução. Um site à medida continua a depender de frameworks, bibliotecas, alojamento e serviços ligados. Essas dependências precisam de atenção. A segurança é trabalho contínuo: as próprias orientações de segurança do WordPress descrevem a redução de riscos e a partilha de responsabilidades, e mudar de plataforma não elimina a necessidade de as atribuir.

Inclua no acordo as atualizações, cópias de segurança, monitorização e apoio em incidentes. Indique quem recebe um alerta, quem pode atuar, como se comunicam problemas urgentes e o que está efetivamente coberto pelo apoio. Defina também um processo para melhorias normais, além das avarias.

Esclareça os acessos e a entrega: contas de alojamento e implementação, credenciais, exportação de dados, documentação, licenças e acesso ao repositório ou ao código-fonte quando aplicável. O acesso ao código-fonte, por si só, não transfere direitos de autor nem demonstra que outro fornecedor consegue operar o sistema. Uma entrega útil também explica como o disponibilizar, recuperar e gerir as suas dependências.

Os especialistas da Google Acacio Cruz e Ashish Bhambhani descrevem documentação, formação e transferência de responsabilidade operacional no seu relato sobre a preparação de um serviço. Uma pequena empresa não precisa da estrutura de equipas da Google para aplicar a ideia central: quem assume a responsabilidade precisa do conhecimento e dos acessos necessários para fazer o trabalho.

A LINK-V desenvolve sites e sistemas à medida e oferece migração, integrações, design e manutenção contínua. A construção, os direitos, a entrega e a manutenção posterior deve ser acordada para o seu projeto. Pode conhecer o desenvolvimento à medida ou os serviços individuais conforme o trabalho de que precisa.

O que preparar para a primeira conversa

Não precisa de chegar com uma especificação técnica. Traga informação suficiente para tornar o problema visível:

• O site atual e quem tem acesso à sua administração, alojamento, domínio e serviços ligados.
• A dificuldade recorrente, um exemplo concreto e o que pretende que as pessoas consigam fazer em vez disso.
• O conteúdo, as funções e os endereços úteis que devem permanecer, além do que pretende retirar.
• Os editores e outros utilizadores que devem ajudar a testar a substituição.
• Os serviços ligados, datas importantes para vendas ou publicações e quanto tempo de interrupção a empresa consegue tolerar.
• As suas dúvidas sobre custos, direitos, acessos, apoio e alterações futuras.

Assim, a próxima conversa terá um objetivo prático: perceber se melhorar o site atual chega, identificar as incógnitas e acordar o que deve ser demonstrado antes de encomendar uma substituição.