curl -sS -D - -o /dev/null "$OLD_URL"

Siga os redirecionamentos e consulte os cabeçalhos das respostas ao longo do percurso

curl -sS -L -D - -o /dev/null "$OLD_URL"

Exiba o status final e o endereço final para facilitar o registro dos resultados

curl -sS -L -o /dev/null
-w 'estado=%{http_code} final=%{url_effective}\n' "$OLD_URL"

O registro de validação deve guardar a primeira resposta, o endereço de destino, a resposta final e o conteúdo da página. O tipo de regra para uma mudança permanente deve ser confirmado pelo responsável técnico de acordo com o ambiente real de implantação; não basta concluir que “parece ter redirecionado” no navegador.

Inclua como impedimentos ao lançamento as cadeias de redirecionamento desnecessárias, os retornos ao endereço antigo, os redirecionamentos para domínios de teste e os destinos inexistentes. Tenha atenção especial para não verificar apenas as regras da página inicial e deixar de fora os artigos e as páginas de detalhes dos produtos.

## 5. Como validar o conteúdo das páginas e a tag canonical em conjunto?

Conseguir abrir um endereço é apenas o requisito mínimo. Recomenda-se selecionar páginas representativas de cada modelo e conferir o título, o título principal, o conteúdo, os textos alternativos das imagens, os links internos e os botões de contato, evitando que a importação deixe apenas a estrutura visual da página.

A tag canonical pode fazer parte da verificação do endereço canônico, mas não deve ser tratada como uma solução substituta para todos os problemas de migração. Durante a validação, registre o endereço canônico declarado pela página e confirme se ele corresponde à página de produção definida no projeto; procure especialmente declarações que ainda apontem para o domínio antigo, para um domínio de pré-visualização ou para uma página sem relação com o conteúdo.

Sites multilíngues exigem uma verificação adicional da correspondência entre as versões de idioma. Uma página de produto em chinês não deve passar a apontar para a página inicial em inglês por causa de uma substituição em lote; a troca de idioma, os links do rodapé e os links recomendados no corpo do texto devem ser testados com cliques reais.

Compare também as informações essenciais antes e depois da migração. Condições de preços, escopo dos serviços, evidências dos casos de clientes e dados de contato não podem ser excluídos involuntariamente durante a troca de modelos. Para as páginas utilizadas pela equipe de vendas, recomenda-se envolver o responsável de negócio na validação, em vez de limitar a verificação à resposta técnica feita pelos desenvolvedores.

## 6. O que verificar no sitemap? Primeiro, confira a lista de páginas de produção

Recomenda-se organizar primeiro uma “lista de páginas de produção que devem ser públicas e descobertas pelos mecanismos de pesquisa” e, depois, compará-la com o sitemap gerado. Não considere a verificação concluída apenas porque “um arquivo XML já foi gerado”.

Verifique principalmente os seguintes pontos:

- Se os endereços do sitemap pertencem ao domínio e ao ambiente de produção.
- Se os novos caminhos após a migração foram incluídos conforme o planejamento.
- Se há endereços excluídos, ainda sujeitos a redirecionamento ou que ainda não estão prontos para publicação.
- Se as páginas listadas no sitemap correspondem aos endereços canônicos declarados por elas.
- Se há omissão de categorias inteiras, como diretórios multilíngues, páginas de paginação de artigos ou categorias de produtos.
- Se estão definidos os responsáveis por atualizar o sitemap e republicá-lo.

Quando a quantidade de entradas do sitemap mudar, investigue a origem da diferença: houve uma consolidação planejada de conteúdo ou ocorreu uma omissão na importação ou um erro nos critérios de filtragem? Recomenda-se guardar cópias dos arquivos anteriores e posteriores à migração para permitir uma comparação item a item.

O sitemap é apenas uma parte da validação da migração. Depois de enviá-lo, ainda é necessário verificar o acesso às páginas específicas, seu conteúdo e seus estados posteriores; o envio não permite prometer resultados de indexação, posicionamento ou tráfego.

## 7. O que verificar no Search Console antes e depois do lançamento?

![7. O que verificar no Search Console antes e depois do lançamento?](https://we0-frontend.oss-cn-beijing.aliyuncs.com/growth-covers/3ae5ab5b-404e-4812-9473-4305e47b4bb6.png)

Antes do lançamento, confirme se a equipe consegue acessar as propriedades relevantes do site e se as permissões dos responsáveis não serão perdidas com a saída do fornecedor antigo. Registre as principais páginas de destino, consultas de pesquisa, cliques e impressões anteriores à migração, incluindo a data da observação, para estabelecer um ponto de partida para as comparações posteriores.

Depois do lançamento, recomenda-se verificar e registrar os itens nesta ordem:

1. **Propriedades e permissões**: confirme se a propriedade em consulta corresponde ao site envolvido nesta migração e se o responsável continua com acesso.
2. **URLs representativas**: verifique o rastreamento, o estado de indexação e as informações de endereço canônico das páginas essenciais, distinguindo os registros históricos das mudanças posteriores.
3. **Sitemaps**: confira qual sitemap foi enviado, seu estado de processamento e os avisos relacionados; caso haja anomalias, volte ao arquivo real para investigar.
4. **Problemas nas páginas**: organize as anomalias por diretório e modelo, em vez de observar apenas o total.
5. **Desempenho**: compare consultas, cliques e impressões considerando as páginas antigas e suas novas correspondentes, e não apenas a página inicial.

Se também houver troca de domínio, confirme separadamente se os procedimentos relacionados à mudança de endereço se aplicam ao seu caso. Não confunda a troca de ferramenta de criação de sites no mesmo domínio com uma migração entre domínios.

Ao identificar um problema, reúna no mesmo chamado o endereço da página, o aviso observado, o horário da observação e o resultado do novo teste. Não exclua páginas nem altere regras repetidamente com base em uma única captura de tela.

## 8. Como organizar a validação e a reversão no dia do lançamento?

Recomenda-se dividir o lançamento nas etapas de preparação, mudança para o novo ambiente, novos testes e observação. Na preparação, congele alterações importantes de conteúdo, faça cópias de segurança dos dados das páginas e das configurações e confirme se os acessos necessários ao site antigo poderão ser mantidos.

Após a mudança, teste primeiro os percursos essenciais de negócio: entrada pelo endereço antigo, leitura da descrição do produto, envio do formulário, recebimento da notificação e acompanhamento comercial. As verificações de SEO e de captação de contatos devem ocorrer em paralelo, para evitar que as páginas estejam acessíveis, mas ninguém receba as solicitações.

As condições que impedem o lançamento devem ser combinadas com antecedência, como a impossibilidade de acessar páginas essenciais de produtos, um grande número de pontos de acesso antigos sem o destino previsto, páginas de produção ainda sujeitas às restrições do ambiente de testes ou falhas no processo de contato comercial. Nessas situações, o responsável deve decidir entre corrigir e reverter, em vez de discutir os critérios enquanto o lançamento acontece.

A reversão também precisa de instruções operacionais: quem pode executá-la, quais configurações devem ser restauradas e como confirmar que a restauração funcionou. Não deixe para descobrir no dia da migração que o site antigo já foi excluído ou que as permissões da conta do fornecedor anterior deixaram de funcionar.

## 9. Como investigar mudanças de desempenho após a migração sem perder o controle?

Recomenda-se investigar primeiro os problemas técnicos e de conteúdo que podem ser reproduzidos e só depois discutir o desempenho mais amplo na pesquisa. A sequência pode ser: verificar se a página está acessível, se os pontos de acesso antigos levam ao destino correto, se o conteúdo está completo, se os links internos foram atualizados e se o sitemap corresponde às declarações das páginas.

Ao comparar os dados, analise em conjunto os endereços antigo e novo da mesma página de negócio. Observar apenas o histórico do novo endereço pode fazer com que os dados anteriores à migração sejam ignorados; observar apenas o total do site pode esconder perdas em um diretório importante.

Registre também as mudanças simultâneas nos anúncios, as alterações e exclusões de conteúdo, as campanhas sazonais e os ajustes nas configurações de medição, para evitar atribuir todas as variações à troca de plataforma. Recomenda-se corrigir apenas um conjunto de problemas bem definido a cada rodada e registrar os resultados dos novos testes, reduzindo a dificuldade de identificar as causas quando várias alterações se acumulam.

Não existe um prazo de recuperação único que se aplique a todos os sites. É possível estabelecer uma periodicidade interna de revisão para validar a migração, mas ela não deve ser apresentada como uma promessa de prazo de processamento dos mecanismos de pesquisa.

## 10. Ao escolher uma plataforma de criação de sites com IA, como avaliar a capacidade de migração?

Gerar páginas e dar continuidade ao site antigo são dois trabalhos de validação diferentes. O [site oficial da we0](https://we0.ai/zh) apresenta um fluxo que inclui descrição de requisitos em linguagem natural, criação com múltiplos agentes, ajustes visuais e implantação em domínio próprio. As empresas podem usar essas informações para avaliar a forma de criação do site, mas ainda devem solicitar, separadamente, demonstrações da preservação dos caminhos antigos, da configuração dos redirecionamentos e dos métodos de teste após a migração. Não se deve presumir que essas tarefas serão realizadas automaticamente.

Como referência de outra categoria de produto, o [site oficial da Readdy](https://readdy.ai/zh) apresenta exportação de código, hospedagem de domínio e ferramentas relacionadas a SEO e GEO. Durante a contratação, pergunte também: quem manterá as configurações de implantação após a exportação, quem administrará as regras de caminhos e quem investigará as anomalias? Os nomes dos recursos não substituem um documento de responsabilidades do projeto.

O [artigo de apresentação do Wan Xiaozhi na Comunidade de Desenvolvedores da Alibaba Cloud](https://developer.aliyun.com/article/1773673) aborda a criação de sites por conversa e o fluxo de implantação, mas a página informa que o conteúdo foi contribuído por usuários. Ele pode ajudar a equipe a entender os cenários de criação de sites, mas não deve ser tratado como um compromisso do fornecedor quanto ao escopo de entrega da migração deste projeto.

Recomenda-se pedir às plataformas candidatas ou aos responsáveis pela implementação que façam uma demonstração com um pequeno conjunto de páginas antigas reais antes de decidir a contratação e o plano de lançamento. A demonstração deve abranger diferentes modelos e situações de erro, em vez de se limitar à geração de uma nova página inicial.

## Perguntas frequentes

### É necessário ter uma checklist de migração mesmo sem trocar de domínio, apenas de plataforma de criação de sites?

Sim. Recomenda-se verificar se os caminhos, o conteúdo principal, as declarações das páginas, os links internos e o processo de contato comercial permanecem consistentes. Manter o domínio não significa que todos os resultados da implantação corresponderão automaticamente ao plano original.

### É possível redirecionar todas as páginas antigas para a página inicial?

Não é recomendável adotar essa abordagem como padrão. Primeiro, avalie se existe uma nova página relacionada capaz de substituir cada página antiga; quando não houver conteúdo substituto, registre claramente o tratamento adotado, em vez de usar a página inicial para esconder a ausência.

### A migração está concluída depois de enviar o sitemap?

Não. Também é necessário testar os pontos de acesso antigos, verificar as páginas essenciais, validar os percursos de negócio e continuar registrando as mudanças de estado no Search Console. O envio não substitui os testes de acesso real.

## Ferramentas relacionadas

- **Mapa de correspondência de URLs**: gerencia caminhos antigos, caminhos novos, tratamentos e responsáveis.
- **curl**: permite consultar cabeçalhos de resposta, o percurso dos redirecionamentos e o endereço final.
- **Google Search Console**: permite organizar os registros de verificação dos estados relacionados ao site e do desempenho na pesquisa.
- **Ferramentas de desenvolvedor do navegador**: permitem testar novamente o carregamento das páginas, os links e as requisições dos formulários.

## Links relacionados

- [we0: fluxo de criação de sites, ajustes de páginas e implantação](https://we0.ai/zh)
- [Readdy: apresentação da criação de sites, exportação de código e ferramentas de operação](https://readdy.ai/zh)
- [Comunidade de Desenvolvedores da Alibaba Cloud: apresentação dos cenários de criação de sites com IA do Wan Xiaozhi](https://developer.aliyun.com/article/1773673)

## Resumo

Ao trocar de plataforma de criação de sites, a validação não deve se limitar ao novo site: ela precisa cobrir todo o percurso, desde os pontos de acesso antigos até o novo conteúdo e, por fim, a solicitação de contato comercial. Primeiro, crie um mapa de correspondência de URLs; depois, teste os redirecionamentos, o conteúdo das páginas, o sitemap e os percursos de negócio; por último, use o Search Console para manter a investigação e o acompanhamento. Os recursos da plataforma devem ser confirmados por demonstrações com páginas reais, enquanto as responsabilidades da migração e as condições de reversão devem ser documentadas antes do lançamento.