Verificação de Paridade Antes de uma Migração

As perdas de uma migração decidem-se antes do lançamento e diagnosticam-se semanas depois, altura em que o site antigo já desapareceu e a comparação que explicaria a queda já não pode ser feita. As auditorias pós-lançamento são trabalho de recuperação, não de prevenção. Isto corre enquanto as duas versões existem, e o resultado é uma decisão de lançar ou não, não uma lista de melhorias para mais tarde.

O ficheiro da competência

---
name: pre-launch-migration-parity-check
description: Use quando uma mudança de plataforma, um redesenho ou uma mudança de domínio está a semanas do lançamento e tanto o ambiente de staging como o site actual ainda existem.
---

# Verificação de Paridade Antes de uma Migração

As perdas de uma migração decidem-se antes do lançamento e diagnosticam-se semanas depois, altura em que o site antigo já desapareceu e a comparação que explicaria a queda já não pode ser feita. As auditorias pós-lançamento são trabalho de recuperação, não de prevenção. Isto corre enquanto as duas versões existem, e o resultado é uma decisão de lançar ou não, não uma lista de melhorias para mais tarde.

## O que precisa primeiro

- Um crawl completo do site em produção que exporte URL, estado, canonical, meta robots, title, H1, contagem de palavras e número de ligações internas
- Acesso de rastreio ao staging protegido por autenticação HTTP ou por lista de IPs autorizados, nunca por um bloqueio no robots.txt
- Os principais URLs por tráfego, por receita e por domínios de referência, em três listas separadas e não numa só
- Uma data de lançamento e o nome da pessoa autorizada a travá-lo

## Método

1. Congele o crawl do site em produção num ficheiro datado e guarde-o fora do projecto. Depois do lançamento o conjunto de URLs antigos não pode ser reproduzido, e este ficheiro é a única prova do que existia.
2. Rastreie o staging com definições idênticas e faça o diff das duas listas de URLs. Esse diff é o mapa de redireccionamentos; não é um documento a escrever à parte mais tarde.
3. Confirme que todos os URLs das listas de tráfego, receita e backlinks aparecem no mapa com um destino um-para-um. Juntar muitos URLs antigos numa categoria ou na homepage é onde as migrações mais perdem, e é sempre defendido como arrumação.
4. Compare template com template em vez de página com página: padrão de title, canonical, meta robots, structured data, H1, contagem de palavras do conteúdo principal e número de ligações internas. Uma regressão num template multiplica-se por cada URL que o usa.
5. Confirme que o staging está protegido por autenticação e não por robots.txt ou por um noindex global, e confirme depois, em separado, que o que quer que o proteja é removido no lançamento. Ambas as falhas já tiraram sites inteiros do índice no dia do lançamento.
6. Teste as regras de redireccionamento no staging contra a lista congelada completa, e não contra uma amostra: query strings, barras finais, caminhos em maiúsculas, padrões antigos de que ninguém se lembra. Regras que passam em vinte exemplos escolhidos a dedo falham rotineiramente na cauda longa.
7. Acorde o conjunto de monitorização antes do lançamento: que URLs são verificados à primeira hora, ao primeiro dia, ao sétimo e ao trigésimo, que números são vigiados, e que valor despoleta um rollback. Decidir isto depois significa discuti-lo durante um incidente.

## O que isto produz

Um relatório de paridade com veredicto de avançar ou não avançar, contendo o inventário congelado do site em produção, o mapa de redireccionamentos completo com cobertura um-para-um de cada URL com valor, um diff por template, e um plano datado de monitorização e rollback.

## Onde isto corre mal

- Proteger o staging com robots.txt ou com um noindex global, qualquer um dos quais segue para produção e desindexa o site novo logo no primeiro dia
- Construir o mapa de redireccionamentos a partir do sitemap em vez dos logs e dos dados de backlinks, deixando cair em silêncio URLs que nunca estiveram no sitemap mas ainda trazem links e tráfego
- Lançar uma mudança de plataforma e um redesenho na mesma semana, o que torna impossível atribuir a um ou a outro qualquer queda posterior
- Dar o mapa por concluído assim que está escrito, quando um mapa por testar é uma folha de cálculo e não uma migração

---

Da biblioteca de competências da QuQi - https://www.quqi.io/pt/skills/pre-launch-migration-parity-check

O que precisa primeiro

• Um crawl completo do site em produção que exporte URL, estado, canonical, meta robots, title, H1, contagem de palavras e número de ligações internas
• Acesso de rastreio ao staging protegido por autenticação HTTP ou por lista de IPs autorizados, nunca por um bloqueio no robots.txt
• Os principais URLs por tráfego, por receita e por domínios de referência, em três listas separadas e não numa só
• Uma data de lançamento e o nome da pessoa autorizada a travá-lo

Método

1. 01 Congele o crawl do site em produção num ficheiro datado e guarde-o fora do projecto. Depois do lançamento o conjunto de URLs antigos não pode ser reproduzido, e este ficheiro é a única prova do que existia.
2. 02 Rastreie o staging com definições idênticas e faça o diff das duas listas de URLs. Esse diff é o mapa de redireccionamentos; não é um documento a escrever à parte mais tarde.
3. 03 Confirme que todos os URLs das listas de tráfego, receita e backlinks aparecem no mapa com um destino um-para-um. Juntar muitos URLs antigos numa categoria ou na homepage é onde as migrações mais perdem, e é sempre defendido como arrumação.
4. 04 Compare template com template em vez de página com página: padrão de title, canonical, meta robots, structured data, H1, contagem de palavras do conteúdo principal e número de ligações internas. Uma regressão num template multiplica-se por cada URL que o usa.
5. 05 Confirme que o staging está protegido por autenticação e não por robots.txt ou por um noindex global, e confirme depois, em separado, que o que quer que o proteja é removido no lançamento. Ambas as falhas já tiraram sites inteiros do índice no dia do lançamento.
6. 06 Teste as regras de redireccionamento no staging contra a lista congelada completa, e não contra uma amostra: query strings, barras finais, caminhos em maiúsculas, padrões antigos de que ninguém se lembra. Regras que passam em vinte exemplos escolhidos a dedo falham rotineiramente na cauda longa.
7. 07 Acorde o conjunto de monitorização antes do lançamento: que URLs são verificados à primeira hora, ao primeiro dia, ao sétimo e ao trigésimo, que números são vigiados, e que valor despoleta um rollback. Decidir isto depois significa discuti-lo durante um incidente.

O que isto produz

Um relatório de paridade com veredicto de avançar ou não avançar, contendo o inventário congelado do site em produção, o mapa de redireccionamentos completo com cobertura um-para-um de cada URL com valor, um diff por template, e um plano datado de monitorização e rollback.

Onde isto corre mal

• Proteger o staging com robots.txt ou com um noindex global, qualquer um dos quais segue para produção e desindexa o site novo logo no primeiro dia
• Construir o mapa de redireccionamentos a partir do sitemap em vez dos logs e dos dados de backlinks, deixando cair em silêncio URLs que nunca estiveram no sitemap mas ainda trazem links e tráfego
• Lançar uma mudança de plataforma e um redesenho na mesma semana, o que torna impossível atribuir a um ou a outro qualquer queda posterior
• Dar o mapa por concluído assim que está escrito, quando um mapa por testar é uma folha de cálculo e não uma migração

Use esta skill na sua própria IA

O ficheiro é markdown simples, com o nome e o gatilho no frontmatter. Quando um assistente consegue carregar skills sozinho, é esse frontmatter que lê para decidir que esta se aplica.

Mais em SEO técnico