Submit Backlinks

Submit Backlinks

Goal

Turn a target-site brief and a raw backlink pool into a qualified queue, execute only authorized actions, verify explicit evidence, and keep submission actions separate from public backlinks.

Treat this skill as a baseline workflow. Follow the user's explicit goals, constraints, tools, and authorization choices over its defaults. Adapt source selection, thresholds, batch size, order, and output format when useful; preserve evidence integrity, privacy, and explicit boundaries for payment, identity verification, and site changes.

Guide the first run

Read references/guided-onboarding.md when the user provides only a site URL, gives an incomplete request, or asks how to begin.

Use these safe defaults when the user does not specify them:

• qualify each candidate before execution; show a queue first when the user requests planning or approval;
• target up to 10 qualified opportunities in the first queue;
• use free routes only;
• allow reciprocal candidates into the queue but require approval before changing the site;
• use queue_only for research requests; a request to submit starts authorized_continuous within the stated scope;
• after authorization, use authorized_continuous and continue through qualified free platforms without repeated confirmation;
• prefer whichever supported SEO tool is currently open and authenticated instead of requiring a named provider;
• for competitor-backlink discovery, find 10–20 relevant competitors when available and build a broad raw pool before ranking or qualification;
• remember the provider only after a successful read or export, without storing account or session data;
• use local JSONL or stdout unless a tracker is configured;
• infer public product facts from the live site before asking questions.

Recover prior campaign results and existing authorization before starting a continuation. Do not restart onboarding or ask the user to authorize an action already covered by the conversation. Keep missing personal facts separate from missing permission.

Ask one bundled question only for facts that block read-only progress. Continue discovery and qualification while optional copy, assets, or execution permissions remain unresolved.

Show a compact kickoff summary before substantial work:

textCopy code
Target:
Mode: pool | discovery
Sources:
SEO source:
Queue target:
Paid policy:
Reciprocal policy:
Execution policy:
Google OAuth policy:
Current stage:

Collect inputs

Collect the target-site brief before screening candidates:

• site name and canonical site URL;
• target page name, URL, and type;
• product category, audience, language, and market;
• tagline, short description, long description, and keywords;
• contact identity, social URL, logo, and screenshots;
• target result count, free/paid constraint, and reciprocal-link policy.

Define the count unit and allowed sources in the brief. A target of new platforms counts distinct platform hosts, not attempts, accounts, redirects, form providers, or repeat submissions. For an underspecified execution request, state that the working target is successful new submissions and report public links separately; honor an explicit live-link target.

Keep competitor-pool provenance, historical supplemental platforms, and fresh discovery distinguishable. If the user restricts the source pool, do not fill a shortage from other sources. If expansion is allowed, label the supplements and report the source split. Generic contact requests and email sends remain outreach actions, not completed listings.

Verify product claims and adapt copy to the actual audience. Never invent country of residence, date of birth, revenue, funding, company status, or affiliation to satisfy a form. Skip optional unknown fields; defer a platform when a required fact cannot be established. A confirmed age threshold is not an exact birth date.

Choose one entry mode:

• Pool mode — preferred: accept CSV, JSONL, spreadsheet, or URL-list candidates from the user.
• Discovery mode: use competitors, keywords, directories, resource pages, or search sources to build a raw pool first. For competitor research, favor broad bulk exports across many relevant competitors; raw pools may contain thousands or tens of thousands of rows.

Read references/candidate-pool.md before parsing a pool or starting discovery. Preserve provenance. Never submit directly from an unverified URL list.

For a local pool file, run scripts/prepare_pool.py to normalize and deduplicate CSV, JSONL, or plain-text input. When a reusable campaign workspace helps, run scripts/init_campaign.py to create editable templates.

Read references/discovery-sources.md before choosing discovery sources. Treat commercial SEO suites as optional sources; do not block discovery when they are unavailable.

At the start of Discovery mode, run scripts/preferences.py --show, then inspect available browser tabs without reading cookies or tokens. Prefer an explicitly requested provider, then the active authenticated SEO-tool tab, then another open authenticated SEO-tool tab, then a remembered provider whose session still works. Read references/preferences.md.

Build a qualified queue

For each candidate, verify:

1. The target page is reachable and relevant.
2. A current submission route or legitimate public contact exists.
3. The product and page type are eligible.
4. Free and paid paths are clearly distinguished.
5. Duplicate listings and prior attempts are checked against the exact target domain, not just the product name. A same-name competitor on another domain is not a duplicate; an existing pending listing of this target is.
6. Login, CAPTCHA, assets, scheduling, and reciprocal-link requirements are known.

Classify every checked candidate:

• A — direct free: eligible working route with no mandatory reciprocal link.
• B — free with login/assets: eligible and free but needs authentication, assets, or scheduling.
• C1 — qualified reciprocal: requires a link, badge, footer placement, or embed and passes references/reciprocal-links.md.
• C2 — rejected reciprocal: fails relevance, legitimacy, evidence, link-attribute, authority, or sitewide-linking gates.
• D — blocked/ineligible: paid-only without approval, duplicate, dead route, account limit, wrong category, persistent failure, or unverifiable outcome.

Execute A, then B, then approved C1. Skip C2 and D.

Do not apply a blanket rejection to mandatory reciprocal links or badges. Keep every gate-passing C1 candidate in the qualified queue with approval_required; reject only C2.

For a target of 10 or more results, read references/high-volume-outreach.md before discovery or execution.

Authorization boundaries

• Treat platform submissions, account creation, and outreach sends as external writes. Perform them only when the user asked to execute the campaign.
• When existing instructions do not cover Google sign-in, ask once whether the user authorizes reuse of an existing Google session for ordinary sign-in, account creation, and qualified free submissions. Explicit permission already given satisfies this step.
• After approval, reuse that authorization across the current campaign. Click Sign in with Google, select the authorized account, and continue without asking again on every platform.
• If the user authorizes remembering this choice, store only the boolean reuse preference with scripts/preferences.py --remember-google-oauth.
• If several Google accounts are available and no preferred account was authorized, ask once which account to use, then reuse that choice for the campaign.
• Stop at payment unless the amount and platform are explicitly approved.
• Obtain approval before adding a reciprocal link, badge, footer item, or embed unless the campaign brief already authorizes that exact class of site change.
• Handle visible CAPTCHA challenges through supported browser interaction when current authorization and the tool permit it; read references/browser-execution.md. CAPTCHA is not the same as passkey, 2FA, recovery, or a legal identity declaration.
• Pause the affected flow on unavailable credentials, account mismatch, user-only 2FA/recovery/passkey, or permissions beyond ordinary profile and email access. Continue independent qualified candidates when possible.
• Login success proves authentication only.

Read references/oauth-session.md before the first OAuth flow or when an account chooser, consent screen, or authentication blocker appears.

Timebox

Use these as diagnostic budgets, not reasons to abandon a healthy flow. Continue past the budget when observable progress is being made and completion is close. Never use the target count to justify blind retries or weaker qualification.

• Budget about 2 minutes to preflight a new platform.
• Budget about 5 minutes for a direct form.
• Budget about 8 minutes for login or multi-step flows.
• After two equivalent failures, try one materially different route or stop.
• Retry one timeout once with a clean state.
• Stop immediately on a confirmed paywall, duplicate, ineligible category, account limit, broken route, or C2 requirement.

Execute one platform at a time

1. Prepare one reusable submission pack.
2. Reuse one active submission tab.
3. Finish authentication, form, challenge, submission, and receipt verification on that platform before opening the next. Treat groups of 3–5 as reporting/tracker checkpoints, not parallel login or CAPTCHA queues.
4. Record every terminal result before moving on.
5. Close tabs or task spaces opened by the campaign after evidence capture.

Do not close browser state that existed before the campaign. Keep context extracts limited to URL, title, required fields, visible errors, selected plan, final status, and evidence URL.

Use the current browser tool's own instructions and documented interfaces. Read references/browser-execution.md for dynamic editors, native frames, image uploads, verification challenges, email activation, and resumable blockers. Keep a small qualified buffer and replenish it during authorized execution instead of requiring the entire day's queue to be ready first.

Evidence rules

Count a successful submission only with at least one of:

• explicit submission or review receipt;
• review, ticket, or submission ID;
• confirmed schedule or queue date;
• a newly created public product, profile, or listing page containing the intended target link.

An assigned URL alone is not evidence of publication. Account activation, a profile without the target link, and solving a CAPTCHA are not successful submissions.

Count a public backlink only when an unauthenticated public page contains a real link to the submitted site. Verify dofollow, nofollow, or sponsored from the rendered link or public HTML; otherwise record unknown.

Store actual anchor text, href, raw rel, and check time. A platform's promised link attribute belongs in notes until the public anchor is inspected. For a redirect link, verify the final destination without assuming how search engines treat it. An authenticated view alone does not establish public access; keep that check pending if it cannot be performed.

Keep these outcomes separate:

• send_clicked;
• pending_review;
• scheduled;
• published;
• rejected;
• paywall_stopped;
• blocked;
• unknown.

Never count a button click, cleared form, generic dashboard, login redirect, search result, or missing confirmation as a successful submission.

For outreach, click Send once and record the recipient, subject, time, and send_clicked. If the action returns an unknown tool state, record send_unknown and do not resend automatically.

Reciprocal links

Read references/reciprocal-links.md before accepting any mandatory backlink, badge, footer link, or embed.

Evaluate reciprocal candidates individually. Include qualified C1 opportunities in the queue even when site-change approval is still pending.

A reciprocal result becomes published only after:

1. the outbound placement is publicly deployed and verified; and
2. the incoming public listing contains the promised link.

If the incoming link fails to appear within the stated review window or later disappears, remove or deactivate the outbound placement when authorized and preserve the historical result.

Record results

Use scripts/record_backlink.py. By default it prints normalized JSON to stdout and performs no external write.

Write locally only when --output-jsonl is provided. Use --lark-config only when the user configured and authorized Lark Base tracking. Read references/tracker.md for setup and field mapping.

Record one row per terminal attempt with provenance, classification, action status, evidence type, evidence URL, reciprocal state, link attribute, timestamps, and notes.

Update an existing tracker row when its status changes; do not create a duplicate attempt.

Preserve local history when the status changes and reuse the original attempt_id and tracker record ID. Read back the configured tracker's platform, status, and evidence URL in bounded groups; a write response alone does not establish that the final record is correct. Report any sync failure separately from the site's submission result.

Report stage boundaries

At the end of qualification, report:

• raw, duplicate, rejected, and qualified counts;
• the A/B/C1 queue with reasons and requirements;
• the C2/D exclusions with concrete reasons;
• unresolved login, asset, payment, CAPTCHA, or site-change blockers;
• the exact next batch proposed for execution.

If execution_policy=queue_only or the user explicitly asked to approve the queue, stop and wait.

If execution_policy=authorized_continuous, show the queue as a progress checkpoint and continue immediately with A, B, and already approved C1 candidates. Do not ask again merely because the queue was displayed.

Maintain reusable knowledge

Use references/platform-playbook.md as a dated template for recurring platform facts. Revalidate pricing, eligibility, route availability, and reciprocal requirements before relying on any cached entry.