Link order QA mistakes: seven bug reports with fixes
Each entry below is written like a ticket: what was expected, what happened, and the fix. Most cost nothing to repair.
LinksVerifier research team ·
Seven defects, in the order we meet them
01
Bug 1: you accept a screenshot as evidence
Expected: a fetched page. Actual: an image anyone can edit. Fix: save raw HTML with a timestamp and a curl -I header dump the day the vendor reports it live.
02
Bug 2: you check the home page, not the exact URL
Expected: a link on the paid article. Actual: a footer link on the home page that disappears on the next deploy. Fix: store the exact source URL in your sheet and test that string.
03
Bug 3: you re-check daily against a monthly index
Expected: fresh results. Actual: thirty identical answers. Fix: schedule one check after each refresh; see the cost table.
04
Bug 4: you compare DR across tools as if it were one number
Expected: 55 equals 55. Actual: Ahrefs, Moz and our formula disagree. Fix: pick one metric for the contract and name it in writing.
05
Bug 5: you never test the target URL
Expected: your page returns 200. Actual: it redirects twice, or a staging rule blocks bots. Fix: run curl -I on your own URL in the same script.
06
Bug 6: you ignore the rel attribute
Expected: a followed link. Actual: rel="sponsored" or nofollow added by a plugin. Fix: parse rel from the fetched HTML and fail the row when it differs from the order.
07
Bug 7: you trust a replacement without re-testing it
Expected: new link equals old. Actual: a different domain with a lower rating. Fix: send every replacement through the same checks as the original.
Why the fixes are small
Notice that none of them needs a second subscription. QA of purchased links is mostly bookkeeping, and the bookkeeping that matters happens on the delivery date.
What costs money is the late discovery. Always. A batch of 40 links paid in advance, found broken three months later, leaves you arguing about a guarantee window that may already have closed. Run the checks on day 0, day 30 and day 60 and the window works for you.
For a concrete schedule with invented but plausible numbers, see the 40-link worked example. For terms used in this list, the glossary is one click away.
A minimal script for bugs 1, 5 and 6
This shell loop reads a file with one source URL per line, saves headers and HTML, and greps your domain. It uses only curl and grep.
It cannot tell you whether Google has indexed the page, and it will not execute JavaScript. A link inserted client-side by a script will read as missing here even though visitors see it.
Where our API joins the loop
After the shell loop, call refdomains once for the client domain and diff the host list against the sheet. That is 2 credits, $0.0002, and one request covers up to 1,000 rows.
Hosts present in the sheet and absent from the list get the label pending until the next monthly refresh. Hosts present in both are cross-confirmed. A short list, cleanly labelled, is the deliverable your manager actually reads. Nobody opens the raw JSON, and nobody should have to. Keep the dump in storage in case a vendor disputes a row six weeks later.
Before you close the ticket
The sheet names an exact source URL for every row, not a domain.
Day 0 evidence is stored: HTML, headers, date and time.
The next re-check date falls after a monthly refresh.
Replacements went through the same seven checks as the first batch.