Why SearXNG's Google Engine Returns No Results (and 3 Ways to Fix It)

You run SearXNG on a VPS. Everything worked for weeks, and then Google results stopped appearing. Other engines still answer, the page shows no obvious error, and restarting the container fixes it for a few minutes at most.

This is one of the most common SearXNG problems, and the cause is usually not a bug in your setup. This guide explains what is going on, the free fixes to try first, and two options if those aren't enough.

Symptoms

• Searches return results from Bing, DuckDuckGo or others, but none from Google.
• Selecting only Google (!go) returns an empty page.
• The engine statistics list Google errors such as CAPTCHA or access denied, or Google shows as suspended.
• It happens far more often on datacenter, VPS or VPN IPs than on a home connection.

Why it happens

Google redirects automated traffic to a CAPTCHA page

When Google decides traffic looks automated, it answers with a redirect to its /sorry/ CAPTCHA page instead of results. SearXNG cannot solve that page, so the request produces nothing usable.

For a while, some of these blocks weren't even detected as CAPTCHAs. That's why "no results, no error" was a common report. SearXNG issue #5286 ("Google no longer yields any results") traced one case to a bot-detection challenge being returned instead of the results page. In May 2026, PR #5922 improved CAPTCHA detection for the Google engines. It now catches HTTP 302 redirects to /sorry/index and short pages that link to /sorry/, and the fix applies to Google web, images, news and videos. If you run an older version, your instance may still be failing silently.

A detected CAPTCHA suspends the engine — for a day by default

Once SearXNG does recognize the CAPTCHA, it suspends the engine. The search settings set these defaults, in seconds:

search:
  suspended_times:
    SearxEngineAccessDenied: 86400      # 24 hours
    SearxEngineCaptcha: 86400           # 24 hours
    SearxEngineTooManyRequests: 3600    # 1 hour
    recaptcha_SearxEngineCaptcha: 604800  # 7 days

A single CAPTCHA therefore takes Google out for 24 hours, and a reCAPTCHA for a week. During that time Google is skipped entirely, so the results look "broken" even after Google would have answered again.

Datacenter IPs have a poor reputation

The root cause behind both is the IP your instance sends requests from. Cloud and VPS address ranges carry far more automated traffic than residential ones, so Google challenges them much sooner. A shared VPN exit has the same problem. That's why the same configuration can work at home and fail on a server.

Fix 1: free changes to try first

1. Update SearXNG. Newer versions include the improved Google CAPTCHA detection, so at least you'll see the real error instead of silent empty results.
2. Check the engine errors. Use the engine statistics page on your instance to confirm the failure is a CAPTCHA or access-denied error, not a timeout or parsing problem.
3. Tune the suspension time. If your instance rotates its outgoing IPs, a long suspension only hurts you. The SearXNG maintainers note that such instances can set suspended_times.SearxEngineCaptcha to 0. On a single fixed IP, though, disabling the suspension usually just means hitting the CAPTCHA again and again.
4. Lean on other engines. Keep Bing, DuckDuckGo and others enabled so searches still return something while Google is suspended.

If Google keeps failing after this, the problem is the IP itself. You can change the IP, or stop running the search backend yourself.

Fix 2: keep self-hosting, change the exit IP

SearXNG can send engine traffic through proxies. Set them for all engines under `outgoing`. With more than one proxy, requests are distributed round-robin:

outgoing:
  proxies:
    all://:
      - http://USERNAME:PASSWORD@HOST:PORT

Or set them for the Google engine only, under its entry in engines (engine settings):

engines:
  - name: google
    # ...keep the existing settings for this engine
    proxies:
      http:
        - http://USERNAME:PASSWORD@HOST:PORT
      https:
        - http://USERNAME:PASSWORD@HOST:PORT

Residential and ISP addresses are generally treated better than datacenter ranges. Search1API sells two kinds of proxies, both with username/password authentication over HTTP or SOCKS5 (use socks5h:// so DNS resolves through the proxy):

• [Rotating residential](https://s1.dev/proxies/rotating-residential): one gateway that sends traffic through residential IPs worldwide, billed by traffic (GB). It can give a new IP per request or keep one IP for a sticky session. If you rotate on every request, a shorter SearxEngineCaptcha suspension makes sense.
• [Static ISP](https://s1.dev/proxies/static-isp): one fixed IP for the whole order. This is a better fit if you want a stable identity rather than constant rotation.

A better IP lowers the chance of a CAPTCHA, but it can't guarantee Google never challenges you. Keep request volume reasonable. For background on how the two proxy types differ, see What Is a Rotating Residential Proxy.

Fix 3: keep your client, drop the instance

Many people run SearXNG only as a search backend for another tool: Open WebUI, Perplexica, gpt-researcher, or a LangChain agent. If that's you, you may not need an instance at all.

Search1API answers SearXNG's JSON search API. Replace your instance address with:

https://api.search1api.com/compat/searxng/YOUR_API_KEY

Examples:

# Open WebUI
SEARXNG_QUERY_URL="https://api.search1api.com/compat/searxng/YOUR_API_KEY/search?q=<query>"

# Perplexica
SEARXNG_API_URL="https://api.search1api.com/compat/searxng/YOUR_API_KEY"

# gpt-researcher
RETRIEVER=searx
SEARX_URL="https://api.search1api.com/compat/searxng/YOUR_API_KEY"

from langchain_community.utilities import SearxSearchWrapper

search = SearxSearchWrapper(
    searx_host="https://api.search1api.com/compat/searxng/YOUR_API_KEY"
)
results = search.results("hono cloudflare workers", num_results=5)

Your client keeps sending engines=google, bangs like !go, categories, time_range and pageno, and keeps reading SearXNG-shaped JSON. Results from several engines are merged and scored with SearXNG's formula, so clients that sort by score keep working.

To be clear about what this is: protocol compatibility, not a hosted SearXNG instance. The differences:

• The key is in the URL, because SearXNG clients can't send an auth header. Treat the whole URL as a secret, and create a dedicated key for it so you can revoke it on its own.
• Engines are a fixed list, including Google, Bing, DuckDuckGo, Yahoo, Yandex, Baidu, Wikipedia, YouTube, GitHub, arXiv, Reddit and several news and image engines. Others come back in unresponsive_engines as engine not supported.
• Some fields stay empty: number_of_results is always 0, and answers, corrections, infoboxes and suggestions are always empty.
• It isn't free: each engine searched costs 1 credit. A request without engines searches one default engine per category. Engines that can't serve the requested page are not charged.
• There's no web UI, and options like safesearch and theme are ignored.

See the SearXNG compatibility reference for the full engine and parameter list.

Which fix fits you

FAQ

Is SearXNG dead?

No. The project is actively maintained, and the May 2026 CAPTCHA-detection fix is one example. Its Google engine is fragile because it scrapes Google from your IP, and Google decides how much of that it tolerates.

Should I set `SearxEngineCaptcha: 0`?

Only if your outgoing IP changes between requests, for example with rotating proxies. On a single fixed IP, it usually means hitting the CAPTCHA repeatedly.

Will a VPN fix it?

Sometimes briefly. Shared VPN exits carry a lot of automated traffic and get challenged too.

Is the compatible endpoint a hosted SearXNG?

No. It answers SearXNG's JSON API with Search1API's own engines, so SearXNG clients work without changes. It doesn't run SearXNG or its full engine list.

Get started

Sign up at app.s1.dev for 100 free credits with no card required. Then try the SearXNG-compatible endpoint, or set up a proxy for your own instance.