Add Search to Any AI-Built Website or Web App

Plan the Search

You decide what people should find. AI works out where that content lives.

Plan the Search

Tell AI what users should be able to find and where search belongs, then let it inspect the project before changing anything.

I want to add search to this existing website or web app. Users should be able to search: {{SEARCH_CONTENT}} Search should appear here: {{SEARCH_LOCATION}} Search should consider: {{SEARCH_FIELDS}} Do NOT change anything yet. First inspect the project and understand how this content currently works. Find: - Where the searchable content comes from - Whether it is local or static data, Supabase or database data, or an existing API - The current page or component that displays it - The fields that are safe and useful to search - Whether the data is public or private - Whether pagination or loading already exists - Whether any search or filter feature already exists - Whether the project already has a reusable input, list or result pattern Then recommend the smallest search implementation that fits THIS project. Do not add a backend if the content is already a small, safe client-side dataset. Do not download an entire remote or database dataset into the browser just to search it. If the data is private or user-owned, preserve the existing authorization and Row Level Security rules. Search must not expose records the user could not normally access. Do not use a Secret or service-role key in browser code. Do not add: - An external search service - Embeddings - Vector search - AI search - Advanced filtering - Autocomplete infrastructure - Search analytics Keep the first version simple. Tell me: 1. What data will be searched 2. Where that data currently lives 3. Which fields should match 4. Where the search UI should appear 5. The smallest implementation approach 6. Which files would need to change 7. How we will test it Do not modify the project yet.

What should users be able to search?

Blog posts, products, resources, listings, projects...

Where should search appear?

Blog page, products page, dashboard, resources page...

What should search look at?

Review the plan before continuing. Search should use the project's existing data source rather than creating a second source of truth.

Confirm the Search Source

Before building search, confirm which existing data source AI identified.

Searchable data source identified

Searchable fields identified

Public or private access confirmed

Existing page or result list identified

If the plan already names one clear data source, skip the prompt below and go straight to the next step. Use it only when the plan was unsure, or when the same content appears to exist in more than one place.

Confirm the Search Source

Resolve the data source before building search so the project does not end up with duplicate data or an unnecessary backend.

Using the project inspection above, confirm exactly where the searchable data currently comes from. Do not modify anything. If more than one source appears to contain the same content — for example a static file or array left over next to the database or API the app actually reads — identify which one the application really uses now, and say so plainly. Do not create a second data source. Return: - Current source - Searchable fields - Access model - Search approach

Build the Search

One search input, connected to the content that is already there.

Add the Search

Add the search input and connect it to the project's real content without rebuilding the page.

Implement the search plan we confirmed. Use the project's current framework, data source and existing UI patterns. Do not rebuild the page and do not redesign unrelated content. SEARCH INPUT Add one clear search input in the approved location. Use a placeholder that fits the content — for example Search posts..., Search products..., Search projects... — rather than a generic one when the project clearly knows what users are looking for. Use the project's existing visual style, and keep keyboard and screen-reader accessibility consistent with the project's current input patterns. SEARCH BEHAVIOR Search the approved fields only. Use case-insensitive matching where appropriate and trim meaningless whitespace. An empty search should return the normal default content state rather than showing no results, and it should not trigger an unnecessary request. LOCAL OR STATIC DATA If the data is a small dataset already safely loaded in the browser, use a simple client-side filter. Do not add a server API. Do not install a search package unless there is a real need. REMOTE OR DATABASE DATA If the data lives in Supabase, another database or an API, search the real source. Do not fetch every row merely to filter it in the browser. Use a focused query, return only the fields and results the existing interface needs, and limit result counts sensibly. Avoid sending a remote request for every meaningless keystroke — use the smallest request-control pattern appropriate to the project's current architecture. Do not introduce a complex search framework. PRIVATE DATA If records are private or user-owned, preserve the existing Row Level Security and authorization. Do not use privileged credentials in browser code. Do not implement search through a server endpoint that bypasses ownership checks unless that endpoint independently enforces the same access rules. Search results must never reveal another user's private row, a protected field, or data the current page could not normally access. RESULTS Reuse the current result cards, list or table where possible. Do not build a separate search-results design if the existing page can simply display the filtered results. Do not duplicate the app's data model. When finished report: - Files changed - Data source searched - Fields searched - Whether search is client-side or remote - How private access remains protected - Any dependency added, if one was genuinely necessary Do not make unrelated improvements.

Search must not widen who can see what

If the content is private or user-owned, the rules that already protect it stay in charge. A search result must never be a row the signed-in user could not open any other way.

Try the Search

A quick check before polishing anything.

Search for an item you know exists

Confirm the expected result appears

Search using different capitalization

Clear the search and confirm the normal content returns

Handle Every Search State

Only the states this project actually needs — nothing decorative.

Finish the Search Experience

Add clear loading, no-results, clear-search, and error behavior where the project actually needs it.

Review the search we just added and finish only the states required for a clean user experience. Keep the existing design. Add or confirm: DEFAULT STATE When the search is empty, show the page's normal content. SEARCHING OR LOADING Only if search uses a remote or database request: show a lightweight loading state using the project's existing pattern. Do not add fake loading behavior to a purely client-side filter. RESULTS Show the matching real records using the existing list, cards or table. NO RESULTS Show one concise state such as No results found. If it is useful, include a simple action to clear the search. Do not suggest fake results. ERROR Only if search can genuinely fail because of a remote, database or API request: show a useful generic error state. Do not expose database, provider or internal error details. CLEAR SEARCH Make it obvious how to return to the normal page state. Do not add: - Search suggestions - Recent searches - Advanced filters - Search history - Recommendations - AI-generated results When finished tell me: - Which states were added - Which existing components were reused - Whether any unnecessary state was deliberately omitted

Test It Yourself

Check it yourself before asking AI anything.

Search for a known result

Search for a term that should match more than one result

Search for something that should return nothing

Clear the search and confirm the default content returns

Refresh or reopen the page and confirm the normal state still works

If the data is private, confirm another user's records never appear

If search reads a database or an API, watch the loading and error behavior once while you do this. There is no need for a longer checklist than that.

Verify the Search

Verify the Search

Check that search uses the correct data source, returns relevant results, and does not expose data users should not see.

Perform a focused verification of the search feature we just added. Verify: - Search uses the project's real existing data source - No duplicate source of truth was introduced - The approved fields are searched - An empty search returns the normal default content - Known queries return the expected records - A no-match query shows the correct empty result - Clearing search restores the normal content - Existing page behavior still works - Search does not unnecessarily load the full remote dataset into the browser - Remote search does not produce obviously excessive requests - No Secret or service-role credential is exposed in browser code - Private or user-owned search results still obey the existing authorization and Row Level Security rules - Search does not expose fields the existing interface should not reveal Do not broaden this into a performance audit or a security audit. Do not add advanced search features. If something directly related is broken, fix only that issue. When finished return: SEARCH VERIFIED or: NEEDS ATTENTION Then summarize: - Data source - Matching fields - Search method - Test result - Any directly related remaining issue

Search for one real item yourself one last time, then clear the search and confirm the page returns to normal.