Linhas estranhas que não são do sistema sendo adicionadas ao core_url_rewrite

Nossa core_url_rewritetabela parece estar crescendo excessivamente (21 milhões de linhas atualmente) - eu sei que houve outras perguntas sobre isso, mas nenhuma delas parece mencionar essa peculiaridade específica: muitas das novas linhas adicionadas têm is_system = 0e id_pathé algo como " 97704000_1422557940 ". O número após o sublinhado parece ser o carimbo de data e hora em que a linha foi adicionada, mas não tenho certeza qual é o primeiro número.

O conselho para os core_url_rewriteproblemas sempre parece ser o de truncar a tabela e re-indexar, e pode ser que isso aconteça, mas temos muitas reescrições personalizadas na tabela, portanto, ter que adicioná-las constantemente constantemente será uma verdadeira dor , e prefiro chegar à raiz do problema.

Acabamos de atualizar para a 1.9.1.0, mas há linhas na tabela que remontam a quase dois anos (!).

Alguma ideia?

Este é um problema clássico com reescritas. A causa raiz não está tendo chaves de URL exclusivas. Normalmente causado por ter produtos simples como parte do configurável com o mesmo nome.

Por razões óbvias, um caminho de solicitação (URL) deve corresponder a uma ação no Magento. Portanto, todos os caminhos de solicitação precisam ser exclusivos. Os caminhos de URL do produto e da categoria são criados a partir de suas chaves de URL e, normalmente, quando você tem produtos configuráveis, os proprietários das lojas / funcionários de back-end não reservam tempo para garantir que os produtos simples abaixo de um configurável tenham chaves de URL diferentes. Isso faz com que o Magento insira um traço e um número de sequência. Dado um produto configurável com 4 simples, isso significa que pelo menos 4 URLs com uma sequência são adicionados a cada iteração (porque o Magento não faz / não pode distinguir entre execuções que uma sequência já foi criada). Isso se soma rapidamente em um grande catálogo.

O fluxo de trabalho a recuperar é o seguinte:

1. Verifique se todas as chaves de URL são únicas para corrigir sua entrada e faça outra reindexação de reescritas.
2. Remova todas as regravações correspondentes WHERE id_path LIKE "%_%" AND options="RP" AND (catalog_id IS NOT NULL OR product_id IS NOT NULL) AND target_path NOT IN (temp_table).
3. Para as correspondências reescritas restantes, WHERE id_path LIKE "%_%" AND options="RP" AND (catalog_id IS NOT NULL OR product_id IS NOT NULL)defina o caminho do pedido como o caminho do destino e defina o caminho do destino como o caminho do pedido que corresponde à combinação category_id-product_id e onde as opções são NULL.
4. Instale esta extensão e ative todas as otimizações
5. Reindexar reescreve pelo menos duas vezes, verificando se a contagem de linhas é consistente (sem alterações nos produtos ou categorias).
6. Monitore as Ferramentas do Google para webmasters e os 404s para obter URLs antigos adicionais que ainda estão em aranhas e devem ser redirecionados. De preferência, implemente o 301 em seu servidor da web para manter-se core_url_rewritelimpo.

Notas: Esse script ajuda a criar chaves de URL exclusivas, iterando valores de atributos e anexando-os até que uma chave exclusiva seja gerada. Observe que esse script não verifica conflitos entre uma categoria e um produto. Normalmente, isso não é um problema, pois as categorias são nomeadas naturalmente no plural, mas se você vende, por exemplo, ovelhas ou peixes, isso ainda pode ser um problema. Outro caso de canto é um conflito entre URLs de catálogo e páginas do CMS. Este script não verifica, mas também não afeta as reescritas, pois os identificadores de página do CMS não estão lá. Isso simplesmente resultará na exibição da página do CMS ou da página da categoria / produto, onde um esperaria ver o outro.

O temp_table mencionado deve ser preenchido com URLs que estão em todos os sitemaps. Isso atenua parte do impacto do SEO, mantendo ativa a variante atual do número do traço e da sequência e, na etapa 3, ela é reescrita no URL correto. A extensão na etapa 4 impede que vários URLs entrem na tabela core_url_rewrite, principalmente produtos que não estão definidos para a visibilidade "catálogo / pesquisa". Quando você tem produtos simples que fazem parte de um configurável e não são listados separadamente, eles devem ser marcados como "não visíveis individualmente" e essa extensão impede que eles digitem reescritas. Essa é uma otimização valiosa para lojas com produtos configuráveis, independentemente de terem esse problema de reescrita de URL. Em relação à etapa 5, se nenhuma alteração for feita nas chaves de URL de produtos e categorias, então toda indexação deve gerar a mesma quantidade de reescritas. Se não for esse o caso, você ainda tem um conflito em algum lugar e deve procurá-lo.

Espero que isso esclareça um pouco as coisas.

Acredito que esses geralmente são redirecionamentos gerados programaticamente quando você altera produtos e categorias no catálogo. Eles destinam-se a manter links antigos para enviar clientes para os novos locais, mas é possível removê-los depois de um tempo, pois eles tendem a se acumular ao longo do tempo - especialmente se você tiver vários sites / lojas / visualizações e muitos produtos.