Using the Link Health Checker on a Real Spreadsheet Row

The link health instrument answers one question and refuses another. It reads a pasted link and reports what the link is made of: which platform it belongs to, which item identifier it carries, and whether somebody else has attached tracking parameters to it. It makes no network requests, so it cannot say whether a listing is still live. On a 195-entry pool where every row points at Weidian, that refusal is easy to overlook and expensive to misread.

The refusal matters because link form and link liveness fail in different ways. A well formed address can point at a listing that closed last month, and a mangled address can point at something perfectly available, and the instrument sees only the first of those two conditions. Its rule set is wider than the pool it usually runs against, since it recognises Weidian, Taobao, Tmall and 1688 along with roughly 25 agent platforms, and each of those has its own identifier conventions. A verdict is a statement about form, and form is what the instrument can see without leaving the page.

The sequence inside the instrument runs in four steps. It identifies the platform, extracts the item identifier from the link, scans the query string for tracking parameters, and emits a verdict of clean, rewritten or unrecognized together with a normalized form of the link. None of the four steps requires anything outside the page, which is why the output arrives immediately and why the output cannot contain information about availability.

The instrument at /instrument/link-health/ runs that sequence on pasted text. It sits alongside the other instruments in this series, and the discipline at /method/ explains where its output belongs in a workbook: a verdict is a field, and a field is only useful when it is dated and can be re-run.

A worked row is the fastest way to see the steps. Take a Weidian entry from the pool, a sneaker row drawn from the Shoes category, and copy the link exactly as it sits in the sheet. What arrives is rarely just an address. A link copied from a listing surface usually carries the item identifier plus whatever the surface appended, which is where the second half of the analysis begins.

Step two is identifier extraction. For Weidian the instrument looks for the item identifier key in the query string, the itemID parameter, and takes its value as the identity of the row. Other platforms use their own keys, and the extractor is per-platform rather than generic, because a generic extractor would happily read an unrelated numeric parameter as an item number. If no identifier can be extracted, the row never reaches the verdict stage.

Step three is the tracking scan. The instrument looks for affiliate and invite-style parameters, including affcode, inviteCode, invitedCode and partnercode, along with campaign keys in the utm family and member identifiers of the same shape. A link that carries any of these is marked rewritten, because the attribution inside it belongs to whoever produced the link rather than to the sheet it was pasted into. The distinction between the platform required parameters and everything else is the whole of this step.

Step four handles input that cannot be parsed. A shortened address, a redirect wrapper, or a cell containing a product title with no address at all returns unrecognized. That verdict is not a failure of the row. It is a statement that the link as stored cannot be reduced to a platform and an identifier, which is exactly the condition that makes a sheet fragile, because the row cannot be reproduced from its own contents.

Paste the link column rather than individual rows. One row at a time produces one verdict at a time, and the useful reading is a distribution: how many rows in the list are clean, how many carry somebody else's attribution, and how many cannot be parsed at all. A distribution changes over a list, and a single verdict does not.

Three verdicts carry the output, and each one maps onto a different action in the sheet. Clean means the link contains only the parameters the platform needs to resolve the item. Rewritten means the link carries tracking parameters in addition to those, so it points at the same item through an attribution path that belongs to somebody else. Unrecognized means the link could not be reduced to a platform and an identifier, so nothing downstream can be computed from it.

Alongside the verdict, the instrument produces a normalized form of the link. For a Weidian row that shape is the platform address followed by the item identifier parameter, written as https://weidian.com/item.html?itemID= and the identifier value. The normalized form is the part worth storing, because it is stable: the same row re-copied from a different surface produces the same canonical address, while the pasted version may differ every time.

Read the output as a column, not as a fact about an item. A list where nine rows in ten are clean behaves differently from a list where half the rows are rewritten, even when both lists hold the same items at the same prices. The first list can be reproduced by anybody who reads it. The second carries attribution that has to be stripped before the row is comparable with a row from somewhere else.

Does a clean verdict mean the item is still available? No. The instrument makes no network requests, so it cannot know whether a listing is live, whether the price moved, or whether the seller is still trading. A clean verdict says the address is well formed and free of foreign tracking parameters. Every question about availability belongs to a different step in the process.

Does the instrument open the link at all? No. Nothing is fetched, resolved or followed. A shortened address is not expanded, because expansion requires a request, and a redirect wrapper is not unwound for the same reason. Both return unrecognized, which is the honest verdict for a link whose destination cannot be determined from its text alone.

Why does a rewritten verdict matter if the link points at the right item? Because attribution travels with the link. A rewritten row pasted into a shared sheet carries the original author tracking parameters into a file where they do not belong, and it produces a canonical form different from the one a clean row produces. Two rows for the same item can disagree purely because one was copied from a different surface.

Can the output be used to compare prices or check a batch? No, and the instrument is deliberately the wrong tool for both. Comparisons belong in the landed cost calculation, where the six fee rows decide the answer, and a batch of rows is compared through the category bands rather than through the address. What the instrument contributes is a form check that can be run over an entire link column before any arithmetic happens.

How often should the column be re-run? Whenever the list is refreshed, and always with a date attached, following the same rule that applies to every other field in the workbook at /method/. A verdict from an earlier week is a verdict about the links as they were stored then. Re-running the column is cheap precisely because nothing is fetched, which is the practical benefit of a tool that refuses to do more than it can see.