New integrations should not assume that Google Custom Search JSON API is available. Google says the API is closed to new customers, and existing customers have until January 1, 2027 to move to another solution. Start by separating two jobs that often get mixed together: searching a known site collection and retrieving broader web-search results. Then test the result shape, limits, and current terms that apply to the path you actually need.
Last reviewed: August 25, 2026. Google’s product availability and provider terms can change, so use the linked documentation before committing application traffic.
What changed with Custom Search JSON API
Google’s Custom Search JSON API overview says that the API is closed to new customers. It also says that existing customers have until January 1, 2027 to transition. That date is the reason to revisit an old integration plan now, not a reason to pick the first service in a comparison list.
The same page describes the JSON API as a way to retrieve web and image results from a configured Programmable Search Engine. Google points teams that need site search across up to 50 domains toward Vertex AI Search. For a full-web-search requirement, the page provides a separate contact path. Those are different use cases, so they should not be scored with one generic “Google Search API alternative” checklist.
Start with the search scope
Google’s Programmable Search Engine overview describes two familiar patterns: search a single website, or search a selected collection of sites. That is a useful starting point for any migration discussion.
If the application needs results from a known documentation set, support center, marketplace, or group of domains, define that collection first. If the requirement is broader web discovery, state that clearly before comparing providers. A service that fits one boundary can be a poor fit for the other, even when both return JSON.
| Requirement | Question to settle | Evidence to collect before choosing |
|---|---|---|
| Site or collection search | Is the content limited to domains your team can name and maintain? | Domain list, update frequency, language and country needs, and the search controls the application needs. |
| Broader web search | Does the application need results beyond a fixed collection of sites? | Representative queries, desired result types, locations, languages, and the response fields the application consumes. |
| Existing JSON API migration | Is there an existing Custom Search JSON API implementation to replace before January 1, 2027? | Current request volume, configured search engine scope, expected response fields, and the parts of the application that display or store results. |
| New integration | Is the request for site search, web discovery, or both? | A written acceptance test before choosing an API or copying an old example. |
Build an evaluation from real queries
An API comparison becomes useful once it uses the same requests your application will make. A provider’s headline page cannot tell you whether it returns the fields your parser expects or whether its documented limits fit a busy hour.
Use a small, representative set of queries. Include the countries and languages your users need, plus a query that has an ambiguous intent or an expected empty result. Record the response fields that matter to the next step, such as result URLs, titles, snippets, images, or pagination. Keep the raw result examples out of production documentation if they contain user or customer data.
For each candidate, confirm the current terms for the exact endpoint and result type. Check how the provider documents request limits, billing units, errors, retries, and any configuration required for the input scope. Do not convert a price or limit from a blog post into a planning assumption when the official documentation says something else.
Test the application, not a marketing example
Write the acceptance test before you choose a service. It should say what a successful response contains, how the application handles an empty result or error, and how you will validate a change in the result fields. That turns the evaluation into an engineering decision instead of a list of labels such as “fast,” “scalable,” or “best.”
A simple trial can follow this sequence:
- Select a small group of non-sensitive queries that represent the application.
- Run the same country, language, and result-depth settings for every candidate where those settings exist.
- Save the response shape and the fields the downstream code reads.
- Include an empty or unusual query to observe the error and no-result behavior.
- Check current account limits and billing terms only after the technical response meets the acceptance test.
The trial has limits. It cannot predict every future result, cost, or service condition. It does give the team evidence for the requests it plans to send.
Keep migration and provider selection separate
Google’s new-customer status is a product-availability fact. It does not mean that every existing Custom Search JSON API workflow should be rebuilt in the same way. A site-search implementation and a broader web-search integration have different input scope, output expectations, and operational questions.
This article also does not rank API providers or quote their pricing. Those claims go stale quickly and often compare different units. Once the team knows the search scope and trial requirements, it can read current provider documentation and ask targeted questions about the specific endpoint it plans to use.
A separate SERPpost test path
SERPpost is not presented here as a Google-prescribed migration. If you want to evaluate a separate result-API workflow, read the current SERPpost documentation and create an account that returns to the Playground. Run a representative query there and keep that result separate from the Google product-status decision.
FAQ
Can a new customer start using Custom Search JSON API?
Google’s Custom Search JSON API overview says it is closed to new customers. Read the current page before you plan a new integration because Google can change its product availability or guidance.
How long do existing customers have to transition?
Google says existing Custom Search JSON API customers have until January 1, 2027 to transition to an alternative solution. The date applies to the Google product statement on the linked official page, not to any other provider’s contract or plan.
Is a site-search requirement the same as a web-search requirement?
No. Google’s Programmable Search Engine documentation distinguishes searching a website or collection of sites from a wider requirement. Define the target content before comparing APIs, because the right acceptance test depends on that boundary.
Should I choose an alternative from a “best API” list?
Use a list only to discover candidates. The decision should come from a representative query set, the fields the application needs, documented limits and terms, and an acceptance test that covers errors as well as successful results.