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.

The skill file

---
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.

## What you need first

- 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

## Method

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.

## What this produces

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

## Where this goes wrong

- 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

---

From the QuQi skill library - https://www.quqi.io/skills/merchant-feed-and-page-parity

What you need first

• 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

Method

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.

What this produces

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

Where this goes wrong

• 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

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Questions about this skill

More in Ecommerce SEO