Checking a W2C link before it costs you a parcel

Prepare four things

A link check is a ten-minute routine, and it starts before the address is pasted anywhere. W2C is the shorthand this desk uses for the leg between a listing and the parcel it becomes, so treat it as a working name for the routine rather than as a platform field. What the routine decides is narrow and useful: whether a link still points at the thing the row claims, at the moment somebody is about to commit money to it.

Four things on the desk before the clock starts: the row as it was printed, with its ten-digit identifier; the address copied from the listing page rather than from a chat preview; one empty line in a file you will still have next month; and the date. The identifier matters more than the title, because the 192-row sample contains three titles that appear twice, so a title alone cannot separate two rows that look identical at a glance.

Preparation takes about a minute, and skipping it is what turns ten minutes into an hour. The file is the part people leave out, and it is the only part that makes the second check cheaper than the first. Keep the four items on one screen, because a routine that needs two windows and a scroll is a routine that gets abandoned halfway through.

Step 1 — confirm the link resolves

Paste the address once, from the listing page, and read what the platform says it resolved rather than what you remember pasting. The step passes when the resolved name matches the row and the marketplace label matches the one in your note. The name is the test rather than the thumbnail, because a thumbnail survives a variant swap and a name usually does not.

Two minutes is enough here, and there are two ways to fail with two different repairs. A link that resolves to a different item has usually lost a parameter on the way through a preview or a shortened address, so copy it again from the source page and paste once, without editing the address by hand. A link that resolves to nothing is dead, and the routine stops at that point rather than continuing through the remaining steps.

One signal is worth watching for: a resolved name that is shorter than the row title. Shortening is not proof of a swap, but it is the usual shape of one, because the segment carrying the variant is the first thing to disappear when an address is rewritten somewhere in the middle. Compare the two strings side by side before moving on, and write down which one you trusted.

Step 2 — read the variation note

The variation note is the bracketed part of the title together with the option list behind it, and it is where a link check earns more than a dead-link check can. The step passes when the note on the resolved page matches the one in your row character for character, including the number inside the bracket. Three minutes covers a row with one bracket and does not cover a row with four.

Failure here is a decision rather than a repair. If the note differs, the row describes a different product range from the one the page now carries, and the honest response is to record the difference and stop, because guessing which variant the row meant is how a parcel arrives holding the wrong thing. If the note has vanished altogether, the page has been re-cut and the row is describing a listing that no longer exists in that form.

This is the step that most changes the freight line, which is why it belongs in a routine about cost. A variant swap alters the packed dimensions more often than it alters the price, and packed dimensions are what a volumetric line charges against. The moment that difference is cheapest to find is before the link is handed over; at the packing bench the remaining options are a return or a shipment of the wrong item.

Step 3 — check the store is still there

Open the store page behind the item, separately from the item page, and record one of three outcomes: it loads, it redirects, or it fails. The step passes when it loads and the store name stays the same across two readings a minute apart. A store page that loads proves somebody trades under that name; it does not prove the row came from that store, and the two facts belong on separate lines of the note.

None of the 192 sampled rows carries a store name, so this is the only step at which a store can enter your record at all. That asymmetry is the reason to run it rather than skip it: the item page says what the thing is, and only the store page says whether a counterpart still exists to answer a question about it. Two minutes, and the result is one word in the file.

The repair depends on which failure appeared. A redirect that lands on the same store under a new address is a repair: record the new address beside the old one. A failure on both the item and the store page usually means the directory dropped a page rather than the product, so record the failure and keep the row. Deleting the row is the one action that makes a later comparison impossible.

Step 4 — record what you checked

One line, five fields, about two minutes: the identifier, the resolved name, the variation note, the store outcome, and the date. The step passes when somebody who has never seen the row could re-run the same four checks from that line and reach the same verdict. That is a higher bar than it sounds, and it is the whole distance between a check and an impression.

Add the verdict as a sixth field and keep it to three words: passes, variant differs, or dead. A verdict with a date can be compared against a later snapshot of the catalogue, and a verdict without one is an opinion about a page that has since changed. This is the discipline the recovery routine asks for after a link fails, applied at the opposite end of the same timeline.

Do not keep the result in a chat thread. A thread is searchable by nobody, comparable with nothing, and it is usually the only place the reasoning survives. The ten minutes end at this step, and the file is the deliverable rather than the browsing.

What each step catches, and what it cannot

The four steps catch four different failures and each one is invisible to the others. Step one catches an address that stopped resolving, and it catches the silent swap that happens when a parameter is dropped in transit. Step two catches a page that has been re-cut since the row was written, which is the failure a resolving link hides perfectly. Step three catches a store that has closed while its item page still renders.

Step four catches nothing at the time and everything afterwards, because it is the step that makes the other three repeatable. Without it, a check run in March and a check run in September cannot be compared, and the second one costs the same as the first. The value of the routine therefore sits in the file rather than in the browser, an unglamorous conclusion for a ten-minute method.

What the routine cannot do is worth stating plainly. It cannot tell you whether the item is in stock, whether the price will hold until the parcel is packed, whether the seller will send what the page shows, or whether the thing will fit. It also does not replace the recovery routine for a link that has already failed and a row that has to be rebuilt from an identifier. That one starts after a link has been handed over and stopped working; this one starts before the handover, while the link still resolves, and confusing the two produces either a recovery attempt on a live link or a check performed on a dead one.

The cost side is the argument for doing it at all. A variant that has to go back costs a return movement and the weeks around it, and a row that has to be rebuilt costs an afternoon that four fields would have made unnecessary. Ten minutes against those two outcomes is not a close comparison, which is also why the routine is short rather than thorough: a check that takes an hour gets skipped on the day it matters most.