Real fixes from seven live sites. No pitch.Log in / My reports
Idea to Traffic Pressure Test

Deployment: the failures that look like success

Most deployment failures on static hosts do not produce an error. The site loads, pages return 200, and something is quietly broken: a data file that never shipped, an ads.txt that is really your homepage, or a hostname with no DNS record. This hub lists each one we hit, the command that exposes it, and the fix.

Deploying a static site feels finished the moment the page loads in your browser. That feeling is the problem. Every deployment failure documented on this site had the same shape: the thing we checked came back fine, and the thing that was broken had no one looking at it.

The catch-all

Many static hosts, and every single-page-app configuration, answer an unknown path with your homepage and a 200 status. That is correct for client-side routing and wrong for everything else. On three of our sites a tool fetched a data file that had never deployed, got HTML back, passed its res.ok check and silently did nothing for two weeks. The same behaviour makes ad networks report ads.txt as missing and turns every typo in a link into a duplicate of your homepage in Search Console.

The replace-not-merge deploy

A Cloudflare Pages deploy makes the folder you point it at the entire site. Deploy one updated page from a folder that does not contain your icons, ads.txt and verification files, and those files are gone from production. Nothing warns you, because from the host's point of view you asked for exactly that.

The half-configured hostname

Attaching www to a Pages project and creating its DNS record are two separate calls. On a six-site network, all six sites were missing www because the apex worked and nobody tried the other name.

Caching

New JavaScript sat behind a four-hour cache: the file on the server was correct and the browser ran the old one. It looks exactly like a failed deploy, which is how it costs a full cycle of redeploying something that was never broken.

GET /data/words.json file was never deployed catch-all route serves index.html 200 OK + HTML body Checking the status curl -o /dev/null -w "%{http_code}" 200 reads as present. Wrong. Checking the body curl -s ... | head -c 80 <!DOCTYPE html> reads as missing. Correct.
The same response, read two ways. This is the whole hub in one picture.

What they have in common

The fix is in your habits, not in any one setting: check the content, not the status code. Compare a nonsense URL against your homepage. Hash the files nobody links to. Request the hostname you did not type. Each guide below ends with the exact command, and together they make a post-deploy check that takes under a minute.

If you are about to launch, read them in the order listed. If something is already broken, start with the symptom that matches what you see.

Start here

Your missing pages return 200 OK. It explains the catch-all, which is the root of half the other problems on this list.

Every guide in this hub, in order

The calculator that goes with this stage

Time to First Dollar, because every silent deploy failure pushes the first dollar further out. A tool that was dead for two weeks earned nothing for two weeks, and the ramp restarts from where it stopped.