Listing Syndication Audit
Verify that a property listing renders correctly — price, photos, and description — across the public real estate portals it was syndicated to.
When to use
- After a new listing is published or an existing listing's price, photos, or description is updated.
- When a client or agent reports a listing looks wrong on a specific portal.
- On a recurring cadence to catch silent portal-side sync failures.
- Before a scheduled open house, to confirm the listing is presentable everywhere buyers might see it.
Tools
browser-navigatebrowser-extractcreate-task
Playbook
- Confirm the source-of-truth listing details before checking anything external: price, photo count and order, and the current description text. Treat these as the baseline you will compare every portal against.
- Use
browser-navigateto open the listing's page on the first target portal (e.g.https://www.zillow.com/homedetails/<listing-id>). - Use
browser-extractto pull the rendered price, photo count, and description text from that page. - Compare the extracted values against the baseline. Flag any mismatch: wrong price, missing or reordered photos, truncated or stale description text.
- Repeat steps 2-4 for each additional portal in scope (e.g.
https://www.realtor.com/realestateandhomes-detail/<listing-id>,https://www.redfin.com/home/<listing-id>, or an MLS (Multiple Listing Service — the regional database brokers use to share listings) public-facing search result). - If a portal shows a listing as expired, unpublished, or missing entirely when it should be live, record that as a hard failure, not just a rendering mismatch.
- Compile findings into a per-portal pass/fail summary noting the specific field that failed (price, photos, or description) and the observed vs. expected value.
- For any failure, use
create-taskto open a follow-up task assigned to a human, since fixing portal sync settings, re-triggering a feed export, or contacting portal support requires account access and judgment calls this audit does not have. - If every portal checked matches the baseline, close out the audit with a clean summary and no follow-up task needed.
Failure modes
- A portal caches old listing data, so a fresh page load still shows a stale price or description even though the source system was updated correctly — note the cache lag rather than assuming the source data is wrong.
- Photos load out of order or are missing on mobile-rendered portal pages but correct on desktop; check both if the portal serves different markup.
- A portal's page structure changes without notice, causing
browser-extractto pull the wrong element (e.g. a promotional banner price instead of the listing price) — sanity-check any wildly implausible extracted value before flagging it as a mismatch. - Listing was intentionally pulled or put under contract, so it correctly disappears from public portals — confirm listing status before treating "not found" as a failure.
Done when
- Every portal in scope has been checked against the current source-of-truth listing details for price, photos, and description.
- A pass/fail summary exists for each portal, with specific mismatches noted.
- A human-facing task has been created via
create-taskfor every confirmed failure, or the audit is closed clean with none needed.