The six-layer discovery stack

No layer replaced the one before it. Each inherits the failures of the layers below. This is why contradictory advice about Amazon ranking can all be partly true — different practitioners are describing different layers.

Amazon search is usually described as a sequence of replacements. A9 gave way to A10, A10 gave way to something else, and every eighteen months a new acronym arrives to explain why last year's advice stopped working. None of that happened. There has only ever been A9, and what actually occurred is stranger and far more useful to understand: the same engine accumulated layers. Lexical matching in 2003. Machine-learned behavioural ranking by the mid-2010s. Embedding-based semantic retrieval from 2019. A commonsense knowledge graph in 2024. A retrieval-augmented shopping assistant on top of that. Agentic purchasing on top of that.

Not one of those layers replaced the one beneath it. Each was added, and each depends on the output of everything below. That single structural fact explains almost every argument in this industry. When one practitioner tells you keyword placement is everything and another tells you it is all conversion rate and a third tells you to write for the AI, all three can be describing real mechanisms accurately. They are describing different layers of the same stack, and they are usually arguing because neither has named which layer they are standing on.

The stack is ordered by dependency, not by recency. The newest layer is not the most important one. It is the most fragile one, because it inherits every failure below it. A listing that is not indexed lexically cannot be retrieved semantically, cannot accumulate behavioural history, cannot form graph relationships, cannot be quoted by an assistant and cannot be transacted by an agent. The failure presents six layers up, at the surface where somebody noticed it, and it lives at the bottom.

What follows is the whole stack, layer by layer, with the lexical layer given the space it deserves because it is the layer that gates everything and the layer the industry stopped writing about a decade ago. Every substantive claim carries a provenance badge. Amazon has published a great deal about architecture and essentially nothing about weights, and the difference between those two things is the difference between this page and folklore.

The central claim: nothing was replaced

Start with the correction, because it reframes everything else.

"A10" is the clearest example of the confusion. It is a real observation with a fake name. Observed Around the middle of the last decade, sellers correctly noticed that behavioural signals had started to dominate outcomes: velocity, click-through rate, conversion, purchase after a specific query. Rankings became far less responsive to keyword frequency and far more responsive to what shoppers did. That observation was accurate. The naming was not. Amazon did not ship a successor algorithm and never announced one. A9's ranker had simply matured into a machine-learned system with behavioural features weighted heavily, which is exactly what A9's own engineers described publicly. Observed The community invented a version number to label a change it could see but could not source.

Treat every "new algorithm" claim the same way. Ask what was actually observed, then ask which existing layer it belongs to. In twelve years I have not once seen a genuine replacement. I have seen many genuine additions.

Four jobs, six layers

Before the layers, the jobs. Every optimisation decision you will ever make belongs to exactly one of four jobs, and most wasted effort in this discipline is the right action performed at the wrong job. Model

The discipline that follows from this is one sentence long: name the layer before you act. PPC cannot fix eligibility. Copy cannot fix the offer. Evidence cannot fix retrieval. A quarter spent on assistant-layer evidence work for an ASIN with a rejected attribute contribution produces exactly nothing, and it is the most expensive mistake in the field precisely because everything about the work looks correct while it is happening.

Five eras of the same engine

The stack in chronological order, with what each era added and what remains true from it today. Amazon research Observed

Read the right-hand column as a single list and you have the honest state of the discipline in 2026. Nothing in it has expired. The 2003 column is still the eligibility gate for the 2026 column.

Layer 1: lexical retrieval, in full

This is the layer nobody publishes on any more, and it is the layer that decides whether any of the others get to run. Semantic retrieval broadens what lexical retrieval finds. It does not resurrect what was never indexed. Observed If the term is not associated with your ASIN somewhere in an indexed field, no amount of embedding similarity, review quality, bid aggression or assistant charm will retrieve you for it.

Everything in this section is practitioner observation unless a badge says otherwise. It is reproducible with the exact-phrase-plus-ASIN test, which is the only proof that exists for any of it: search the exact phrase together with the ASIN, and if the ASIN returns, the term is indexed. Category behaviour varies. Verify in yours rather than trusting a generalisation, including mine.

1.1 Tokenisation and normalisation

1.2 Stemming and morphological equivalence

The engine reduces words to roots before matching, which means a large amount of the keyword work sellers still perform is buying nothing.

1.3 The field indexation map

This table is the most operationally valuable thing on this page. It is where a term must live to be retrievable, and it is the reference that settles most listing arguments before they start.

Two rows in that table are worth reading twice. The Item Highlights row, because a title over 75 characters silently forfeits a confirmed equal-weight search field, which makes the title cap a retrieval decision rather than a cosmetic one. And the image-text row, because in most audits I run there is at least one genuinely important fact that exists only as a graphic.

1.4 Cross-field combination and proximity

Query tokens can be satisfied jointly across fields. "Mulberry" in the item name and "standard" in a bullet together can retrieve the ASIN for "mulberry standard pillowcase". You do not need the full phrase in any one field, which is why phrase-stuffing a title is both unnecessary and actively costly.

Word order is broadly flexible, with one qualification: exact-phrase adjacency in the item name appears to carry additional relevance weight on head terms. Observed The operating rule that follows is to put the purchase-dominant word order into the 75 characters and let everything else be assembled across fields.

Repetition buys nothing. A term is indexed or it is not. The second occurrence adds zero at this layer, and it consumes surface that could have carried a query you currently do not serve at all. If you take one thing from this section, take that.

1.5 Variation-level behaviour

Children contribute terms to a shared family footprint, and child-specific terms such as size and colour index per child. Observed The construction rules that follow are simple and rarely followed: keep the structure identical across every child, and put the variant token last in the name so the identity root reads consistently across the family.

The failure mode here is the one worth internalising. Invalid variation groupings and parent/child mismatches suppress or fragment indexation. That is an eligibility failure that presents as a retrieval failure. Somebody sees impressions collapse, concludes the copy broke, rewrites the copy, and changes nothing, because the copy was never the problem.

1.6 The silent failure modes, in checking order

Lexical failures are almost always silent. The interface confirms your change, no error appears, and the system behaves as though the change never happened. Check these in this order, because they are ordered by how cheap they are to rule out.

Layer 2: semantic retrieval

Embedding-based matching retrieves products that share meaning with the query rather than sharing its characters. Amazon published the architecture as "Semantic Product Search" at KDD 2019. Amazon research The practical effect is that the vocabulary gap closes without your help. You no longer need to enumerate every synonym a shopper might use, because the model already knows that a duvet and a comforter occupy adjacent territory.

What moves this layer. One identity root, stated consistently. Category-normal vocabulary rather than invented brand language. Unambiguous material and product-type wording. Terminology that does not drift between the title, the bullets and the description. The listing is producing an embedding whether you think about it or not, and everything on the page contributes to where that embedding lands.

How it fails. Identity ambiguity. A listing that calls itself two different products blurs its own embedding and lands between two neighbourhoods rather than inside either. The severe version of this is identity sabotage, and it is the single most damaging copy pattern I find in audits. Observed A premium product uses its cheaper substitute's category or material name "for coverage", and in doing so teaches semantic retrieval that it is the substitute.

The reference case, anonymised and real: six self-identifications as the substitute material scattered across the description and the backend field. The result was indexation on the substitute's six-figure-volume head term at roughly 0.5% impression share, dozens of clicks, and zero purchases, against a market median price around a fifth of the product's own. The listing had bought itself a battlefield it could only lose on. Worse, asked directly whether the product was one thing or the other, the assistant found both answers on the same page.

Layer 3: behavioural ranking

A machine-learned ranker weighting sales velocity, click-through rate, conversion, returns and in-stock rate. Observed This is the layer the industry mislabelled "A10", and the observation underneath the wrong name was correct: from roughly the middle of the last decade, what shoppers do with your listing began to matter more than what you wrote on it, once you were eligible to be shown at all.

What moves it. Converting on the query. Purchase-after-query is the strongest observable rank driver in the system, and price within the query's revealed budget is the precondition for it. Observed Precision of early traffic matters disproportionately, because the first purchase cohort is what teaches the association. And nothing here is a substitute for stock: velocity breaks reset behavioural momentum in a way that takes weeks to rebuild.

How it fails. Broad launch traffic teaches a blurred association, so the ASIN ends up mediocre across many query families rather than dominant in one. Price-mismatched queries burn CTR history, which is a cost that persists after you stop bidding on them. Stockouts break velocity. Each of those is a decision somebody made deliberately, usually for a defensible-sounding reason, and each is more expensive than it looks. The mechanics of spending into rank are covered in PPC and organic rank.

Layer 4: the COSMO knowledge graph

Published at SIGMOD 2024. Amazon research COSMO is a commonsense knowledge graph mined by large language models from query-purchase and co-purchase behaviour, then filtered by humans, and reported as deployed in search and navigation. The refinement tiles you see above search results are the visible surface of it.

The relationship types it learns are the useful part: used-for function, used-by audience, used-in context, complement, and substitute. That is a map of why people buy things rather than what things are called, and it sits between retrieval and selection.

What moves it, phrased as signals rather than mechanisms, because Amazon has published the architecture and not the weights. Model

One phrasing discipline, and it matters for credibility. Never say "PPC trains COSMO" as though it were a documented mechanism. Say that behaviour and traffic-purchase alignment are strategically important signals, and that Amazon has not published the weights. The first version is a claim you cannot support. The second is true and just as actionable.

Layer 5: the shopping assistant

A shopping large language model performing retrieval-augmented generation over the product catalog, customer reviews, community Q&A, other Amazon data and, in current experiences, external web content. Amazon confirmed Amazon has reported 350 million customers on a trailing twelve-month basis, with active users roughly doubling in Q2 2026. Note also the naming: the assistant is now generally referred to as Alexa for Shopping rather than Rufus. Observed The rename is practitioner consensus, since Amazon Science's own paper still carries the original name.

The architecture is what matters strategically. The assistant does not maintain a separate index. It retrieves through the same index the search bar uses. It grounds an answer in retrieved passages and then speaks on your behalf. Your listing is the evidence base it quotes, and what it cannot quote from you it rebuilds from reviews, from competitors, or from generic category content that describes your product about as well as a category page does.

What moves it. Three things, in order.

Extractability: the copy standard

A claim can be true, indexed, and completely useless, because it cannot be lifted as a self-contained passage. This is the highest-leverage copy change most listings can make, and it costs nothing but discipline.

The standard: every load-bearing claim is a standalone sentence structured fact, then consequence, then audience or use, with numbers and units. The test is to read the sentence aloud with zero surrounding context and ask whether it answers a shopper's question completely and unambiguously.

The five failure patterns, all of them common:

• The referent sits outside the sentence. "It holds up to 12 kg" is useless without knowing what "it" is.
• The fact is split across two bullets, so neither one survives extraction.
• The copy implies rather than states, leaving the assistant to infer something it will not risk asserting.
• A number appears without its unit.
• The fact exists only inside an image, which the retrieval layer cannot read at all.

Evidence consistency and class questions

The assistant reads your claims against your reviews, your Q&A and your structured data. Contradiction is more expensive than absence. An unsupported claim can surface inside your own answer as a caveat, which is a worse outcome than never having made the claim. Reconcile your top ten claims against the review corpus quarterly, and retire or reframe anything the corpus contradicts.

Then cover the class questions. Every category has a set of questions its buyers actually ask, usually about constraint, comparison, care, compatibility and sizing. Q&A is a named source for retrieval-augmented answers, Amazon confirmed so seed and answer those questions in extractable form. Every answer standalone, factual, number and unit.

Sponsored Prompts

Paid placement inside assistant answers, currently in beta. Observed The mechanic is worth understanding before the invoices start: you pay for the question, the system writes the answer, and your retrieval quality sets the ceiling on what it can say about you. Buying placement in an answer the assistant cannot fill with anything specific about your product is buying a worse version of your competitor's ad. Organic evidence work is the precondition for paid assistant placement being worth the money.

Layer 6: agentic commerce

Auto Buy, Lens, assistant-initiated purchasing and the emerging external agent protocols. Amazon confirmed direction, with the operational detail still moving. The mechanic that matters is that matching at this layer scores structured fields against the query: GTIN integrity, flat-file consistency, attribute completeness and attribute correctness. There is no persuasion surface. An agent does not read your bullet about premium craftsmanship. It reads your material attribute.

There is also a compliance countdown running here, and it is worth stating plainly. Assistants already detect claim-versus-attribute mismatches internally without surfacing them. Observed Detection and enforcement currently sit at different tables. They will not sit at different tables indefinitely. Every material claim on your listing needs to match the structured field behind it, and the cheap time to fix that is before detection gets wired to enforcement rather than after.

The compression chain

Amazon now generates display content from your content. Observed The chain runs in three directions at once:

The consequence is uncomfortable and specific. Whatever is thin or generic is exactly what gets summarised and shown. The strong-title-and-weak-bullets strategy, which worked for years because nobody read the bullets, is now actively harmful, because the weak layer is the layer that surfaces. Your bullets and description must be strong enough to be summarised favourably by a system that will not flatter you.

Query rewriting and the fan-out

Amazon does not use the phrase "query fan-out". Amazon's own term is query rewriting, and there are multiple Amazon Science publications on it, covering context-aware query rewriting, QUEEN, and query rewriting for voice-shopping null queries, all describing the generation and ranking of multiple alternative queries from a single input. Amazon research "Fan-out" is community shorthand for the same mechanism. Use "query rewriting" in anything client-facing or citable.

One shopping mission generates multiple retrieval paths the seller never sees: the need, the constraint, the attribute, the substitute, the context. The shopper experiences one request. The system conducts many searches. That is the whole idea, and it inverts a decade of keyword practice.

Exact-string density buys less. Honest concept coverage buys retrieval across child queries that are invisible in every report you have access to. Depth on a single head term is worth progressively less. Breadth across the query family the category naturally produces is worth progressively more. The construction method is in keyword strategy.

AI Overviews as a query generator

The category-level overview module, rendered in the sidebar on desktop and in-feed above the first result on mobile, has a five-part structure: an insight stating what decides the purchase in that category, four tappable attribute cards backed by live product thumbnails, two click-trained prompt pills, external source citations, and an open ask bar. Observed

Its ranking significance is not the module. It is that tapping a card injects a near-exact long-tail query into the search bar and runs it through conventional retrieval. The module is a query generator. It produces more specific searches automatically, on the shopper's behalf, at scale, weighted by which prompts get clicked most in that category over time. Amazon is publishing its preferred child queries in public.

What that gives you is unusual: the category's dominant decision axis, disclosed. The exact child-query strings Amazon treats as priority branches. A per-category citation pool. And, because the pills and card axes shift as they are click-trained, the diff between monthly captures is category demand-shift telemetry that no tool sells.

What it demands is that coverage on each generated pathway stops being optional. The question becomes structural rather than editorial: does the variation family contain a listing built for each long-tail pattern the category naturally produces, across style, use case, material and audience? Gaps in that map are gaps in visibility, regardless of how good the front end looks.

The pool architecture

This is the mechanism that connects conventional search to the assistant, and it is the single most consequential correction to how most sellers reason about AI search.

The prerequisite that falls out of this settles the SEO-versus-AI argument in both directions. If the ASIN is not on page one of conventional search, it cannot be on page one of AI search. It has to be in the pool to be re-ranked into the answer.

So "abandon SEO for AI" is arithmetically wrong. The assistant cannot select a product it was never handed. Conventional ranking is the eligibility gate for the entire assistant layer, which makes retrieval work more load-bearing under AI search, not less. And "just do SEO" is equally wrong. Pool entry gets the ASIN considered. The re-rank decides whether it is one of the five to eight, and that is where evidence quality, context fit and the behavioural graph do their work.

How the narrowing actually works

The pool does not get sorted. It gets filtered through four stages, and a listing can fail at any one of them for reasons the stage above cannot see. Observed

Which means position one in an assistant answer is a fit decision, not a relevance score. "Rank one on the assistant" does not exist as a single stable thing, and any tool selling you that number is selling you one sample from a distribution.

Diagnose the state before assigning the work

Personalisation makes visibility conditional

Rank is treated everywhere as a position. It is more accurately a distribution conditional on who is looking, and Amazon has published the mechanism.

An Amazon Science paper on whole-page optimisation, deployed in a live environment, describes a page ranker that arranges different widgets in different positions for different users. Amazon research One shopper sees 19 organic results then two widgets; another sees eight then a widget. The reported uplift was +1.87% brand relevance and +0.5% revenue. Products are weighted by pixel coverage and page region, which means where an ASIN lands on the page is part of the scoring, not merely its ordinal position.

The ranker's inputs are context, customer and content.

The same broad query renders different insights and different card ordering per account, per session and per inferred household context. An overview can open with context the shopper never typed and reorder the pathways accordingly. Since you cannot know which personalised ordering you must qualify under, the only defence is attribute breadth across every constraint dimension your product legitimately serves.

Three consequences for measurement, and they change how you report:

• A single rank check is not the truth. It is one sample from a distribution.
• A screenshot from a logged-in account measures that account's personalisation, not the market. Rank evidence going into a report should come from Search Query Performance impression share, which is aggregated across shoppers, not from manual position checks.
• Pixel coverage and page region matter, so a "position 8" rendering in a large-format grid may outperform a "position 4" in a dense list. Position number alone is a weaker metric than this industry has historically treated it.

This is also the honest answer when a client asks why they can see themselves ranking and their customer cannot.

Proportion, before you reprioritise anything

Assistant-originated detail-page traffic is growing quickly, at roughly six times its mid-2025 indexed baseline on a US desktop index, and independent retail data puts AI-referred traffic growth near +393% year-on-year with materially better conversion. Observed Both figures are directional and indexed rather than absolute, and the same research bodies concede that conventional rank and page quality still decide the overwhelming majority of outcomes.

What this means in practice

Five things you can do this week, in the order the stack says to do them.

Then re-read the four-state table above before you assign anything larger. Almost every failed optimisation programme I have reviewed was competent work performed at the wrong layer, and the diagnosis costs an afternoon while the mistake costs a quarter. The complete guide works the stack top to bottom, and the scenario runbooks handle the specific failures once you have named the layer.

Sources