Se añaden filas extrañas que no son del sistema a core_url_rewrite

Nuestra core_url_rewritetabla parece estar creciendo excesivamente (21 millones de filas actualmente). Sé que ha habido otras preguntas al respecto, pero ninguna de ellas parece mencionar esta particularidad en particular: muchas de las nuevas filas que se agregaron tienen is_system = 0, y id_pathes algo así como " 97704000_1422557940 ". El número después del guión bajo parece ser la marca de tiempo en la que se agregó la fila, pero no estoy seguro de cuál es el primer número.

El consejo para los core_url_rewriteproblemas siempre parece ser truncar la tabla y volver a indexar, y puede llegar a eso, pero tenemos muchas reescrituras personalizadas en la tabla, por lo que tener que volver a agregarlas constantemente será un verdadero dolor. , y preferiría llegar a la raíz del problema.

Acabamos de actualizar a 1.9.1.0, pero hay filas en la tabla que se remontan a casi dos años (!).

¿Algunas ideas?

Este es un problema clásico con reescrituras. La causa raíz no es tener claves de URL únicas. Típicamente causado por tener productos simples parte de configurables con el mismo nombre.

Por razones obvias, una ruta de solicitud (URL) debe coincidir con una acción en Magento. Por lo tanto, todas las rutas de solicitud deben ser únicas. Las rutas de URL de producto y categoría se crean a partir de sus claves de URL y, por lo general, cuando tiene productos configurables, los propietarios de tiendas / trabajadores de backend no se toman el tiempo para asegurarse de que los productos simples debajo de un configurable tengan diferentes claves de URL. Esto hace que Magento inserte un guión y un número de secuencia. Dado un producto configurable con 4 simples, esto significa que se agregan al menos 4 URL con una secuencia en cada iteración (porque Magento no puede / no puede distinguir entre ejecuciones que una secuencia ya está creada). Esto se suma rápidamente en un gran catálogo.

El flujo de trabajo para recuperar es el siguiente:

1. Asegúrese de que todas las claves de URL sean únicas arreglando su entrada y realice otra reindexación de reescrituras.
2. Elimine todas las reescrituras que coincidan 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 las coincidencias de reescrituras restantes, WHERE id_path LIKE "%_%" AND options="RP" AND (catalog_id IS NOT NULL OR product_id IS NOT NULL)establezca request_path en target_path y establezca target_path en request_path que coincida con la combinación category_id-product_id y las opciones IS NULL.
4. Instale esta extensión y habilite todas las optimizaciones
5. Reindex reescribe al menos dos veces, verificando que el recuento de filas sea consistente (dado que no hay cambios en productos o categorías).
6. Monitoree las Herramientas para webmasters y los 404 para obtener URL obsoletas adicionales que todavía están en las arañas y deben redirigirse. Preferiblemente implemente el 301 en su servidor web para mantenerse core_url_rewritelimpio.

Notas: Este script ayuda a crear claves de URL que son únicas, iterando valores de atributos y agregándolos hasta que se genere una clave única. Tenga en cuenta que este script no verifica los conflictos entre una categoría y un producto. Por lo general, esto no es un problema, ya que las categorías se nombran naturalmente en plural, pero si vende, por ejemplo, ovejas o peces, puede ser un problema. Otro caso de esquina es un choque entre las URL de catálogo y las páginas de CMS. Este script no lo verifica, pero tampoco afecta las reescrituras ya que los identificadores de página de CMS no están allí. Esto simplemente dará como resultado que se muestre la página de CMS o la página de categoría / producto donde uno esperaría ver al otro.

El temp_table mencionado debe llenarse con las URL que se encuentran en todos los sitemaps. Esto mitiga parte del impacto de SEO al mantener viva la variante actual del guión y el número de secuencia y, en el paso 3, esto se reescribe en la URL correcta. La extensión en el paso 4 evita que varias URL ingresen a la tabla core_url_rewrite, especialmente los productos que no están configurados para visibilidad de "catálogo / búsqueda". Cuando tiene productos simples que forman parte de un dispositivo configurable y que no se enumeran por separado, estos deben marcarse como "no visibles individualmente" y esta extensión les impide ingresar reescrituras. Esta es una optimización valiosa para tiendas con productos configurables, independientemente de que tengan este problema de reescritura de URL. Con respecto al paso 5, si no se realizan cambios en las claves de URL de productos y categorías, entonces cada indexación generará la misma cantidad de reescrituras. Si este no es el caso, todavía tiene un conflicto en algún lugar y debe buscarlo.

Espero que esto aclare un poco las cosas.

Creo que estos suelen ser redireccionamientos generados mediante programación cuando cambia productos y categorías en el catálogo. Su objetivo es mantener enlaces antiguos para enviar clientes a las nuevas ubicaciones, pero probablemente pueda purgarlos después de un tiempo, ya que tienden a acumularse con el tiempo, especialmente si tiene múltiples sitios web / tiendas / vistas y muchos productos.