Where to Put Product Recommendations: A Page-by-Page Placement Guide

The same candidate can be useful on a product page and distracting in a cart. The difference is not the candidate alone. It is the commitment the shopper has already made and the amount of new decision work the page can safely introduce.

Use the table below as a design brief. The “safe position” is a starting condition, not a universal pixel location. Theme structure, catalog complexity, product configuration, and device all change the final placement.

A product page gives the recommendation system a strong anchor: the product the shopper is evaluating. It also creates two different jobs. Related or substitute products help the shopper compare. Complementary products help the shopper use, install, protect, or extend the selected product.

Do not mix those jobs under one generic heading. A shopper comparing office chairs needs different evidence from a shopper choosing the correct floor mat for a chair they already want.

Shopify’s native Search & Discovery recommendations distinguish related products from complementary products. As checked on July 28, 2026, eligible recommendations depend on product status, Online Store publication, price, inventory conditions, cart state, and the product type. That means a visually correct placement can still be empty because no candidate is eligible.

If a native module is missing or returns the wrong products, use the Shopify recommendation diagnostic before moving the section. Placement cannot repair a failed request, ineligible candidate, or wrong recommendation intent.

Collection and search pages already contain a product-finding system. A recommendation module adds a second path, so the relationship and visual boundary need to be explicit.

On a collection page, use recommendations to extend the category mission: a related project, adjacent category, or curated solution. Avoid repeating the products already visible in the grid or inserting a second carousel before the shopper can use filters and scan the category.

Search has a stricter boundary because the query is an explicit request. Products that matched the query belong in the result set. Substitutes, popular alternatives, and adjacent categories belong in a labeled recovery module.

A cart is not another collection page. The shopper has already assembled an order and is trying to confirm quantity, total, delivery, and the route to checkout. A recommendation belongs here only when the relationship is easy to evaluate and the action is easy to ignore.

Direct add works for a fully specified item such as a care cloth or a consumable with one purchasable state. If the candidate requires size, color, voltage, fit, or compatibility, open a focused choice and preserve the cart. Do not choose a variant silently to make the module feel faster.

Post-purchase recommendations have a different anchor: ownership. Use the purchased product, order composition, expected usage cycle, and compatibility data to decide what comes next. Setup items can appear quickly. Replenishment should respect the expected consumption window. A durable product should not be recommended again without a replacement, team purchase, or multi-unit reason.

On a narrow viewport, a recommendation row can occupy the full screen before the shopper sees the primary action. Horizontal cards can hide how many choices remain, and late-loading images can move the page after the shopper starts interacting.

Test the module at the narrowest viewport your storefront supports and at the actual breakpoints where the layout changes. The goal is not to satisfy one magic width. It is to preserve reading order, relationship clarity, touch interaction, and the primary path across the supported range.

A placement can increase recommendation clicks while making the page worse. A module above the main purchase action may attract attention because it interrupts the shopper, not because it helps them.

Track the recommendation module and the page’s original job. For a product page, that may include product evaluation, add to cart, and purchase. For search, it includes result engagement, reformulation, recovery, and product discovery. For cart, checkout progression is a required guardrail.

Choose the page job before the module, and choose the relationship before the candidates. A recommendation should extend the current decision without making the shopper restart it.

ParticleSearch currently supports managed recommendation shelves for product and cart contexts. A merchant can enable each placement, choose its title and result limit, and select a strategy suited to the job. Product placements can support similar products, frequently-bought-together or complete-the-look decisions. Cart placements can use cart cross-sell or a broader catalogue strategy when that is the clearer job.

The theme still determines the physical location of the matching recommendation block. That is intentional: ParticleSearch should not guess where the primary purchase action sits or cover a store’s checkout progression. Once the block is placed, ParticleSearch owns the eligible candidate set, shared product-card presentation, and recommendation event context.

After a verified launch, the merchant should not need separate recommendation providers for the product page and cart, or a custom event plan for each shelf. Strategy comparisons can run on the recommendation surface, with views, clicks, verified attribution, and primary-path guardrails reviewed before a change is called a winner.

If placement is only one part of the problem, continue with the complete ecommerce product recommendations guide. It connects placement to candidate generation, eligibility, ranking, set quality, and measurement. The ParticleSearch experiment guide explains how recommendation strategies are compared without changing the search surface at the same time.