The dead landing page behind a 200 status code
A 200 proves one thing: a server answered. It says nothing about whether the page a human lands on is the page you paid to send them to. Every check in this post looks paranoid until the day it saves you a month of budget.
What a status code actually tells you
Status codes describe the transaction, not the content. A server can return 200 with an error message, an empty shell, a “Not Found” screen, or a page that is missing the one element the ad promised. All of those are, from the network’s point of view, a complete success.
Which means every automated link checker, every uptime monitor, and every pre-flight validation that stops at the status line is answering a question you did not ask.
Three ways this has actually bitten us
Single-page-app fallthrough. On a client-rendered site, a URL that does not exist still returns 200 and serves the app shell. The app then paints “Not Found” in the browser. An ad can point at that URL for weeks. The status monitor reports healthy the entire time, because it is.
The unpublished product page. The page renders. It looks right to a human. But the record behind it was never published, so the page ships without Product structured data. Search engines and shopping surfaces treat it as an unremarkable document. Nothing errors. Nothing warns.
The 105-character body. We fetched one of our own product pages the way a crawler does — no JavaScript — and got back roughly 105 characters. No product name, no description, no structured data. To a person the page was perfect. To a crawler it was blank. Same URL. Same 200.
The rule we run now
Validate every ad destination URL by parsing the live page body, never by status code alone. Before a single dollar moves, the check has to find the actual expected content on the actual page: the product name, the structured data block, the booking form — whatever the ad is promising.
If the ad says “book a consultation” and the fetched HTML contains no form, the ad does not launch. Not a warning. A block. The check is only worth having if it can stop the launch.
And never accept an API’s JSON as proof of what a page renders. A content management system will happily tell you a field is set while the template that was supposed to output it was refactored away. The API describes intent. Curling the live HTML describes reality. Only one of those is what your customer receives.
The same trap on the other end of the funnel
A working landing page with a broken conversion event is the same failure wearing a different hat. The campaign runs. Clicks arrive. The platform reports zero conversions, and the honest interpretation — “the offer is not working” — is completely wrong.
Worse, a campaign optimizing against an event that never fires will spend its full budget learning nothing. The algorithm needs signal to improve. No signal means it is guessing for the entire flight, at full price, and the report at the end will blame your creative.
So we verify the conversion event actually fires — by triggering it and watching it arrive in the platform’s own event tool — before launch. Not by confirming the tag is installed. By confirming the event landed.
What we would check before your next launch
- Curl every ad destination URL and read the body. Search the returned HTML for the specific thing the ad promises. If it is not in the raw response, your check has not passed.
- Deliberately request a URL that does not exist. If it returns 200 instead of 404, every link checker you own is lying to you about every URL.
- Confirm structured data is in the served HTML, not just enabled in a plugin setting.
- Fire your conversion event by hand and watch it arrive. An installed tag is not a firing event. Check the platform’s live event view before you spend.
- Stop trusting API responses as evidence about pages. Fetch the page. The gap between what a system says it publishes and what it actually serves is where budget goes to die.
- Make the check a blocker, not a note. A check that produces a warning nobody reads is decoration.
Why this is worth the friction
Every one of these checks adds minutes to a launch, and every one of them will feel excessive on the days nothing is broken. That is the deal. The alternative is discovering at the end of a flight that you bought a month of traffic to a page that was never really there, and there is no way to get that money back or that month of learning.
We did not invent these rules on a whiteboard. Each one is a bill we already paid.