Mapa de Redireccionamentos de SKU na Mudança de Plataforma

As checklists de migração assumem que se pode rastrear o site antigo e mapear o que se encontra, o que falha num catálogo grande porque o rastreio deixa de fora produtos órfãos e esgotados que ainda têm links e posições. A segunda falha é assumir que os SKU mapeiam um para um: as mudanças de plataforma alteram o tratamento das variantes, fundem ou dividem categorias, e normalmente deitam fora os caminhos de faceta por completo, pelo que uma parte dos URLs antigos fica sem destino e acaba redireccionada em massa para a homepage. É dessa parte que vem a perda de tráfego, e é resolúvel antes do lançamento se o mapa for construído a partir da exportação do catálogo.

O ficheiro da competência

---
name: replatform-sku-redirect-mapping
description: Use quando está a mudar um catálogo para uma nova plataforma e os padrões de URL de produtos, variantes, categorias e facetas mudam todos ao mesmo tempo.
---

# Mapa de Redireccionamentos de SKU na Mudança de Plataforma

As checklists de migração assumem que se pode rastrear o site antigo e mapear o que se encontra, o que falha num catálogo grande porque o rastreio deixa de fora produtos órfãos e esgotados que ainda têm links e posições. A segunda falha é assumir que os SKU mapeiam um para um: as mudanças de plataforma alteram o tratamento das variantes, fundem ou dividem categorias, e normalmente deitam fora os caminhos de faceta por completo, pelo que uma parte dos URLs antigos fica sem destino e acaba redireccionada em massa para a homepage. É dessa parte que vem a perda de tráfego, e é resolúvel antes do lançamento se o mapa for construído a partir da exportação do catálogo.

## O que precisa primeiro

- um inventário de URLs montado a partir de quatro fontes e sem duplicados: a base de dados, os sitemaps antigos, 12 meses de páginas da Search Console, 12 meses de páginas de entrada da analítica
- contagens de domínios de referência por URL antigo, para poder priorizar a cauda que tem links
- os padrões de URL da nova plataforma para produtos, variantes, categorias e quaisquer facetas indexáveis, confirmados em staging e não a partir de uma especificação
- o mapeamento de identificadores de SKU e de categoria do antigo para o novo, vindo da equipa de migração

## Método

1. Monte o inventário a partir das quatro fontes e não de um rastreio. É o histórico da Search Console e da analítica que revela URLs que ainda ganham tráfego mas já não estão ligados de lado nenhum.
2. Junte o inventário ao mapeamento de identificadores e deixe as regras por padrão gerar a maior parte do mapa. As regras são mais fiáveis e mais revisíveis do que uma folha de 40.000 linhas feita à mão.
3. Isole as linhas que as regras não conseguiram mapear e ordene-as por domínios de referência e entradas orgânicas. Esta cauda é pequena em número e grande em valor, e é a única parte que precisa de decisões humanas.
4. Resolva os URLs sem correspondência para o equivalente genuíno mais próximo e aceite um 410 para aqueles que não têm nada por trás. Mandá-los para a homepage é lido como soft 404 e queima rastreio durante meses.
5. Decida o tratamento das variantes de forma explícita antes de gerar seja o que for. Um site que tinha um URL por tamanho a passar para uma única página de produto é uma fusão de muitos para um, e cada URL de variante antigo continua a precisar da sua própria regra.
6. Teste o conjunto de regras contra o inventário completo em staging, verificando o código de estado, o destino final e o número de saltos. Cadeias que passam por uma regra sobrada de uma migração anterior são comuns e cada salto custa rastreio.
7. Mantenha os sitemaps antigos vivos e submetidos durante algumas semanas depois do lançamento, para que os redireccionamentos sejam descobertos depressa, e só depois os substitua pelos novos.
8. Volte a correr o inventário completo contra produção no dia do lançamento e outra vez ao dia 7, acompanhando as contagens de URLs sem correspondência e de erros em vez de esperar que os dados de tráfego revelem a falha.

## O que isto produz

Um mapa de redireccionamentos do antigo para o novo, testado e a cobrir o inventário histórico completo de URLs, com cada URL sem correspondência resolvido individualmente ou retirado de forma deliberada.

## Onde isto corre mal

- construir o mapa a partir de um rastreio do site em produção, o que deixa de fora produtos esgotados e órfãos que ainda têm links e posições
- redireccionar em massa os URLs sem correspondência para a homepage ou para uma categoria de topo, o que é tratado como soft 404 e descartado
- lançar com cadeias de uma migração anterior ainda na pilha, de modo que cada URL antigo custa vários pedidos até resolver
- retirar os sitemaps antigos no lançamento, o que atrasa a descoberta dos redireccionamentos precisamente quando a descoberta mais importa

---

Da biblioteca de competências da QuQi - https://www.quqi.io/pt/skills/replatform-sku-redirect-mapping

O que precisa primeiro

• um inventário de URLs montado a partir de quatro fontes e sem duplicados: a base de dados, os sitemaps antigos, 12 meses de páginas da Search Console, 12 meses de páginas de entrada da analítica
• contagens de domínios de referência por URL antigo, para poder priorizar a cauda que tem links
• os padrões de URL da nova plataforma para produtos, variantes, categorias e quaisquer facetas indexáveis, confirmados em staging e não a partir de uma especificação
• o mapeamento de identificadores de SKU e de categoria do antigo para o novo, vindo da equipa de migração

Método

1. 01 Monte o inventário a partir das quatro fontes e não de um rastreio. É o histórico da Search Console e da analítica que revela URLs que ainda ganham tráfego mas já não estão ligados de lado nenhum.
2. 02 Junte o inventário ao mapeamento de identificadores e deixe as regras por padrão gerar a maior parte do mapa. As regras são mais fiáveis e mais revisíveis do que uma folha de 40.000 linhas feita à mão.
3. 03 Isole as linhas que as regras não conseguiram mapear e ordene-as por domínios de referência e entradas orgânicas. Esta cauda é pequena em número e grande em valor, e é a única parte que precisa de decisões humanas.
4. 04 Resolva os URLs sem correspondência para o equivalente genuíno mais próximo e aceite um 410 para aqueles que não têm nada por trás. Mandá-los para a homepage é lido como soft 404 e queima rastreio durante meses.
5. 05 Decida o tratamento das variantes de forma explícita antes de gerar seja o que for. Um site que tinha um URL por tamanho a passar para uma única página de produto é uma fusão de muitos para um, e cada URL de variante antigo continua a precisar da sua própria regra.
6. 06 Teste o conjunto de regras contra o inventário completo em staging, verificando o código de estado, o destino final e o número de saltos. Cadeias que passam por uma regra sobrada de uma migração anterior são comuns e cada salto custa rastreio.
7. 07 Mantenha os sitemaps antigos vivos e submetidos durante algumas semanas depois do lançamento, para que os redireccionamentos sejam descobertos depressa, e só depois os substitua pelos novos.
8. 08 Volte a correr o inventário completo contra produção no dia do lançamento e outra vez ao dia 7, acompanhando as contagens de URLs sem correspondência e de erros em vez de esperar que os dados de tráfego revelem a falha.

O que isto produz

Um mapa de redireccionamentos do antigo para o novo, testado e a cobrir o inventário histórico completo de URLs, com cada URL sem correspondência resolvido individualmente ou retirado de forma deliberada.

Onde isto corre mal

• construir o mapa a partir de um rastreio do site em produção, o que deixa de fora produtos esgotados e órfãos que ainda têm links e posições
• redireccionar em massa os URLs sem correspondência para a homepage ou para uma categoria de topo, o que é tratado como soft 404 e descartado
• lançar com cadeias de uma migração anterior ainda na pilha, de modo que cada URL antigo custa vários pedidos até resolver
• retirar os sitemaps antigos no lançamento, o que atrasa a descoberta dos redireccionamentos precisamente quando a descoberta mais importa

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 para e-commerce