Five steps for a dead link with a live product

Prep list: four things to have open before you start

A dead link with a live product is a routine failure of a directory rather than a lost order. Nothing about the product has changed; what broke is the pointer to it. The cheap way to handle it is to work from four things at once, so that the search does not turn into an afternoon of browsing.

Have these four open: the original row with its ten-digit id, the exact title string copied character for character, the item page address as it appeared when the row was live, and one empty line in a file you will keep. The fourth item is the one most people skip, and it is the reason the same search gets repeated a month later with less information than before. One browser window and one text file are enough for the whole routine.

Copy the title rather than retyping it, because punctuation and bracket shape are part of the claim. Start from the row id rather than from a marketplace search box, because a generic noun returns more candidates than you can check in one sitting. If the row came from an exported file, keep that export open beside the browser so the original line can be compared without scrolling.

Step one: capture the original row while you still have it

Write down five values before going anywhere: the row id, the title as printed, the marketplace tag, the category label, and the date you copied them. The id is the anchor, because every sampled slug ends with the same shape, a hyphen, a ten-digit id and the suffix kox, and all 192 ids in the sample are unique. Five values take about a minute to copy and save an hour of guessing.

Save the id even when the title looks unmistakable. Three titles in the sample appear twice, so a title-only search returns two candidates for rows that look identical at a glance, and the id is what separates them.

Note the shape of the link as well. Product addresses on the source site follow one pattern, a product path, a slug, a ten-digit id and the kox suffix, and the site’s own sitemap lists 11,393 product URLs that all match it. A link that does not match the pattern was never a product page, whatever it looked like when it was saved. Write the pattern you expected on the same line, so a later reader can see which test was applied.

Step two: test whether the store is still there

Open the item page once more and record what happens: it loads, it redirects, or it fails. Repeat that test for the store page behind it, and write both results on the same line as the row id.

Two rows in one sheet can point at one store or at two, and the sheet cannot tell you which, because none of the 192 sampled rows carries a store name. A store page that loads tells you somebody is trading under that name, and it does not tell you that your row came from that store. Treat those two facts as separate entries in the file, because only one of them can be confirmed by somebody else.

If both pages fail, check the path before concluding anything about the product. The source site is a directory and referral page whose footer states that it does not sell and does not take payment, and two of its own paths return 404. A directory can drop a page while the underlying product stays open on the marketplace.

Step three: search candidates by title

Search the marketplace for the product noun together with the brand token, when the title carries one, and paste rather than retype. Compare the results on three visible facts: the noun, the brand string, and any quantity claim in brackets. Two terms are usually enough; a third narrows the field to a set of pages you can read in one pass.

Expect a crowded field for generic titles. In the sample, 56 rows name no brand at all and 89 titles are shorter than 24 characters, so many rows offer a noun and a marketplace tag and nothing else. Add the row id to your search notes even though it will not survive a marketplace search, because it is what you will check the candidates against.

Stop at three candidates and write them down before opening any of them. A shortlist written in advance prevents the common failure of accepting the first page that looks close enough, and it makes the next search cheaper because the rejected candidates are already recorded. A rejected candidate stays in the file with the reason it was rejected, so the same page is not reopened next month.

Step four: check that the specification agrees

Compare the candidate against the original row on the facts a parcel will be judged by: what the item is, what it is made of, what it measures, and how many pieces are in the order. The row will often be silent here, since 181 of the 192 sampled titles name neither a material nor a measurement.

Where the candidate and the row disagree, prefer the candidate page for product facts and the row for identity. The row holds the id, the date and the title as printed, while the page holds the current description, and swapping those two roles is how a replacement ends up carrying an old specification. One line of your file can therefore hold two sources, and both of them carry a date.

Record the disagreements instead of resolving them silently. A note that says material claim differs, title names denim and the page does not is usable three weeks later, while a note that says looks the same is not. A disagreement left unrecorded is the one that reappears as a surprise later in the order.

Step five: log the replacement result

End the search with one of three outcomes written into the notes file: replaced with a candidate id, unresolved but verified as still sold, or unresolved and treated as gone. Each outcome takes the date and the check that produced it. An outcome with a date can be compared against a later snapshot of the catalogue; an outcome without one cannot be compared against anything.

Attach the fields you used. A usable line carries the original id, the candidate id or the words no candidate, the field that decided the outcome, and the review date; the point is not tidiness, but that a second person can re-run the decision without repeating the search.

Keep the file beside your sheet export rather than inside a chat thread. The list export tool produces a file you can keep and compare, a chat log cannot be compared line by line, and the row that failed once tends to fail again when the catalogue is refreshed.

The pass mark for each of the five steps

Step one passes when the id, the printed title and the copy date are in the file. It fails when the note holds a paraphrase of the title, or no id at all.

Step two passes when both the item page and the store page have one of three outcomes written next to them: loads, redirects, or fails. It fails when the note says the link is dead without saying which of the two pages was tested.

Step three passes when three or fewer candidates are written down together with the terms you searched. It fails when the shortlist was assembled by opening pages first and describing them afterwards.

Step four passes when the four product facts are marked as agreed, absent, or conflicting, each with the source that settled it. It fails when the only entry is a general impression of the new page. The distance between those two entries is the whole value of the step.

Step five passes when the outcome names the deciding field and the dates. It fails when the entry cannot be read by somebody who was not part of the search, which is the test that matters if the row is later handed to another person. A step that fails costs a repeat rather than a loss, which is why the failing option is worth writing down instead of hiding.