About backlink
backlink is a business Skill for the full backlink lifecycle, intended for workflows involving link research, evaluation, and publishing. It organizes data files, scripts, and operational references for competitor discovery, quality assessment, and browser-based data collection.
Key features
- 01Find and filter backlink targets
- 02Discover competitor links and manage leads
- 03Assess backlink quality and toxicity
- 04Research with Similarweb and Semrush
- 05Harvest reports from sites without APIs
Use cases
- 01Select sites for backlink submissions
- 02Find competitor links and potential opportunities
- 03Assess link quality and disavow decisions
- 04Extract reports from logged-in SaaS dashboards
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ yan-labs/ yan-skills --skill backlinkAfter installing, type/backlinkin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
CONTRIBUTING.mdagents/openai.yamldata/free-channels.jsonindex-submission.jsonnetwork-fingerprints.jsonpaid-platforms.jsondata/schema/free-channels.schema.jsonindex-submission.schema.jsonsubmission-targets.schema.jsonevals/evals.jsonevidence/screenshot-chain-VERDICTS.mdreferences/acquisition-doctrine.mdanalysis-templates.mdauthorized-data-sources.mdbacklinkdirs.mdbatch-campaign.mdbrowser-runtime-detail.mdbrowser-runtime.mdcredits.mddata-source-operations.mddirectory-run-playbook.mddiscovery-loop.mdfield-notes.mdharvest.mdindex-submission.mdinstant-publish.mdintent-routing.mdknown-forms.mdLICENSE-analysis-templates-Apache-2.0link-quality-rubric.mdDetails
From the project READMETwo 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 |
|---|---|
| 去哪发、批量提交 | node scripts/targets-select.mjs --stats; ; 100+ targets: |
| 免费免注册、即时发布 | data/free-channels.json (account:none, status:live); |
| 竞品外链、新机会 | and Semrush platform manual; write leads back to registry |
| 质量、毒性、要不要 disavow | and data/network-fingerprints.json |
| 发出去了没有 | ; inspect exact public anchor and rel |
| 索引提交 | ; it publishes no backlink |
| Semrush/Similarweb 报表、流量 | ; platform manuals under ../platforms/ |
| 没有 API 的后台表格 |
Query the database instead of guessing from examples:
| 问题 | 用哪个 | 拿得到什么 |
|---|---|---|
| 这个站多大、流量从哪来、还有哪些同类站 | Similarweb | 总访问量(含直接/推荐)、渠道构成、相似站、地理分布 |
| 这个词多少量、多难、谁在排、它的外链长什么样 | Semrush | 分国家搜索量与 KD、关键词全库导出、自然排名、主要页面、引荐域名与反链 |
两边的「流量」口径不同,对不上很正常。 Semrush 域名概览给的是自然搜索流量估算,
Similarweb 给的是总访问量。同一个站两边差三倍以上是常态,写结论时必须标明口径,
否则会得出「竞品比想象中弱」这种错误判断。绝不放进同一列。
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:
Count the record-shaped lines in `rawText`, compare with `parsed.rows.length`. A gap here means **your regex has a blind spot** — the rows arrived and you dropped them. This is the silent, dangerous one. Fix the parser. Semrush prints its own total (`自然搜索排名: N`). If that exceeds what `rawText` even contains, the rows **never reached you**: these tables are virtual-scroll and only mount a fraction at a time, so a full pull needs the export, which costs quota. This is a known ceiling, not a bug — say so rather than "fixed the parser".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.
The qualifying test is real traffic (`>= 100` monthly visits), never DR, and it runs BEFORE the form does. The division of labour is fixed: **scripts collect evidence, the AI reads the evidence and judges, a human can re-check both.** The batch scripts emit measured raw values plus a parse status, a raw-text excerpt, a screenshot in `<out>.jsonl.evidence/`, and a `stopReason` — never a pass/fail verdict. `apply-traffic-screen` copies numbers and evidence paths into the table; the threshold is computed at query time by `targets-select`. **A null value is NOT low traffic — it is an unmeasured or failed capture, and treating it as a conclusion is banned.** `stopReason` tells you which: `stable`/`empty-state` mean the capture completed (and `empty-state` means the source itself printed a no-data sentence — whether that means "too small to measure" is the AI's call, made against the screenshot and raw text); `unstable`/`timeout`/`exception` mean *this check did not finish* — resume retries them, and applying such a row clears any stale same-source measurement instead of writing one. Rows without a number never fall into the "unqualified" bucket: `targets-select --min-traffic` lists them separately and `--unmeasured` queues them. Measuring a domain costs one query; filling its form costs two orders of magnitude more. One run filled every form across a 73-domain family and only then sampled five for traffic — every filled form was discarded. Inspect every target independently. Never infer a form from a sibling site. `inspect-page.mjs` outputs a **full form census** — every form, every field (visible and hidden) with its semantic tuple and stable marker — plus a captureScene pair (piercing census + screenshot) in the evidence dir. Its `fillable` / `blocker` / `reason` / `selectedForm` fields are **heuristic suggestions** (see the `suggested` note in the output), not verdicts: the AI judges "can this page be filled, and what gates it" from the census and the screenshot, and may overrule the suggestion. The mechanical rule safe-fill still enforces: it only proceeds on one unambiguous qualifying form. A CAPTCHA page may be staged only when the owner explicitly accepts normal human completion; never bypass or solve it by an external CAPTCHA service. Modes are `comment`, `directory`, or `auto`. Evidence lands in `.backlink/scan.json.evidence/` (override with `--evidence-dir`). Create a reviewed JSON payload with truthful values. For comment mode, `description` is the comment body. It revalidates the URL, form identity, field semantics, login state, and CAPTCHA state, installs a submit guard, and never submits. The human reviews the rendered page and performs final submission. Only after the user explicitly authorizes one exact reviewed submission may the agent run `release-submit-guard.mjs` — and releasing the guard still does not click Submit. When the owner has explicitly accepted normal CAPTCHA completion, add `--allow-captcha`; this only permits guarded filling and leaves the CAPTCHA and final submission untouched. CAPTCHA routes are always handoff-only. Once the filled form is visibly ready for the owner, release only the guard with `release-submit-guard.mjs --human-handoff`, then stop. The agent must not solve the challenge or click Submit, even when a batch authorization already exists. Lane B leaves forms on screen for the owner to finish. **One session name per staged site** — a session owns one tab, so reusing one session overwrites the previous staged form while the report still says N staged. `adapter-phpld.mjs` carries the reference implementation. Analyze referring-domain quality and topical relevance; suspicious networks, sitewide links, and toxic patterns; anchor and target-page diversity; follow/nofollow/UGC/sponsored distribution **when observed**; competitor gaps and prioritized next opportunities. — scoring, toxicity, disavow. — report shapes. — frameworks; sending needs the user's explicit approval per message. These templates assume you already have the data. They do not fetch it. **A report built from templates alone, with no observed rows behind it, is fabrication.** Do not disavow links, contact site owners, or change production sites unless the user separately asks. Treat third-party authority and traffic estimates as directional and time-sensitive. before writing any scraping loop. It documents failures that produce **plausible, silently wrong output**: virtual scroll tables that are not `<table>` and drop rows without erroring, long URLs that make whole rows vanish, execution-channel timeouts that look like failure while the page loop is still running, and Chrome's intensive throttling stretching a four-second loop into twenty-five minutes. `scripts/harvest.browser.js` is the in-page collector. Its output arrives via a Blob download rather than a return value, because the execution channel truncates at roughly 1 KB.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.
candidate → qualified → drafted → filled → submitted → public → indexed → rel_verifiedPer-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.