How it was done before

The old routine had four steps and none of them involved a date. Collect addresses from wherever the sheet lived, copy them into a platform, wait for the warehouse to photograph what arrived, then choose a parcel and send it. The address was treated as a live pointer rather than as a record, because the pointer worked. Paste it in, and the platform would fetch the listing, quote what it cost, and put an order button underneath.

Every column in a 2025-era sheet reflects that assumption. The address column is a destination. The price column is a quotation. The notes column holds sizes, colours and seller remarks, because the row was expected to survive long enough for those details to matter at checkout. Nobody wrote down when the address had last been confirmed, because confirmation was not a step anybody performed. Opening the link was the confirmation.

The guidance that grew around those sheets carried the same blind spot. Reconstruction mattered only when an address had been mistyped. A dead link meant the seller had pulled the listing. Backup advice was about copying files rather than about preserving evidence, because the file was understood as a shopping list that could be rebuilt from the source at any time. Its author assumed the file would be read again while every link in it still worked, and that assumption was never written down anywhere.

The old approach also handled ambiguity badly, and it did so invisibly. A row that could not be resolved simply got skipped, and a skipped row left no trace in the table. Nothing distinguished a listing that had gone away from a listing that had never been typed correctly. The column order tells the same story: address first, price second, notes third, and no slot anywhere for the one fact that would matter later, which is when anybody last confirmed that the row was still good.

What changed

The change arrived in dated steps rather than as one event. On 2026-06-01 a platform notice described a security and compliance upgrade and mentioned disrupted links, slower pages and some cancelled orders. Purchasing and top-up stopped on 2026-06-12 and stayed stopped through the end of the month, while warehouse and parcel work continued under the same notice. The gradual restart planned for 2026-07-01 did not restore ordering.

Then the record thinned out further. Around 2026-07-10 a community representative said ordering had not been restored and gave no new date. By August, third-party records showed the storefront offline, and the operator never announced a permanent closure. Nothing in that sequence was a single dramatic break, which is exactly why so many sheets were left sitting in a state their owners assumed was temporary, and why waiting for a clean announcement was never going to work.

The measured consequence is sharper than the announcements were. Thirty-one wrapped addresses collected from public sheet pages were requested as they appear in the file, and not one connected. The same thirty-one, rebuilt into the listings they encode, answered normally. All ninety-three records in the sample carried a source marker reading WD. The layer in front of the listing stopped answering. The listing did not move, which is why a sheet can look dead and still be worth a full evening of work.

What the check produces now is a reading rather than a verdict: a status label, a check date, and a statement about whether something answered at a moment. A hundred and thirteen further directory addresses were left out of the table because the host stopped accepting connections, and they were excluded rather than written down as unknown. That exclusion is the new guidance in miniature. An unanswered question gets recorded as unanswered, and it is never quietly filled in with an assumption, which is exactly the habit that makes a thin table trustworthy.

What the change costs you

The first cost is a step per row that used to be free. A wrapped address has to be decoded into the listing behind it, and the decoded address has to be confirmed before it goes anywhere near an order box. That is one extra action per line, and on a sheet of fifty rows it is fifty actions performed by a person rather than by a platform. The work did not become difficult, and it is not a one-off task either, because every row that gets edited, moved or copied from somebody else's file has to be rebuilt again.

The second cost is a column. Every row now needs a date recording when it was last confirmed, because a status without a date cannot be compared with anything. Two rows marked as resolving tell you nothing if one was read this month and the other was read in the spring. The date is what turns a column of marks into a record, and a record is the only thing that survives when the platform underneath it stops answering.

The third cost is where the chain now ends. A confirmed address used to lead to a purchase, and the purchase used to lead to a warehouse, and the warehouse used to lead to a parcel. The middle of that chain is gone, so a reader has to decide separately what a confirmed row is for: sending an item that is already stored, or holding the address until a platform that is still accepting orders can take it.

The fourth cost is not easy to plan around. Rows that were never confirmed cannot be confirmed retrospectively without someone doing the work now, and rows that were confirmed months ago have aged. There is no shortcut through either problem. A reader who wants a sheet they can act on has to spend the time, and the only thing the site can do is make the reading cheap and the date visible so the work is spent once. One cost is not a cost at all. A rebuilt row is the only version of it a platform can accept today.

What to rewrite in your own notes

Add two columns before touching anything else: a status label and a date checked. Use the five labels the method publishes so that your sheet speaks the same language as the weekly snapshots. A row is either resolving, moved, gone, shielded or unrecorded, and the last one is a real answer rather than a placeholder. A row with no label is a row nobody has looked at, which makes it the first thing to fix.

Split the address into two columns, one holding the wrapped address exactly as it was found and one holding the rebuilt listing address. Keeping the original preserves the evidence; keeping the rebuilt one makes the row usable. Add a third column for the marketplace marker on its own, separate from the address, because every marker observed in the current sample reads WD and a marker written as free text inside a long address is a marker nobody can sort by. Three columns replace one, and the row becomes searchable.

Keep the product identifier as its own column and treat it as the join key across sheets. Two rows that look unrelated will match on that identifier, and a row whose address failed to rebuild can still be found again through it, which turns a dead row from a loss into a lookup. The sheet column mapper shows how a pasted block lines up with the fields a receiving platform expects, which is the step where a rewritten sheet either survives the move or loses a column quietly.

Finally, write the date of the last full check at the top of the sheet, not only in each row. A sheet carries one overall reading and every row carries its own, and the two drift apart as soon as rows get updated individually. The changelog records what this site edited and when, and the weekly snapshots carry the dated readings themselves. A reader's own sheet deserves the same two habits rather than more columns: a label on every row, a date on everything, and a short note attached to any row carrying neither.