This Documentation is for SearchWP Version 3


Search implementations each have their own philosophy. For example, WordPress’ search philosophy was once¬†generalized as:

Find any post that mentions these keywords in the post title or content and return them ordered by date descending.

It has since been updated to implement a few improved rules:

The ordering logic is as follows:

  • Full sentence matches in post titles.
  • All search terms in post titles.
  • Any search terms in post titles.
  • Full sentence matches in post content.

Each section and any remaining posts are then sorted by date.

The updates to consider more than rudimentary matches sorted by date are (very) welcome, but often not enough. As a reaction, many WordPress developers have embraced third party solutions such as Google Custom Search to power their search. While GSC can be effective, it ultimately has a number of drawbacks that force concessions when it comes to design. There’s a branded search field, search results have ads (unless you pay to get them off), and it’s sometimes really difficult to give search the attention you’ve afforded everywhere else.

There are also some third party solutions out there that operate in a similar way to SearchWP, but as a developer I wanted even more fine grained control. I wanted something that would let me:

  • Give separate keyword weights per taxonomy
  • Assign keyword weights per custom field
  • Have search results for Media point to the post_parent
  • Let me attribute CPT hits that don’t have a permalink to a parent page
  • Index PDF content
  • Build ‘secondary’ search engines that can operate outside my main site search and let me offer search for a specific section of my site

Existing solutions didn’t offer any of those, so I went ahead and built my dream search plugin. That’s SearchWP.