agentlinkopsAgentLinkOps / Compare
Backlink monitors: Linkody, LinkGuard and AgentLinkOps.
A backlink monitor tells you when a link you earned changes or disappears. The useful comparison is what stands behind that sentence: how the tool decides a link is lost, what it does with a page that only renders in a browser, what evidence it keeps, who owns the records afterwards, how the alert arrives, whether your agent can reach it, and what it publishes about price. Checked September 15, 2026.
Who this is for
You paid for links, or earned them, and you want to know when one goes away without reading a dashboard every week. You have been burned by an alert that said “lost” about a link that was right there. And you may want an agent, rather than a person, to read the results. If you are new to the checks themselves, the backlink monitoring overview explains what a single check can and cannot conclude.
The three, in one sentence each
- Linkody. Its home page says “your backlinks and your competitors are monitored 24/7” and “get notified via email reports about new links or any change of status”; its plans page says “Linkody checks your links and updates their status every 24h” (fetched September 15, 2026).
- LinkGuard. Its home page sells “automated monitoring with instant alerts when your $300-1000 links get removed, changed to nofollow, or modified”, with “no monthly subscriptions” and prepaid tokens spent per check (fetched September 15, 2026).
- AgentLinkOps. A hosted service and a local CLI that verify the source and destination URLs you supply, record dated observations with evidence, keep checking on a schedule with nobody connected, and deliver changes as an event feed and signed webhooks. Hosted access is invitation-only.
Side by side
Competitor cells quote the vendor’s own pages as fetched on September 15, 2026. AgentLinkOps cells quote the public claims ledger; the ledger row names the source file behind each one. “No statement found” means we did not find one on that vendor’s fetched pages that day, and nothing more.
| Question | AgentLinkOps | Linkody | LinkGuard |
|---|---|---|---|
| How is a lost link decided? | A check that cannot conclude returns unknown with a named reason, and unknown never means the link was removed. Confirmed loss needs two complete absent observations at least 30 minutes apart; the last verified state and the latest attempt stay separate fields on the watch. | “Know when you lose or gain links” and status updated “every 24h” (their pages, fetched September 15, 2026). No statement found about how many checks precede a lost verdict or how a blocked fetch is treated. | “Alerts are sent within minutes of detecting a change” (home page). Their article on false alerts, updated August 31, 2026, says LinkGuard “falls back to a real cloud browser when a plain fetch returns an empty or suspicious result” and recommends that a monitor “re-check a suspicious result before raising an alarm”. No statement found giving the number of checks before a lost verdict. |
| Pages that only render in a browser | The verifier reads static HTML and says so on every observation: “JavaScript execution and visual visibility were not checked.” A page that needs a browser returns unknown with the reason possible_render_required, which never counts as loss. On the September 11, 2026 benchmark, render-required was 2.2% of the checked pages in that sample. | No statement found on Linkody’s fetched pages either way. LinkGuard’s comparison article, updated September 11, 2026, states that Linkody has “no JavaScript-rendered fetching (so links on modern Webflow or React donor pages can read as ‘lost’ when they’re fine)”. That is a competitor describing a competitor; we did not test it. | Their comparison article says “we run a JavaScript-capable fetcher (so modern donor pages don’t throw false ‘lost’ alerts)”, and their Ahrefs page, marked last reviewed May 2026, describes an “on-demand, real-browser fallback” (fetched September 15, 2026). |
| Evidence retained | Every observation stores the fetched URL and each redirect hop, the HTTP status, the robots posture and a SHA-256 hash of the bytes read, dated. Hosted rows keep the hash beside the result; the retained snapshot is readable through get_link_evidence until retention removes it, then the call says EVIDENCE_EXPIRED. Raw snapshots expire after 30 days in the pilot; the history stays. | No statement found about retained fetch evidence. The home page offers “PDF reports for your clients” (fetched September 15, 2026). | Their false-alerts article says a good monitor should “let you see the evidence so you can judge fast”. No statement found describing what evidence LinkGuard itself retains per check. The home page offers white-label PDF reports (fetched September 15, 2026). |
| Who owns the records, and how do you leave? | The ledger that declares each expected placement is a plain JSON Lines file in your own repository; cloud sync mirrors it and never writes back. Monitored placements export with pagination through export_link_watches or the REST route for local CRM recovery. Prospects and outreach were never uploaded. | “When your subscription period ends your account will automatically convert to a free plan” (plans page). An API is offered to “integrate Linkody’s data into your own tools” (home page). No statement found about a bulk data export (fetched September 15, 2026). | “Tokens never expire” and no subscription (pricing page). Links are added by CSV upload or by hand, with “no API keys” (their Ahrefs page). No statement found about a data export beyond PDF reports (fetched September 15, 2026). |
| Alerts and delivery | Changes arrive as a resumable event feed and as webhooks signed with HMAC-SHA-256, at-least-once, with the secret shown once and rotation supported. Webhooks deliver single events or periodic digests. Hosted delivery to your receiver is gated by environment configuration in the current build; the transports exist in source and are tested. | “Get notified via email reports about new links or any change of status” (home page, fetched September 15, 2026). | “The instant a link is removed or flipped to nofollow, an Email or Slack alert lands in your inbox” (home page, fetched September 15, 2026). |
| Can an agent reach it? | Yes, three ways: MCP at /mcp, REST under /v1, and a local CLI that runs the same verifier module the cloud runs. Keys carry workspace scopes. | API, per the home page (“build custom solutions tailored to your needs”). No MCP statement found (fetched September 15, 2026). | No API or MCP statement found on the fetched pages; the setup story is CSV upload with “no API keys” (fetched September 15, 2026). |
| Published pricing model | No public price. Hosted access is an invitation-only pilot, and payment collection does not exist in this build. Usage is metered in check units, reported as reserved, consumed and released. | Link slots by plan, monthly. Webmaster $14.90 (2 websites, 500 monitored links, 1 user); Advanced $24.90 (5, 2,000, 1); Pro $49.90 (20, 5,000, 3); Agency $99.90 (50, 20,000, 5); Agency XL $153.90 (100, 50,000, 10). Annual billing is lower. 30-day trial, “no credit card required” (plans page, fetched September 15, 2026). | Prepaid tokens, spent per check. An HTML check costs 5 tokens, a SERP check 7, both together 12. Packs: $25 for 25,000 tokens, $50 for 55,000, $100 for 115,000, $500 for 625,000; “every new verified user receives 1,000 free tokens”. Their own example: 100 links checked weekly is 2,200 tokens a month (pricing page, fetched September 15, 2026). |
How “lost” gets decided
This row is the one that changes what you do on a Monday morning. LinkGuard’s own article describes the failure well: a plain fetch “sees the shell, finds no link, and reports it lost, even though a human (and Google’s renderer) would see the link load a half-second later.” Their answer, as published, is a browser fallback and a re-check before alarming.
AgentLinkOps answers it with vocabulary. A fetch that is blocked, refused, login-walled or render-required is unknown with that reason, and unknown never advances the loss clock. Only an expected link, observed absent, in a complete page, starts a confirmation window, and loss is confirmed by a second complete absence at least 30 minutes later. Every result on the watch keeps the last verified state apart from the latest attempt, so an outage on the publisher’s side reads as an outage, and the link’s last known state stays visible.
The cost of that discipline is measurable and we publish it: on the September 11, 2026 benchmark run across the hardest pages of one target domain, 75.5% of checks concluded and the rest were named unknowns, with zero false absents against a raw-bytes oracle on the pages read. Those rates belong to that sample and date. The buyer page carries the full table and its boundary.
JavaScript pages, stated plainly
AgentLinkOps does not execute JavaScript in the hosted verifier. Every observation says so. A page that only shows its links after rendering comes back unknown with the reason possible_render_required. It is never recorded as lost, and the placement keeps its last verified state until a complete observation replaces it. If the only way to confirm a link is a browser, checking backlinks on JavaScript pages walks through recording that inspection and attaching it to the placement record.
LinkGuard sells the opposite choice, a browser fallback, in its own words above. We quote it because it is the clearest published statement of the trade-off. We have not measured how often either approach is right on the same pages, so this page does not say which is better.
What this page does not claim
- No accuracy ranking. We did not run the three monitors over the same links. The one measurement here is our own benchmark, with its date and sample attached.
- No statement that Linkody lacks JavaScript rendering. The only sentence to that effect is LinkGuard’s, quoted with its date; Linkody’s fetched pages said nothing either way.
- No hosted email alerts. AgentLinkOps sends no email; delivery is the event feed and signed webhooks, and hosted delivery to your receiver is gated by environment configuration in the current build.
- No verified contact addresses and no outreach. Published contact routes come from a saved page; deliverability is never checked, and the service sends nothing.
- No price, no open signup. Reading this page creates no account and starts no monitoring.
How this was checked
Written September 15, 2026 against the repository at commit fa927cf. Each AgentLinkOps statement quotes a row of the DP-0023 claims ledger (W-01, W-06, W-07, W-08, W-09, M-04, M-06, B-01, B-03, B-04, A-03, A-10, P-01 to P-08), and each row names the source file and line or the dated record behind it.
Competitor statements were fetched on September 15, 2026 from these pages and are recorded as ledger rows C-03 and C-11 to C-16: the Linkody home page and plans page; the LinkGuard home page, pricing page, false-alerts article (published May 20, 2026, updated August 31, 2026), Ahrefs comparison page (marked last reviewed May 2026) and three-way comparison article (published June 22, 2026, updated September 11, 2026). Linkody’s API documentation URL returned a resource listing without prose on that day, so the API row quotes the home page only.
A competitor’s number is their published statement on the fetch date, never a capability we verified. If a vendor page changes, the cell that quotes it is stale until this page is rechecked and its date updated.