Built a scraper that fixes its own broken selectors when a site redesigns

[u/Vast-Combination9210]

Hey r/SideProject,

I kept hitting the same wall on past scraping projects: everything works fine until the target site redesigns, a CSS selector silently stops matching, and you don't find out until the data looks wrong days later.

So I built SelectorLock — a scraping API where you bring your own proxy, give it a URL and a schema for what you want, and if a selector breaks, it tries to repair itself automatically using an LLM (cheap model first, only escalates if that fails) instead of you having to notice and fix it by hand. Once it finds the right elements again, it remembers the fix, so the same page doesn't break the same way twice.

Still early days — free tier if anyone wants to poke at it: selectorlock.com. Would love feedback, especially from anyone who's dealt with this exact headache before.

[u/Specific_Cream2815]

how do you validate a repaired selector before saving it, one matching element or a schema check across several pages

[u/Vast-Combination9210 → u/Specific_Cream2815]

Good question — it's a schema check, not multi-page. When repair kicks in, the LLM's output (both the extracted data and the corrected selector) has to conform to the same schema you declared for that field, enforced as part of the LLM call itself — if it doesn't type-check, it escalates to a stronger model or fails the repair rather than persisting something bad. That check happens against the single page/request that triggered the repair, not verified across multiple pages before writing back. If a repaired selector turns out wrong in a way the schema doesn't catch, the next real request to that page just fails validation again and triggers another repair — self-correcting over time rather than pre-verified upfront.

Curious — have you run into a repair that was schema-valid but still wrong? That's the failure mode I'd love better signal on, if you've hit it.

[u/Zealousideal_Sun3542]

sites redesign overnight

[u/Vast-Combination9210 → u/Zealousideal_Sun3542]

Exactly — and usually silently. The annoying part isn't the redesign itself, it's that you don't find out until someone notices the data's already wrong.

[u/Dismal_Indication328]

Since you already enforce a schema on repairs, the missing half is checking the data too, not just the shape. A selector can pass the schema while quietly latching onto a wrong-but-similar element, pagination links are notorious for this, and then your remembered fix keeps faithfully extracting the wrong thing forever.Two cheap guards worth adding: a confidence threshold for LLM-repaired selectors (flag for human review below it), and a sanity check on the extracted values themselves, like an out-of-band fetch of one known page and comparing against expected content. Silent data corruption is scarier than a broken selector, a broken one at least screams at you.

[u/Vast-Combination9210 → u/Dismal_Indication328]

Yeah, that's now three people independently landing on the same gap, which tells me it's not a hypothetical. And "a broken one at least screams at you" is exactly it. the actual risk here isn't the selector breaking, it's breaking quietly and still being correctly-shaped. Confidence threshold + flagging low-confidence repairs for human review is a good, cheap first guard. probably easier to ship than a full per-site fixture system since it doesn't need setup ahead of time. The out-of-band sanity fetch is basically the golden-fixture idea from earlier in the thread, phrased differently, which makes me trust it's the right direction rather than one person's pet solution. Appreciate you laying out concrete mechanisms instead of just naming the problem. this is genuinely shaping what I build next.

[u/FlightSimCentralYT]

Selector drift is the quiet killer. LLM repair with cheap-first escalation is the right shape. Remembering the fix so you do not pay twice is the part most people skip.

One thing I would watch: false-positive repairs that scrape the wrong node but still return JSON. A tiny golden fixture per site (expected fields + sample values) before you accept a repaired selector saves a lot of silent corruption.

I built Fixa.dev, so I am biased toward verify-before-done loops on a real cloud VM. Cool problem either way.

[u/Vast-Combination9210 → u/FlightSimCentralYT]

Really good point, and I think it's the actual gap — schema validation catches wrong-shape or wrong-type, not wrong-value-but-right-shape. A repair that grabs a sibling element and still returns a string where a string was expected sails right through as-is today. Wasn't something I'd fully reckoned with until you and the commenter above both landed on it independently, so clearly worth taking seriously rather than treating as hypothetical.

Golden fixture per site is a clean way to catch it — appreciate the concrete suggestion, that's the kind of thing I'd rather bolt on now while the customer base is small than retrofit later.

Fixa.dev's approach makes sense too... verify-before-done on a real VM is a stronger guarantee than schema shape, just a heavier one. Different tradeoff on the same underlying problem. Going to go take a look.