Reporting & research on Shopify and ecommerce
Merchants type 'shopify predictive search' expecting a feature they can shape, but the section files show the real boundary is fixed in code long before any merchant opens the theme editor.
Merchants who type “shopify predictive search” into a search bar are usually hunting for a setting that will make search results smarter or faster, but the actual code tells a different story. Dawn puts 14 settings into one file and lets a merchant shape the display of results in real detail. Horizon puts zero settings into the two files that handle the search experience itself and moves every adjustable knob into a separate block. Neither theme lets a merchant change the search logic through the editor. The settings that exist govern how results look, not which results appear, and knowing that distinction before opening the theme editor saves a lot of clicking around for something that was never there.
Dawn’s sections/main-search.liquid, labeled internally as t:sections.main-search.name, carries 14 settings as recorded in the Shopify/dawn repository at commit 258f00f from 2026-08-10. The range setting columns_desktop runs from 1 to 6 in steps of 1, giving fine control over how many results sit in a row on wider screens. columns_mobile is a select with only 2 variants, so mobile layout choice is a binary rather than a spectrum. image_ratio is a select with 3 variants and image_shape goes further with 8 variants, covering things like how product thumbnails get cropped and framed. Two checkboxes round out the notable settings: show_secondary_image and show_vendor, both simple on-off toggles.
None of these 14 settings touch the search algorithm. They govern presentation only, which is consistent with what a section file is supposed to do in Shopify’s theme architecture. A merchant wanting different result ranking or fuzzy matching behavior will not find it here, because that logic sits outside the section’s settings schema entirely.
The comparison gets sharper with Horizon. Its sections/predictive-search.liquid, labeled t:names.predictive_search, has 0 settings, confirmed at commit 8b42ace from 2026-08-31. That section does declare 1 block type, but the section’s own settings schema is empty. Its companion file, sections/predictive-search-empty.liquid, labeled t:names.predictive_search_empty and handling what shows when a search returns nothing, also has 0 settings at the same commit.
This is not a gap in the measurement. It is how the theme is built. Horizon moves the configurable surface into blocks/_search-input.liquid, labeled t:names.search_input, which carries 8 settings. Among them: width, a select with 2 variants; custom_width, a range from 0 to 100 in 1 percent steps; input_style, a select with 2 variants; and three color settings covering input_background_color, input_text_color, and input_border_color. So a merchant editing Horizon’s search appearance needs to find the block, not the section, because the section itself offers nothing to adjust.
| Theme | File | Settings count | Notable settings |
|---|---|---|---|
| Dawn | sections/main-search.liquid | 14 | columns_desktop (range 1–6), image_shape (select, 8 variants), show_vendor (checkbox) |
| Horizon | sections/predictive-search.liquid | 0 | none; 1 block type declared |
| Horizon | sections/predictive-search-empty.liquid | 0 | none |
| Horizon | blocks/_search-input.liquid | 8 | custom_width (range 0–100%), input_background_color, input_border_color |
The method here is straightforward: read the settings schema declared at the top of each Liquid file, count entries, and note their type and range where the schema specifies one. Same repository, same commit reference per theme, no interpretation added beyond what the schema itself states.
Across the broader market tracked by themescout.co, 329 themes sit in the ranking checked on 2026-09-04, with a median price of $300 and a range from $100 to $500. The average rating across 308 themes with enough reviews is 4.53 out of 5, and the median number of reviews per theme is 23. None of that tells a merchant anything about a specific section’s settings, but it frames how much choice exists in the market before narrowing down to Dawn or Horizon specifically.
Performance is the other piece of context worth naming once. On mobile, the median share of stores passing all Core Web Vitals sits at 85.5% across 247 themes with sufficient data, with the best theme in the market at 98.6% and the worst at 46.1%. On desktop, the median is 86.2% across 199 themes, with a best of 99.2% and a worst of 30.3%. This comes from CrUX data covering July 2026, meaning real visitor traffic rather than a lab benchmark. A heavier search section with more markup could plausibly push a theme toward the lower end of that range, though the facts here do not isolate search sections as the specific cause.
Check the actual section and block files for the theme under consideration rather than assuming predictive search settings will look like Dawn’s just because Dawn is the reference theme most guides use. If a theme’s search section shows zero settings the way Horizon’s does, look for a companion block before concluding the feature is missing entirely.
Yes, through columns_desktop, which is a range setting from 1 to 6 in steps of 1 inside sections/main-search.liquid. There is a separate columns_mobile setting, but it is a select with only 2 variants rather than a range, so mobile layout choice is narrower than desktop. Both settings live in the same file, Shopify/dawn at commit 258f00f, dated 2026-08-10. Neither setting touches which products the search algorithm surfaces, only how the returned results are arranged.
Yes. show_secondary_image is a checkbox setting in sections/main-search.liquid, one of the 14 settings recorded in that file as of the 258f00f commit from 2026-08-10. There is also a show_vendor checkbox in the same section, so vendor name and secondary image can be toggled independently. Neither setting changes what data the search query returns, only what the theme chooses to render from it.
Because Horizon's sections/predictive-search.liquid has 0 settings and sections/predictive-search-empty.liquid also has 0 settings, both confirmed at commit 8b42ace from 2026-08-31. Horizon moves the adjustable part into a block instead of the section: blocks/_search-input.liquid carries 8 settings, including width, custom_width as a range from 0 to 100 in 1 percent steps, and three color settings for background, text, and border. So the absence in the section files is real and measured, not a gap in reporting, and anyone editing search appearance in Horizon has to look at the block, not the section.
The facts here do not isolate search sections specifically, but they do show the range across which a theme's overall Core Web Vitals performance can sit. On mobile, the median across 247 themes with sufficient data is 85.5% of stores passing all Core Web Vitals, with a spread from 46.1% to 98.6%. On desktop, the median across 199 themes is 86.2%, spread from 30.3% to 99.2%. These numbers come from CrUX data covering real visitors in July 2026, not a lab test, so a heavier search section is one plausible contributor among many to where a given theme lands in that range.
By setting count alone, yes. Dawn's sections/main-search.liquid has 14 settings in one file. Horizon splits the same function across three files, two of which have 0 settings each and one block, blocks/_search-input.liquid, with 8 settings. Added up, Horizon's search-related surface is 8 settings across the block plus zero from the two sections, versus Dawn's 14 in a single section. The architecture differs more than the raw configurability does.