Google Custom Search JSON API 將於 2027 年 1 月 1 日停用：該如何應對

If your app calls https://www.googleapis.com/customsearch/v1, it has a hard deadline. Google closed the Custom Search JSON API to new customers on January 20, 2026, and the API shuts down on January 1, 2027. After that, requests fail.

This post covers the timeline, what your options are, and how to migrate with the smallest possible diff.

Deadline: January 1, 2027. Plan to switch at least two weeks before the deadline, so December change freezes and holidays don't catch you.

The timeline

The partner-only API matters because it was the only hint of an official successor. As of today there is no self-serve official Google web search API you can sign up for after the shutdown.

What breaks on January 1

The shutdown is at the endpoint, so everything that reaches it stops at once:

• Direct HTTP calls to https://www.googleapis.com/customsearch/v1, whatever language or tool sends them.
• Google's client libraries, which call the same endpoint: Python's googleapiclient.discovery.build("customsearch", "v1"), the Node googleapis customsearch client, the Go customsearch/v1 package and their equivalents.
• No-code flows whose HTTP or "Google Custom Search" nodes point at it (n8n, Make, Zapier, Pipedream).
• Plugins and integrations that fetch results as JSON for site search or "related content" features.
• API keys and quotas in Google Cloud: the keys stay, but there is nothing left for them to call.

Plan for the calls to fail, not to slow down: add a timeout and an error path now, so a forgotten caller degrades instead of crashing.

Who is affected

Anything that reads items[] from the CSE JSON API:

• SaaS features that "search the web" behind the scenes (research assistants, fact-checking, content tools).
• Internal tools and scripts, often years old, that nobody remembers owning.
• No-code flows in n8n, Make and Zapier that call the endpoint through an HTTP node.
• Agent tools that wrap CSE because it was the official, cheap option.

Find them with a code search for googleapis.com/customsearch across your repos, and check your Google Cloud console for projects with the Custom Search API enabled.

Your options

1. Drop the feature. Sometimes right for internal scripts. Rarely right for customer-facing features.
2. Move to a different kind of search. AI-native search APIs (Tavily, Exa, Brave) run their own index. Results and response shapes differ, so you rewrite the integration and re-test relevance.
3. Use a SERP API that speaks CSE. You keep the same request and response, and the results are Google's public results page.

We built SerpKite's /customsearch/v1 endpoint for option 3. It accepts key, cx, q, start, num, gl, hl, lr, safe, dateRestrict, siteSearch and searchType=image, and returns kind, searchInformation, items[] and queries.

The migration

Before (Google):

res = requests.get(
    "https://www.googleapis.com/customsearch/v1",
    params={"key": GOOGLE_API_KEY, "cx": CX, "q": query, "start": 1},
)
items = res.json().get("items", [])

After (SerpKite):

res = requests.get(
    "https://api.serpkite.com/customsearch/v1",
    params={"key": SERPKITE_API_KEY, "cx": CX, "q": query, "start": 1},
)
items = res.json().get("items", [])

Two lines: the hostname and the key. Your parsing code doesn't change.

The one real difference: cx is ignored. SerpKite searches the public Google results page, so settings from the Programmable Search console (site lists, promotions, custom ranking) are not applied. If your engine was restricted to your own domains, add siteSearch=example.com or site:a.com OR site:b.com to the query.

A ten-week plan

A checklist before January

• Inventory every caller of the CSE endpoint, including no-code flows.
• Swap the hostname and key. Prefer sending the key as an Authorization: Bearer header so it stays out of URLs and logs.
• Recreate site restrictions with siteSearch or site: operators.
• Update error handling. SerpKite errors look like {"error":{"code","message","request_id"}}. Failed calls (503) are not billed and are safe to retry.
• Run a few dozen real queries through both endpoints and compare items[].link.
• Set a spend cap in the dashboard so a runaway loop can't surprise you.
• Deploy well before the holidays. December 31 is a bad day to find a forgotten cron job.

Cost

Google charged $5 per 1,000 queries after 100 free queries a day, with a cap of 10,000 queries a day. On SerpKite each /customsearch/v1 call is 1 credit, packs run from $1.00 per 1,000 down to $0.60, there's no daily cap, and credits never expire. You get 2,500 free credits on signup and 1,000 a month after that. Details are on the pricing page.

Next steps

• The full parameter mapping and gotchas: Migrate from the Google Custom Search JSON API.
• Paste an existing CSE URL into the CSE migration helper to get the SerpKite equivalent.
• Need more than items[]? The Google Search API returns the knowledge graph, People Also Ask and Markdown output.

Runnable Python and Node.js versions of the migration, with a --check flag that compares response keys: SerpKite/custom-search-api-migration.

Disclosure: I work on SerpKite. This post first appeared on the SerpKite blog.