I have a cron job that runs on the first of every month and POSTs three URLs to https://web.archive.org/save/. It's been running since launch. The job takes under 30 seconds per site and produces no CI artifact I ever look at. I set it up specifically for a future buyer I haven't met yet.
The three sites I'm running have a target sale timeline of month 6–12. Empire Flippers and FE International are the intended brokers. I haven't listed anything. But sale preparation started at launch, not when I decided to sell.
What site brokers actually verify
Every major content site broker has a standard intake form. Before they'll publish your listing, they want to see:
- Google Search Console screenshots showing 90+ days of impressions and clicks
- GA4 screenshots for the same window
- Revenue screenshots (AdSense, affiliate dashboards) covering at least 90 days
- Proof that the site has been continuously live and not abandoned
The last one is the interesting requirement. "Continuously live" is straightforward to verify for recent history — uptime monitors, Vercel deploy logs, GitHub commit timestamps. The harder question is: how do you prove the site was live six months ago, in a way a buyer can independently verify without relying on your own records?
Your own screenshots are inside the seller's control. A buyer has to trust you didn't take them yesterday and Photoshop the dates. That's not a knock on buyers' intelligence — it's just that provenance-blind records are weak evidence.
What a Wayback Machine timestamp proves
The Internet Archive maintains an independent record of when a page was first captured, what it contained at that time, and when subsequent snapshots were taken. A buyer who looks up your domain on web.archive.org can see the calendar of captures going back to whenever the first one was made — and that record is outside your control.
You can't retroactively insert a capture dated six months ago. You can't modify what a past capture shows. The content visible in the archive is what was live on your site at capture time, served from a third party's cache. For a buyer validating the "has this site been live since month 1" question, a Wayback Machine calendar with consistent captures is a stronger signal than any screenshot you provide.
I'm not claiming it's fraud-proof. Someone who controls DNS and fakes a site at a specific domain at the right time could game it. But for legitimate sales to brokers who do basic diligence, the independent timestamp matters.
The automation
The workflow is in .github/workflows/wayback-monthly.yml, running on the first of each month:
schedule:
- cron: "0 3 1 * *" # 1st of each month at 03:00 UTC
For each of the three domains — aiappdex.com, findindiegame.com, ossfind.com — it submits two URLs:
- The homepage (
https://domain/) - The sitemap (
https://domain/sitemap.xml)
The sitemap submission is deliberate. Sitemaps list the URLs of your content. A Wayback capture of sitemap.xml timestamped six months ago proves that specific pages existed then, not just the homepage. If a buyer wants to verify that the indie game directory had 6,000 entries at launch and wasn't bulk-seeded right before listing, the sitemap archive provides that.
The HTTP request uses a POST to the save endpoint:
curl -sS -o /tmp/wayback_response.txt -w "%{http_code}" \
-X POST "https://web.archive.org/save/$URL" \
--max-time 60
The step continues on non-200 responses rather than failing — the archive sometimes rate-limits or returns 503. A failed submission month isn't catastrophic; a broken monthly job is. I log the status and move on.
The third reason: I don't know what I'll want to prove
The first reason is buyer-facing age documentation. The second is independent provenance. The third is vaguer: I genuinely don't know what a future buyer will want to verify, and monthly snapshots accumulate evidence about site state I can't predict I'll need.
A capture from month 2 showing a sparse directory is evidence of organic growth. A capture from month 4 showing the same site with more entries shows it's actively maintained. The specific pages a buyer asks about — did this category exist at launch? when did the AI tools section get the comparison feature? — may not be answerable from GSC or deploy logs, but they might be answerable from Wayback archives if the captures are comprehensive enough.
The cost of capturing is near zero. The storage cost is the archive's problem. The only failure mode is forgetting to set it up — which is why it runs as a cron, not a reminder.
What this doesn't replace
Wayback captures aren't a substitute for uptime monitors (they prove the site responded on capture days, not between them), revenue screenshots from the platforms themselves, or GSC exports for traffic. A broker wants all of those independently.
But for the "has this site been live continuously since launch" column of the diligence checklist, automated monthly snapshots are the simplest thing that could work. I set the cron up on day 3 of the experiment, and I haven't thought about it since.
Part of an ongoing 6-month experiment running three AI-curated directory sites. The technical claims here are real; this article was AI-assisted.
Top comments (0)