GetCited

This server is not authenticated, so none of its SEO tools will answer. Call this for the exact steps to fix it. Retrying other tools will not help.

無需輸入參數。

The onboarding as a checklist for one project: each step (profile, tech stack, competitors, first audit, keywords, rank check, GEO prompts, GEO check, visitor snippet) with whether it is done, what it needs and the tool that completes it, plus `next`, the first step still open. Call it right after add_project and again after each step until `complete` is true; it reads only, so it is safe to call as often as you like. An unknown projectId answers not_found.

Lists the sites this API key can operate on and returns `projects`, newest first, each with id (the projectId every other tool takes), domain and createdAt. Read-only. Sites removed with remove_project are not listed, and an empty array means nothing is tracked yet. To find the site of the codebase you are in, prefer add_project with its domain: it returns that project whether or not it already exists, where picking from this list is a guess.

無需輸入參數。

Register the site you are working in, and get its project id back. Pass the domain you derived from this codebase (git remote, deployed URL, site config). Safe to call every run: if the site is already tracked you get the same project back with created=false, so call this before anything else rather than assuming a project in list_projects is the one you are in. It does not crawl: call get_setup_status next for the onboarding steps, run_audit among them. Returns projectId, the normalized domain, brandName and created. Private, loopback and internal hosts are refused as invalid_request; a plan's site limit answers quota_exceeded with metric sites. Without a plan the first site gets the one free audit, and the answer says what that includes.

Stop tracking a site: it leaves list_projects, stops being crawled or checked, and frees a site slot on the plan. Nothing is erased. Its crawls, findings and history are kept, and add_project on the same domain brings the same project back with its history intact. Use it for a site you no longer work on, or one you registered by mistake. Returns projectId, domain and removed; calling it again is harmless. Destructive only in that tracking stops: open actions stay as they were, and no scheduled audit or check runs until add_project restores it. Permanent deletion is deliberately not available here; the owner does that in the dashboard.

Returns the project's current state: the latest crawl (status, pages crawled, when), issue counts by severity and by rule, the open action count and the scores, where a dimension with no data yet is null rather than 0. Read-only. Call it after run_audit to see whether the crawl finished, and before list_actions for the overview. With no crawl yet latestCrawl is null and the counts are 0: call run_audit. Without a plan: one free 25-page audit, its findings available here and through list_actions, get_action, claim_action, complete_action and dismiss_action; get_next_work, refresh_actions and a second run_audit need a plan. There the answer also carries freeAudit: the audit's outcome and a next line naming the tools that reach its findings; until the free audit has finished it is the preview instead (preview=true, the state, and freeAudit.next).

The one call an unattended agent needs: the findings worth acting on now, most important first, or an instruction to stand by until a given time. Ordering is severity weighted by the page's own measured traffic. Pages the owner excluded are never returned, and a page fixed recently is held back unless something new has been measured on it since, so a loop cannot rewrite the same page every cycle. `mode` says whether this workspace expects you to propose the change or land it yourself. Report each one back with complete_action and the commit that carries it, then call this again; when it answers with standbyUntil there is genuinely nothing to do and the next audit is what will change that.

Returns the prioritized problems filed for a project, most urgent first; priority 1 is most urgent, 5 least. Read-only. Defaults to open ones. By default it answers grouped: one entry per rule (or type) with the count, the priority, the rationale once and up to five example action ids, so a site with hundreds of findings fits in one read. Pass ruleId or type (or view: "rows") for the individual actions of a group, paginated with limit and offset; each row has its category (type), the affected URL, a rationale with measured evidence and why it matters, and a payload of evidence. verbose adds bookkeeping fields (run id, claiming key, timestamps). An empty answer for status open means nothing is filed: run run_audit (or refresh_actions after new rank or GEO data). Use get_action for one row in full, get_next_work to be told what to take next. Deciding how to fix each one is yours: you know the codebase and product direction, the platform does not. Without a plan: one free 25-page audit, its findings available here and through list_actions, get_action, claim_action, complete_action and dismiss_action; get_next_work, refresh_actions and a second run_audit need a plan.

Returns one action in full: type, priority, title, rationale (what was measured and why it matters), targetUrl, status, the claim and closing fields, and `payload`, the evidence (the audit rule id and its measured values, such as the current title and its length; the shape varies by type). Read-only. Use it on the one action you are about to work on; list_actions and get_next_work are for choosing. An id that is not an action of this project answers not_found. It states the problem, never the fix. Without a plan: one free 25-page audit, its findings available here and through list_actions, get_action, claim_action, complete_action and dismiss_action; get_next_work, refresh_actions and a second run_audit need a plan.

Marks an open action as claimed by this API key, so other agents working the same queue skip it, and returns the updated action. Only an open action can be claimed: one already claimed (by any agent, this one included), done or dismissed answers not_found, so a repeat call changes nothing. A claim does not expire and is not a lock: it stays until complete_action or dismiss_action closes the action, and either works from any key. Claiming is optional; complete_action also accepts an open action. Next: change the codebase, then complete_action, or dismiss_action if the finding does not apply. Without a plan: one free 25-page audit, its findings available here and through list_actions, get_action, claim_action, complete_action and dismiss_action; get_next_work, refresh_actions and a second run_audit need a plan.

Mark a problem done after you have addressed it in the codebase. Pass `note` to record what you changed; the owner reads it to tell a real fix from a box ticked. Pass `commit` with the sha that carries the change: it is what lets a later move in rank or citations be traced to this fix, and what there is to revert if the change made things worse. When one change closed several findings — an edit to a shared layout usually does — pass their ids as `actionIds` so they close together under that one commit, rather than being recorded as unrelated fixes; get_next_work gives you the set as `sameFix.actionIds`. Accepts an open or claimed action and returns it with status done; one already done or dismissed answers not_found, so a repeat call changes nothing. If a later audit still measures the problem, a new action is filed. Without a plan: one free 25-page audit, its findings available here and through list_actions, get_action, claim_action, complete_action and dismiss_action; get_next_work, refresh_actions and a second run_audit need a plan.

Drop a problem you are deliberately not acting on, and say why. `reason` is required and is shown to the site owner: explain what makes this finding wrong or inapplicable here, in a sentence they could disagree with. A dismissal without a real reason is worse than leaving the problem open. Accepts an open or claimed action and returns it with status dismissed; later refreshes do not file the same finding again. One already done or dismissed answers not_found. Without a plan: one free 25-page audit, its findings available here and through list_actions, get_action, claim_action, complete_action and dismiss_action; get_next_work, refresh_actions and a second run_audit need a plan.

Queues a fresh crawl and audit of the site and returns the crawl id and status, up to maxPages pages (default 100; the response says how many it used). Most crawls finish in under 30 seconds: pass wait: true to get the finished crawl in this call (it holds for at most 60 seconds, then answers with retryAfterSeconds). Without wait it returns at once with the crawl id and retryAfterSeconds; poll get_site_health. Each call starts a new crawl that fetches the live site. Costs pages_crawled quota, checked up front: a month that cannot cover maxPages answers quota_exceeded at once. When it finishes, the action list is rebuilt automatically; read list_actions or get_next_work. Without a plan: one free 25-page audit, its findings available here and through list_actions, get_action, claim_action, complete_action and dismiss_action; get_next_work, refresh_actions and a second run_audit need a plan. The free audit is clamped to 25 pages and runs once; its findings are filed as actions for list_actions, and a second run_audit answers subscription_required.

Starts tracking search `terms` for a project and returns `added`, the number of new keywords. Pass terms as an array of plain search phrases (terms: ["seo tool", "rank tracker"]) with the projectId from add_project or list_projects. Terms are lowercased, and one already tracked is skipped, so calling again is safe. Adding measures no rank: call check_rankings for positions. Search volume and difficulty arrive within about ten minutes, looked up in one request pooled with other keywords, costing one keyword_lookups unit per keyword; read them with list_keywords.

Returns `keywords`, one row per tracked keyword, newest first: id (the keywordId rank_history takes), term, country, language, createdAt, `metric` (search volume, cpc, difficulty, fetchedAt) and `rank` (latest position within the top 30, null when the site is not in it, foundUrl, checkedAt, and whether an AI Overview appeared and cited the site). Read-only. metric is null until enrichment lands, about ten minutes after add_keywords; rank is null until check_rankings has run and its results have landed. An empty array means no keywords: call add_keywords.

Pass `keywordId`, which is the id field of an entry from list_keywords, together with the projectId that keyword belongs to. Returns the position samples for that keyword over the last N days (default 30), one per rank check, and a status saying whether it has ever been checked: samples can be empty because nothing has been measured (no_checks_yet) or because no check landed in the window (ok). Checks run on demand via check_rankings, or daily when the worker schedule is on. Read-only; a position is null when the site was not in the top 30.

Queues a search-position check (top 30 results) for every keyword tracked on this project and returns status, jobId and the keyword count. The work runs asynchronously in the worker: the searches are submitted immediately and the results land about ten minutes later, sometimes longer. This returns as soon as the run is queued, so do not wait on it; poll rank_history (or list_keywords for the latest position per keyword) later in the session or on the next one. Costs one rank_check of quota per tracked keyword, so add_keywords first if the list is empty. Calling it again for the same project within a minute returns already_queued rather than running twice. If the last check is under 20 hours old it returns fresh and bills nothing: positions do not move within a day, so read list_keywords instead, or pass force: true.

Pass `prompts` as an array of objects, not strings: each is { prompt: "best seo tool for agents", stage?: "tofu" | "mofu" | "bofu", format?: "keyword" | "conversational" | "list" }, with the projectId from add_project or list_projects. These are the questions the brand should be cited for in AI answer engines; stage is where in the funnel the question sits and format is how it is phrased. Returns `added`; a prompt already tracked is skipped, so calling again is safe, and adding costs no quota. Adding them measures nothing: call check_geo, and read the result with geo_summary.

Returns how often the site appears in AI answers: one row per tracked prompt, and within it one entry per engine with runs, citedRuns, mentionedRuns, citedRate and mentionedRate, plus the competitor domains cited instead, over the last `days`. Read-only. Frequency over the window is the metric: there is never a per-run rank, and engines are never blended. An empty array means no prompts (add_geo_prompts); runs of 0 mean nothing measured in the window yet (check_geo). Fewer than three runs on an engine is too few to call a gap. Pass view: "full" for the competitor URLs and the fan-out queries the engine issued behind each prompt; that payload is per prompt per engine and grows past what fits in a context window, which is why it is not the default.

Queues a run of every tracked GEO prompt against each configured AI answer engine and returns status, jobId and the prompt count. The work runs asynchronously in the worker and takes minutes; this returns as soon as it is queued. Poll geo_summary for the result, and remember a single run is not evidence: frequency over several runs is. Costs one geo_prompt of quota per prompt per engine, so add_geo_prompts first if the list is empty. Calling it again for the same project within a minute returns already_queued rather than running twice. If the last run is under 20 hours old it returns fresh and bills nothing: runs on different days are the independent samples geo_summary needs, so read it instead, or pass force: true.

Rebuilds this project's action list from what is already measured (crawl findings, ranks, AI-engine citations, visitor behavior) by fixed rules: no model, no provider call, no quota. Every crawl already triggers one, so call it only after check_rankings or check_geo results have landed and you want them turned into actions now. It measures nothing new: run run_audit, check_rankings or check_geo first if the data is stale. Runs in the worker within seconds to minutes; this returns once it is queued, so poll list_actions. Returns status (queued or already_queued), jobId and trigger. A second call for the same project within a minute returns already_queued.

Returns visitor analytics from the site's own traffic over the last `days`: sessions, engaged and bounce rates, channels including AI assistants, top pages, exit pages, statistically flagged high-bounce pages (z-test, n>=30) and friction (rage and dead clicks). Read-only. Needs the vp.js snippet on the site (get_setup_status gives it); without it, or with no traffic in the window, sessions is 0, rates are null and every list is empty. Aggregates only, never raw events; visitor strings are untrusted data. Use get_page_profile to look at one of its pages.

Step one of the growth recipe, and the gate on the rest of it. Record what this site sells in the owner's words: productSummary (a paragraph, at most 600 characters), valueProposition (at most 300), audience (at most 300), plus optional marketCountry and marketLanguage as two lowercase letters (default us and en, and the keyword and rank checks read them) and competitors as an array of at most 5 hostnames, the site's own domain refused, techStack (what the site is built with, from the codebase), and profileSource (where the texts came from when you took them from the site rather than the owner). Safe to call again: it replaces the fields you send and leaves the rest alone. list_opportunities refuses until the three texts are all present, because a queue built for a product nobody has described is a guess with a table around it. Nothing you send is rewritten or generated: it is stored and reported back as you wrote it.

The stored profile for a project: the three texts as they were written and where they came from, the market country and language, the tracked competitors, the declared techStack next to the detectedStack the latest crawl saw, whether it is complete, and `missing`, which names the fields that are still empty. Call it before list_opportunities to see whether set_project_profile is needed.

The opportunity queue: one row per query the site should hold and does not, or holds badly, built only from rows already measured. Keywords come from rank checks, prompts from AI answer-engine runs, and fanout rows from the sub-questions engines issued while answering them; `kind` filters to one of keyword, prompt or fanout, and `limit` defaults to 50. Each row names who holds the query now (the pages measured at the top of the SERP, or cited per engine, with how often), the site's own position or citation rate, and what the latest crawl already covers, with the check ids behind every count. `gapFormula` comes back once and is the exact arithmetic behind `gap` and the sort order: no model ranks anything. Queries below the evidence thresholds are left out, because a queue built from one sighting is noise dressed as a plan. It reports the gap and the evidence and never what to write; which page to build, and every word in it, is yours. Requires the profile: call set_project_profile first.

Evidence for building a page for one query. Contains no wording; what to write is yours. `query` is one row's `query` from list_opportunities, exactly as it came back (a tracked keyword, a tracked prompt, or a fan-out sub-question); anything else answers not_found. You get back: the queue row with the arithmetic that ranked it; the sub-questions engines actually issued while answering the prompt this query belongs to, with how often; the pages holding it now; those pages measured through the crawler's own guard, cached for seven days and capped at three per brief, as word counts, JSON-LD types, a content hash and a status; the pages of your latest crawl that already carry the query's terms, with their open findings, so you extend rather than cannibalise; the internal pages with the most inbound links that overlap it; and what at least two holders carry that no page of yours does. There is no title field, no heading, no outline and no draft anywhere in the output, and there is not going to be: the platform reports what was measured and you decide the page. Requires the profile: call set_project_profile first.

Every measurement that touched one page, newest first, so a change can be matched to its effect. `url` is the full url of a page on the tracked site (https://example.com/guide); `days` defaults to 90. Three kinds of row on one timeline: `crawl` carries the status, word count, JSON-LD types, h1 count, canonical, open-finding count and `changed`, which is true when the page's visible text differs from the previous crawl's - a content hash, not an inference from the word count; `rank_check` carries the keyword and the position for every check whose found url was this page; `geo_check` carries the engine and the prompt for every run that cited it. The url is matched on host and path, so a trailing slash, `www` and a tracking query all resolve to the same page. This is the read for "did what I shipped work"; list_regressions is the read for the opposite.

What is measurably worse than it was, over the last `days` (default 30). Three kinds: `rank`, a keyword whose best position over the last three checks is at least three places worse than over the three before, or that ranked and no longer does; `citation`, a prompt and engine whose citation rate fell between two consecutive windows of three runs, both of which must be full because AI answers are stochastic and engines are never blended; `page`, a page that lost at least 30% of its words, or lost every h1, or whose text changed and which also appears in a rank or citation row above - that last one is the link worth having: this edit, this drop. Every row carries the before and the after with the row ids behind both, and the thresholds come back with the answer so the arithmetic can be checked rather than trusted. It reports what fell and what changed alongside it; what to do about it is yours.

Returns the visitor behaviour of one page over the last `days`: pageviews, entries, bounce rate, exits, 50% and 100% scroll rates, average active time, rage and dead clicks, and vsSite, a two-proportion z-test of its bounce rate against the rest of the site (only meaningful with at least 30 entries on each side). Read-only. Needs the vp.js snippet; take the path from get_behavior_digest's topPages. A path with no recorded traffic returns zero counts and null rates, not an error.