A deploy deleted files you did not touch
You deployed one updated page. Now your icons are 404, your ads.txt is gone, and a verification file you set up weeks ago has vanished.
Nothing deleted them on purpose. A Pages deploy replaces the entire site. It is not a merge, not a sync, and not incremental. Whatever is in the folder you deploy becomes the complete contents of the site, and anything absent from that folder ceases to exist.
Why this catches people
The mental model most of us bring from FTP and from rsync is additive: push what changed, leave the rest. Deploy commands that take a directory argument look like they work the same way. They do not. The directory is the new site, in full.
npx wrangler pages deploy . --project-name=my-site
Run that from a folder holding one HTML file, and your site is now one HTML file.
What tends to disappear
The losses are predictable, because they are the files nobody keeps in their working folder:
- Favicons, touch icons and Open Graph images, which are binary and often were never committed
ads.txt, added directly during an ad network setup and never written down- Search engine verification files, whose removal quietly un-verifies the property
- IndexNow key files, which must keep matching what was registered with the search engine
.gitignore, if you built the folder withtar --exclude=.git, which drops it too
How to not do this
Diff before you deploy. The whole safeguard is one command:
diff -rq ./deploy-folder ./repo-checkout
Anything listed as "Only in repo-checkout" is about to be deleted from production. Decide that on purpose or not at all.
Then verify after, against the live site rather than your assumptions:
for f in ads.txt robots.txt sitemap.xml favicon.ico og-image.png; do
echo "$f -> $(curl -s -o /dev/null -w '%{http_code}' https://yourdomain.com/$f)"
done
The rule that actually prevents this: never rebuild a site by scraping production. If the only copy of your site is the live one, a single partial deploy destroys files you cannot regenerate. Keep the source in version control and deploy from a checkout, not from whatever folder you happened to be working in.
If it already happened
Cloudflare keeps previous deployments. Open the project, find the last good deployment in the list, and roll back to it. That restores the full previous file set immediately. Then fix your deploy folder before deploying again, or you will simply repeat it.
Related
Why AdSense Rejects Sites (And How to Actually Get Approved)
The real approval checklist, plus the silent bugs that tank it without you knowing.
ANALYTICSGA4, Search Console and Bing: The Setup Nobody Explains Clearly
Property IDs vs measurement IDs, verification, and why Google may not know you exist.
OVERVIEWWhat it actually takes to put a site together
The full sequence, the real timings, and what each step actually cost. Start here.