The problem in plain terms
Readers treat a column of addresses as one object that ages at one rate, and that assumption is what makes a dead row feel like bad luck rather than a pattern. The familiar failure modes already look unlike each other: an address that stops resolving altogether, one that still answers but lands somewhere unexpected, one whose listing returns a not-found response, and one that reaches a wall instead of a page. A fifth possibility is easy to miss, and it is the one this period produced. The reference failed while the destination stayed reachable.
Both readings inside a single row can be true at once, which is why the wording people reach for keeps causing confusion. A sheet can be fully unusable and completely intact in the same afternoon, because unusable describes the front of the address and intact describes what sits behind it. Sorting out which of the two you are holding takes one attempt from outside an account, and the weekly snapshots exist to keep that attempt on a dated record. The distinction is not academic. It decides whether an evening of work is necessary.
A useful way to say it: an address is not a container, it is a pointer. Nothing was stored inside the wrapper strings collected from those public sheet pages, and nothing was lost when they stopped answering. What changed was the behaviour of the thing doing the pointing, and the marketplace identifiers those strings carried were sitting undisturbed the whole time. Anyone who reads a column of dead rows as evidence that the goods are gone has skipped the step where the layers get separated. Those layers fail independently and at very different rates.
Four things follow once the separation is made, and they are worth stating before the detail arrives. Rows can be triaged without an account, because the rebuild step needs only the identifier already written in the cell. The urgent part of the task shrinks to whatever cannot be rebuilt. The record you keep matters more than the tidy version of the file. And a status label answers exactly one question, about one address, on one day. None of the four depends on knowing why the platform changed.
Five parts, each argued in turn
Part one is position in the chain. A wrapper address was a convenience layer written on top of a storefront, never part of what the marketplace serves, so it had no original content to fall back on. Once the thing in front stopped doing its job, that address had nothing to return and failed at the network layer immediately. A source address sits with the marketplace that still holds the listing, one step closer to the goods. The five arguments all reduce to that same question about where in the chain an address lives.
Part two is the number of parties who have to keep doing their job. A rebuilt source address needs one marketplace to stay in business and keep serving item pages. A wrapper needs the storefront operator, the host serving it, and the marketplace behind it, and the record only breaks when the first of those stops. This period, twenty-two platform objects sit in the ledger and eleven of them carry a page in the public directory it reads, which is a reminder that the middle layer is thinner than the ends. Fewer moving parts age slower.
Part three is what the string actually encodes. In the thirty-one wrapped addresses on file, the source marker read WD every time, and that marker points at Weidian. It is a case where a short piece of the address carries a real meaning: change it and the rebuild goes somewhere else, or nowhere. Most of the rest of the string is scaffolding around one identifier, and the scaffolding died with the layer that issued it. Roughly forty characters of decoration protected one number, and the number outlived all of it.
Part four is time, which points in two directions. A rebuild carries no expiry: 2026W39-001 still resolves to 7625036493, and 2026W39-014 still resolves to 7577045115, because those digits belong to the marketplace rather than to any storefront. Part five is whether the original was ever text at all. A rebuilt address is digits and a marker, so it survives being copied between files or typed out by hand from a photograph of a screen, while an image of a sheet cannot be copied anywhere. Format quietly decides how much of the list is recoverable.
The strongest objection
The strongest objection is that the sample was never random. All thirty-one wrapped addresses were copied from public sheet pages, so what got measured is the subset of addresses that somebody posted publicly and then abandoned, which is exactly the subset most likely to sit on a dead layer. Sampling from a place people publish abandoned work will over-represent abandoned work. The objection is correct as far as it goes, and it removes one specific claim from the table: this record cannot say anything about how fast a healthy wrapper decays.
The second half of the objection concerns the marketplace. Every source marker observed this period read WD, all ninety-three sampled addresses run to Weidian, and the site holds no verified sample from any other marketplace. So no claim here says that a rebuilt address on another marketplace would answer, or that the same digits would rebuild against the same host with the same result. That limit was set before the checking started rather than discovered afterwards, and it stays attached to every number on the page. One marketplace is one marketplace.
The third piece is deliberate exclusion. Of two hundred and twenty-five addresses that went through the process, one hundred and thirteen were dropped when the host stopped accepting connections, and those were excluded rather than written down as unknown. Exclusion is honest and it also biases the denominator, because the dropped rows are not a random subset either. A reader who wants to argue that the split is an artefact of the sampling has real material here. The rebuke lands, and it lands hardest on any general rate of decay.
What survives all three is narrower and still worth having. Group A failed at exactly one layer while the layer behind it returned normal responses thirty-one times out of thirty-one, and a pattern that clean does not need a random sample to be useful. It works as a diagnostic habit: when a row fails, ask which layer failed before rewriting anything. The objection costs the page its universality, which was never earned, and leaves it the observation, which was. A reader can re-run the same test on their own rows tonight.
The conclusion and its limits
The conclusion is that the failure recorded this period belongs to one layer. The wrapped addresses stopped answering at the network level, the addresses behind them answered, and the sample carries no row marked as gone. Nothing here says a listing was still available for purchase, priced as before, or shippable. A source address that returned a normal response was reachable at a moment on the checking date, and that is the entire content of the claim. It is a narrow statement, and it is the one the evidence covers.
The limits come attached to the same numbers. This is one window, period 2026-W39, read under one setup: an eight-second allowance per address, no cookies and no account credentials, and at most two requests running against a single host. Another window would produce another distribution, and repeating the check is the only way to learn which parts of the split are stable. The checking method page states the setup so a reader can argue with it, and the weekly snapshots carry the same observations forward one period at a time.
Three further limits are worth saying plainly. No verified sample covers any source marker except WD, so nothing generalises to other marketplaces. The one hundred and thirteen addresses that were excluded tell you nothing about how those rows would have been classified. And a status records a response, not a purchase: whether a marketplace still sells to your account, whether an agent will take a rebuilt address, and what any of it costs are all outside what a status column can hold. Each of those questions lives on a different page.
So the habit to take away is humble and portable. Treat every row as two things, a pointer and a destination, and find out which of them broke before you spend an evening on the file. Write the date beside whatever you learn, because a row with a day attached can be compared later and a row without one can only be argued about. Re-check on a schedule rather than when panic arrives. The wrapper layer is the fragile part, and the numbers underneath it are the part that lasts.