Fetchie doesn’t search your database directly — it searches a small, purpose-built index of your content. That’s what makes results fast and ranking possible. This page covers how the index is built, how it stays fresh on its own, and the two situations that genuinely trip it up.
—
Calibrate First: the Index Tab
Tracksies > Fetchie > Index is designed to be read before you build. Under What gets indexed, every content type on your site is listed with a count of published items, so you can see exactly what each toggle adds. Choose, click Save selection, then click Rebuild index to apply it.
Two annotations worth noticing:
- Types marked no public page can appear in results, but visitors may not be able to open them directly — usually best left off
- Counts are of published items only; drafts, private posts and password-protected content are never indexed, full stop
Unticking a type and rebuilding removes everything of that type from the index — nothing lingers.
—
Indexed as a Visitor Sees It
Here’s the part that makes Fetchie work with any page builder: when Fetchie indexes a page, it fetches the rendered page — the finished HTML, requested anonymously the way a logged-out visitor would receive it — and extracts the main content from it. Not the raw stored content, the real page.
Why it matters:
- Builder content is fully searchable. Bricks, Elementor, Divi and friends store content in their own way; the rendered page is the one place it all comes together
- Jump links can work. The links that scroll a visitor to the exact matching passage only work when the indexed text genuinely exists on the page a visitor sees
- Navigation, headers, footers and sidebars are stripped out, so a search for a word in your menu doesn’t match every page on the site
If a page can’t be fetched, Fetchie falls back to indexing the stored post content — better than nothing, but thin for builder-based pages. Fallback documents are surfaced as a visible list on the Index tab (see below), never hidden.
—
Staying Fresh, Automatically
Once built, the index looks after itself:
- Publish or update a post, page or product and it’s re-indexed on the spot
- Unpublish, trash or delete something and it leaves the index immediately — an expired page never haunts your search results
- A daily freshness pass re-checks a batch of the longest-untouched entries, so changes that don’t fire a save — a template tweak, a builder-wide style change, content edited directly in the database — drift back into sync within days
When to click Rebuild
- After changing which content types are indexed
- After fixing a fetch problem (maintenance mode switched off, security rule relaxed)
- After a large redesign or migration you want searchable today rather than gradually
- On first install, of course
Rebuilding is always safe — it refreshes what changed and leaves the rest.
—
Two Things That Genuinely Break Indexing
Maintenance and coming-soon mode
A maintenance or coming-soon plugin shows logged-out visitors a placeholder page — and Fetchie indexes as a logged-out visitor. Build the index while one is active and every document quietly falls back to thin stored content. You’ll know because the Index tab shows a warning listing documents “running on thin content”, and the Test page fetch button gives you a one-click diagnosis before you burn a rebuild: it fetches your homepage exactly the way the indexer would and reports what came back.
The fix: finish launching (or allowlist the indexer — see Troubleshooting for the search-bot tip), then Rebuild index.
Content injected by JavaScript
Fetchie reads the HTML your server sends. Content that only exists after JavaScript runs in a browser — a widget that loads reviews on the fly, an app-like block that draws itself client-side — isn’t in that HTML, so no fetch-based indexer can see it, Fetchie included. If something important lives in a script-drawn widget, the searchable version needs to exist in the page itself.
—
The Index Itself
For the curious: the index is three small database tables — the documents, the term index that powers ranking, and the search log. It’s lean by design, and if you ever uninstall Fetchie, the On uninstall setting decides whether it’s kept or removed (Search settings).
—
Related
- Troubleshooting — fetch failures, allowlisting the indexer, the debug log
- WooCommerce & product search — how product variations join the index
- Getting started — the first-build walkthrough