Before you check anything
The first surprise is how much of a row is decoration. A wrapped address follows the shape product?id={identifier}&source=WD&u={code}, and only two of those pieces survive the platform they were written for. The identifier names the item, and the source marker names the marketplace it lives on. Everything else exists to route a request through a storefront that may not be answering any more. Read a column of them as three parts rather than one address, and half the confusion about what broke disappears before any check begins.
The second surprise is that a sheet usually holds a mixture, and nobody wrote down which rows are which. Rows copied from different places across different months end up in one column under one header, some wrapped, some rebuilt, some reduced to a bare number by whoever retyped them. That mixture is why two people can describe the same file very differently without either of them being wrong. Before testing a single row, sort the column by shape, because a check that treats all three forms alike produces a count that means nothing.
The third step happens before any request goes out: copy the file. A check does not write anything except a date and a status, but the sorting and retyping that follows a check will overwrite cells, and the original column is the evidence for what the file used to contain. Keep one untouched copy and work on another, the same way the ledger keeps its own sample rows readable rather than tidying them away. A wrapped address you still hold is proof of where a listing came from, which is a fact no rebuilt row carries by itself.
A date belongs on the copy before the work starts, not after. Write the day the copy was made beside the untouched column, so a reader six months later can tell whether they are looking at a file from before or after the platform changed. This site keeps the same habit in its records: period 2026-W39 was read on 2026-09-29, and every value in it carries that frame. An undated copy of a sheet tells you what somebody had, and nothing about when they had it.
While you are checking
Checking starts with one identifier and one attempt. Rebuild a single row, open the result, and note what came back before touching the next row. The point of going slowly at the start is that the first row tells you which of several situations you are actually in: the marketplace answers, or it does not, or something answers that is plainly not the listing you expected. Working through ten rows before writing anything down produces ten memories and no record, and memories of failures are the least reliable kind.
The responses sort into a short list that is worth knowing by heart. A normal answer means the listing is reachable today. A not-found answer means this particular row has gone. A wall of verification or a login prompt means the check never finished and no conclusion can be drawn from it. Silence after a bounded wait means the same as the wall: unrecorded, not gone. Those last two categories get merged by careless readers, and merging them is how a working listing gets written off in somebody else spreadsheet.
Rebuilds should never be retyped. The identifier came out of the wrapped row as digits, and those digits get copied rather than read off a screen and typed again, because a single transposed pair produces an address that looks perfectly normal and points somewhere else entirely. The legacy link resolver exists to make that copy step mechanical, and it is worth using on a column rather than a row, since the failure mode it prevents is proportional to volume. Ten correct rows prove nothing if the eleventh is wrong.
Every row that gets checked earns a date and a word. One line per row is enough: what answered, on which day, and which address form was used. A row that says nothing is the one somebody else will re-check next month, at cost, for the same result. This period carried a hundred and thirteen addresses dropped when the host stopped accepting connections, and they were excluded rather than guessed at, which is what separates a gap in a record from an invented value inside one.
At the agent handoff
The handoff is where address forms stop being a private filing matter. An agent receives a queue of rows, and what it can do with a row depends on which address is in it. A rebuilt source address points at the marketplace where the item lives, which is what a buying process can act on. A wrapped address points at a storefront that may no longer answer, and a bare number in a cell is not an address at all until somebody supplies the rest of it. Two of the three forms create work before any order can happen.
The field worth reading before choosing anybody is whether a platform accepts a rebuilt marketplace address, and it is recorded per platform in the ledger with a date rather than described in prose. Twenty-two objects sit in that ledger this period, eleven of them carry a page in the public directory it reads, and the address handling field is the one that decides whether your file transfers or gets retyped. A reader who checks that single field before committing saves the whole exercise of rebuilding a sheet for a platform that will not take it.
Sending a mixed column is the quiet mistake of this stage. If half the rows are wrapped and half are rebuilt, the receiving side has to work out which is which, and the rows it cannot parse will come back as questions rather than as orders. Sorting the column into the two forms before sending costs a few minutes and removes that exchange entirely. The sheet column mapper is built for exactly this kind of pass, mapping what a column actually contains rather than what its header claims it contains.
One address form is worth converting even when it still works. A wrapped row that answers today is still a dependency on a layer that this period stopped answering thirty-one times out of thirty-one, while the identifier inside it never stopped being valid. Converting a working wrapped row into a rebuilt source row costs one step per row and removes the fragile part of the address from the file permanently. Doing that while the storefront still answers is easier than doing it afterwards.
After the order lands
Once an order is placed, the address in the sheet stops being an input and starts being a reference. The useful thing to keep at that point is the pair: the original wrapped row as it arrived, and the rebuilt address that was actually ordered from. A dispute, a re-order, or a question about which listing a photograph belongs to all resolve faster with both than with either alone. Replacing the original with the tidy version feels efficient and throws away the only record of where the row came from.
Statuses change meaning at this stage, and reading them the way they were read before the order causes needless worry. A row marked as resolving means an address answered on a date. It does not mean the item is available, that a seller will accept the order, or that anything is on its way. Those questions are answered inside an account or in a warehouse, not by a column of addresses. A reader who keeps the two kinds of question apart will not be alarmed by a status that was only ever describing reachability.
The date is what makes the record useful later. Six months on, a rebuilt row with 2026-09-29 beside it can be compared against the then-current reading and produce a fact; the same row without a date produces an argument. That is why the weekly snapshots publish the checking date along with the counts rather than storing one value and overwriting it. A record that says when it was taken is worth keeping; a record that does not is worth retaking.
Nothing in this chain is expensive except the step that gets skipped. Sorting a column by address form takes minutes, copying instead of retyping takes no extra time at all, and dating a checked row costs one field. Each of those small moves removes a failure that shows up later at the worst moment, when a platform has stopped and the file is the only thing left. The consequences of a link are out of proportion to its size precisely because the file is what survives when the platform does not.