We run two Meta catalogs holding the same ~16,336 homes: one is the correct real-estate home_listings catalog (what DPA LAB serves from), the other is a commerce catalog (Catalog_Homa_Commerce_LAL). They crawl our site in different ways — and the commerce one is worth understanding, because its model is pixel-driven, not feed-driven.
commerce catalog updates & validates items via the Meta Pixel + on-page microdata, not a scheduled feed. Per Meta: "your product information won't be updated in Commerce Manager until your pixel has fired at least once."/property/{id} route, that's another path that can trigger the RapidAPI/OpenAI reads.meta-externalads/1.1 — so the same fix applies: serve it (and the pixel-triggered re-fetch) cached/lightweight property data.home_listings catalog). If it exists only to seed lookalikes, it may be removable — which would shrink the crawl surface. Housing must not be advertised off a commerce catalog (policy).home_listings — Catalog_Real_EstateThe real-estate vertical. Updated by a scheduled data feed (our worker's feed.csv). Meta re-ingests the feed on a schedule and re-crawls product URLs to validate. This is what all active LAB DPA campaigns serve from. (Feed refresh now paused.)
commerce — Catalog_Homa_Commerce_LALThe generic-products vertical. Same 16,336 homes as products. Kept fresh primarily via the Meta Pixel + microdata on the page — updates are pixel-triggered, not feed-scheduled. Not used by any active LAB DPA campaign.
A commerce catalog can be fed three ways: a data feed, a partner/manual upload, or the Meta Pixel + microdata path. The pixel path is the one with distinct crawl behavior:
<head>, Schema.org microdata, and JSON-LD.ViewContent event), Meta ties the event to a product and reads/refreshes the page's microdata to keep the catalog item current.Fields Meta reads from the microdata:
og:title product:price:amount productID / retailer_item_id og:description product:price:currency item_group_id og:image product:availability product:condition og:url (Schema.org / JSON-LD equivalents all accepted)
/property/{id}, which fires ViewContent and does live RapidAPI + OpenAI work, this is a second mechanism (besides the DPA feed crawl) that can drive expensive re-reads.The crawler doing the fetching is still Meta's ads crawler:
| User-agent | Role for the commerce catalog |
|---|---|
meta-externalads/1.1 OURS | Fetches product URLs to validate / enrich catalog items for ads (both verticals) |
facebookexternalhit/1.1 | Reads OG/microdata for link previews & sharing |
So the fix is identical to the DPA brief — detect the crawler UA on the property route and serve cached/lightweight data (title, price, availability, image, OG/microdata tags) without the live RapidAPI + OpenAI calls. The microdata is exactly what Meta wants anyway, and it's cheap to serve statically:
if (uaIsMetaCrawler(req)) {
return renderCachedProperty(id); // OG + product microdata from cache; no live reads
}
Catalog_Homa_Commerce_LAL — they all use the home_listings catalog. If it's only there to seed a lookalike audience, confirm that dependency; if nothing needs it, archiving it removes a whole duplicate crawl/pixel surface for the same homes.commerce (generic products) catalog would be a fair-housing policy problem — real estate must use home_listings + the HOUSING special-ad-category. Worth a quick audit.