Search is one of the most important features of any content-heavy site. It’s what connects users directly to the information they’re looking for—and if it’s slow or incomplete, the whole experience suffers.
On this site, the search isn’t just an afterthought. It’s a carefully engineered hybrid system that combines the best parts of headless WordPress (dynamic, always up-to-date content) with the speed of static page indexing (cached, CDN-delivered JSON). The result is a search experience that’s both lightning fast and consistently fresh.
Let’s break it down.
WordPress Content via getStaticProps
Blog posts and pages live in WordPress. Instead of relying on static indexing alone, they’re integrated into the search in real time:
- Data fetching: Content is pulled into the site at build time using
getStaticProps. - Incremental Static Regeneration (ISR): Each post/page regenerates every 60 seconds, ensuring content stays fresh without requiring a redeploy.
- Search flow: When a user searches, the query is sent to the WordPress REST API (
/wp/v2/posts?search=…and/wp/v2/pages?search=…). - Block coverage: Gutenberg blocks, custom blocks, and even ACF fields are included, since WordPress stores them as structured content in
content.rendered. - This means blog posts, pages, and block content are always available in search—accurate, up-to-date, and pulled straight from WordPress.
Static Pages via Pre-Built JSON
Not everything is in WordPress. Static Next.js pages (like /about or /shop) are indexed at build time. Here’s how that side works:
- Build step: All static content is scanned, titles and body text extracted, and stored in
search-index.json. - CDN delivery: The JSON file lives as a static asset, cached globally by Vercel.
- On-demand loading: It’s only fetched when someone uses search—never during normal browsing.
- Performance bonus: The index is tiny (currently ~28KB for 6 pages, ~200KB at 50 pages) and automatically gzipped down even further.
For simple static pages, this is as fast and efficient as it gets.
Unified Search Architecture
When a search is triggered, both sources are queried in parallel:
- WordPress content: Queried live via REST API.
- Static pages: Filtered locally from the pre-built JSON index.
- Merge layer: Results are combined and returned as a single unified response.
From a user’s perspective, it’s seamless: one search box, one set of results. Behind the scenes, two complementary systems are working together.
Performance Benefits
The hybrid model gives this site the best of both worlds:
- ✅ Static search: Blazing fast, zero database overhead
- ✅ WordPress search: Real-time, always up-to-date
- ✅ No impact on page loads: Search is lazy-loaded only when triggered
- ✅ Optimized by ISR: WordPress pages regenerate every 60 seconds
- ✅ CDN powered: Static index is served and cached globally
Even as content grows, search remains reliable, scalable, and snappy.
The Lifecycle of a Search
To really appreciate the design, here’s the lifecycle in three parts:
- At build time: Static pages are indexed into JSON; WordPress paths are pre-generated with
getStaticPaths. - At runtime: WordPress pages regenerate via ISR, keeping content up-to-date without full rebuilds.
- At search time: Static results come instantly from the JSON index, while WordPress queries return live, fresh content—then both sets are merged.
That’s the whole system: static speed + dynamic freshness.
Bottom Line
Search on this site isn’t just functional—it’s strategically engineered. By combining static JSON indexing with live WordPress queries, the system ensures that users get instant, reliable results whether they’re looking at a static page or a freshly published post.
Fast, fresh, scalable. That’s the architecture.
So if anyone wonders how the search here works, the answer is simple:
“It’s hybrid, it’s optimized, and it’s fast!”