Why some stores rank and yours doesn't

Two stores sell the same trail shoes at the same price. One has its collection page on the first page of Google for "trail running shoes". The other gets search traffic only from people who already know its brand. A product or collection page ranks only after Google has found it, understood it as a distinct page worth keeping, and decided the store is trustworthy enough to show for that search. Most stores that don't rank are failing one of those three steps, and the fix is different for each.

Google has to find the page

Googlebot, Google's crawler, discovers pages by following links from pages it already knows and by reading the sitemap your platform generates. A product that nothing links to is invisible, however good its photos are, and stores create unlinked pages easily because the catalogue is managed in an admin screen.

The common ways a store hides its own products:

• The product isn't in any collection, or its collection isn't linked from the menu, so the only route to it is the store's search box. Google doesn't type into search boxes.
• The collection loads products through an infinite scroll or a "load more" button. Google's guidance on pagination and incremental loading for e-commerce sites recommends giving each page of results its own URL, because a crawler may never press the button.
• The store is still behind the platform's password page, so nothing can be crawled. A password left on after launch is a common reason a new store has no pages in Google.
• A robots.txt rule or noindex tag left over from the build blocks the collections folder, or the whole store.

Filters and sort options add a budget problem: every combination is a new URL, so a modest catalogue can present Google with far more addresses than it has products. Google's crawl budget guidance says budget matters mainly for very large sites, but a store with runaway filter URLs becomes one in Google's eyes, and Googlebot spends its visits on filters instead of your best sellers.

Make every product reachable from the menu in a few clicks, give pagination real URLs, and remove the password before you expect any ranking.

Google has to understand it and keep one copy

Once a page is fetched, Google works out what it's about and stores it in the index; only indexed pages can rank. Stores fail here in two ways: the page looks like a copy of something Google already has, or too thin to keep.

Copies are everywhere in a store: the same product reachable at its own URL and at one that includes the collection it was clicked from, a tag page listing the same products as a collection, and a description that is the manufacturer's text, already seen on every other retailer's page for the same item. Google's documentation on consolidating duplicate URLs explains what happens next: it picks one version as the canonical, the representative copy, and folds the rest into it. There is no penalty, but Google may pick the wrong version, and the product's signals get split across copies instead of stacking on one.

Thin pages are the other failure: a collection that is a bare grid of product cards gives Google little beyond the product names, and a product page that repeats the supplier's three lines looks like every other store's.

What helps:

• A canonical tag on every product and collection page that names its own clean URL, so copies point home.
• A few sentences of your own at the top of each collection: what it is, who it's for, how to choose.
• Descriptions written by you, plus Product structured data, the machine-readable block that states price, availability and reviews, which Google's e-commerce guidance recommends.

Google has to trust the store

Only now does ranking happen. For a product or category search the candidate pages look alike, so much of the decision rests on signals about the store: links and mentions from other sites, reviews, people searching for the brand by name, and whether the store's product information matches what the rest of the web says. Google's own explanation of how results are ranked lists the trustworthiness of the source alongside relevance and usability.

This is why an established retailer with a worse product page can outrank a new store with a better one, and why no edit to the page fixes it. What does is the store becoming a known thing: reviews on and off the store, mentions in guides and press, consistent product names and prices across your site, feed and marketplaces, and a brand people search for directly. Reviews, UGC and brand signals covers building it, and Store speed and themes covers usability, which Google's page experience guidance counts as part of ranking.

Work out which step you're failing

Before you change anything, find the step. Google Search Console, Google's free reporting tool for site owners, answers this.

1. Inspect the URL. If it reports the page is not on Google, you're failing step one or two, and the reason it gives (not found, blocked by robots.txt, crawled but not indexed, duplicate with a different canonical) says which.
2. If it's indexed but Google chose a different canonical, you have a duplicate problem and your canonical tags need fixing.
3. If it's indexed with the right canonical and still sits far down, it's step three: the work is trust and matching the page to the search, not more tweaking.

Most store owners start at step three because that's where the advice is. Start at step one and you'll often find the real problem in an afternoon.

What to take away

• A product or collection ranks only after Google finds it, indexes it as a distinct page, and trusts the store enough to show it, in that order.
• Stores hide their own products through unlinked collections, browser-only pagination, leftover passwords and filter URLs that eat the crawl.
• Duplicate URLs and copied supplier descriptions make Google fold your pages together or drop them; canonical tags and your own text keep one strong copy.
• Trust is built at the store level through reviews, mentions and consistent product data, and it's the slow step, so check the fast ones first.

Next

Now that you know the pipeline, learn which of your three page types should be catching each search in Which page catches which search.