What do I do when a DHgate spreadsheet link stops working?

Why

• Links fail in a fixed order and each failure has a different repair. A retired listing can be replaced by finding the relisted item. A renamed storefront can be found from the old seller page. A row typed from a mobile app can carry a mangled address that never resolved in the first place. Diagnosing which of these you have takes a minute and decides whether the item still exists.
• The row's attributes outlive its address. Material, colourway, size run, hardware finish and price band can all be searched again, while the row's title usually cannot, because sellers rewrite titles to avoid filtered searches. Searching by attribute finds the same factory output under a different name, which is exactly what a relist is.
• The storefront is the closest thing to a stable pointer. Searching the seller's own pages within the same category and price band often turns up the relisted item, since the same workshop tends to keep the same product photographs, the same variant wording and the same price step across a relist, even when the identifier changes.
• Recovery has a deadline of its own. Row text and price are lost the moment the list is rebuilt, dead rows are usually pruned rather than repaired, and a storefront that has gone quiet takes its product photographs with it when it closes. Capturing the row on the day it fails costs one screenshot and preserves the only record that the row ever existed at all.

When this answer flips

• The storefront itself has gone and no page under the old seller name resolves at all. Recovery then depends on finding the same build under another seller, which is a fresh identity question rather than a link repair, and it needs the full check rather than a quick comparison of two addresses. The row's attributes are the only thread left, and a search on material, colourway, size run and price band is the whole method available.
• A saved capture of the row shows a different price and a different label from the version you kept. Two conflicting captures mean the row was edited after you saved it, and the earlier capture is the one to search from, because it reflects the version that was current when the row was written and shared. Check the capture date on both before trusting either, since a maintainer who noticed the failure may have replaced the row's text rather than its address.
• A reader report or a community thread names a replacement row for the same item. A named replacement is a shorter path than re-deriving the attributes from scratch, though it still needs the same verification before any payment, since a replacement row carries every risk the original one carried. Treat it as a lead rather than as a repair, and run the identity check on it before anything else.

Three things to do next

1. Report the dead row so the desk can re-check it
2. Rebuild the identity check on the replacement link
3. Check the seller's dated record before re-ordering