url_rewrite com milhões de linhas? Desligue essa opção

Meça antes de mexer

Primeiro, o tamanho do problema. Essa consulta divide a tabela por tipo de entidade:

SELECT entity_type, COUNT(*) AS total
FROM url_rewrite
GROUP BY entity_type;

Agora a parte que interessa. As URLs de produto dentro de categoria são as que têm o category_id gravado no campo metadata:

SELECT COUNT(*) FROM url_rewrite
WHERE is_autogenerated = 1
  AND metadata LIKE '{"category_id"%';

Esse segundo número é exatamente o que vai desaparecer se você desligar a opção. O documento de arquitetura da própria Adobe estima que ele representa cerca de 95% da tabela em catálogo grande. Se na sua loja der 60 mil de 65 mil linhas, bate.

Confira o valor atual, porque o padrão mudou

Isso pega muita gente. Até o Magento 2.4.5 o config.xml do Magento_CatalogUrlRewrite vinha com generate_category_product_rewrites igual a 1. A partir do 2.4.6 o padrão passou a ser 0.

Só que subir de versão não apaga o que está gravado no banco. Se alguém já salvou a seção de SEO no admin em algum momento, o valor foi para o core_config_data e continua lá, valendo mais que o novo padrão. Confira:

bin/magento config:show catalog/seo/generate_category_product_rewrites

Se o comando responder que a configuração não existe, ótimo: você está no padrão do arquivo, que depende da sua versão. Se responder 1, alguém gravou, e a geração está ligada mesmo numa loja 2.4.6 ou mais nova.

Vale checar a config vizinha também:

bin/magento config:show catalog/seo/product_use_categories

Esse é o Use Categories Path for Product URLs, que vem 0 de fábrica. Com ele em 0, os links de produto da loja já apontam para /produto.html — ou seja, aquele monte de rewrite está ocupando disco sem ninguém clicar nele.

Desligar apaga de verdade

Aqui está o aviso que o admin dá em vermelho e que quase todo tutorial omite. O campo tem um backend model chamado TableCleaner, e ele roda um DELETE na url_rewrite assim que o valor vira 0, em cima de tudo que for autogerado e tiver category_id no metadata.

Não é preguiçoso, não é assíncrono e não tem desfazer. Religar a opção depois não recria nada — as linhas só voltam quando cada categoria for salva de novo.

E não adianta fugir para a CLI: o config:set passa pelo mesmo Magento\Config\Model\Config que o admin usa, então o backend model roda igual. Faça o dump antes:

mysqldump -u usuario -p banco url_rewrite > url_rewrite_backup.sql
bin/magento config:set catalog/seo/generate_category_product_rewrites 0
bin/magento cache:clean config

O documento de arquitetura original previa manter as linhas antigas e calcular o resto no roteador. Não foi assim que ficou no código. Confie no que o TableCleaner faz, não no design doc.

O que muda na loja

Se product_use_categories já estava em 0, a resposta honesta é: nada visível. Os links continuam saindo como /produto.html, o canonical continua o mesmo, e o Google não perde nenhuma URL que estivesse indexada por link interno.

Se estava em 1, aí muda. Os links de produto dentro das categorias voltam para a URL curta, e as URLs longas que estavam indexadas deixam de resolver. Nesse caso o roteiro é outro: primeiro decida qual formato você quer manter, publique os redirects 301 das URLs longas para as curtas, deixe o Google digerir, e só depois desligue a geração.

O ganho aparece onde dói: salvar categoria deixa de gravar milhares de linhas, o setup:upgrade para de arrastar a tabela e o backup encolhe. Se você ainda está decidindo qual formato de URL de produto usar, o raciocínio completo está no guia de SEO técnico para Magento 2.