Collect Google and Bing results with an output record that preserves the engine identity. A shared provider envelope does not make positions or optional features equivalent across engines. Keep each observation’s query, market, time and native response with its normalized output.
Use explicit engine-tagged records
| Field | Rule |
|---|---|
| engine | Google or Bing for the documented SearchCans contract |
| query and market | Store with the requested country and language |
| observed_at | Identify the collection time |
| organic rows | Keep link and observed position |
| optional features | Store observed, absent or unvalidated status |
| raw envelope | Keep the provider response available for review |
Validate each engine independently
Use POST /api/v1/search with t selecting google or bing and s containing the query. Check the business status and data.organic shape for each response. Do not claim support for an engine that is not documented just because a loop can generate its name.
An empty list can be a valid observation. A failed call should retain its failure status instead of becoming an empty success. A result position belongs to its engine and market; do not average Google and Bing positions into one rank.
Compare the downstream requirement
The parser fixtures validate shared envelope handling. They do not establish identical engine coverage, provider availability or a universal answer-quality gain.
- Use a fixed query and market set for both collections.
- Keep missing optional fields visible to the consumer.
- Inspect selected sources separately when an answer needs page evidence.
- Evaluate whether the additional engine adds independent useful evidence under the same budget.
Reference documentation: www.searchcans.com — /google-search-api; www.searchcans.com — /bing-search-api.
