The link that wasn't a link 

Three links. Three different ways to fail. A Facebook event URL that looked valid but returned nothing. An event website that silently redirected to a different business. An Instagram profile page instead of an event. None of them threw an error. All of them produced garbage.

The share URL

Facebook has multiple URL formats for the same event. The standard one works: /events/12345/. The share format doesn't: /events/s/event-name/12345/. Same event, same browser behavior, but the scraper only recognizes the first format. The share URL returns empty. No error. Just nothing.

Fix: strip the /s/event-name/ segment. Two lines of code. Hours to find.

The redirect

A dance school's website was listed as the event source. The domain redirected to a completely different dance school. Legitimate redirect, the school had moved. The pipeline followed the redirect, scraped the wrong website, fed it to the AI, and the AI created a fake event from someone else's content. Title wrong. Dates wrong. Venue wrong. Everything wrong.

And it passed validation. Because the fake data was internally consistent. That's the dangerous kind of failure. Not the one that crashes. The one that looks fine.

Fix: compare the original domain with the resolved domain after following redirects. If they don't match, stop. Don't scrape a page you weren't sent to.

The profile

An organizer posted their Instagram profile as the "event link." Not a post, not a story, the profile page. No dates, no venue, no description. Just a bio and a grid of photos.

Fix: nothing. This is a source data problem. The pipeline flags it and moves on. Some links can only be handled by a human who knows what to search for.

The pattern

When you process hundreds of links, you learn that "valid URL" and "usable source" are different things. Share URLs need normalization. Redirects need domain validation. Platform links need classification. Profile is not post. Photo is not event. Ticket page is not event page.

The first 80% of automation is the happy path. The next 15% is handling the weird paths. The last 5% is knowing which paths to refuse.

Most of the bugs weren't in the code. They were in the assumptions about what a "valid link" looks like.

72 links from a calendar spreadsheet. 59 led to real, publishable events. 13 didn't. The system knew the difference. That knowledge is the product. Not the scraping, not the AI. The ability to say "this isn't what it claims to be" before creating garbage. All orchestrated through PulseAI, where every URL, every redirect, every decision is logged and traceable.