On 17 September 2026 we recounted our own history in the web archive: what the moment a site disappears along with its domain looks like from the outside. The material was ours. Deli.com.ua — an online store of hosiery and lingerie, our own project rather than a client's: we came up with it, built it and ran it ourselves. In spring 2022 we lost it — we failed to renew the domain registration in time. We know the reason from the inside, but we can no longer confirm it with a document: access to the registrar, the hosting and the analytics was lost along with everything else.
What can be confirmed is the timeline. It sits in the open: the Wayback Machine hands out the list of its captures through the CDX API to anyone, with no key and no registration. Below is only what we counted with requests to the archive on 17.09.2026, plus one measurement from the case card taken on 01.08.2026. There will be no sales, order or traffic figures here: the analytics account was lost at the same time, and there is nothing left to verify them against.
The timeline visible from the outside
We asked the archive for every capture of the domain's home page during 2022 — the time, the response code and the checksum of the body. Here is what the year looks like:
| Month of 2022 | Home page captures with code 200 | With code 301 |
|---|---|---|
| January | 2 | — |
| February | 551 | — |
| March | 2,378 | — |
| April | 7 | 3 |
| May | 1 | 1 |
Why the archive captured the home page 2,378 times in March 2022 we do not know — CDX does not explain it, and we are not going to invent an explanation. Something else matters: after March the frequency drops to single figures, and a redirect appears for the first time.
The reference dates, each of them a row in the CDX response:
- 1 April 2022, 02:13 UTC — the first capture of the home page with code 301. Before that, in all of 2022, the home page had none.
- 18 May 2022, 04:03 UTC — the last capture of the home page with the same body checksum as in January–March. After that date the same fingerprint never appears in the archive again.
- 6 June 2022 — the home page returns 200 again, but the checksum is already a different one.
- 1 July 2022 — the archive records addresses of a different shape for the first time: a numeric prefix appears in the first path segment, one our address structure never had.
- 17 September 2026 — the domain returns HTTP 200, sits behind Cloudflare, and sets the cookies
BITRIX_SM_SALE_UIDandASPRO_MAX_USE_MODIFIER. This is a different site with a different owner, so we do not link to the live domain — only to the archived capture of the home page from 1 March 2022, the way the crawler saw it.
Why this is invisible from the inside
A collapse in capture frequency is a signal that can be read only in hindsight and only in the archive. None of an owner's usual tools shows it, and there are three reasons for that.
First: losing a domain does not look like a breakdown. The site does not fall over with a 500 error and does not show the hosting provider's page. It keeps answering with code 200 — just not with your content. An uptime monitor that checks “does the address respond” stays calm in this situation: the address responds.
Second: a 301 is a successful response too. From 1 April the home page starts picking up captures with code 301, mixed in with the ordinary ones. To any “is the site alive?” check a redirect looks normal; it becomes abnormal only once you know where exactly it leads and why it appeared.
Third: the only warning arrives by email. The registration expiry date lives in the registrar's panel and in a message sent to the address given when the domain was bought. If that mailbox is not the one you open every day, the notice simply never reaches the person who could do something about it.
What the archive kept — and what is not in it
We made the second request across the whole domain for the period from 2019 to 31 March 2022: every address with code 200 and type text/html, collapsed to unique ones. Here is what the archive remembers about a store that no longer exists:
| What we counted | How many |
|---|---|
unique addresses on deli.com.ua |
8,938 |
| of them product pages (path “section/product”) | 7,469 |
| unique final segments among the product pages | 6,741 |
addresses of the Ukrainian-language /ua version |
401 |
pagination addresses (page-N) |
188 |
| single-segment addresses — sections and information pages | 289 |
The first caveat to this table is the date of the count. It was taken on 17.09.2026 and does not match what is recorded in our own case card from 01.08.2026: there it is 8,909 addresses and 7,565 product pages. The discrepancy in product pages comes down to the counting rule: in the card the Ukrainian-language product addresses were counted together with the main ones, whereas here they are pulled out into a separate “/ua” row — add them back and you get 7,567, the same figure to within two addresses. The discrepancy of 29 addresses in the overall number cannot be explained by anything but the fact itself: the same request over the same date range returned more rows a month and a half later, and CDX does not say why.
The difference between 7,469 and 6,741 is 728 addresses, meaning part of the products were reachable from more than one category. For a redirect map this is exactly the detail that makes it impossible to build automatically, “one to one.”
Separately we counted the overall footprint: within the request window 2019 → 18 May 2022 the archive holds 16,624 HTML captures with code 200. The continuous flow of captures across the whole domain breaks off on 1 April 2022 — that day the archive took eight pages, the last one at 04:50 UTC. After that exactly one capture remains in the entire set: the same home page on 18 May 2022 that we cited above. By year: 1,345 in 2019, 419 in 2020, 9,185 in 2021 and 5,675 in 2022.
The second caveat is the one without which these numbers lie. 7,469 product pages is a union across three years, not a snapshot of the catalog. We counted the live catalog separately: on the captures of 24.02–01.03.2022, going through the pagination of seven root sections, we arrived at 3,640 products (a measurement of 01.08.2026, recorded in the case card). These two numbers cannot be placed side by side as “the store had this many”: one is an accumulated footprint including items pulled from sale, the other is the state in one specific week.
And the main thing the archive does not have: the database, the orders, images in their original quality, the admin panel, the settings. The archive is not a backup. From 8,938 addresses you can assemble a redirect map and a list of what once existed. A store cannot be assembled from them.
How to check your own in 15 minutes
This needs neither server access nor reading any code.
1. Look at the expiry date of your domain registration — and at whose name it is in. In the registrar's panel. You are checking three things: what date it is paid up to, whether auto-renewal is on, and whether the email listed there is one you actually read. If the record names a contractor as the owner rather than you or your company, that is the first thing to change.
2. Count what the archive already holds about your site:
curl -s "https://web.archive.org/cdx/search/cdx?url=example.com&matchType=domain\
&from=2019&filter=statuscode:200&filter=mimetype:text/html\
&fl=original&collapse=urlkey" -o urls.txt
wc -l < urls.txt
3. Look at the home page's capture frequency by month:
curl -s "https://web.archive.org/cdx/search/cdx?url=example.com/&fl=timestamp,statuscode" \
| awk '{print substr($1,1,6), $2}' | sort | uniq -c
If the last few months show 301 or 404 instead of 200 and you did not know about it, from the outside your site is already not the one you take it for.
4. Compare the archive's list against your own sitemap. Addresses the archive knows and the sitemap does not are either lost pages or ones that ought to be returning a redirect:
sed -E 's#^https?://(www\.)?[^/]+##' urls.txt | sort -u > archive.txt
5. Restore your backup on a test domain. Not check that the file exists — actually restore it. A copy that has never once been restored is not a copy, it is a file.
What we changed and what that does not fix
The domain, the hosting, the repository and the analytics we register in the client's name, not our own — this is written into our working rules as a mandatory item, not a wish. The state of the site and the server is covered by uptime monitoring, preservation by backups. We do build a redirect map from an archived list of addresses when the old site is already switched off; how that looks technically is broken down on the page about redirects after a migration.
What it does not fix — four honest points.
Registering the domain to the owner does not renew the registration. That is done by a person who reads the registrar's emails, and no technical setting replaces that person.
Uptime monitoring catches outages, not dates. On 1 April 2022 the domain was returning 301 — to a monitor that is a successful response. To see the problem you have to check not “does it respond” but “is it the same content.”
The archive does not bring the store back. It brings back addresses: 8,938 of them in our case. Everything else — the database, the orders, the images — stayed on hosting we no longer have.
And the last point, the most unpleasant one. Our own Deli.com.ua case study is assembled from somebody else's copy of our own site: every figure in it is taken from Wayback Machine captures, because no other source is left. That is the real price of an unrenewed domain. A page that stopped opening is the consequence you see straight away. And then it turns out that you can prove your own work only through the archive, and exactly to the extent the crawler managed to capture.
