{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreia2as5fisfagngkz4iqwqgvq2mq2zsfzgrwkmycyq6wkthjd3ezhq",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mh5iufroq472"
  },
  "path": "/t/using-openwebui-gema-3-1b-model-will-not-search-web/174291#post_2",
  "publishedAt": "2026-03-16T00:12:47.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "Open WebUI",
    "GitHub",
    "Google for Developers",
    "Google Cloud Documentation",
    "Google Help",
    "google.com"
  ],
  "textContent": "There seems to be a failure mode specific to OpenWebUI + Gemma 3 1B.\n\n* * *\n\nYou are probably **not** missing one tiny checkbox. The more likely explanation is that **OpenWebUI web search is failing in the middle of its pipeline** , and **Gemma 3 1B** makes that much more likely. OpenWebUI’s current docs split web search into multiple layers: provider setup, query generation or tool use, model capability flags, content fetching, and final answer generation. They also say small local models often struggle with Native mode tool use, while Google’s own Gemma docs recommend **Gemma 3 12B or 27B** for function-calling performance, not 1B. (Open WebUI)\n\n## What is probably happening in your case\n\nWhen OpenWebUI cannot complete the search path cleanly, it often falls back to answering from the model’s built-in knowledge. That matches what you described. There are multiple similar OpenWebUI reports with symptoms like **“No search query generated”** , query-generation failures, or Google PSE errors that end with stale or generic answers instead of live results. (GitHub)\n\nFor **Gemma 3 1B** specifically, there are two different failure modes depending on how you configured OpenWebUI:\n\n### 1. If you are using **Default mode**\n\nOpenWebUI says the `TASK_MODEL` is used for tasks such as **web search query generation**. By default, that often ends up being the same model you are chatting with unless you explicitly set something stronger. So if you are chatting with **Gemma 3 1B** , OpenWebUI may also be asking that 1B model to generate the search query that drives the whole web search flow. That is a weak point. (Open WebUI)\n\n### 2. If you are using **Native mode**\n\nOpenWebUI injects `search_web` and `fetch_url` tools into the model, but its own docs warn that **small local models under 30B often struggle with Native mode**. The stated failure modes include malformed tool output, poor tool choices, and unreliable multi-step behavior. OpenWebUI explicitly says **Default mode is usually more reliable** for small local models. (Open WebUI)\n\nThat is why your setup can look correct in the admin panel and still behave like “search does not work.”\n\n## Why Google PSE may also be part of the problem\n\nYour Google setup may still be wrong even if it looks right.\n\nGoogle’s official docs say the Custom Search JSON API requires:\n\n  * a configured Programmable Search Engine\n  * an API key\n  * the engine ID `cx`, which is found in the engine’s **Basic** section. (Google for Developers)\n\n\n\nGoogle also says:\n\n  * the API is **closed to new customers**\n  * existing customers have until **January 1, 2027** to transition\n  * there are **100 free queries/day** before paid usage. (Google for Developers)\n\n\n\nSo Google PSE is still usable for eligible existing customers, but in 2026 it is not the most forgiving or future-proof provider.\n\nThere are also direct OpenWebUI bug reports showing **Google PSE returning`400 INVALID_ARGUMENT`** from the Google endpoint even when users thought they had configured it correctly. That is a real, documented failure pattern. (GitHub)\n\n## A common Google-specific mistake\n\nThe API key may be restricted for the **wrong kind of client**.\n\nGoogle’s API key docs say restrictions can be set by:\n\n  * HTTP referrer for browser keys\n  * server IP for backend/server keys. (Google Cloud Documentation)\n\n\n\nOpenWebUI calls Google PSE from the **backend** , not from your browser tab. So a key restricted like a browser key can fail when OpenWebUI uses it server-side. That is one of the first Google-side things I would suspect.\n\n## Another common mistake: the engine itself is not set up the way you expect\n\nGoogle’s help docs say:\n\n  * you can still use a Programmable Search Engine configured to **search the entire web**\n  * but **no new creation is supported**\n  * and even then, results can differ from normal Google Search because PSE emphasizes your configured sites and may use only a **subset** of Google Web Search results. (Google Help)\n\n\n\nSo even a “working” Google PSE setup does **not** behave exactly like google.com.\n\nAlso, Google’s help says the “Search the entire web” setting is managed in the control panel under the engine’s settings, and once toggled off on an existing engine it cannot be toggled back on. (Google Help)\n\n## OpenWebUI setting traps that matter a lot\n\nIn current OpenWebUI builds, Native mode requires more than just “Web Search enabled.”\n\nThe docs say that in **Native mode** you need:\n\n  1. global web search configured\n  2. the model’s **Web Search capability** enabled\n  3. **Web Search** enabled under the model’s **Default Features** or toggled on in the chat\n  4. Native function calling enabled for that model. (Open WebUI)\n\n\n\nIf any of that is missing, the `search_web` and `fetch_url` tools are not injected, and the model answers from its own weights instead. (Open WebUI)\n\nThere is also a recent OpenWebUI issue reporting that web search behavior breaks depending on the interaction between **Web Search** and **Builtin Tools**. In that report, search worked only when Builtin Tools was enabled, and failed when Builtin Tools was off even if Web Search was on. (GitHub)\n\nSo yes, the current settings model is confusing enough that you can do a lot “right” and still not actually have working search.\n\n## One more hidden problem: PersistentConfig\n\nOpenWebUI marks many of these settings as **PersistentConfig** , including:\n\n  * `TASK_MODEL`\n  * `GOOGLE_PSE_API_KEY`\n  * `GOOGLE_PSE_ENGINE_ID`\n  * web-search-related settings. (Open WebUI)\n\n\n\nThat means if you changed values in the UI before, the database-stored values can override what you later put in `.env` or Docker env vars. So restarting the container does **not** always mean your latest env values are the ones actually being used. (Open WebUI)\n\n## Another reason it can look broken even when search technically runs\n\nOpenWebUI’s troubleshooting docs say web search can fail after the provider returns results. Common reasons are:\n\n  * proxy-related fetch failures unless **Trust Proxy Environment** is enabled\n  * empty fetched content\n  * too-small context window\n  * poor loader choice. (Open WebUI)\n\n\n\nThe docs specifically recommend increasing context length to **16384+** for web content because pages often contain **4,000–8,000+ tokens**. Gemma 3 1B only has a **32K** context window, while larger Gemma 3 sizes have **128K**. (Open WebUI)\n\nSo even if search partly works, a 1B model can still end up acting stale because it does not use the fetched material well.\n\n## What I think is most likely, in order\n\n### Most likely\n\n**Gemma 3 1B is the wrong model for this job.**\nIf you are in Default mode, it is probably weak at query generation. If you are in Native mode, it is probably weak at tool use. Both are documented risk areas. (Open WebUI)\n\n### Second most likely\n\n**You enabled web search globally but not fully at the model/chat level.**\nThat includes Native mode, Web Search capability, Default Features, chat toggle, and possibly Builtin Tools interactions. (Open WebUI)\n\n### Third most likely\n\n**Your Google PSE config is incomplete or rejected server-side.**\nThat could be the wrong `cx`, a browser-restricted API key, the wrong engine type, or the documented Google PSE `INVALID_ARGUMENT` issue seen in OpenWebUI. (Google for Developers)\n\n### Fourth\n\n**Search returns something, but fetching/extraction/context makes the final answer useless.**\nThat usually shows up as stale or generic responses even though “search” seems to happen. (Open WebUI)\n\n## What to check first\n\nDo these in this order.\n\n### 1. Stop testing with Gemma 3 1B as the search brain\n\nFor diagnosis, switch to:\n\n  * **Default mode** first, not Native mode\n  * and a stronger model for search-related tasks if possible. OpenWebUI and Google’s own Gemma docs both point away from 1B for tool-heavy workflows. (Open WebUI)\n\n\n\n### 2. Verify Google PSE outside OpenWebUI\n\nTest the Google API directly. Google’s REST docs say each request needs `key`, `cx`, and `q`. (Google for Developers)\n\n\n    curl \"https://www.googleapis.com/customsearch/v1?key=YOUR_API_KEY&cx=YOUR_ENGINE_ID&q=latest+OpenWebUI\"\n\n\nInterpretation:\n\n  * JSON with `items` → Google side basically works\n  * 400/403 → Google side is wrong or restricted\n  * no useful results → engine setup may be wrong or not configured how you think. (Google for Developers)\n\n\n\n### 3. Confirm your `cx`\n\nGoogle’s official help says the Search Engine ID is in the engine’s **Basic** section. (Google Help)\n\n### 4. Confirm whether the engine is really set to search the web\n\nGoogle’s help says PSE can search the whole web, but it behaves differently from Google Search and can still emphasize your sites or use only a subset of the corpus. (Google Help)\n\n### 5. Check the API key restriction type\n\nIf the key is restricted, it likely needs to be valid for **server/backend** use, not only browser referrers. (Google Cloud Documentation)\n\n### 6. Re-check the OpenWebUI model settings\n\nFor your model, verify:\n\n  * Web Search capability\n  * Web Search in Default Features\n  * Function Calling mode\n  * chat-level Web Search toggle\n  * Builtin Tools behavior if you are in Native mode. (Open WebUI)\n\n\n\n### 7. Check logs\n\nOpenWebUI’s troubleshooting page says to check logs, and recent issues show the exact kinds of messages to look for:\n\n  * `No search query generated`\n  * `NoneType` errors during search generation\n  * Google `INVALID_ARGUMENT`\n  * timeout or empty-content fetch errors. (Open WebUI)\n\n\n\n### 8. If search succeeds but answers stay stale\n\nCheck:\n\n  * context length set to **16384+**\n  * proxy trust\n  * loader engine. (Open WebUI)\n\n\n\n## The blunt conclusion\n\nYour setup is probably failing because **Gemma 3 1B is too weak for OpenWebUI’s search orchestration path** , and **Google PSE is a brittle provider choice with several configuration traps**. The result is exactly what you described: an error appears, then the model falls back to old built-in knowledge instead of giving a current answer. (Open WebUI)\n\nThe fastest way out is usually:\n\n  1. test Google directly with `curl`\n  2. switch OpenWebUI to **Default mode**\n  3. stop using **Gemma 3 1B** for query/tool orchestration\n  4. then verify model capability and chat toggles. (Google for Developers)\n\n",
  "title": "Using OpenWebUI (gema 3.1b model) will not search web"
}