Merchant Feed And Page Parity

The feed and the product page are two representations of the same item, maintained by different teams, so they drift. The mismatch suppresses the item without touching organic ranking, which is why it goes unnoticed for months. The instinct is to work through disapprovals in the interface one at a time, but they are nearly always produced by a handful of feed rules or by fields missing from the source catalogue.

Die Skill-Datei

---
name: merchant-feed-and-page-parity
description: Use when free product listings show far fewer items than the catalogue holds, or items get disapproved while the product pages themselves look fine.
---

# Merchant Feed And Page Parity

The feed and the product page are two representations of the same item, maintained by different teams, so they drift. The mismatch suppresses the item without touching organic ranking, which is why it goes unnoticed for months. The instinct is to work through disapprovals in the interface one at a time, but they are nearly always produced by a handful of feed rules or by fields missing from the source catalogue.

## Was Sie vorher brauchen

- The current feed export plus item-level diagnostics with disapproval reasons attached
- Rendered product pages for a sample across categories, showing price and availability as a crawler sees them
- GTIN, MPN and brand coverage figures per category taken from the source catalogue, not the feed
- The tax and shipping settings configured on the merchant account

## Methode

1. Count disapproved and pending items by reason before opening a single item. Two or three reasons usually account for most of the volume and they are configuration or coverage faults, not per-item ones.
2. Reconcile counts first: feed rows against sellable SKUs in the database. A feed missing a third of the catalogue is a generation fault and no attribute work matters until that is fixed.
3. Diff price and availability between feed and rendered page across the sample, comparing timestamps as well as values. Different caches on the two paths is the most common source of mismatch.
4. Fix identifier coverage at the catalogue source rather than in a feed rule. An identifier invented during a feed transformation fails validation and corrupts the record you will need later.
5. Build feed titles from your own attribute order, brand then product then the attribute buyers search by, rather than reusing the page title. Feed titles are matched against queries and truncated hard, so page title order is rarely right.
6. Write down which fields the feed is allowed to differ on. Shipping and tax belong in account settings rather than item data, and descriptions may legitimately be shorter than the page.
7. Recheck diagnostics at 14 days and watch the reason mix rather than the headline count, since clearing one reason routinely exposes a second that was masked behind it.

## Was dabei herauskommt

A reconciled feed with a stated field parity rule, disapprovals cleared at cause, and identifier coverage repaired in the source catalogue.

## Wo es schiefgeht

- Patching mismatches with feed rules while the source catalogue stays wrong, so the same errors return at the next full rebuild
- Generating placeholder identifiers to satisfy a required field, which produces disapprovals harder to diagnose than the missing field was
- Reading an account-level approval rate as health when the disapprovals sit on a few high-revenue lines
- Comparing the feed against the source HTML when price and stock are injected client-side, so the mismatch never shows up in testing

---

Aus der QuQi-Skill-Bibliothek - https://www.quqi.io/de/skills/merchant-feed-and-page-parity

Was Sie vorher brauchen

• The current feed export plus item-level diagnostics with disapproval reasons attached
• Rendered product pages for a sample across categories, showing price and availability as a crawler sees them
• GTIN, MPN and brand coverage figures per category taken from the source catalogue, not the feed
• The tax and shipping settings configured on the merchant account

Methode

1. 01 Count disapproved and pending items by reason before opening a single item. Two or three reasons usually account for most of the volume and they are configuration or coverage faults, not per-item ones.
2. 02 Reconcile counts first: feed rows against sellable SKUs in the database. A feed missing a third of the catalogue is a generation fault and no attribute work matters until that is fixed.
3. 03 Diff price and availability between feed and rendered page across the sample, comparing timestamps as well as values. Different caches on the two paths is the most common source of mismatch.
4. 04 Fix identifier coverage at the catalogue source rather than in a feed rule. An identifier invented during a feed transformation fails validation and corrupts the record you will need later.
5. 05 Build feed titles from your own attribute order, brand then product then the attribute buyers search by, rather than reusing the page title. Feed titles are matched against queries and truncated hard, so page title order is rarely right.
6. 06 Write down which fields the feed is allowed to differ on. Shipping and tax belong in account settings rather than item data, and descriptions may legitimately be shorter than the page.
7. 07 Recheck diagnostics at 14 days and watch the reason mix rather than the headline count, since clearing one reason routinely exposes a second that was masked behind it.

Was dabei herauskommt

A reconciled feed with a stated field parity rule, disapprovals cleared at cause, and identifier coverage repaired in the source catalogue.

Wo es schiefgeht

• Patching mismatches with feed rules while the source catalogue stays wrong, so the same errors return at the next full rebuild
• Generating placeholder identifiers to satisfy a required field, which produces disapprovals harder to diagnose than the missing field was
• Reading an account-level approval rate as health when the disapprovals sit on a few high-revenue lines
• Comparing the feed against the source HTML when price and stock are injected client-side, so the mismatch never shows up in testing

Diese Skill in Ihrer eigenen KI nutzen

Die Datei ist einfaches Markdown, mit Name und Auslöser im Frontmatter. Wo ein Assistent Skills selbst laden kann, liest er genau dieses Frontmatter, um zu entscheiden, dass diese hier passt.

Mehr in E-Commerce-SEO