Limpeza de URL rewrites no Magento 2: reduza a tabela url_rewrite
Em muitas lojas Magento 2 mais antigas, a tabela url_rewrite tem milhões de linhas para um catálogo de alguns milhares de produtos. Ela deixa lentos os saves de categoria e de produto, faz as importações se arrastarem e incha todo dump do banco. Este artigo explica de onde vêm as linhas no Magento Open Source e no Adobe Commerce 2.4.8, como medir o problema e como limpar sem quebrar URLs que buscadores e clientes ainda usam.
Como o Magento monta os URL rewrites
Toda URL da storefront que não é um caminho cru de controller é resolvida pela url_rewrite. Cada linha tem um request_path, um target_path, um redirect_type (0 para rewrite interno, 301 ou 302 para redirects), um store_id, um entity_type e entity_id, e uma flag is_autogenerated. Uma segunda tabela, catalog_url_rewrite_product_category, liga os rewrites de produto que incluem um caminho de categoria a essa categoria.
Para um único produto o Magento pode gerar:
- um rewrite para a URL do produto sem categoria, por store view
- um rewrite por categoria em que o produto está, com o caminho da categoria na frente, por store view, quando os caminhos de categoria nas URLs de produto estão ativados
- um redirect 301 para cada URL key antiga, por store view, quando o redirect permanente na mudança de URL key está ativado
Multiplique por store views e por categorias, some o histórico de cada mudança de URL key e de cada movimentação de categoria, e os números crescem rápido. Mover uma categoria com muitos filhos e produtos gera redirects para a categoria, todas as suas subcategorias e todas as URLs de produto que continham o caminho dela.
As configurações que controlam o crescimento
Elas ficam em Stores, Configuration, Catalog, Catalog, Search Engine Optimization:
| Configuração | Path | Efeito |
|---|---|---|
| Use Categories Path for Product URLs | catalog/seo/product_use_categories | Se os links de produto na storefront usam o caminho da categoria |
| Generate "category/product" URL Rewrites | catalog/seo/generate_category_product_rewrites | Se os rewrites com caminho de categoria chegam a ser gerados |
| Create Permanent Redirect for URLs if URL Key Changed | catalog/seo/save_rewrites_history | Padrão para manter os 301 quando uma URL key muda |
A segunda configuração é a grande. Os rewrites com caminho de categoria costumam ser a maior parte da tabela. Se a loja linka os produtos pela URL curta e a tag canonical aponta para ela, essas linhas não são necessárias. O admin avisa que definir como No remove os rewrites de produto com caminho de categoria que já existem. É esse o objetivo, mas também significa que essas URLs deixam de resolver. Veja antes se elas já foram linkadas ou indexadas.
As configurações de canonical link na mesma seção decidem o que os buscadores enxergam como URL principal. O quadro mais amplo está no checklist de SEO técnico.
Meça antes de apagar
Comece com contagens por tipo e por store:
SELECT entity_type, store_id, redirect_type, COUNT(*) AS total
FROM url_rewrite
GROUP BY entity_type, store_id, redirect_type
ORDER BY total DESC;
Depois compare os rewrites de produto com os produtos. Uma proporção de dezenas de rewrites por produto aponta para caminhos de categoria ou histórico de redirects:
SELECT
(SELECT COUNT(*) FROM url_rewrite WHERE entity_type = 'product') AS product_rewrites,
(SELECT COUNT(*) FROM catalog_product_entity) AS products;
Rewrites que apontam para produtos que não existem mais são puro desperdício. Normalmente o Magento remove os rewrites quando um produto é apagado, mas produtos removidos com SQL ou por módulos com defeito deixam rewrites para trás:
SELECT COUNT(*)
FROM url_rewrite ur
LEFT JOIN catalog_product_entity p ON p.entity_id = ur.entity_id
WHERE ur.entity_type = 'product'
AND p.entity_id IS NULL;
Rode a mesma checagem para categorias com catalog_category_entity e para cms-page com cms_page.page_id. Procure também rewrites de produtos com visibilidade Not Visible Individually. Esses produtos não têm página própria e não deveriam ter rewrites.
Limpando com segurança
Trabalhe primeiro num staging com uma cópia recente da produção, e faça backup da url_rewrite e da catalog_url_rewrite_product_category antes de mexer na produção. Um dump no nível da tabela basta para restaurar em minutos.
mysqldump --single-transaction magento url_rewrite catalog_url_rewrite_product_category \
| gzip > url_rewrite_backup.sql.gz
1. Remova os órfãos
Apague os rewrites de entidades que não existem mais. Isso não tem custo de SEO, porque essas URLs já retornam uma página 404 ou deveriam retornar.
DELETE ur
FROM url_rewrite ur
LEFT JOIN catalog_product_entity p ON p.entity_id = ur.entity_id
WHERE ur.entity_type = 'product'
AND p.entity_id IS NULL;
No Adobe Commerce o join continua sendo em entity_id, já que a url_rewrite guarda o ID da entidade e não o ID da linha de staging.
2. Decida sobre os rewrites com caminho de categoria
Se as URLs de produto com caminho de categoria nunca foram linkadas na storefront, o que acontece quando Use Categories Path for Product URLs sempre foi No, elas não trazem nada e podem sair. Desligue a configuração de geração e deixe o Magento removê-las. Se foram linkadas no passado, veja no seu analytics e no Search Console se há tráfego para essas URLs. Para as URLs que ainda recebem visitas, mantenha redirects 301 para a URL curta do produto em vez de descartá-las.
3. Reduza o histórico de redirects com cuidado
Redirects 301 antigos protegem links de entrada. Apagar todos é uma vitória rápida no tamanho da tabela e uma perda lenta de tráfego. Uma regra razoável é manter os redirects que receberam tráfego no último ano e remover o resto. Para fazer isso direito você precisa de logs de acesso ou dados de analytics. Sem dados, eu deixo o histórico de redirects em paz.
Redirects customizados criados à mão em Marketing, URL Rewrites têm is_autogenerated igual a 0. Nunca inclua esses em deletes em massa. Eles foram adicionados de propósito.
4. Regenere quando for preciso
O Magento não tem um comando no core para regenerar todos os URL rewrites. Os rewrites são gerados quando um produto ou categoria é salvo. Para uma regeneração completa, o módulo da comunidade elgentos/regenerate-catalog-urls adiciona comandos para regenerar os rewrites de produto, categoria e página CMS pela linha de comando. É muito usado, mas teste no staging, porque regenerar os rewrites de um catálogo grande leva tempo e substitui as linhas geradas.
Mantendo a tabela pequena
- Decida a estrutura de URL cedo: URLs curtas de produto com tags canonical são o setup mais simples.
- Evite mover categorias grandes numa loja no ar sem pensar nos redirects que vêm junto.
- Não altere URL keys em importações em massa a menos que a mudança seja intencional. Cada mudança cria redirects em todas as store views.
- Use só as store views que o negócio precisa. Cada store view multiplica todos os rewrites.
- Confira o tamanho da tabela a cada poucos meses com as queries acima.
Problemas de rewrite costumam aparecer junto com outros problemas de catálogo. Quando o save de produto está lento, confira também os modos dos indexers e observers de terceiros, como descrito em erros comuns do Magento 2 e como resolver.
Erros ligados a rewrites
O mais comum é "URL key for specified store already exists". Ele aparece ao salvar produto ou categoria e na importação quando outra entidade já usa o mesmo request_path naquela store. Às vezes a linha em conflito pertence a uma entidade que não existe mais, o que é mais um motivo para remover os órfãos. Ache o conflito com uma query em request_path e store_id antes de alterar dados.
FAQ
Posso dar truncate na tabela url_rewrite do Magento 2?
Só se você regenerar tudo logo em seguida e aceitar perder todo o histórico de redirects e os redirects customizados. Numa loja no ar isso significa links de entrada quebrados. Deletes direcionados são mais seguros.
Por que salvar uma categoria demora tanto?
Salvar ou mover uma categoria regenera os rewrites da categoria, dos filhos e dos produtos com caminho de categoria, em todas as store views. Uma tabela url_rewrite inchada deixa isso muito mais lento.
As URLs de produto devem incluir o caminho da categoria?
Na maioria das lojas, não. URLs curtas de produto evitam conteúdo duplicado e mantêm a tabela de rewrites pequena. Caminhos de categoria só agregam valor se o negócio realmente os quer na URL visível.
O Magento remove os rewrites quando um produto é apagado?
Sim, quando o produto é apagado pelo Magento. Produtos removidos com SQL direto ou por módulos que pulam o delete normal deixam rewrites órfãos para trás.
Atendo como freelancer em Magento e Adobe Commerce, incluindo limpeza de banco e SEO técnico. Se você precisa de ajuda com isso, fale comigo.
Artigos relacionados
Core Web Vitals no Magento 2: como corrigir LCP, INP e CLS
Onde lojas Magento 2 com Luma perdem nos Core Web Vitals e como corrigir LCP, INP e CLS: resposta do servidor, CSS, fontes, imagens, galeria e scripts de terceiros.
Checklist de SEO técnico do Magento 2 para desenvolvedores
Checklist de SEO técnico do Magento 2: URLs e rewrites, canonicals, layered navigation, robots.txt, sitemap, status codes, HTTPS e conferências pós-deploy.
Magento 2: tipos de cache, clean, flush e cache type próprio
O que cada cache type do Magento 2 guarda, a diferença real entre cache:clean e cache:flush, caches invalidados e como criar seu próprio cache type.
Ajuste do PHP-FPM no Magento 2: workers, OPcache, php.ini
Dimensione os pools do PHP-FPM para o Magento 2, escolha o process manager certo, configure o OPcache para um codebase grande e evite os erros de php.ini que deixam a loja lenta.