Why listing photos must never hotlink the MLS CDN

Every MLS listing arrives with photo URLs pointing at the board’s or feed vendor’s image servers. The tempting shortcut is obvious: just put those URLs in your image tags and ship. We built an entire mirroring pipeline to never do that, and this post is the case for why — because half of it is compliance and the other half is engineering, and either half alone would have been reason enough.

The licence half

Board data agreements govern display, and display includes images. When you serve a photo from the vendor’s CDN, you are consuming their bandwidth in a way most agreements never contemplated at consumer scale, and you have zero control over what that URL does next. Boards rotate image hosts. Vendors expire URLs. Records leave the feed — an expired listing, a seller who withdraws consent — and the licence expects those images gone from your site too. If your pages point at someone else’s server, “gone” happens on their schedule, not in step with your data. Mirroring makes takedown a thing we execute ourselves: when a listing leaves the feed, its images leave our storage on the same pipeline that learned about the change. What you may do with photos after a sale closes is its own topic — we answer it separately — but none of it works if you never controlled the files.

The engineering half

Hotlinked images are somebody else’s performance problem happening on your page. You cannot resize them for cards, convert them to modern formats, or set caching headers on a server you do not run. Our pipeline mirrors each original into our own storage, then generates WebP derivatives — a small one for search cards, a large one for the gallery — served from our CDN with immutable, year-long cache headers. The result is that a search results page loads dozens of appropriately sized images instead of dozens of full-resolution originals, which is much of the difference between a listing grid that feels instant and one that shudders in. There is also the availability question nobody prices in: a hotlinked site inherits every outage, throttle, and maintenance window of an image server it has no contract with. When our CDN has a bad day, that is our problem to fix. When theirs does, a hotlinking site just shows broken houses.

Sold data raises the stakes

On a VOW site, sold listings carry their own display rules, and imagery is part of them. Anonymous visitors must never see sharp sold photography where the rules restrict it — which is why our sold cards show a pre-generated blurred preview until a visitor registers. Generating that blur requires owning the pixels. Why sold photos are blurred covers the consumer-facing side; the infrastructure-facing point is that a hotlinked image cannot be blurred, gated, or resized. It can only be shown or not shown, and compliance lives in the space between.

Enforced by the build, not by policy

The uncomfortable truth about rules like this is that they erode. One rushed feature, one pasted URL, and a vendor image address is back in a template. So we made the rule executable: a scan runs in continuous integration on every change, and the build fails if any vendor image host appears anywhere in a render path. The same fence applies inside the website editor — paste a board CDN address into a page and the editor refuses it. A compliance rule that survives only as long as everyone remembers it is not a rule. Ours is a failing test, which is the strongest form a promise can take. It is the same philosophy that drives our approach to data freshness: guarantees you can demonstrate, not guarantees you assert.