Skip to main content
Use an export you already hold. Imported candidates keep the supplier’s source information and dates; an import does not establish current presence or start recurring monitoring. Import formats lists the columns AgentLinkOps reads from each source, with file limits and the reasons a row is skipped.

Review a retrieved set in the app

To look up backlinks using only your website address, start with Find your backlinks. That guide covers saved searches, source coverage, initial checks and the selection you can add to monitoring. Continue here when you already have an export to import.

Review an import with the discovery skill

Use agentlinkops-discovery with your export and website. Its import workflow preserves the source dates, rejected rows and saved run identity, then recommends selected checks within the available allowance. Review unknown results separately. Recurring monitoring and disavow review remain separate decisions under your task or standing authority. For a hosted import, your agent should return the saved run reference, rejected rows and a reviewable selection. A local CSV import only previews candidate rows; it saves no ledger or hosted records. Choose where you want to save selected links before continuing.

Preserve and inspect the import

Keep the original export unchanged. Use a CSV parser that preserves quoted commas, escaped quotes and multiline fields; splitting each line on commas can change the rows. Keep supplier collection/export times, imported row dates and your import time separate. A missing date stays unknown, and importing today does not establish when a link appeared. The local import reference lists eight presets including generic CSV, custom column mappings and --generated-at for the supplier timestamp.Call import_backlinks using its supported supplier value and row format. Inspect rejected rows and keep the run identifier. Read get_discovery_run, then page through list_discovery_candidates.For a local CSV with an authorized checkout or supplied toolkit:
Replace the path, file and target with your own values. The ledger guide explains how to save selected links after previewing. A local import does not create a hosted discovery run.For a source-only Search Console export, the whole-site target is an expectation you supply. Google has not supplied an exact destination for that row. Monitoring the saved candidate preserves its imported website scope, including whether the saved import includes subdomains. A row with an explicit destination, including a homepage URL, keeps that exact destination.

Monitor imported candidates in the app

Use Monitor all N to start monitoring the remaining candidates across the import, or Monitor the other N after adding some. You can also select rows and use Monitor N links. The import’s bulk action includes unchecked candidates; the search’s live-links action selects checked-present results. When you add links to monitoring, a recent completed check can be kept; otherwise, their first check is queued automatically, within your available checks. Read the progress and result counts. Wait for a queued check to finish before treating it as evidence. An existing link that you paused stays paused until you resume it explicitly in Links. If the links you chose exceed your plan’s room, review the confirmation before adding those that fit. It shows the number left out and the ordering: bulk actions put live links first and likely spam last; a selection keeps the order you chose. These cues do not establish link quality. When no more links fit, an owner can choose See plans. Other members see Your plan is full and need to ask the workspace owner. Links left out are not added automatically when room becomes available.

Verify selected candidates

  1. Choose a stored candidate and retain its run and candidate identifiers.
  2. Call verify_discovery_candidate with its documented inputs and a stable idempotency value for this check.
  3. Save the returned job_id and watch_id. Read get_candidate_verification until the job finishes, following returned retry guidance.
  4. Read the observation’s state, reason and timestamp. A successful job can return present, absent or unknown evidence. If the job failed without an observation, keep its error and do not invent a result.
Repeat for the selected rows within your available check allowance. After a lost response, preserve the same request and idempotency value. Keep rejected and unknown results for review.

Start monitoring deliberately

A single-candidate check returns a watch but creates no recurring monitoring. Read its current status: a new watch starts paused, and an existing watch retains its status. To start recurring checks deliberately, confirm the project, URLs and cadence, then use update_link_watch with status: "active". This can make a check due immediately. Follow monitoring changes; do not resume a watch merely because a verification request was replayed.

Verify fifty selected candidates

Check your connected catalog for these commands. Workspace permissions and check allowance still apply.
  1. Select one to fifty stored candidates from the same run, with actual identifiers and optional local references.
  2. Call verify_discovery_candidates with runId, items and an idempotencyKey.
  3. Save the batch identifier and per-item outcomes, including budget rejections. Read get_candidate_verification_batch until the jobs finish.
  4. For a completed present result from the last 24 hours, with no newer observation, monitor_discovery_candidate preserves the candidate’s lineage and local reference. Replay does not reactivate a watch someone later paused.
Admission follows the submitted item order. If check allowance runs out, earlier admitted items keep their reservations and later items retain their quota rejection. Replaying the same batch after allowance changes returns those original decisions; it does not admit rejected items again. A different payload under the same value is refused with IDEMPOTENCY_CONFLICT.Replay a lost batch response with the same payload and idempotency value. A different selection needs a new value. Read availability and troubleshooting before retrying an unavailable operation.

Keep disavow review separate

Disavow review is a separate decision. Adding a candidate does not submit anything to Google.
In the app, use Add for review with a reason when you decide a specific site or page needs disavow review. New items added this way enter Needs review, including items added by an administrator. Repeating an existing proposal can retain its earlier decision.An owner or administrator can approve reviewed items. Approved for export includes them in the downloadable disavow file. Exported records the download; it does not mean the file was uploaded to Google.After uploading through Google’s tool, use Confirm uploaded file with the file downloaded from that tool. User-confirmed upload or Agent-reported upload identifies who supplied the report. AgentLinkOps compares that supplied evidence with the approved list; it does not read Google’s disavow list directly. Counts-only reports cannot establish that file contents match.The proposal, review, export and confirmation references describe the separate operations.