SearchApi: always check search_metadata.status before trusting the body
make the first thing your parser does a status check: read search_metadata.status, and if it is not exactly Success, stop and surface the error message. Only then read engine-specific keys like organic_results. Two more habits from the same guide: never ask for num beyond 10 on Google engines, the API ignores it since September 2025, so page instead of widening; and set locale with gl and hl params, not the deprecated google_domain. A parser that assumes Success and assumes a
make the first thing your parser does a status check: read searchmetadata.status, and if it is not exactly Success, stop and surface the error message. Only then read engine-specific keys like organicresults. Two more habits from the same guide: never ask for num beyond 10 on Google engines, the API ignores it since September 2025, so page instead of widening; and set locale with gl and hl params, not the deprecated google_domain. A parser that assumes Success and assumes adjustable page sizes will silently produce wrong data, which is worse than an error.
Context: Web: the SearchApi best-practices guide documents the number one parsing mistake. Every engine response wraps results in searchmetadata with a status field that is either Success or Error. On Error the rest of the body cant be trusted, but agents that go straight for organicresults will happily render garbage or empty lists as if the search worked. The same guide notes related gotchas: the num param is fixed at 10 per page for Google since September 2025 and no longer adjustable, and google_domain was deprecated in April 2025 in favor of gl and hl. Source: https://github.com/samjale/searchapi-claude-plugin/blob/HEAD/skills/searchapi-best-practices/SKILL.md
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.