Type something into your site’s search box and look at what comes back. If you’re running stock WordPress, the results are ordered by publish date. The most recent thing that happens to contain your word wins, whether or not it has anything to do with what the visitor asked.
That isn’t a ranking. It’s a filter with a date sort bolted on.
Fetchie replaces it with an actual search index.
What "ranked" means here
When Fetchie indexes a page, it doesn’t store the page as one undifferentiated lump of words. It splits the content into two tiers and weights them:
- Titles carry the most weight. A page called "Refund policy" is almost certainly the answer to "refund policy", and Fetchie treats it that way.
- Body text is the baseline: everything else printed on the page.
A word in your title is worth more than the same word buried in paragraph fourteen, so the page whose title answers the question rises above the page that only mentions it in passing.
The result is that search stops being a lottery. Ask for "shipping to New Zealand" and the shipping page comes first, not last week’s blog post that mentioned New Zealand in passing.
Multi-word questions
Real visitors don’t search the way a database wants them to. They type "how long does delivery take" rather than "delivery".
Fetchie tokenises the query the same way it tokenised your content: strips the filler words that carry no meaning, keeps the words that do, and scores every page against the remaining terms together. A page matching three of your four meaningful terms outranks a page matching one of them, even if that one page repeats it a dozen times.
The scoring you can feel
Two adjustments sit on top of the base score, and both exist because of how people actually search.
A title match bonus pushes pages whose title contains a search term above pages that merely mention it. Someone searching "returns" wants the returns page, not the product review that mentions returns.
Source-type bias nudges products and pages above blog posts on a store. If you sell something and a visitor searches for it, they want to buy it, not read about it.
What gets indexed
The content types you choose on the Index tab: posts, pages, and any public custom post type your site has. Products too, when you’re running WooCommerce, with every variation’s details rolled into the parent.
A custom post type from a plugin you install next month becomes available to tick on the Index tab, so you decide whether it belongs in search rather than having it turn up unannounced.
Page-builder layout templates are skipped, because nobody wants a layout template appearing in their search results.
Speed
The index is two lean tables: one row per source, one row per term occurrence. A search is an indexed lookup and a sum, not a LIKE '%term%' scan across your entire posts table.
This matters more than it sounds. WordPress core search does a wildcard string comparison against every post body on every search. On a site with a few hundred posts nobody notices. On a site with several thousand products, it’s the slowest query on the page, and it gets slower every time you publish.
Fetchie’s cost scales with how many terms are in the query, not how much content you have.
Where it takes effect
Fetchie takes over the native search results page, the one your theme renders at ?s=. Visitors don’t need to find a special search page or use a different box. The search form already in your header starts returning better results.
If your page builder has a search template assigned, Fetchie yields to it and hands the ranked results to that layout instead, so your design survives.
Why shops turn it on
The searches that matter most are the ones from visitors who already want something. Someone typing into your search box has skipped your navigation entirely and told you exactly what they came for. If the answer is on your site and search doesn’t surface it, you have lost a sale to your own search box.
Ranked results are the difference between a visitor finding the thing and a visitor deciding you don’t sell it.