WordPress AI Search with Gemini File Search Store: What Worked and What Didn’t

Source: Dev.to

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

The default WordPress search returns a list of posts matched by keywords. It doesn’t understand intent, doesn’t answer questions, and feels outdated in a world where users expect conversational AI and full‑sentence queries.

I built Geweb AI Search – a WordPress plugin that replaces traditional search with an AI‑powered assistant powered by Google Gemini.

How it works

Instead of a list of links, users get:

• a direct AI‑generated answer
• source links to the exact pages used to generate that answer
• optional conversation history for follow‑up questions

The plugin intercepts the standard WordPress search form and opens a modal with two modes:

At the core of this architecture is Gemini File Search Store.

Why File Search Store instead of classic RAG?

A typical LLM‑powered site search usually requires:

1. Converting content into vector embeddings
2. Storing them in a vector database (Pinecone, pgvector, Weaviate, etc.)
3. Running similarity search on each query
4. Retrieving relevant chunks
5. Passing them into the LLM as context

That’s a full RAG stack – infrastructure‑heavy and operationally complex.

Gemini File Search Store simplifies the workflow

1. Convert WordPress posts to Markdown
2. Upload documents to a Store via the Gemini API
3. When a query arrives, instruct Gemini to use that Store

Indexing, retrieval, and answer generation are handled internally by Gemini.

• No separate vector database
• No embedding pipeline
• No retrieval orchestration layer

Ideal use cases

• Corporate websites
• Documentation portals
• E‑commerce catalogs
• Content‑heavy blogs

Because the model operates strictly within the uploaded content boundaries, responses stay grounded in the site’s data instead of relying on general model knowledge.

Demo

• Live demo: – test both autocomplete and AI answers right away.
• WordPress directory:
• Source code:

Screenshots

What I Learned

Gemini 3 vs 2.5 – What changed and what matters for integration

During integration I discovered important behavioral differences between Gemini 2.5 and Gemini 3 when working with File Search Store.

Takeaway: If your UI depends on structured responses (e.g., programmatic rendering or attaching metadata), the model version matters. The plugin supports both generations, but full structured attribution works correctly with Gemini 3. Always test the exact model + Store combination in staging before shipping to production.

Secure API‑key storage

The Gemini API key is stored encrypted in the WordPress database using libsodium.

Implementation principles

• The key is encrypted before being saved to the database.
• Only users with proper WordPress capabilities can modify it.
• Decryption happens only at runtime when making API requests.
• No external dependencies are required.

Store opens up new use cases

While building this plugin, I realized that File Search Store is not just about search. It enables an entire class of AI‑driven features built on isolated, trusted content:

• AI‑powered site search
• Virtual assistants for corporate websites
• Product advisors for online stores
• FAQ bots grounded in real documentation

All are based on the same principle: upload structured content into a Store and let the model operate strictly within those boundaries. This provides predictable, content‑scoped answers without building a full custom RAG stack.

Google Gemini Feedback

What worked well

• File Search Store is the biggest win.
• No need to spin up a vector database, build an embeddings pipeline, manage similarity search, or maintain retrieval logic.
• You simply upload documents, and Gemini handles indexing and retrieval internally.

From a developer’s perspective, this significantly reduces infrastructure complexity and time‑to‑market.

What caused friction

(Content truncated in the original submission.)

Issues with the Gemini File Search Store API (v1beta)

The API is still in beta (v1beta), and that shows.

1. Multiple base URLs

File uploads go through:

https://generativelanguage.googleapis.com/upload/v1beta

While other operations use:

https://generativelanguage.googleapis.com/v1beta

Working with the same logical entities across different base URLs is confusing.

2. Different upload flows return different structures

There are two ways to upload files:

1. Upload a file first, then attach it to a Store
2. Upload directly into a Store

These approaches return different response formats.

• If you upload separately and then attach, the path starts with files/....
• If you upload directly into a Store, you get documents/....

For File Search Store queries, the documents/... format is required. This behavior is not immediately obvious and required trial‑and‑error testing.

3. Stability under load

During peak hours, the API occasionally returns delays or intermittent errors. In production, this requires:

• Proper error handling
• Retry logic with exponential backoff

What I’d Like to See

• Unified base URL for all API operations
• Consistent response structures across upload flows
• Clear documentation with end‑to‑end File Search Store examples
• Store‑level management operations (e.g., delete a Store with all documents in one request)
• Long‑term: S3‑compatible storage interface for easier integration
• A stable, non‑beta release

Overall Takeaway

Google Gemini — and especially File Search Store — significantly lowers the barrier to building AI‑powered site search. For WordPress developers, this makes advanced AI search achievable without maintaining a full RAG infrastructure.