Google Custom Search: Site Search SaaS Review
Do not start a new integration with the Google Custom Search JSON API. Google has closed the API to new
customers, and existing customers must migrate before the service is discontinued on 1 January 2027.
A migration should begin with a precise distinction between the hosted Programmable Search Element and the
JSON API: an application that calls customsearch.googleapis.com has a hard deadline, while an
embedded search element has a different integration and must be assessed against its own current terms.
What the shutdown changes
Google's Custom Search JSON API overview
is the authoritative source for the cutoff and discontinuation date. Inventory API keys, search-engine IDs,
quota dashboards, billing projects, and every client or server that parses the response. Search for fields
such as items, queries.nextPage, searchInformation, and
spelling; they reveal assumptions that a replacement must either preserve or deliberately remove.
Do not model the migration as an endpoint swap. Result URLs, snippets, pagination, safe-search behavior, language controls, image results, and per-domain weighting vary between engines. Capture the contract your product actually uses, including empty-result behavior and error handling, before selecting a successor.
Choose a replacement by corpus boundary
For a bounded set of owned sites, Google's documented alternative is Vertex AI Search; its operational model, pricing, and data processing are different from the retired API. For content you control, a self-managed index such as Elasticsearch, OpenSearch, Typesense, Meilisearch, PostgreSQL full-text search, or SQLite FTS may offer clearer portability and ranking control. For unrestricted web search, there is no guaranteed drop-in Google API replacement, so confirm coverage and redistribution rights before promising parity.
Keep the hosted option separate from programmatic search. The Programmable Search Engine product can render a search interface for configured sites, but it does not give an application the same ownership of result data or presentation that a JSON response does.
Run a measured cutover
Build a versioned query set from real, privacy-reviewed search logs: common navigational queries, rare terms, spelling errors, multilingual queries, and known zero-result cases. Run old and new systems side by side. Compare result coverage, normalized discounted cumulative gain or a simpler judged top-three relevance score, p50/p95 latency, error rate, and cost per thousand queries. Record human judgments; click-through rate alone can reward prominent but wrong results.
Put the provider behind a small application-owned response model rather than exposing vendor JSON throughout the UI. Add a kill switch, bounded timeouts, cached fallback results for high-value queries, and quota alarms. Move traffic gradually, then revoke the old key and delete obsolete parsing code only after the replacement has survived production load.
Failure modes to test before the deadline
The common failures are starting too late, assuming identical ranking, leaking queries that contain personal data, and discovering during cutover that a provider cannot index authenticated or JavaScript-rendered content. Also test quota exhaustion, provider errors, stale documents, deleted-page removal, and regional data-processing requirements. A successful migration is one in which users still find the right page and the organization can change providers again without rewriting its product.
Published · Updated