A client-side search index contains the text of every page you indexed, delivered as a file anyone can download. If drafts, unlisted pages or internal notes were indexed at build time, they are readable even if no link points to them. Index what is already public, and nothing else.
How these indexes work
Many static sites add search without a server. At build time, a tool reads your content and writes an index file, often JSON or a compact binary format. The browser loads that file and searches it locally. It is fast and cheap. It also means your index is a public asset, in the same folder as your images.
What can end up in it
- Draft pages that the build includes when a flag is mis-set.
- Pages excluded from navigation but still built, such as old campaign pages or a partner landing page.
- Front matter fields, like internal author notes, if the indexer takes whole files.
- Content gated by a login, if the gate lives in the browser.
- Text from private content that was pulled from a CMS with a preview token.
None of this needs an attacker to be clever. Opening the browser's network tab shows the file name, and the file is plain data.
Check yours in ten minutes
- Load your site and open the network tab. Reload and look for large JSON or index files.
- Open one and search it for a word that appears on a page you consider unlisted.
- Search for the words draft, internal, confidential and a few product code names.
- Compare the number of entries with the number of pages you intend to be public.
- Repeat on a preview deployment, which may use a different content set.
Fixes
| Problem | Fix |
|---|---|
| Drafts indexed | Filter by status in the indexing step, and test that drafts are absent |
| Unlisted pages indexed | Add an explicit exclude flag, default to excluded for new sections |
| Whole-file indexing | Index title, headings and body fields, not the whole file |
| Gated content | Do not index it client-side. Use server-side search with access checks |
| Index too big | Split by section, which also makes accidental inclusion easier to spot |
Add a test to the build
A small script that reads the generated index and fails the build if it contains any entry whose URL or title matches a deny list is cheap insurance. Pair it with a check that the number of indexed pages is within a range you expect, so a sudden jump gets noticed.
Remember the other copies
Search engines may have crawled a page before you hid it. Removing it from the index file does not remove it from the web. If the content was sensitive, treat it as exposed, change what needs changing, and request removal from search engines where appropriate.
Where Safeguard fits
Safeguard scans the packages your search tool pulls in, which is a separate concern from what you index. It will not review your content. Free scan: gold.safeguard.sh/scan.
Quick check
Is a hosted search service safer than a client-side index?
It can be, because filtering happens on a server, but you then depend on a provider. Apply the same vetting you would to a form handler.
Can I protect the index file with a password?
Yes, if the whole site is protected. Otherwise visitors who can load the page can load the index.
Last reviewed: 19 October 2026.
