← Blog

Case study: Trek.ca — WordPress search that finds pages, not just posts

Trek.ca is a Numinix content property. Native WordPress search kept burying service pages under blog posts — Seekmodo fixed typeahead, SERP parity, and the “I know this page exists” frustration.

Every content site has that moment: a reader (or a salesperson) knows a page exists, types the obvious keyword, and WordPress cheerfully returns three old blog posts while the actual service page sits on page two — or nowhere.

That was the daily texture of search on Trek.ca, a Numinix content property. Trek is not a giant newsroom, but it is busy enough that search is a real product surface: visitors looking for services, GEO/SEO explainers, and the page they saw last month. Native ?s= search was not cutting it.

The human problem

Editors and account folks would say things like:

  • “Search for PPC and you get articles, not the services page.”
  • “I start typing and nothing useful appears until I hit Enter — and then it’s still wrong.”
  • “Clients ask if the site is broken when they land on an empty results page.”

None of that is a “relevance algorithm” complaint in the abstract. It is people losing time and confidence. On a marketing site, that is conversion and brand damage dressed up as a search bug.

Why stock WordPress search failed here

WordPress core search is a SQL LIKE over a narrow field set. It does not know that a page about paid media should outrank a blog post that happens to mention “PPC” in passing. It does not offer typeahead. It does not rescue a near-miss query with “did you mean” or popular destinations. And once a theme or cache layer enters the picture, empty or oddly ordered SERPs feel even worse.

Trek’s catalog is content — posts and pages (and the CPTs the connector picks up) — not a WooCommerce product grid. So we needed the content vertical, not a commerce-shaped index.

What we changed

We installed Seekmodo Search for WordPress in content mode, paired a tenant, and iterated the way we do on client sites: watch real queries, fix the embarrassing misses, ship connector improvements when the platform needed them.

  • Typeahead that matches the SERP — suggestions for titles and excerpts so “I know this page” queries surface before Enter. We spent real engineering time on content typeahead / SERP parity so the dropdown and the results page stop disagreeing.
  • Editorial ranking priority — pages can be bucketed above blog posts when that is what the business wants (the classic “services over stories” preference), without throwing away textual relevance inside each tier.
  • Zero-result recovery — empty states that point somewhere useful instead of a dead end.
  • Branding off — the search UI stays on-theme for Trek; Seekmodo is infrastructure, not a badge.

Some of the fixes that landed in the WordPress connector — content SERP union with native rows when the gateway returned a thin ID list, stronger title-phrase ranking, suggest/SERP consistency — were literally exercised and validated against Trek-shaped queries. Dogfooding a Numinix property again paid for itself.

What it feels like now

Search stopped being the thing people apologize for on calls. Typeahead gives an early signal that the site understands the query. Service and destination pages show up where humans expect them. Editors keep publishing without adopting a second CMS or standing up Elasticsearch.

If you have ever muttered “WordPress search is useless” while staring at your own homepage search box, you are the audience for this install.

Try the pattern

Live site: trek.ca. Product path: Seekmodo for WordPress or install from WordPress.org.

FAQ

Is Trek a separate company?

Trek.ca is operated by Numinix — the same team behind Seekmodo. We name it because it is ours; we still treat it like a production content site, not a demo sandbox.

Do I need WooCommerce?

No. The content vertical runs on WordPress alone. WooCommerce activates automatically when present.

Case study: Trek.ca — WordPress search that finds pages, not just posts · Seekmodo