First Sale Plan

Gumroad search uses AND matching: titles and tags

By yoshibuild · Published · Last verified

Say a buyer types "google sheets budget tracker" into Gumroad search. Your product is called "Money Tool". It will not show up, and no amount of good design changes that. The words are not there.

This is what Gumroad's public source code does with a search query, as read on 2026-10-11, and what it suggests for titles and tags. The author's own store has no sales as of 2026-10, so none of this is tested on live results.

How the query is matched

In searchable.rb the text query is sent to Elasticsearch as a simple_query_string. It searches four fields: the product name, the creator name, the description and the tags.

The default operator is AND. If a buyer types three words, all three must appear somewhere in those four fields. A product with two of the three is not a partial match. It is out.

Words can be spread across fields. "budget" in the name and "sheets" in a tag still counts, as far as the code shows. The author did not run queries against a live index to confirm this. A separate autocomplete query searches only the name (and its ngrams), also with AND.

What happens after matching

Matching decides who is in the result set. Order comes next. The default "featured" sort has no relevance score in it, so among products that contain every word, the one with the most recent fees comes first, as described in the ranking article. The "curated" sort does start with _score, so text-match relevance can matter when curated is the active sort. That happens by default when the visitor has curated products, as the ranking article explains.

Either way, a product with no sales is not in the set to begin with, as covered in the first-sale article.

Titles

These points are the author's inferences from the matching rule. They are not tested.

  1. Use the words a buyer would type. "Google Sheets Budget Tracker" beats a brand-like name, because every word in the query has to be present.
  2. Repeat the product type and use case in the description. The description is searched too.
  3. Do not stuff. AND matching needs each word once. Repeating words does nothing in the code read, and it makes the page worse for people.

Tags

Tags do two jobs. As free text they are one of the four searched fields. As a filter, the tags field is also mapped with a tags.keyword subfield, and a tag filter from the URL is a terms clause on it. The filter queries both the tag as given and the same tag with spaces replaced by hyphens, so either spelling matches the spelling it was saved with. A code comment explains that Discover and profile URLs spell spaces as hyphens.

On the number of tags, the sources disagree, so do not rely on a count beyond what the editor allows:

Claims that tags raise ranking are unverified. The code read shows tags as a match field and a filter, not as a ranking boost.

A small worked example

Say a product is titled "Life Admin Tracker". The words a buyer would type are probably "household", "bills", "spreadsheet" or "Google Sheets". A title like "Household Bills Tracker for Google Sheets" contains all four, in both likely phrasings. The old title has none.

This is an illustration of the rule, not a result. The author has not measured whether renaming changes anything. With no sales, no rename can show up in Discover yet.

Caveats

Matching decides who is in the set. The eligibility gate decides who may enter the set at all. The first is about words, the second is about a sale.

The author's 30-day experiment

In 2026-10 the author plans to rewrite titles and tags for a few products on their own store using this rule, while sending outside traffic. Nothing has been measured yet. A write-up, including a result of zero, will be linked here: [case study link, not yet published].

Sources