Google Search API Alternatives After Custom Search JSON API

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: September 10, 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.

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:

1. Select a small group of non-sensitive queries that represent the application.
2. Run the same country, language, and result-depth settings for every candidate where those settings exist.
3. Save the response shape and the fields the downstream code reads.
4. Include an empty or unusual query to observe the error and no-result behavior.
5. 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.

Run one Google result request

In a Bash-compatible shell, replace YOUR_API_KEY with your own key. This request uses the fields in the current SERPpost docs. It saves the response body to google-search-response.json and prints the HTTP status. Keep your key and response files private.

export SERPPOST_API_KEY="YOUR_API_KEY"

curl --silent --show-error --max-time 35 \
  --request POST 'https://serppost.com/api/v1/search' \
  --header "Authorization: Bearer $SERPPOST_API_KEY" \
  --header 'Content-Type: application/json' \
  --output google-search-response.json \
  --write-out 'HTTP %{http_code}\n' \
  --data '{
    "s": "web to markdown api",
    "t": "google",
    "p": 1,
    "d": 20000,
    "country": "us",
    "language": "en",
    "maxCache": 0
  }'

If curl reports a connection or timeout error, do not treat a response file left from an earlier run as a new result. Otherwise, check the printed HTTP status and open the saved JSON. Check code and msg before reading data. The current docs use code: 0 for success. For Google Search, inspect data.organic and verify the fields your application needs in the actual returned entries. An empty result set needs an explicit application decision; it is not evidence that the query has no demand.

This is a separate integration test, not a drop-in replacement for a Custom Search JSON API request or response parser. Review the stored result and map its fields explicitly before changing an existing application. The command was checked against the source and tested with a local fixture on September 10, 2026; it is not a published production result.

Fill in a small acceptance record

The table below is a test template, not a result from a live API call. Replace the pending entries with what your own request returns. Use non-sensitive queries that reflect your application.

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.