Evaluate a web data vendor on accepted records delivered to your application, not request success or a headline price.
Test the real source mix: static pages, JavaScript-rendered pages, redirects, locale variants, errors, and pages that should be rejected.
Compare discovery, rendering, output fidelity, task recovery, access controls, support, data handling, and cost under one acceptance contract.
Require provenance, versioning, correction, and deletion paths; a page-to-JSON API is not automatically a product-ready dataset.
Nstdata Crawl is a candidate acquisition layer for site discovery, recursive crawling, rendering, multiple outputs, and built-in proxy routing; measure it against your own pilot and source policies.
What Should a Web Data Vendor Actually Deliver?
A web data vendor should deliver the artifact your product can accept within a defined time and policy boundary. For a RAG application, that might be a current document with headings, source URL, and version. For a price-monitoring feature, it might be a correctly identified product variant with currency and evidence. A request count alone does not show whether the user-facing data is correct.
Nstdata Crawl is one candidate to measure against that contract because it returns page content in multiple formats through an API.
Write the acceptance contract before talking to vendors. Specify source groups, target page types, required fields, permitted access method, refresh target, output formats, error handling, and retention. A vendor that excels at one known URL might fail at site discovery; a vendor with strong rendering might still omit a table or produce an error page as Markdown. Nstdata Crawl should be assessed by the same contract as any other candidate.
Experience Nstproxy Crawl - Start Your Free Trial Today
Use a scorecard with fields that can change your selection. Give each criterion a measurable test rather than a marketing adjective.
Criterion
Pilot question
Evidence
Coverage
Did the vendor discover and retrieve the approved URLs?
URL manifest vs returned pages
Rendering and fidelity
Are dynamic fields, tables, code, and links preserved?
Raw/rendered/output comparison
Output contract
Can the product consume the result without guessing its schema?
Validated records and field evidence
Reliability
Can jobs be resumed, polled, and diagnosed?
Task IDs, statuses, terminal errors
Governance
Can data be traced, corrected, and removed?
Provenance and deletion drill
Cost and support
What does one accepted record cost at the required freshness?
Vendor bill, engineering time, support response
The criteria should be weighted by use case. RAG teams may care most about heading and citation fidelity. A commerce product may care most about variant identity and current price. A compliance-sensitive organization may reject a vendor that cannot meet a required data-handling contract regardless of acquisition yield.
How Do You Design a Fair Vendor Pilot?
Method 1: Build the Representative Source Set
Step 1. Select permitted URLs from each source class: static HTML, JavaScript-rendered content, redirects, multiple locales, pagination, and expected failures. Include both easy and difficult templates.
Step 2. Write a gold record for each page: expected title, source URL, fields or document sections, and explicit rejection conditions. A consent wall or challenge page should not count as a successful document.
Step 3. Freeze the test set and acceptance rules before running candidates. Avoid choosing only pages a vendor recommends; that would bias the comparison.
Method 2: Run Every Candidate Against the Same Contract
Step 1. Submit the same URL manifest and request the output format your product needs. Record configuration, timeouts, source scope, and account plan.
Step 2. Validate the returned artifacts with the same parser and quality checks. Keep raw acquisition evidence where policy allows and note the exact cause of rejected records.
Step 3. Measure accepted-record yield, tail latency, freshness lag, duplicate rate, diagnosis time, and total cost. Do not treat a vendor's HTTP 200 as semantic success.
Method 3: Test Operations and Exit
Step 1. Deliberately include a timeout, an invalid page, and a changed template. Ask the team to identify and repair the issue through the vendor's task state and documentation.
Step 2. Remove one accepted record and verify deletion from raw storage, derived tables, caches, and indexes. Check whether the vendor's retention and export behavior fits your policy.
Step 3. Export a sample into a provider-neutral schema and repeat one page with another acquisition method. Record how much application code would need to change if the provider changed.
This pilot is more informative than a vendor feature checklist alone. The Azure RAG design guide treats ingestion, retrieval, and answer evaluation as distinct boundaries; use the same separation when a vendor claims βAI-readyβ data.
What Should You Ask About Formats and Schema?
Ask whether Markdown preserves headings, code blocks, lists, tables, and links; whether HTML is raw or cleaned; whether screenshots and PDF reflect the rendered page; and whether a JSON result is generic page metadata or a domain-specific entity schema. Inspect large-output handling and reference-token expiration if the API returns artifacts by reference. Validate output on the most difficult page, not only a simple article.
For structured data, require field provenance. If a price changes, the product should explain which URL, variant, currency, and observation time produced it. A schema-valid JSON object can still contain a wrong price or duplicated product. Keep your own domain-level validation even when the vendor offers extraction assistance. The website-to-Markdown guide is useful for document fidelity, while the web extraction tools comparison discusses different tool boundaries.
What Should You Ask About Reliability, Security, and Cost?
Ask for documented authentication, task status, retry behavior, concurrency and submission limits, incident communication, support path, data retention, deletion, and billing conditions. Verify each answer against current documentation or contract, not a sales slide. For cost, calculate (vendor charges + proxy or bandwidth charges + engineering + QA + incidents) / accepted records. Refresh frequency and browser-rendering share can materially change that result.
Review source policy separately. A provider may fetch a page successfully without granting you the right to train on, resell, or retain it. The Robots Exclusion Protocol is one technical access signal, not a content license. Nstdata's data compliance statement says customers choose targets and downstream uses and must ensure those uses are allowed.
How Can Nstdata Help as a Web Data Vendor Candidate?
Nstdata Crawl can turn a reviewed seed URL into a bounded set of page artifacts. Its documented product model includes site discovery, recursive crawling, JavaScript rendering, a Crawl API, and multiple outputs. This makes it a candidate when browser and proxy operations are becoming recurring infrastructure work. Your team still owns source permissions, business schema, validation, storage, and the final buying decision.
LLM-ready formats: Markdown can feed RAG and agents; HTML and raw data support custom parsers and replay; links support discovery; screenshots and PDF provide visual evidence. The Crawl docs list these outputs and explain how to read large artifacts by reference. Verify the product page's JSON claim against the exact schema you need.
Built-in proxies: Standard Crawl jobs use managed routing without separate proxy Host, Port, Username, Password, or Protocol fields. That reduces setup in a pilot; compare total cost, including any applicable proxy usage, against accepted-record yield.
Task visibility and limits: Site jobs accept maxDepth, maxPages, include, and exclude rules, and expose status and pages endpoints. Use them to reconcile submitted, completed, failed, and accepted counts.
Step 1. In Dashboard β Crawl Playground, obtain an API key and test a representative approved URL. Define a title/content fixture and a rejection case before submission.
Step 2. Submit a bounded site job with the same scope used for other candidates:
curl--request POST 'https://api.nstdata.io/api/v1/crawl'\--header"x-api-key: ${NSTDATA_API_TOKEN}"\--header'Content-Type: application/json'\--data'{"url":"https://example.com/docs/","formats":["markdown","html"],"maxDepth":2,"maxPages":25,"includeUrls":["*example.com/docs/*"]}'
Step 3. Save the returned job ID, poll GET /api/v1/crawl/status/{crawlId}, and paginate GET /api/v1/crawl/pages/{crawlId}. Apply your gold-record checks and compute cost per accepted record. The code is based on official endpoint and field documentation but needs an account key and a real approved target for execution.
The next decision is practical: shortlist vendors only after the pilot exposes where each one helps or leaves work with your team. For interaction-heavy tasks, Nstdata Cloud Browser is a separate capability to evaluate; for self-managed proxy pools, Proxy Manager addresses a different operations layer. The automated collection guide can help frame recurring job requirements.
How Do You Turn the Pilot Into a Buying Decision?
Give each criterion a weight based on its effect on the product, then record measured evidence and unresolved risks. A vendor that has the lowest request price may lose on accepted yield or correction time; a vendor with excellent rendering may be unsuitable if the required data-handling terms are absent. Document the chosen boundary, pilot URLs, assumptions, and review date. Re-run the scorecard when the source mix, scale, or product use changes.
For an exchangeable export format, the JSON specification defines syntax; correctness of extracted fields still needs domain checks.
