Search or filters not returning results Free & Pro
Why FileDeck search or filters return nothing: what search matches, stale content indexes, hidden documents, cached results, and blocked scripts.
Updated September 29, 2026
When FileDeck search or filters come up empty, the cause is almost always one of five things: you are searching for text the search does not cover, the content-search index is out of date, the document is hidden from this visitor or this library, a page cache is serving stale results, or an optimization plugin is blocking FileDeck’s JavaScript. Work through the sections below in order.
What search actually matches
FileDeck’s keyword search matches a document’s title, excerpt, description, categories, tags, and filename. With content search, it also searches inside the files themselves — PDFs, Office and OpenDocument files, and text files — once the search index is built. See search, sort, and filter for the full behavior.
Keyword search ignores case and accents, so "cafe" finds "Café". Letters that your site’s language spells out follow that language (Settings → General → Site Language): on a Danish site, "møde" and "moede" both find "Bestyrelsesmøde", and on a German site, "prüfung" and "pruefung" both find "Prüfungsordnung". Before FileDeck 2.106.1, instant search could miss titles with ø, æ, å, ß or umlauts in them; if yours does, update the plugin.
If a phrase that appears only inside a file returns nothing, the index is the first thing to check.
Searches inside file contents return nothing
Content search relies on an index of your files’ text. If searches for phrases inside files come back empty:
- Go to Documents → Settings → Search Index and click Rebuild search index. Rebuilding is needed after a bulk import, or whenever results look out of date.
- If the missing documents are scanned or photographed PDFs, they have no text layer to index. Enable OCR under Documents → Settings → Scanned OCR. Scans published after that are sent automatically; for ones already in your library, press Send scanned PDF(s) for OCR under Documents → Settings → Search Index — see scanned-PDF OCR.
- If the Search Index tab says the server is missing PHP extensions FileDeck needs to read PDFs (zlib, iconv or mbstring), the text inside PDFs can’t be indexed until your host enables them. Then rebuild the search index.
The Search Index tab shows how many documents are indexed, which is a quick way to spot an empty index.
A rebuild is stuck or isn’t moving
A rebuild runs in the background, a few documents at a time, using WordPress’s scheduled tasks. Some hosts switch those off, and then a rebuild can sit at "0 of 1,000 documents processed" however long you wait.
When a rebuild hasn’t processed a document for a few minutes, the Search Index tab says so. Click Continue in this browser to run the rebuild from that page instead, and keep the page open until it finishes. Run this way, the rebuild doesn’t depend on scheduled tasks, and the progress updates as it goes. The button is there during any rebuild, so you can also use it to finish one faster.
On a site where scheduled tasks don’t run, FileDeck indexes documents as you save them instead of leaving them for the background, so new and edited documents stay searchable without a rebuild. A large batch at once, such as an import, starts a rebuild instead, which you can finish with Continue in this browser. The Search Index tab says when FileDeck is working this way.
If one file can’t be read in time (usually a very large or damaged PDF), the rebuild indexes that document by its title and description, moves on, and lists it on the Search Index tab. To make its contents searchable, replace the file (for example with a re-saved or smaller PDF), then rebuild the search index.
On a server with WP-CLI, wp filedeck reindex rebuilds the whole index in one go and ends any rebuild that was queued.
A document does not appear in results
If a specific document is missing from the library or from search results, check these in order:
- Is it published? Go to Documents → All Documents and confirm the document’s status is Published, not Draft, Pending, or Scheduled.
- Has it expired? (Pro) If the document has an auto-expiry date in the past, it is no longer available in the library.
- Is it restricted for this visitor? (Pro) Access control can hide documents from visitors who do not meet a password, role, or user restriction — at the document, category, or library level. Test in a private browsing window and while logged in as an appropriate user to compare.
- Is it outside the library’s category scope? If the block or shortcode uses category scoping (for example
[filedeck category="policies"]), only documents in that category appear. Check the document’s categories against the scope set on the block or in the shortcode.
A quick diagnostic: if the document appears when you view the library as an administrator but not as a logged-out visitor, the cause is access control or expiry, not search.
Filter options are missing
The multi-select category and tag filters only show terms that are actually in use within the current library. Three common causes:
- No categories or tags assigned. If your documents have no categories (or no tags), there is nothing to filter by. Assign terms under Documents → Document Categories and Documents → Document Tags.
- Scoped out. If the block or shortcode is scoped to one category, terms outside that scope do not appear in the filters.
- Already narrowed by something else. Options with no matching documents are hidden while a search or another filter is active, so a term you expect can disappear until you clear the rest. A ticked option always stays visible, so you can always untick it.
Results are stale after edits
If you added, renamed, or recategorized documents but the library still shows the old state, a page cache is serving an outdated copy of the page. For libraries of 500 documents or fewer, the search index is inlined into the page itself, so a cached page also means a cached index.
Fix: Purge your page cache (and CDN, if any) after making changes, or set a reasonable cache lifetime so edits appear automatically. The library’s own data rebuilds automatically when the page is regenerated — only the content-search index is separate, with its own rebuild button under Documents → Settings → Search Index.
The search box does nothing at all
If typing in the search box has no effect, or the multi-select filters and sortable column headers are inert, FileDeck’s JavaScript is not loading or is loading too late. The usual culprit is an aggressive script optimization plugin that defers, delays, combines, or minifies scripts.
Fix:
- Temporarily disable script optimization (defer/delay/combine settings) and reload the library page. If search works, you have confirmed the cause.
- Re-enable optimization but exclude FileDeck’s assets from it. Most optimization plugins accept an exclusion keyword — add
filedeckso its scripts and styles are left untouched. - Clear all caches and retest in a private browsing window.
Because FileDeck output is server-rendered with progressive enhancement, the document list itself still displays even when scripts are blocked — only the interactive parts (instant search, filters, click-to-sort) stop working, which makes this failure easy to recognize.
FAQ
Can visitors search the text inside PDFs or other files?
Yes, with content search: FileDeck searches inside PDFs, Office and OpenDocument files, and text files once the index is built. Keyword search alone covers title, excerpt, description, categories, tags, and filename.
Why can I see a document that my visitors cannot?
It is usually Pro access control or an expiry date. Administrators often pass restrictions that logged-out visitors fail, so always test in a private browsing window.
Do I need to rebuild a search index after importing documents?
For content search, yes — go to Documents → Settings → Search Index and click Rebuild search index after a bulk import. Also purge your page cache so visitors get the updated page.
Still stuck? Email support@getfiledeck.com.