FlatSearch.Pro Getting Started

Launch a faster WooCommerce search stack without the guesswork.

Configure FlatSearch.Pro in the right order: search surface first, Fast Index second, relevance third, then caching and optional commerce features.

Flatsome remains the deepest-tested integration, while the current universal search surface also allows FlatSearch.Pro to run as its own WooCommerce search interface.

WooCommerce-native Fast Index Engine Universal search option Cloudflare optional Redis optional

Recommended deployment order

Configure correctness before acceleration.

1
Choose search surface Flatsome integration or universal UI
Start here
2
Build Fast Index Prepare WooCommerce search data
Core
3
Validate relevance Exact, typo, multi-word and price intent
Verify
4
Add acceleration Browser, Redis and Cloudflare as needed
Optional
5
Validate production UX Desktop, mobile, images and network
Finish
Before installation

Prepare the store before changing search.

FlatSearch.Pro requires WordPress and WooCommerce. Theme integration, Cloudflare and persistent object cache are separate choices.

WP
Required

WordPress

Use a healthy current WordPress environment before changing production search behavior.

WC
Required

WooCommerce

Products, prices, images and commerce actions come from the WooCommerce catalogue.

UI
Choose

Search Surface

Keep the optimized Flatsome integration or deploy FlatSearch.Pro’s own universal search surface.

BAK
Recommended

Backup / Staging

Take a current backup. High-traffic or mission-critical stores should validate significant changes on staging first.

Important: Flatsome is no longer a hard requirement for the FlatSearch-owned universal search interface. It remains the deepest-tested theme integration.
Deployment roadmap

Seven steps from installation to validated production search.

Each step isolates one layer. If something breaks, you know which change introduced it.

1

Install and activate

Upload the FlatSearch.Pro ZIP through WordPress Plugins and activate it normally.

  • Take a backup first.
  • Upload plugin ZIP.
  • Activate FlatSearch.Pro.
  • Open FlatSearch.Pro settings.
2

Choose the frontend search surface

Decide whether the store will use the optimized theme integration or FlatSearch.Pro’s universal WooCommerce surface.

3

Enable Fast Index

Prepare the product-search data used by the dedicated high-speed origin search path.

  • Enable Fast Index Engine.
  • Run Rebuild Product List Now.
  • Wait until preparation finishes.
4

Configure search intelligence

Enable only the accuracy modules relevant to the catalogue and verify each search meaning.

  • Better Word Matching
  • Priority Typo Fix
  • Multi-word behavior
  • Price Search Words
  • First-letter discovery
5

Validate search presentation

Confirm product rows, images, prices and mobile behavior before adding more infrastructure complexity.

6

Add cache acceleration

Enable browser, persistent object cache or Cloudflare according to the infrastructure the store actually uses.

7

Run production validation

Test Incognito, desktop, mobile, cold cache, repeated search and browser Network behavior.

Deployment rule

Correctness before caching.

If relevance is not correct before Cloudflare or Redis is added, caching will only make the wrong result arrive faster.

Frontend integration

Choose how shoppers will access FlatSearch.Pro.

Search engine capability is separate from the presentation surface.

Universal WooCommerce

FlatSearch-Owned Search Surface

Use FlatSearch.Pro’s independent search form or icon when you do not want to depend on the active theme’s native autocomplete implementation.

Search products…
Search form [flat_search_pro_form]
Search icon [flat_search_pro_icon]
The shortcode examples above are intentionally escaped so this documentation page displays them without executing an additional search instance.
Core Search Engine

Build Fast Index before tuning the cache.

Fast Index prepares WooCommerce product-search data so uncached search can use a dedicated search path instead of doing broad catalogue work on every request.

  • Enable Fast Index Engine.
  • Run Rebuild Product List Now.
  • Wait for the build to complete.
  • Test exact product names.
  • Test product-family names.
  • Test an SKU where relevant.
Core concept: Fast Index is the origin search engine. Cloudflare and Redis can accelerate it, but they do not replace the index’s job.
First validation

Test these queries immediately after rebuilding

  • Exact product title
  • Brand name
  • First few letters
  • Multi-word product query
  • Common typo
  • Price phrase such as under 300
Search Intelligence

Validate what search means before measuring how fast it is.

Each relevance module solves a different customer-search problem.

Multi-term

Better Word Matching

Improves searches containing several meaningful product terms.

Typo

Priority Typo Fix

Helps misspelled brands or products reach their intended matches without weakening exact search.

Intent

Price Search Words

Interprets budget language such as “under 300”, “above 500” and range-based queries.

Prefix

Search From First Letter

Supports early discovery from short prefixes while the canonical transport remains coordinated.

Query structure

Multi-Word Matching

Coordinates several query terms so important words contribute together to ranking.

Editorial

Page & Blog Search

Allows relevant published content to participate when it helps commerce discovery.

Search Presentation

Make the dropdown feel complete as soon as it appears.

A technically fast result can still feel slow if visible product images arrive one-by-one.

Image selection

Better Search Images

Uses search-appropriate WooCommerce image URLs instead of unnecessarily large source images.

Protection

Small Image Guard

Protects result presentation when an image is unsuitable, oversized or broken.

Current runtime

Viewport Image Admission

Prioritizes the product thumbnails currently visible inside the search dropdown and leaves hidden rows deferred until needed.

What you should see: the visible thumbnail group should appear quickly together. Scrolling should admit newly visible images without loading the entire hidden result list up front.
Add acceleration after correctness

Understand which cache layer you are enabling.

Browser reuse, shared cache, Cloudflare and Fast Index solve different parts of search latency.

LAYER 01

Browser

Reuses suitable previously seen search data for that visitor.

LAYER 02

Shared Cache

Reuses valid normalized public results on the server/cache layer.

LAYER 03

Cloudflare

Optional edge caching moves hot public query responses closer to visitors.

LAYER 04

Fast Index

Answers uncached origin search from prepared WooCommerce data.

Browser

Browser Quick Search

Useful for repeated searches in the same browser.

Server

Redis / Object Cache

Optional persistent caching for stores that already operate a healthy object-cache layer.

Edge

Cloudflare Fast Search

Optional shared edge acceleration for public query results.

Do not compare cold and warm results as if they are the same test. A first Cloudflare MISS can include CDN-to-origin fill latency. A repeat HIT measures a different path.
Optional commerce features

Add conversion features after core search is stable.

Commerce

Quick Add

Allows eligible WooCommerce products to expose Add to Cart directly from the search experience.

  • Test standard products first.
  • Validate special product types separately.
  • Frontend assets load conditionally.
Guided discovery

Guided Answer Search

Create controlled answers for recipes, routines, buying guides or product-selection topics.

Content-to-cart

Selectable Guided Products

Attach real WooCommerce products to answer cards and allow shoppers to select relevant products.

Production Validation

Test like a shopper and inspect like an engineer.

Use several representative searches and check both visible UX and the browser Network panel.

Exact product Confirm the expected product or family ranks correctly.
Typo query Confirm Priority Typo Fix reaches the intended product.
Multi-word query Verify important terms contribute together.
Price intent Test phrases such as “under 300”.
Mobile Check focus, keyboard, dropdown/modal and scrolling.
Images Visible thumbnails should appear quickly without loading all hidden rows.
Cold cache Test once from Incognito and inspect HIT/MISS where applicable.
Repeat query Search the exact same term again and compare the warm path.
Network validation

Look for canonical FlatSearch transport

  • Open DevTools → Network.
  • Type a representative query normally.
  • Look for /fsp-search.js.
  • Confirm there is no unnecessary request storm for every character.
  • Confirm started canonical requests are not deliberately cancelled.
Result validation

Search should remain semantically consistent

  • Fast Index on versus expected relevance.
  • Cold versus warm cache.
  • Desktop versus mobile.
  • Quick Add on/off if used.
  • Cloudflare on/off where tested.
Healthy warm-search reference: production testing has demonstrated approximately 30–50 ms cached edge responses in the validated environment, including a recorded 29.5 ms response. Treat this as measured evidence, not a universal guarantee.
Maintenance

What to do after installation and future updates.

First installation

Finalize the initial deployment

  • Save selected settings.
  • Confirm Fast Index is prepared.
  • Clear only relevant caches.
  • Test desktop and mobile in Incognito.
  • Capture a baseline Debug Report.
Plugin update

Revalidate the search stack

  • Read the changelog.
  • Purge relevant frontend/page cache.
  • Rebuild Fast Index only when required.
  • Test representative product queries.
  • Confirm optional modules still behave correctly.
Troubleshooting

Diagnose the right layer first.

Search relevance, CDN fill, browser transport and image loading are different systems. Avoid changing one to solve another.

Search still shows old results after changing settings.
Clear the relevant FlatSearch/page cache, persistent object cache where used, Cloudflare where applicable, then retest from Incognito. Avoid repeatedly purging unrelated cache layers without reason.
Fast Index results look incomplete.
Rebuild Fast Index, clear relevant search cache and test the same query again. Then verify that the expected product data participates in the configured search path.
Search shows “No products found” too early.
Check Fast Index readiness, first-letter behavior and active accuracy modules. Test from Incognito after clearing relevant cache.
Product images are grey, broken or missing.
Verify Better Search Images and Small Image Guard, inspect the underlying WooCommerce thumbnail, and confirm another image optimization service is not incorrectly transforming an already suitable image.
Too many product images load when the dropdown opens.
Verify the current viewport-aware image runtime is active. Visible search rows should receive priority while hidden off-screen rows remain deferred.
Cloudflare Fast Search is slower immediately after cache clear.
Check whether the request is a Cloudflare MISS. The first edge fill can include CDN-to-origin network time. Compare the same repeated query before diagnosing the search engine.
I see several FlatSearch requests while typing.
The current architecture is designed to coalesce transient typing. Check stale frontend assets, duplicate plugin versions, page cache, or another autocomplete script competing for the same input.
I see cancelled FlatSearch requests in DevTools.
The current no-abort coordination should not deliberately cancel a started canonical FlatSearch request. Purge stale frontend assets and confirm the current runtime is loaded.
Search stops working after enabling WP Rocket JavaScript delay.
Test the JavaScript delay setting first and use Delay JS Search Protection where appropriate. Exclude only the specific asset shown to be affected rather than disabling all optimization.
The new FlatSearch version is installed but the frontend still behaves like the old version.
Clear page/server cache, persistent object cache where applicable, Cloudflare where applicable and browser cache, then test from a fresh Incognito session.
Need technical help?

Send evidence that identifies the failing layer.

A useful support request should make the problem reproducible without guesswork.

  • FlatSearch.Pro version
  • Exact query that reproduces the problem
  • Expected result
  • Actual result
  • Screenshot
  • Debug Report
  • Incognito HAR for timing/network problems
Recommended format

Support example

Problem: Search result is incomplete.

Query: glenlivet

Expected: Glenlivet product family.

Actual: Specific products missing.

Attached: Debug Report + HAR + screenshot.

Ready to deploy?

Build the index, validate the search meaning, then accelerate what already works.

FlatSearch.Pro is designed so WooCommerce search can become faster without sacrificing relevance, product imagery or commerce behavior.