On 17 September 2026 we recounted in the web archive what losing our own store along with its domain looked like from the outside: 2,378 captures of the home page in March 2022, the first 301 on the first of April, the last capture of our content on 18 May. We show what the archive restores and what it does not.
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.
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:
BITRIX_SM_SALE_UID and ASPRO_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.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.
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.
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.
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.
Your opinion helps us create better content
Help others learn about it - share the article on social networks
Thank you for helping us grow
Writes about what he builds himself: online stores on OpenCart, applications on Next.js, integrations and site speed. The articles carry measurements and checks a reader can repeat on their own project, not general advice. Commercial development since 2015.
Answers to common questions on the topic
The site, no; the addresses and the texts, yes. The web archive keeps what the crawler saw: the HTML of the pages it managed to capture. The database, the orders, the settings and images in their original quality are not there. In our case 8,938 unique addresses of the former store can be pulled out of the archive (counted on 17.09.2026; the case card records 8,909 — the same request, taken on 01.08.2026) — from them you build a list of what existed and a redirect map, but not a working store.
With a single request to the Wayback Machine CDX API, no key and no registration: ask for every address of the domain with code 200 and type text/html, collapsed to unique ones, and count the rows in the response. We gave the exact command in the article — it runs in a terminal in a minute and needs no access to your server.
Because it checks whether the address responds, not whether it returns the same content. In our timeline the home page starts returning responses with code 301 from 1 April 2022, and in June it returns 200 again — both responses are successful as far as the monitor is concerned. The problem becomes visible only when what is compared is not the response code but the content of the page itself.
So that the accumulated weight of the addresses is not lost when you move to a new site: every old address should return a redirect to its counterpart. This is not done automatically, “one to one.” In our list there are 7,469 product page addresses against 6,741 unique final segments — the difference of 728 addresses means part of the products were reachable from several categories at once, and those cases have to be untangled by hand.
The business owner's or their company's, not the contractor's and not a private mailbox nobody reads. We register the domain, the hosting, the repository and the analytics in the client's name as a mandatory part of the work. That does not save you on its own: the registration is still renewed by a person who reads the registrar's emails — but at least that person has access.
Subscribe to our newsletter and receive useful tips, insights and news about web development, marketing and business.
Web developmentOn 21 September 2026, the first day of per-route request tracking, the internal /api/health endpoint received 13,666 requests, 60% of application traffic, and every one of them hit the shared database. Here are the two settings that fixed it, what they cost us, and how to check your own healthcheck.
Web developmentOn 21 September 2026, a type check on our site reported 154 errors, even though the build had been green every time: the check's result was simply thrown away. Inside, we found zeros in link statistics and in the analytics export, sorting that didn't sort, and tests that never ran. Here is how we worked through them, what we changed, and how to check your own project.
Web developmentOn 22 September 2026 we checked the HTTPS certificates on 116 sites we had already measured for market studies, and for 104 of them we compared the state with August. All 116 passed verification, 108 run on 89- and 90-day free certificates, and only one site's certificate has still not renewed, even though with typical settings it should have by now. We walk through the measurements and the limits of the method, and show how to check your own site with a single command.
