core_url_rewriteに追加されている奇妙な非システム行

私たちのcore_url_rewriteテーブルには、（現在は21M行）が過度に成長しているようだ-私はこれについて、他の質問があった知っているが、それらのどれもが、この特定の風変わりに言及するように見えるん：追加された新しい行の多くは持っているis_system = 0、とid_pathのようなものです」 97704000_1422557940」。アンダースコアの後の数字は、行が追加されたタイムスタンプのように見えますが、最初の数字が何であるかわかりません。

core_url_rewrite問題に対するアドバイスは、常にテーブルを切り捨ててインデックスを再作成することであるように思われますが、そのようになる可能性がありますが、テーブルには多くのカスタムリライトがあり、常に再追加しなければならないのは大変なことです。 、そして私はむしろ問題の根本に到達したいと思います。

1.9.1.0にアップグレードしましたが、テーブルに約2年前の行があります（！）。

何か案は？

これは、書き換えに関するクラシックの問題です。根本的な原因は、一意のURLキーがないことです。通常、同じ名前の構成可能ファイルの一部に単純な製品が含まれていることが原因です。

明らかな理由により、1つのリクエストパス（URL）はMagentoの1つのアクションと一致する必要があります。したがって、すべての要求パスは一意である必要があります。製品とカテゴリの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の組み合わせと一致するrequest_pathに設定します。オプションはNULLです。
4. この拡張機能をインストールして、すべての最適化を有効にします
5. 再インデックスは少なくとも2回書き換え、行数が一貫していることを確認します（製品またはカテゴリに変更がない場合）。
6. ウェブマスターツールと404を監視して、まだスパイダー内にあり、リダイレクトする必要がある古いURLがないか確認します。core_url_rewriteクリーンを保つために、Webサーバーに301を実装することをお勧めします。

注： このスクリプトは、属性値を繰り返し、一意のキーが生成されるまで追加することにより、一意のURLキーを作成するのに役立ちます。このスクリプトは、カテゴリと製品間の競合をチェックしないことに注意してください。カテゴリは通常複数形で名前が付けられているため、通常これは問題になりませんが、たとえば羊や魚を販売する場合は、これでも問題になる可能性があります。別のコーナーケースは、カタログURLとCMSページ間の衝突です。このスクリプトはそれをチェックしませんが、CMSページ識別子がそこにないため、書き換えにも影響しません。これにより、CMSページまたはカテゴリ/製品ページのいずれかが、一方が他方に表示されると予想される場所に表示されます。

上記のtemp_tableには、すべてのサイトマップにあるURLを入力する必要があります。これにより、ダッシュとシーケンス番号の現在のバリアントを存続させることにより、SEOへの影響の一部が軽減され、ステップ3で正しいURLに書き換えられます。ステップ4の拡張機能により、多数のURLがcore_url_rewriteテーブルに入るのを防ぎます。最も顕著なのは、「カタログ/検索」表示に設定されていない製品です。構成可能であり、個別にリストされていない単純な製品がある場合、これらは「個別に表示されない」とマークする必要があり、この拡張機能はそれらが書き換えに入るのを防ぎます。これは、このURL書き換えの問題があるストアに関係なく、構成可能な製品を使用するストアにとって価値のある最適化です。ステップ5に関して、製品とカテゴリのURLキーに変更が加えられていない場合、その後、すべてのインデックス作成で同じ量の書き換えが生成されます。これが当てはまらない場合は、まだどこかで競合が発生しているため、それを回避する必要があります。

これで状況が少し明確になることを願っています。

これらは通常、カタログ内の製品とカテゴリを変更したときにプログラムで生成されたリダイレクトであると思います。それらは古いリンクを維持して顧客を新しい場所に送ることを目的としていますが、特に複数のWebサイト/ストア/ビューや多数の製品がある場合は、時間がたつにつれて蓄積する傾向があるため、しばらくするとおそらくそれらを削除できます。