Lá em 2021, uma grande varejista do Reino Unido entregou à Seahawk um brief de migração para um site com pouco mais de 22.000 URLs indexados. O time de desenvolvimento já estava trabalhando na nova plataforma há quatro meses. Eles tinham uma data de lançamento. Eles tinham um site de staging. O que não tinham, e genuinamente não tinha passado pela cabeça deles, era um mapa de redirecionamento. Nem um rascunho. Nenhum. O plano do SEO lead era "resolver isso após o lançamento". Ainda penso naquela reunião às vezes.
Adiamos o lançamento em três semanas. Reconstruímos a estratégia de redirecionamentos do zero. O site foi ao ar limpo, manteve 94% do seu tráfego orgânico durante a transição, e o cliente nos enviou uma garrafa de Scotch. As três semanas de atraso os salvaram do que teria sido quase certamente uma recuperação de seis meses.
Então. Aqui está como você realmente constrói um mapa de redirecionamento para um site nessa escala, o processo, as ferramentas, a lógica de priorização, e as partes que a maioria dos guias de migração discretamente ignora.
---
Comece com um Inventário Completo de URLs
Você não pode mapear o que não contou. Antes de qualquer coisa, você precisa de uma exportação completa de cada URL ao vivo e indexado no site de origem. Não apenas o sitemap. Sitemaps mentem, geralmente estão desatualizados, excluem URLs paginadas, e rotineiramente omitem páginas de produtos ou arquivo que acumularam links ao longo dos anos.
Executo Screaming Frog SEO Spider em modo list contra uma fonte combinada: o sitemap XML mais uma exportação do Google Search Console de todos os URLs indexados. Essas duas fontes juntas quase sempre revelam URLs que uma perdeu da outra. Para um site com 20.000 URLs, espere que a contagem real da crawl retorne em qualquer lugar entre 18.000 e 35.000, paginação, filtros, navegação facetada, tudo isso.Screaming Frog SEO Spider in list mode against a combined source: the XML sitemap plus a Google Search Console export of all indexed URLs. Those two sources together almost always surface URLs the other misses. For a 20,000-URL site, expect the real crawl count to come back anywhere between 18,000 and 35,000, pagination, filters, faceted nav, all of it.
Exporte o rastreamento para uma planilha. Você quer no mínimo: URL, status HTTP, title tag, H1, contagem de links internos apontando para ela e se ela aparece no GSC com impressões. Essa última coluna importa mais do que as pessoas admitem.
Não esqueça dos 404s que ainda recebem tráfego
Enquanto você está no GSC, puxe o relatório de Coverage e pegue cada URL que o Google tentou fazer crawl nos últimos seis meses, incluindo 404s existentes. Algumas dessas páginas quebradas ainda têm backlinks externos apontando para elas. Já vi um 404 com 40 domínios referenciadores em um site que não tinha sido mantido há dois anos. Aqueles também precisam de um destino.
---
Categorize Antes de Mapear
Uma lista plana de 20.000 URLs é inutilizável. A primeira coisa que faço após a exportação da crawl é categorizar cada URL por tipo, porque a lógica de mapeamento é completamente diferente dependendo do que um URL é.is.
Aqui está a taxonomia aproximada que uso:
- Páginas de produtos, mapeamento 1:1 para novo URL de produto onde possível, 1:1 map to new product URL where possible
- Páginas de categoria / coleção, mapeie para categoria equivalente nova, ou parente mais próximo, map to equivalent new category, or nearest parent
- Posts de blog / artigos, corresponda por slug, similaridade de título, ou cluster de tópico, match by slug, title similarity, or topic cluster
- Páginas de tag e arquivo, geralmente consolidam para categoria ou página inicial, usually consolidate to category or homepage
- URLs paginadas (ex: /category/shoes/page/3), quase sempre → categoria pai (e.g.
/category/shoes/page/3), almost always → parent category - URLs de usuário gerado ou conta, geralmente removem ou redirecionam para login, usually drop or redirect to login
- Páginas de landing de campanha antigas, avalie equity de link antes de decidir, evaluate link equity before deciding
- Variantes duplicadas/canônicas, redirecione para a canônica, pronto, redirect to the canonical, full stop
Fazer essa categorização em Google Sheets com uma coluna de dropdown leva algumas horas. Economiza dias. Uma vez que tudo está digitado, você pode processar cada categoria com um conjunto de regras diferente em vez de tomar 20.000 decisões individuais.
---
A Fase de Correspondência: Automatizada Primeiro, Manual Segundo
É aqui que a maioria das equipes erra. Tentam fazer matching manual de cada URL. Com 20 mil linhas, isso não é minucioso, é um colapso nervoso esperando para acontecer.
Meu processo é matching automatizado primeiro, revisão manual segundo, apenas para as URLs que realmente importam.
Matching automatizado com VLOOKUP e Python
Para sites onde a estrutura de URL é similar entre a versão antiga e nova (por exemplo, /products/red-shoes/ virando /shop/red-shoes/), um simples VLOOKUP no Sheets na porção slug resolve 60–70% da lista em menos de dez minutos. Find/replace baseado em Regex lida com mudanças de padrão estrutural./products/red-shoes/ becoming /shop/red-shoes/), a simple VLOOKUP in Sheets on the slug portion sorts out 60–70% of the list in under ten minutes. Regex-based find/replace handles structural pattern changes.
Para migrações mais complexas, mudanças de plataforma, redesigns completos de IA, uso um pequeno script Python que faz matching de string fuzzy nos títulos das páginas entre o export de crawl antigo e o crawl do novo site. A biblioteca thefuzz (anteriormente FuzzyWuzzy) funciona bem para isso. Qualquer coisa acima de uma pontuação de match de 85% recebe atribuição automática. Qualquer coisa abaixo vai para uma fila de revisão manual.thefuzz library (formerly FuzzyWuzzy) does this well. Anything above an 85% match score gets auto-assigned. Anything below goes into a manual review queue.
A fila manual costuma ser 20–30% da lista. Nem toda ela precisa de atenção de alguém sênior.
Priorizando a fila manual
Nem todas as 20 mil URLs merecem tempo igual. Eu score cada URL por:
- Impressões do GSC nos últimos 90 dias, se está gerando tráfego de busca, é alta prioridade, if it's driving search traffic, it's high priority
- Número de domínios referenciadores (extraído do Ahrefs), equity de link que você não pode perder (pulled from Ahrefs), link equity you can't afford to drop
- Contagem de link interno do crawl, sinaliza importância estrutural, signals structural importance
- Atribuição de receita, se o cliente puder fornecer dados de ecommerce do GA4, páginas que geram conversões saltam para o topo, if the client can provide GA4 ecommerce data, pages driving conversions jump to the top
Qualquer coisa com impressões, backlinks ou receita recebe uma decisão de mapeamento manual. Tudo mais pode seguir um fallback baseado em regras (geralmente → categoria pai ou homepage). Sendo honesto, para um site com 20.000 URLs, talvez 800–1.200 URLs genuinamente precisem de atenção individual. O resto é cruft de cauda longa.
---
Estruturando o Documento do Mapa de Redirecionamentos
O mapa final fica em uma planilha. Simples. Nenhuma ferramenta sofisticada é necessária nesta etapa, o arquivo apenas precisa ser inequívoco e importável.
As colunas que uso:
- URL de origem (URL completa e absoluta da página antiga)
- URL de destino (URL completa e absoluta da página nova)
- Tipo de redirecionamento (301 em quase todos os casos, 302 apenas para genuinamente temporário, o que é raro)
- Tipo de correspondência (exato / padrão / regex)
- Categoria (da etapa de taxonomia)
- Nível de prioridade (Alto / Médio / Baixo, baseado na pontuação acima)
- Status (Pendente / Confirmado / Implementado / Testado)
- Notas
Aquela coluna "Notas" é subestimada. É onde você coloca coisas como "cliente confirmou que este produto descontinuado, redirecionar para categoria" ou "backlink da Forbes apontando aqui, mapear para equivalente mais próximo, não homepage." O futuro-você agradecerá ao você do presente.
Mantenha as URLs de origem exatamente como aparecem, com ou sem barra final, com query strings se aplicável. Inconsistência aqui causa matches parciais e redirecionamentos perdidos que são um pesadelo para diagnosticar pós-lançamento.
---
Redirecionamentos Baseados em Padrão vs. Exatos
Nesta escala você absolutamente precisa de redirecionamentos baseados em padrão, não apenas aqueles de match exato. Escrever 20.000 linhas individuais de Redirect 301 em um arquivo .htaccess funciona, mas é frágil, lento para fazer parse, e um desastre de manutenção.Redirect 301 lines in an .htaccess file is, well, it works, but it's fragile, slow to parse, and a maintenance disaster.
Para configurações Apache/WordPress, uso RewriteRules baseadas em regex para padrões estruturais. Por exemplo, se cada URL antiga sob /old-blog/[post-slug]/ mapeia para /insights/[post-slug]/, isso é uma regra, não 4.000.regex-based RewriteRules for structural patterns. For example, if every old URL under /old-blog/[post-slug]/ maps to /insights/[post-slug]/, that's one rule, not 4,000.
No Nginx, o mesmo princípio se aplica com diretivas rewrite. No Cloudflare, você pode usar Bulk Redirects (o tier gratuito deles suporta até 20 regras de correspondência exata; Workers ou o produto pago Redirect Rules lidam com lógica de padrão em escala).rewrite directives. On Cloudflare, you can use Bulk Redirects (their free tier handles up to 20 exact-match rules; Workers or the paid Redirect Rules product handles pattern logic at scale).
O documento de mapa deve sinalizar quais redirecionamentos são elegíveis para padrão versus quais precisam de correspondência exata. Tipicamente: posts de blog, produtos e páginas de categoria seguem padrões. Páginas de campanhas antigas, subdomínios legados e URLs históricas estranhas precisam de correspondência exata.
Teste padrões antes de eles irem para produção
Executo o conjunto completo de regras de padrão contra a lista de URLs em um ambiente de staging e faço log de cada resposta de redirecionamento com uma ferramenta como Redirect Checker (bulk) ou um loop curl em bash. Cada redirecionamento em cadeia (antiga → intermediária → nova) é um problema, Google segue cadeias mas perde alguma equidade de link a cada salto. Achate-as antes do lançamento.Redirect Checker (bulk) or a curl loop in bash. Every chain redirect (old → interim → new) is a problem, Google will follow chains but loses some link equity at each hop. Flatten them before launch.
---
Lidando com a Cauda Longa: A Estratégia de Fallback
A coisa sobre um site de 20.000 URLs é que vários milhares dessas URLs provavelmente têm zero tráfego, zero backlinks, e zero motivo para alguém visitá-las novamente. Redirecionar todas para a homepage cria um problema diferente: parece manipulador para o Google, e confunde usuários que seguiram um link específico.
Minha hierarquia de fallback:
- Se a URL é uma página de subcategoria sem tráfego e sem links → redirecione para a categoria pai
- Se for um arquivo de tag ou autor → redirecionar para o índice do blog
- Se for uma página verdadeiramente órfã sem equivalente lógico → deixar retornar 404, ou fazer um soft-redirect para uma página 404 bem-projetada com navegação
Uma boa página 404 customizada com busca contextual e links de categorias populares recupera mais dessas visitas do que um redirecionamento genérico para homepage. Construí uma para um cliente Seahawk no ano passado, teve uma taxa de 28% "recuperada" (usuários navegando da 404 para outra página) versus cerca de 9% antes.
---
Validação Pós-Lançamento
O mapa de redirects não termina no lançamento. As primeiras 72 horas são críticas.
Configurei a verificação de propriedade no GSC no dia anterior ao lançamento, depois monitoro o relatório de Cobertura diariamente nas primeiras duas semanas. Novos 404s que aparecem após o lançamento geralmente significam URLs que escaparam do inventário, variantes de parâmetros não autorizadas, alternativas hreflang ou URLs antigas em campanhas de email externas.
Para cada novo 404 que encontro, adiciono um redirect e faço o push. Pequenos incêndios. Você quer apanhá-los antes que o Googlebot desista daquelas URLs completamente.
Além disso, verifique seus logs do servidor. Não apenas GSC. O Googlebot visita URLs que não estão vinculadas em lugar nenhum com base em seus próprios dados históricos de rastreamento. A análise de logs (uso GoAccess para leituras rápidas em configurações menores de servidor) revela 404s que o GSC às vezes leva uma semana ou mais para relatar.
---
FAQ
Quanto tempo realmente leva para construir um mapa de redirecionamento para 20.000 URLs?
Sendo realista, reserve de duas a três semanas de trabalho em tempo parcial, talvez 40–60 horas no total, dependendo de quão bagunçada for a estrutura de URL do site antigo. A fase de correspondência automatizada é rápida. A revisão manual de URLs de alta prioridade e a fase de validação consomem mais tempo. Nunca deixe um cliente ou PM dizer que isso pode ser feito "em um fim de semana".
Devo redirecionar cada URL ou está tudo bem deixar alguns URLs retornarem 404?
É perfeitamente aceitável deixar URLs genuinamente mortos, sem tráfego e sem backlinks retornarem 404 naturalmente. Forçar um redirecionamento para uma página irrelevante cria um sinal de soft-404 que é discutivelmente pior. Faça triagem sem piedade. Redirecione o que importa e invista em uma experiência de 404 personalizada sólida para o resto.
Qual tipo de redirecionamento devo usar, 301 ou 302?
301 (permanente) para praticamente tudo em uma migração. Um 302 diz ao Google que a mudança é temporária e ele vai preservar a URL antiga no índice. Já vi agências usarem 302s "para ser seguro" e depois ver o domínio antigo continuar ranqueando enquanto o novo fica estagnado por meses. Use 301.
Posso usar um plugin para gerenciar 20.000 redirecionamentos no WordPress?
Sim, mas escolha com cuidado. Redirection by John Godley lida bem com grandes volumes e armazena regras no banco de dados em vez de .htaccess, o que é melhor para desempenho em larga escala. Para qualquer coisa acima de ~10.000 redirecionamentos de correspondência exata, eu ainda recomendaria migrar regras baseadas em padrão para a configuração do servidor em vez de depender inteiramente de um plugin.Redirection by John Godley handles large volumes well and stores rules in the database rather than .htaccess, which is better for performance at scale. For anything above ~10,000 exact-match redirects, I'd still recommend migrating pattern-based rules to server config rather than relying entirely on a plugin.
Qual é o erro mais comum que as equipes cometem em migrações grandes?
Iniciar o mapa de redirecionamento muito tarde. Vejo isso constantemente, o trabalho de dev está 90% pronto, o lançamento é em duas semanas e alguém pergunta "e quanto aos redirecionamentos?" Nesse ponto você está se apressando e inevitavelmente perdendo coisas. O mapa de redirecionamento deve começar a ser construído no momento em que a estrutura de URL do novo site é confirmada. Fluxo de trabalho em paralelo, não uma reflexão tardia.
---
Três semanas de atraso, uma garrafa de Scotch, 94% de retenção de tráfego. A matemática de acertar isso é bem simples.
O mapa de redirecionamento não é a parte glamurosa de uma migração. Ninguém o coloca no banner do herói do case study. Mas é a diferença entre uma migração e uma recuperação, e sei qual delas eu preferiria estar cobrando.
