奇怪的非系统行被添加到core_url_rewrite

我们的core_url_rewrite表格似乎增长过度（目前有2100万行）-我知道还有其他问题，但是似乎都没有提到这个奇怪的问题：正在添加的许多新行都有is_system = 0，而id_path诸如此类的“ 97704000_1422557940”。下划线后的数字似乎是添加行的时间戳，但是我不确定第一个数字是什么。

对于core_url_rewrite问题的建议似乎始终是截断表并重新索引，这可能会导致这种情况，但是表中有很多自定义重写，因此不得不不断地重新添加它们将是一个真正的痛苦。 ，而我宁愿找到问题的根源。

我们刚刚升级到1.9.1.0，但是表中的行可以追溯到将近两年（！）。

有任何想法吗？

这是重写的经典问题。根本原因是没有唯一的URL密钥。通常是由于具有相同名称的可配置简单产品部分引起的。

出于显而易见的原因，一个请求路径（URL）必须与Magento中的一项操作匹配。因此，所有请求路径都必须是唯一的。产品和类别URL路径是通过其URL密钥创建的，通常，当您拥有可配置的产品时，商店所有者/后端工作人员不会花时间确保可配置下的简单产品具有不同的URL密钥。这会导致Magento插入破折号和序列号。给定一个具有4个简单变量的可配置产品，这意味着每次迭代至少添加4个带有序列的URL（因为Magento不能/不能区分已经创建序列的运行）。这在一个大目录中迅速加起来。

恢复的工作流程如下：

1. 确保所有URL键都是唯一的，以固定您的输入，并进行另一次重写索引。
2. 删除所有匹配的重写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. 对于其余的重写匹配，WHERE id_path LIKE "%_%" AND options="RP" AND (catalog_id IS NOT NULL OR product_id IS NOT NULL)将request_path设置为target_path，将target_path设置为与category_id-product_id组合匹配且选项为NULL的request_path。
4. 安装此扩展并启用所有优化
5. Reindex至少重写两次，以验证行数是否一致（不更改产品或类别）。
6. 监视网站站长工具和404，以获取仍在蜘蛛网中且应重定向的其他过时的URL。最好在您的网络服务器中实施301以保持core_url_rewrite清洁。

注意： 该脚本通过迭代属性值并将其附加到生成唯一键之前，可以帮助创建唯一的URL键。请注意，此脚本不会检查类别和产品之间的冲突。通常，这不是问题，因为类别自然会以复数形式命名，但是如果您出售例如绵羊或鱼类，这仍然是一个问题。另一个极端情况是目录URL和CMS页面之间的冲突。该脚本不会对其进行检查，但也不会影响重写，因为CMS页面标识符不在其中。这只会导致CMS页面或类别/产品页面显示在希望看到另一个的位置。

提及的temp_table应该填充所有站点地图中的URL。这通过保持短划线和序列​​号的当前变体有效来减轻了SEO的某些影响，然后在步骤3中将其重写为正确的URL。步骤4中的扩展名阻止了许多URL进入core_url_rewrite表，最明显的是未设置为“目录/搜索”可见性的产品。如果您有一些简单的产品是可配置的一部分，并且没有单独列出，则应将其标记为“单独不可见”，然后使用此扩展名阻止它们输入重写。对于具有可配置产品的商店，这是有价值的优化，无论它们具有此URL重写问题。关于步骤5，如果未对产品和类别的网址键进行任何更改，那么每个索引都将生成相同数量的重写。如果不是这种情况，那么您仍然在某个地方存在冲突，应该追查一下。

希望这可以澄清一些事情。

我相信这些通常是在更改目录中的产品和类别时以编程方式生成的重定向。它们旨在维护旧的链接，以将客户吸引到新的位置，但是您可能会在一段时间后清除它们，因为它们的确会随着时间的流逝而建立，尤其是在您拥有多个网站/商店/视图和大量产品的情况下。