# Submitted Is Not Live: Building an Evidence Trail Clients Can Audit

> Agent-friendly Markdown of https://www.buildseo.org/blog/submitted-is-not-live — full index for AI agents: https://www.buildseo.org/llms.txt

_Verification · 8 min read — Anurag Pattnaik, Platform engineering, Andolasoft · June 29, 2026_

Anchor text, follow status, indexation, screenshot, HTML snapshot, timestamp. What we store per check, and why re-verification schedules matter more than the first result.

Submitted is a claim about our system. Live is a claim about the publisher's. Most link-building reporting quietly treats the first as evidence for the second, and the gap between them is where the category loses its credibility.

A submission can succeed in every observable way â€” form accepted, confirmation page rendered, thank-you email received â€” and still never produce a public listing. Editorial queues reject silently. Listings publish to a page that is not linked from anywhere. Moderators approve the entry and strip the link. If your report counts submissions, none of that is visible to you or to the client.

## What we store per check

A verification is a record, not a boolean. Every check writes the same fixed set of fields against the submission, whether it passed or failed.

| EVIDENCE | TYPE |
| --- | --- |
| Listing URL | Text |
| Target URL found | Bool |
| Anchor text | Text |
| Rel attribute | Text |
| HTTP status | Int |
| Rendered screenshot | Image |
| HTML snapshot | Blob |
| Checked at | Time |

The pairing of screenshot and HTML snapshot is deliberate. A screenshot is legible to a client and proves nothing on its own; an HTML snapshot is checkable and unreadable in a report. Stored together they let anyone re-derive the verdict months later without trusting our summary of it.

> A screenshot without an HTML snapshot is a picture of a claim. Store both, or stop calling it evidence.

## The first check is the least interesting one

Verifying immediately after publication tells you the listing went up. It tells you nothing about whether it will still be there when the client renews. Links are removed during directory clean-ups, pages get pruned in a migration, and a template change can flip an entire directory from follow to nofollow overnight without anyone announcing it.

So verification is a schedule, not an event. Each placement is re-checked at twenty-four hours, seven days, thirty days and ninety days, then quarterly for as long as the client is reporting on it. Each run appends a record. The history is the product â€” a single current status is exactly the kind of unfalsifiable claim we are trying to get away from.

## Statuses that are honest

Live, live-nofollow, altered, missing, unreachable, and blocked are distinct outcomes with distinct causes, and collapsing them into a pass or fail throws away the only information that suggests what to do next. Altered is the one people forget: the listing exists, the link exists, and the anchor text is not the one that was submitted. That is a real and common outcome, and it needs to be reported rather than rounded up to live.

Unreachable is a statement about the check, not about the link. A verification that could not complete is never allowed to downgrade a placement's status on its own; it retries with backoff and only escalates after repeated failures on different days. Reporting a live link as missing because a publisher had a bad afternoon is a fast way to lose an operator's trust in the whole system.

## Indexation is a separate question

A link can be live and never indexed. The two are reported in separate columns because they fail for different reasons, they have different remedies, and they are the responsibility of different people. Conflating them produces a number nobody can act on â€” the client cannot tell whether the placement was bad or the page it landed on was.

## The test that matters

Hand the report to somebody who does not work for you and ask them to disprove a row. If the answer is that they would have to take your word for it, the evidence trail is decorative. If they can open the snapshot, find the anchor, check the rel attribute and see when it was last confirmed, the report is doing its job.

**Takeaways**

- Never let a successful submission stand in for a verified placement â€” they are claims about two different systems.
- Store the screenshot and the HTML snapshot together; either one alone is unfalsifiable or unreadable.
- Make verification a schedule with an append-only history rather than a single current status.
- Keep unreachable separate from missing, and indexation separate from live â€” different causes, different owners.

## Keep Reading

- [The Hidden Cost of Manual Link Submission: A 5-Year ROI Case Study](https://www.buildseo.org/blog/the-hidden-cost-of-manual-link-submission.md): One agency spent $840k on manual link building over five years. We mapped where every dollar went, and why their cost per verified link was 12Ã— higher than they reported.
- [Cost Per Link: How To Calculate It, Why Vendors Hide It, and What It Actually Means](https://www.buildseo.org/blog/cost-per-link-what-it-actually-means.md): Every link-building platform quotes a different number. Here's how to calculate the one that matters: cost per link still live at 90 days. And why that number is the only one your CFO should care about.
- [The Link Database Advantage: Why Campaign Two Should Cost 20% Less Than Campaign One](https://www.buildseo.org/blog/link-building-database-compounding.md): Campaign one teaches you everything about your vertical. Campaign two should cost less, take less time, and deliver more verified links â€” because you kept what you learned.

## See the Score Run on Your Category

We will qualify live publisher inventory in your vertical and show you every signal behind it. Schedule a demo: https://calendly.com/buildseo-sales/30min

---

[All posts](https://www.buildseo.org/blog.md) · [BuildSEO AI](https://www.buildseo.org/index.md)

