Search plugins that need a manual reindex have a predictable failure mode. Someone sets it up, it works beautifully, and eight months later search is quietly serving results for a product you discontinued in March.
Nobody notices, because the person who would notice is a customer, and they just leave.
Three ways the index stays honest
On save. Hit publish or update and that page is reindexed then and there, through the same path as everything else. The new copy is searchable before you have finished closing the tab.
On removal. Delete a post and it leaves the index. Move it to draft, private or pending and it leaves the index too. A page that is not public is not findable, immediately, without waiting for a scheduled job to catch up.
This one matters more than it looks. Unpublishing something is often urgent: wrong price, wrong claim, product pulled. An index that keeps serving it for another day is a real problem.
Nightly. Once a day Fetchie re-checks a batch of the pages it has not looked at in longest, comparing each against what it has stored. Anything that changed gets reindexed. Anything that did not is skipped in a single comparison, so the pass stays cheap and your site works through itself over the following days.
The nightly run exists for the drift that never touches the editor: a theme change that alters how a template renders, a plugin that adds content to your product pages, a global block you edited once that appears on two hundred posts. None of that fires a save, so nothing else would catch it. When you want the whole site brought current at once rather than gradually, that is what the reindex control below is for.
Why it is cheap
Fetchie stores a fingerprint of each page’s indexed content. On the nightly pass, if the fingerprint matches, there is nothing to do and the page costs almost nothing to check.
That means the routine case, where most of your site did not change today, is fast. The work is proportional to what actually changed, not to how much content you have.
No external index to keep in step
Because the index is a set of tables in your own database, there is nothing to synchronise with an outside service. Your content and your search index are the same thing, in the same place, updating together.
This is the difference from a hosted or vector-based search setup, where the index is a separate copy held elsewhere. There, publishing a post or changing a price means pushing the change out to that service and waiting for it to catch up, and on embedding-based setups it means paying to re-encode the content every time it changes. Fetchie’s reindex happens on save, on your own server, at no extra cost. Change a price, save, and search reflects it.
Over the life of a site that adds up, and not only in fees. There is no external account to provision, no API quota to watch, and no sync to break at the worst moment. One less moving part is one less thing to service.
What you have to do
Nothing. There is no schedule to configure, no reindex to remember, and no maintenance task to add to a monthly checklist.
Fetchie also carries a reindex control for the moments you genuinely want one, after a bulk import or a big content migration. It runs in batches with a progress bar rather than one long request, so it finishes on shared hosting instead of timing out halfway.