Configure and price a Keyword Research run

Start with the question, then choose a mode

Quick and Deep begin with seed phrases. Competitors begins with domains. The distinction changes the source recipe, request count, limits, and evidence you receive. It is not simply a cosmetic speed selector.

Use Quick to map a question before spending on a broader search. Use Deep when the topic and market are already credible enough to justify more source coverage. Use Competitors when rankings from specific domains, or their gaps against the tracked own domain, are the actual research input.

Quick is narrow, but it still combines several sources

For each seed, Quick requests a narrow set of paid related terms. It also queries free autocomplete families for questions, prepositions, modifiers, alphabet variants, comparisons, years, and local language patterns. Up to four seeds drive those autocomplete requests, starting with the original inputs and then eligible positive-volume related candidates.

Surviving autocomplete candidates receive paid metric validation. The seed itself can be retained as source evidence after at least one provider path succeeds. The current result ceiling is 600 candidates. Source yield, deduplication, provider coverage, and filters can leave the run well below the interface's rough 300 to 600 framing.

Deep buys breadth and adaptive exploration

Deep requests broad related terms for every input seed, cost-bounded phrase suggestions per seed, and broader keyword ideas seeded by the originals plus eligible related neighbors. It runs the same autocomplete families as Quick, then can add a second hop from up to four promising seeds and a conditional third hop from up to two seeds when the previous hop produced enough new evidence.

Google-derived candidates receive paid metric validation. The current candidate ceiling is 2,000. It is a storage and presentation boundary, not a promised output. Weak seeds, narrow demand, duplicates, provider omissions, or failed source paths can produce much less.

Competitors turns domain rankings into candidates

The current setup accepts 1 to 20 normalized competitor domains and 250, 500, or 1,000 requested rows per domain. Effective safety policy may lower those values. The ordinary mode asks for ranked keywords per domain. Gap only asks for the intersection logic against a tracked own domain and freezes that own target on the run.

The current setup must fit within the 10,000-row run request ceiling. Candidate preview deduplicates the same keyword and retains the strongest competitor position and domain for that row, while the competitor dossier can preserve rankings for each analyzed domain separately. If at least one domain succeeds, the run may complete with partial evidence. If all domains fail, it fails and the customer charge is released.

Normalize inputs without losing the intended question

Seeds are trimmed, lowercased for identity, deduplicated in first-seen order, and limited by current policy. The present defaults allow up to 100 unique normalized seeds, 200 characters per seed, 500 raw input rows, and 64 KB for the raw request. A list prefill takes the first eligible rows up to the active seed limit and does not remain linked to later list changes.

Competitor domains are normalized by removing schemes, common `www` prefixes, paths, and duplicates. Use domains that answer the same market question. A marketplace, publisher, directory, or international sibling domain may rank widely without being the business competitor you meant to study.

Confirm the exact market pair

The current selector offers Germany in German, Austria in German, Switzerland in German, the United States in English, the United Kingdom in English, France in French, Spain in Spanish, Italy in Italian, and the Netherlands in Dutch. Germany and German is the current default. The interface does not expose a device choice for Keyword Research.

Country and language become part of the stored run and provider request. They do not translate the seeds, repair a mixed-language list, or make metrics from another market comparable. Review spelling, locale, and search intent before approving the quote.

Treat limits as admission controls

A workspace can currently hold at most two pending or running research runs by default, and one user can start at most ten runs per workspace in an hour. Result writes arrive in batches of up to 200 and one run stores at most 10,000 rows under current policy. Plan and safety settings can be stricter than these defaults.

These controls prevent a large setup from becoming an unbounded provider or database job. They do not imply that every admitted request will return the maximum number of candidates. Source-specific limits, provider responses, deduplication, cancellation, and partial completion still shape the result.

Wait for the current quote before starting

Separate quote, reservation, provider spend, and customer charge

The quote can show paid related work, free suggestion request counts, paid metric-validation batches, keyword-idea requests, competitor domains multiplied by their row limit, bundle savings, total, and projected balance after. It is recalculated on the server when you start. A stable client request ID makes an identical retry idempotent and rejects a conflicting setup under the same ID.

The accepted quote is reserved against spendable organization balance. During completion, Crawl Foundry settles actual billable work but caps the customer charge at that reservation. A provider overrun above the quote is absorbed by the platform. A failed or cancelled run releases the reservation and leaves the customer charge at zero, even if some provider spend occurred internally.

Follow the run from dispatch to a terminal state

After admission, local development can dispatch directly while production writes a durable outbox event. The worker has a claim deadline, runs at a bounded concurrency, and claims a five-minute lease that heartbeats extend. The visible stages can move through dispatching, claimed, preflight, source fetch, provider reconciliation, result write, settlement, and finalizing.

The only run statuses are pending, running, completed, failed, and canceled. A person can cancel pending or running work. A watchdog can fail an unclaimed run or one whose lease expired. Partial success is stored as completed with a partial flag and error detail; the current history row does not always surface that partial label prominently, so candidate count, Activity, and error evidence still deserve review.

Check the claim before you approve it

• The research question is narrower than the list of possible inputs.
• Quick, Deep, or Competitors matches the evidence required.
• Seeds or domains are normalized, relevant, and within the current limits.
• Country and language describe the intended search market.
• Gap only has the correct tracked own domain and does not hide useful shared rankings by accident.
• The quote matches the final setup and leaves sufficient spendable balance.
• No equivalent run is already pending, running, or fresh enough in history.