404, not a holdup
A source link that returns an error page has failed to resolve, which is a different condition from a page that loads slowly or asks you to sign in. Treating the two as one problem is what produces the habit of clicking a dead row five times a day for a fortnight, and on our records the rows that stopped resolving did not come back inside the window we measured.
1. Open the link in a private window so a saved session cannot mask the result. 2. Note the response rather than the appearance of the page. 3. Record the date it failed, because that date is the only evidence you will have later.
Treat a 404 as a terminal state rather than a slow load, because the two failures need different handling. 1. Enter the address in a fresh private window, log the status code beside the minute it appeared, and separate a timeout or a 5xx from a 404. 2. If the code is 404, mark the row dead on the same day and keep the old address in a visible superseded column. 3. If it is a timeout, retry twice across 24 hours before editing anything. Waiting on a true 404 is the first mistake, since medians of 8 to 19 days across 24 UK routes in the window 2026-08-01 to 2026-09-30 (Recorded) make almost any gap look like normal transit. Deleting the row straight away is the mirror mistake: requests that named the address, the code and the timestamp drew a 6-hour reply, while vague ones took 2 days (Recorded), and a deleted row leaves nothing to cite when the same address resurfaces.
Dormant advert
A row can be perfectly alive and still be stale, and stale is the more common condition by a wide margin. Across the 85 entries in our record, changes to the weight band or the source column showed up on rows whose link still resolved, which means the link is the last thing to fail rather than the first.
1. Compare the weight band on the entry against the band you wrote down when you shortlisted it. 2. Compare the source column and the seller name in the same pass. 3. If either has moved, treat the row as new rather than as the row you saved.
Compare today's page against the snapshot saved when the row was created, because a resolving link is not a current listing. Of 12 rate reviews logged between 2026-08-01 and 2026-10-02, 4 recorded a first-weight rise on the same route, the largest +£1.60, and 3 carried no labelled volumetric divisor (Not verified). 1. Copy the visible first weight, the 2 kg and 3 kg figures, and the divisor line into a column dated the same day. 2. Flag the row stale once the first weight has moved by more than £0.50, then re-tier it against the current table. 3. Leave a row with an unlabelled divisor unrated rather than guessing between the three possible values of 5000, 6000 and 8000. Treating a working address as proof of a current listing is the usual error; re-checking every row each week is its opposite, and it buries the 4 real changes among 8 untouched rows until the flags stop meaning anything.
Substitute then protest
The useful sequence is to find a replacement first and raise the point second, because a complaint without a substitute only returns you to the same empty row. On our record the rows that were genuinely gone were all replaceable within the same category, and the replacement usually carried a different weight band rather than a different price.
1. Search the same category rather than the same title. 2. Compare the replacement's weight band against the one you lost. 3. Only after a replacement exists is it worth writing down what happened, because that note is for your own next order rather than for anyone else.
Verify the variant as well as the address, since a live link can point at a different colour, label or size while the URL stays identical. Across 85 curated QC entries our sample logged 23 flags: 11 label mismatches, 6 edge or border concerns of which 5 were lighting artefacts, 4 hardware faults and 2 stitching faults (Recorded). Taking a 200 response as proof of identity is one error; calling every visible difference a swap is the other, and that habit would have escalated the 5 lighting artefacts as substitutions. 1. Shoot the label and the packed item in one frame under neutral light. 2. Match the label code against the code stored in the row before writing the word swap. 3. If the codes differ, keep the photo, mark the row Community-reported, and request a re-shoot naming the exact frame required. Vague re-shoot requests took 2 days in our sample and explicit ones were answered in 6 hours (Recorded).
Links moved unannounced
One failure mode runs opposite to the dead link and costs more money. A row whose link is dead but whose goods are still available under a new identifier looks identical to a row whose goods have genuinely gone, and the difference only appears when you search by the item rather than by the row.
1. Search for the item by its own description rather than by the sheet row. 2. If a near-identical entry appears with a different identifier, compare the weight band before assuming it is the same item. 3. If the band has moved by more than one step, treat it as a different product and price it again from scratch.
Recompute the affected line instead of rebuilding the tab. Replacing one row changes the volumetric arithmetic: length x width x height, divided by 5000, 6000 or 8000, rounded up to the next 0.5 kg, with chargeable weight taken as the heavier of actual and volumetric (Recorded method). Boundaries sit at 1, 2, 3, 5, 8 and 10 kg, so 8 kg and 8.5 kg both bill at £43.60 while 10 kg reaches £54.60 (Recorded); a swap that adds 400 g can cost nothing, and one that crosses 8 kg changes the total. 1. Enter the new dimensions in centimetres and note the date they were measured. 2. Re-round upward to the next 0.5 kg. 3. Compare the new chargeable weight with the old tier before quoting any difference. Rewriting the whole sheet after a single replacement wastes the audit trail, and its mirror fault is leaving the stale figure in place because the delta looks too small to matter at a glance.
Phantom switches
The opposite mistake is treating a live link as proof that nothing changed. A page that still resolves can have had its variant, its colourway or its material altered since you shortlisted it, and none of those changes produce a visible failure; they simply make the row a different purchase. Our record carries no reliable change history for individual listings, so any claim about how often this happens would be Not verified.
1. Re-read the variant field rather than the title when you return to a saved row. 2. Re-check the material or composition line on the entry. 3. If either differs from your note, discard the saved row and shortlist again.
One record swapped
Both directions of misreading have a cost, and they are mirror images of each other. Treating a live-but-changed row as unchanged buys the wrong item at the right price; treating a dead row as a temporary glitch keeps a basket waiting for something that will not return. The first cost is a return and the second cost is a fortnight.
1. Re-check a saved row once, on the day you settle rather than on the day you saved it. 2. Decide in that pass whether the row is dead, stale or unchanged. 3. Replace dead rows and discard changed rows in the same pass, so the shortlist never carries a row you have not read this week.
The data point behind this note
Across the 85 entries in our record, weight-band or source changes appeared on rows whose link still resolved, while rows that stopped resolving did not return inside our measured window — so a live link proves less than a re-read of the band (Recorded).
Rates last checked 2026-10-02. Where a figure is community-reported we say so; where we could not verify it, we write Not verified instead of estimating.