Começa pelo que as pessoas já conseguem encontrar
O inventário deve mostrar que páginas existem, para que servem e como as pessoas chegam até elas. Reúne os endereços do site atual e identifica conteúdos, imagens e documentos associados. Uma migração fica mais fácil de avaliar quando há uma lista concreta do que precisa de continuar a funcionar.
Quando tratei da passagem do meu site em WordPress para uma aplicação, pedi primeiro uma análise do site existente e um levantamento das páginas. A preservação dos endereços fazia parte do pedido. Isso obriga a olhar para o que já está publicado antes de decidir como organizar o novo projeto.
A página inicial raramente representa todo o trabalho. Há artigos antigos que continuam úteis, páginas de serviços, contactos, documentos descarregáveis e páginas legais que aparecem apenas no rodapé. Se o levantamento depender só do menu principal, parte desse património pode desaparecer sem ninguém ter tomado essa decisão.
O sitemap ajuda a descobrir endereços, mas eu não o trataria como prova de que a lista está completa. Acrescentaria a exportação de conteúdos e, quando disponíveis, registos de visitas e ligações recebidas. Guardaria também uma cópia consultável do site antigo para esclarecer diferenças durante a revisão.
Este levantamento liga-se ao diagnóstico antes de propor um plano de marketing: primeiro perceber o que existe e que função desempenha. Uma página com poucas visitas pode conter informação necessária para quem está prestes a contactar a empresa. O volume, sozinho, não decide o seu destino.
Para preparar o próximo passo, consulta Desenvolver aplicações com IA.
Dá um destino explícito a cada endereço
Cada URL antigo deve ter uma decisão registada: manter a mesma página, encaminhar para um conteúdo equivalente ou retirar por uma razão definida. Evita deixar esta escolha implícita no trabalho da IA. A correspondência entre origem e destino é um documento de decisão que depois orienta a implementação e os testes.
Pensa num exemplo hipotético: uma empresa tem uma página sobre formação presencial e decide reorganizar a navegação. Se a oferta continua a mesma, mudar o menu não obriga a mudar o endereço. Pode atualizar a apresentação e conservar o caminho que clientes e parceiros já conhecem.
Se duas páginas forem realmente substituídas por uma página mais completa, a correspondência deve apontar para essa substituta. Um redirecionamento permanente pode servir essa mudança. Mandar indiscriminadamente todos os endereços antigos para a homepage deixa o visitante sem o conteúdo que procurava e esconde decisões que deviam ser revistas individualmente.
Há também conteúdos que deixam de fazer sentido. Retirá-los exige uma decisão editorial, não uma tentativa de criar equivalências artificiais. Na tabela, registaria o motivo e quem o validou. Assim, a pessoa que testa consegue distinguir uma remoção intencional de uma página esquecida na transferência.
Inclui os endereços que já circulam fora do site. Imagina um QR impresso num folheto ou uma ligação enviada numa proposta comercial. A equipa pode corrigir o menu em segundos, mas não consegue recolher todos os materiais distribuídos. Preservar esse acesso tem valor prático mesmo quando não aparece numa discussão sobre design.
Entrega à IA requisitos que possam ser conferidos
O pedido de implementação deve juntar o inventário, as decisões sobre URLs e critérios observáveis para cada tipo de página. Explica o que deve aparecer, quem pode editar e o que acontece nos formulários. Pede à IA que identifique dúvidas antes de transformar pressupostos em comportamento da nova aplicação.
Eu separaria conteúdo, apresentação e operação. O conteúdo inclui títulos, texto, imagens e idioma; a apresentação define a forma de os mostrar; a operação cobre edição, pedidos recebidos e permissões. Uma aparência semelhante à original não demonstra que estas três partes ficaram bem transferidas para o novo sistema.
Um requisito útil seria: “Este artigo deve abrir no endereço indicado, mostrar o texto completo e manter as ligações internas úteis.” Outro seria: “Este formulário precisa de validar os campos e apresentar uma confirmação coerente com o que foi efetivamente registado.” São condições que alguém consegue observar sem adivinhar intenções.
Antes de construir, aplica o mesmo cuidado que proponho ao planear uma aplicação com Claude Code. A IA precisa de conhecer os limites do projeto, os dados necessários e o que depende de uma decisão tua. Pedir uma cópia visual de um site deixa demasiadas questões de funcionamento por responder.
Também definiria como a equipa vai atualizar conteúdos depois da migração. Se mudar uma descrição passar a exigir mexer no código, pode haver um custo de manutenção que não estava previsto. Uma aplicação à medida só resolve o processo quando a pessoa responsável consegue operá-la nas condições reais do negócio.
Testa os percursos antes de trocar o site
A revisão deve começar pelos endereços antigos e percorrer o novo site como uma pessoa que procura informação ou quer agir. Confere páginas completas, imagens, downloads e formulários. Junta testes automáticos da lista de URLs a uma leitura dos percursos importantes, porque uma resposta técnica válida pode mostrar conteúdo errado.
Por exemplo, uma página pode abrir sem erro e ter perdido metade do artigo. Uma imagem pode existir, mas pertencer a outro serviço. Um botão pode levar a uma página correta no idioma errado. Estes casos exigem comparação com os requisitos e com o material de origem, não apenas uma lista de respostas positivas.
Nos formulários, usa um ambiente e dados de teste que não enviem mensagens reais a clientes. Confere campos obrigatórios, erros compreensíveis e o resultado de uma submissão válida. Se existe uma área privada, testa também o que uma pessoa sem acesso não consegue ver nem alterar.
Verifica os títulos das páginas, os endereços canónicos, as ligações entre idiomas e o sitemap do novo sistema. Confirma ainda que as proteções usadas durante o desenvolvimento não impedem a descoberta das páginas públicas depois da troca. A configuração de um ambiente de teste não deve passar despercebida para o site final.
Distribuir esta revisão ajuda a encontrar falhas diferentes. Quem conhece o conteúdo pode identificar uma omissão; quem trata dos pedidos pode reconhecer uma informação em falta. A IA pode preparar verificações e localizar diferenças, mas a decisão de aceitar uma mudança de conteúdo continua a exigir um critério editorial definido.
Faz a troca com uma forma de recuar e acompanhar
A entrada em funcionamento deve ter um responsável, uma cópia recuperável do estado anterior e verificações preparadas para o momento seguinte. Define o que justificaria corrigir rapidamente ou recuar. Depois acompanha erros e percursos reais, sem interpretar uma oscilação inicial de visitas como prova automática de sucesso ou fracasso.
Antes da troca, decide como tratar conteúdos ou pedidos que possam entrar entretanto. Num exemplo hipotético, exportar um site de manhã e migrá-lo à noite pode deixar alterações pelo caminho. A equipa precisa de saber quando interrompe edições, como transfere a última atualização e onde ficam os novos pedidos.
A possibilidade de recuar também precisa de considerar dados. Repor a versão antiga do site não deve apagar submissões recebidas na aplicação nova. Por isso, o plano deve indicar onde esses registos ficam guardados e como serão reconciliados se houver uma reversão. Uma cópia visual do site não resolve essa dependência.
Após a mudança, acompanha páginas em falta, destinos errados e problemas comunicados por utilizadores. Compara os percursos importantes com a lista inicial e regista o que foi corrigido. A existência de testes prévios reduz surpresas, mas não transforma o lançamento no último momento de revisão do trabalho.
É aqui que usar IA no negócio para além do chatbot ganha uma aplicação concreta: ajudar a analisar, construir e verificar uma mudança com critérios teus. A migração fica concluída quando os conteúdos e as tarefas úteis funcionam no novo sistema. O aspeto visual, por si só, não permite dar esse trabalho como aceite.