Slug Padronizado: A Fundação do SEO em E-commerce de Alto Volume

80.000 SKUs e o Caos de URLs que Ninguém Percebeu

Quando um e-commerce de materiais de construção chega a 80.000 SKUs ativos, o problema de URL deixa de ser hipotético e se torna mensurável em receita perdida. O ERP gerava slugs automaticamente a partir do nome do produto cadastrado pelo time de compras — sem nenhuma normalização. O resultado era previsível: produtos com nomes como "Parafuso 4×20 Cabeça Chata (Caixa c/ 100un)" geravam URLs como /parafuso-4x20-cabeca-chata-caixa-c-100un em alguns ambientes e /parafuso-4%C3%9720-cabe%C3%A7a-chata em outros, dependendo de qual sistema havia criado o registro.

O Google indexava as duas versões como páginas distintas. O PageRank se dividia entre URLs que eram, na prática, o mesmo produto. Em uma auditoria de SEO conduzida 18 meses depois do lançamento do e-commerce, encontramos mais de 12.000 pares de URLs com conteúdo duplicado — 15% do catálogo total. Nenhuma dessas duplicatas tinha sido sinalizada como erro — elas simplesmente existiam, silenciosamente diluindo a autoridade do domínio.

Por Que Slugs Importam para SEO

A URL é um fator de ranqueamento confirmado pelo Google desde a era do PageRank, e sua importância é especialmente alta em e-commerce por três razões:

Legibilidade para crawlers e humanos: uma URL como /cimento-cp-ii-50kg carrega informação semântica que reforça o sinal da página para a keyword "cimento CP II 50kg". Uma URL como /produto?id=39471&cat=12 não carrega nenhuma informação semântica.
Prevenção de duplicatas: um slug normalizado garante que o mesmo produto tem sempre a mesma URL, independentemente de qual sistema o gerou. Sem normalização, o mesmo produto pode ter 3 ou 4 URLs válidas — e o Google escolhe qual indexar, não necessariamente a que você prefere.
Linkbuilding: links externos que apontam para /cimento-cp-ii-50kg e para /Cimento-CP-II-50Kg e para /cimento-cp-ii-50-kg são três backlinks distintos para o Google — nenhum deles acumula autoridade suficiente.

As Regras de Normalização de Slug

O pipeline de normalização que implementamos para catálogos de alto volume segue esta sequência, nesta ordem:

Decomposição NFD: converte caracteres acentuados para sua forma decomposta (a letra + o diacrítico separados). "câmera" vira "câmera" em nível de codepoints.
Remoção de diacríticos: remove os diacríticos (acentos, cedilha), deixando apenas a letra base. "câmera" vira "camera", "parafuso" continua "parafuso".
Lowercase: tudo em minúsculas. "Cimento CP II" vira "cimento cp ii".
Remoção de caracteres não-alfanuméricos exceto espaço: "4×20" vira "4 20", "(Caixa c/ 100un)" vira "Caixa c 100un".
Substituição de espaços por hífens: "cimento cp ii" vira "cimento-cp-ii".
Remoção de hífens múltiplos consecutivos: "4--20" vira "4-20".
Remoção de hífens no início e no fim.

Use o Gerador de Slug para normalizar slugs individualmente ou validar sua lógica antes de implementar em produção. Para processamento em lote de catálogos grandes, o mesmo pipeline pode ser implementado em PHP, Python ou Node.js seguindo a mesma sequência.

O Problema de SKUs com Nome Igual em Categorias Diferentes

Materiais de construção têm um problema específico: nomes de produto genéricos que aparecem em múltiplas categorias. "Mangueira 3/4 15m" existe em elétrica (para eletrodutos) e em hidráulica (para jardim) — são produtos completamente diferentes, com preços e fornecedores diferentes, mas que geram o mesmo slug: /mangueira-3-4-15m.

A solução é incluir um identificador de categoria no slug: /hidraulica/mangueira-3-4-15m e /eletrica/mangueira-3-4-15m. Mas isso exige que a categoria também tenha slug normalizado — e que o ERP exporte a hierarquia de categoria junto com o nome do produto.

Em catálogos grandes, mapeie primeiro os produtos com slug duplicado antes de definir a estratégia. Em nossa auditoria do catálogo de 80.000 SKUs, 3.200 produtos tinham slug que colidiria com outro produto em uma categoria diferente.

Canonical Tags e Migração Segura

Quando você padroniza slugs em um e-commerce que já está indexado, o trabalho não termina na normalização. Cada URL antiga precisa de um redirecionamento 301 para a URL nova, e durante o período de transição, a URL nova precisa de uma canonical tag apontando para si mesma — para evitar que o Googlebot trate a URL nova e a URL antiga (ainda indexada) como duplicatas simultâneas.

O protocolo de migração segura:

Mapeie todas as URLs existentes (crawl completo com Screaming Frog ou similar)
Aplique o pipeline de normalização para gerar as URLs destino
Identifique os casos de colisão (dois produtos com o mesmo slug novo)
Resolva colisões manualmente ou com sufixo de SKU (/cimento-cp-ii-50kg-sku39471)
Configure os 301s
Implante e monitore o Search Console por 4 semanas

Monitoramento de 404s em Catálogos de Alto Volume

E-commerces de alto volume têm produtos descontinuados o tempo todo. Um produto descontinuado sem redirecionamento 301 vira um 404 — que corrói a autoridade de domínio e frustra o usuário que chegou de um link indexado. Em um catálogo de 80.000 SKUs com rotatividade mensal de 2-3%, você tem 1.600 a 2.400 novos 404s potenciais por mês se não tiver um processo.

O monitoramento mínimo necessário: alertas automáticos do Google Search Console para páginas com aumento súbito de impressões com 0 cliques (sinal de indexação de 404), e um job semanal que verifica se as URLs exportadas pelo ERP como "ativas" respondem com 200.

Perguntas Frequentes

Preciso incluir o SKU numérico no slug do produto?

Depende da estratégia. SKU no slug resolve colisões de nomes duplicados e garante unicidade absoluta, mas prejudica a legibilidade e o sinal semântico da URL. Em catálogos com muitos produtos de nome genérico (como materiais de construção), incluir o SKU como sufixo é uma solução pragmática: "/cimento-cp-ii-50kg-39471". Em catálogos de moda ou eletrônicos com nomes únicos, o SKU geralmente é desnecessário.

Qual o impacto de migrar slugs em um e-commerce já indexado?

Migração de URL com 301s bem configurados tem impacto temporário de 2 a 8 semanas no ranqueamento, com recuperação total em seguida. Sem 301s, o impacto é permanente — o Google trata as novas URLs como novas páginas sem histórico. O risco real não é a migração: é manter URLs incoerentes e acumular duplicatas por anos. Quanto mais tarde você migra, mais caro fica.

Underscores ou hífens no slug?

Hífens, sempre. O Google trata hífens como separadores de palavras — "cimento-cp-ii" é lido como três termos separados. Underscores são tratados como parte da palavra — "cimento_cp_ii" é lido como uma string única. Isso foi documentado pelo Google em 2009 e permanece válido até hoje. Não use underscores em slugs de produto.

Qual o tamanho ideal de um slug?

Entre 3 e 5 palavras, idealmente. Slugs muito curtos perdem sinal semântico; slugs longos são truncados em SERPs e difíceis de ler em backlinks. Para produtos com nomes naturalmente longos, priorize as palavras com maior valor de keyword e corte as palavras funcionais (de, para, com, em).