backlink

Two former Skills were merged in on 2026-08-16 and deleted: backlink-analyzer (analysis templates, toxicity rubric, outreach — now in three references under its original Apache-2.0 licence) and browser-harvest (pulling tables out of logged-in dashboards — now ). The harvest knowledge is general-purpose: ad platforms, e-commerce backends, any no-API SaaS report. When a harvesting task has nothing to do with links, load this Skill anyway and read that one reference.

Ask	Start
Where to post, bulk submission	node scripts/targets-select.mjs --stats; ; 100+ targets:
Free, no registration, instant publishing	data/free-channels.json (account:none, status:live);
Competitor backlinks, new opportunities	and Semrush platform manual; write leads back to registry
Quality, toxicity, whether to disavow	and data/network-fingerprints.json
Did it go out or not	; inspect exact public anchor and rel
Index submission	; it publishes no backlink
Semrush/Similarweb reports, traffic	; platform manuals under ../platforms/
Backend tables without an API

Query the database instead of guessing from examples:

Question	Which one to use	What you can get
How big this site is, where its traffic comes from, and what similar sites exist	Similarweb	Total visits (including direct/referral), channel composition, similar sites, geographic distribution
How much volume this term has, how difficult it is, who is ranking, and what their backlinks look like	Semrush	Search volume and KD by country, full keyword database export, organic rankings, main pages, referring domains and backlinks

The two sides use different definitions of "traffic," so it is normal for them not to match. The Semrush domain overview givesestimated organic search traffic, while Similarweb givestotal visits. It is common for the same site to differ by more than three times between the two; when writing conclusions, you must specify the definition, otherwise you will make incorrect judgments like "the competitor is weaker than expected." Never put them in the same column. Use node scripts/tools-share-open.mjs --tool semrush or --tool similarweb; reuse the same session for a task and check the landed route, target and quota. Semrush organic estimates and Similarweb total visits have different denominators. Panel launch, node quotas, and the Semrush overview criteria: . Tool account and source details: .

bulk: feed an authorized referring-domains export straight in. Edges are typed refdomain — do NOT route these through import-commenters, which would record a commenter relationship nobody observed.

node scripts/discovery-queue.mjs import-refdomains --file .backlink/discovery.json
--source competitor.com --input .backlink/competitor-refdomains.csv

node scripts/harvest-commenters.mjs --session "discovery-commenters" --url https://example.com/article --out .backlink/commenters.json node scripts/discovery-queue.mjs import-commenters --file .backlink/discovery.json --input .backlink/commenters.json node scripts/discovery-queue.mjs next --file .backlink/discovery.json --limit 10 ]]> A second, non-recursive lane: search-operator footprints instead of competitor backlink rows. footprint-discover.mjs prefers Serper.dev's API (a real Google SERP over HTTP, no browser, no CAPTCHA) when SERPER_API_KEY is set — its free tier caps operator queries at 10 results. Without a key it falls back to the owner's own logged-in Chrome via OpenCLI, where a session hits a CAPTCHA / "unusual traffic" wall after roughly 4 operator queries, and a flagged exit IP gets blocked even from a fresh independent profile (2026-09-12 agent-browser finding). General search APIs and Bing/DuckDuckGo still do not execute inurl:/intitle: operators either way. See references/discovery-loop.md § "Footprint discovery" for the effective/noisy footprint table and the CAPTCHA policy before running a real sweep. <![CDATA[ node scripts/health.mjs # confirm opencli before opening a browser node scripts/footprint-discover.mjs --keyword "browser games" --preset submit
--num 20 --out .backlink/footprint-browser-games.jsonl

writes JSONL incrementally; stops and leaves a scene under .backlink/footprint-browser-games.jsonl.evidence/ on any CAPTCHA signal. --resume picks a stopped run back up later without re-running done queries.

]]> Domain overview is one page; semrush-report.mjs covers the other eight, which have no export button and are where competitor recon actually happens. Five of those eight (organic-overview/organic-positions/organic-pages/keyword-magic/ keyword-overview) have no worldwide option and land on an unpredictable country without --db — pass it explicitly or the script exits with an error; the other three (backlinks-list/referring-domains/backlinks-overview) aren't country-scoped. Pass the same --session across the whole recon — the panel launch costs 20–40s and a login, the report itself ~15s, and semrush-report.mjs skips the launch when the session is already parked on the tool origin (sessionReused: true says which happened). <![CDATA[

Semrush is a quota site: the script resolves the session to the fixed semrush-nav itself, so do NOT pass --session. Passing one is ignored with a warning; the fixed name is what serialises concurrent callers into one tab.

node scripts/semrush-report.mjs --report keyword-overview --keyword 'grid maker' --db us node scripts/semrush-report.mjs --report backlinks-overview --domain rival.com node scripts/semrush-report.mjs --report organic-positions --domain rival.com --db us opencli browser semrush-nav close ]]> This is the one place a session legitimately handles several reports — it is still one page at a time, navigated in sequence, which is what allows. Holding them open simultaneously would need N session names. These metrics help discover and prioritize candidates. They never prove a backlink is public, indexed, followable, or causally producing traffic. The parsing traps that make a report silently return zeros are documented in — read it before writing any new reader, especially the rule that a readiness predicate must key on a data row, never on a tab name, column header, or filter chip.

Then check the parser against itself. A ready page and a correct parse are different claims, and the second one fails silently. One live run under-reported all five domains it touched — the worst lost 91 rows of 93, and the one that looked healthiest still lost 49 — with no error anywhere and a wrong written conclusion on top.

The check is two comparisons, and conflating them produces false alarms:

A live re-run shows both at once: three domains matched their headline exactly (14/14, 22/22, 5/5) while one read 91 against a claimed 430. The first three prove the parser; the fourth is level 2 and needs no fix.

Reach for it only when you need the whole table as a file. For reading a report — "what does this page say", "is there data here at all" — use instead: it is the collector names, and harvest.browser.js has exactly one witness (the DOM), no manifest, and no screenshot to contradict it. When you do use harvest.browser.js, take the screenshots yourself.

Per-project progress: what have I submitted vs what's left?

node scripts/ledger.mjs stats --file .backlink/ledger.json node scripts/ledger.mjs remaining --file .backlink/ledger.json --min-traffic 100 node scripts/ledger.mjs remaining --file .backlink/ledger.json --cohort open --free-only

Select next batch — reads .backlink/ledger.json by default (relative to cwd) and excludes submitted-or-later AND rejected domains with no flag needed

node scripts/targets-select.mjs --cohort open --min-traffic 100 ]]> submitted, public, indexed, and rel_verified each require an evidence note. Never promote a record from a filled form, a pending notice, or a historical assumption. indexed must name the engine — indexed@google, indexed@brave. An unqualified "indexed" is a claim about the whole web built from one crawler's opinion.

opencli comes first. Every browser action in this Skill runs through it, and it carries the rules this Skill only summarises.

It also requires the OpenCLI binary and browser extension from yan-labs/OpenCLI releases — not the Chrome Web Store build. The store build defaults to foreground: it raises a window and steals the tab the person is reading. That failure is silent — commands still succeed, only the behaviour is wrong — so opencli doctor flags an extension older than 1.0.32 explicitly. When it does, act on it rather than working around it.