Summary. A Google result or AI citation can introduce a merchant to a shopper. It cannot, by itself, confirm that a particular SKU, variant, price, and stock state are still buyable. For that, an assistant needs a current query against the merchant’s catalog or search system.
A merchant marks a size 9 hiking boot out of stock at noon. The product page changes immediately. The store’s own search changes when its catalog data syncs. But a shopper can still find yesterday’s price, or yesterday’s availability signal, in a search result for some time after that.
That is not an argument against Google. It is a description of what an index is: a system that discovers, crawls, processes, and serves a representation of a site. It is not the store’s transaction system.
The same distinction matters when AI is part of the shopping journey. An AI answer can cite a merchant as a useful source. That is valuable. But the citation does not prove that the assistant checked the current offer before it named it. A source link and a buyable product result are different things.
A citation says, “this merchant is relevant.” A live product query says, “this specific option can be considered right now.”
For a catalog with prices, variants, inventory, delivery dates, and policies that change, the difference is not technical trivia. It decides whether an assistant sends a shopper toward a viable product or a dead end.
Why the gap exists
At Search Central Live Deep Dive Europe, Google’s Gary Illyes shared internal figures for crawling, indexing, and serving. Search Engine Roundtable reported typical times of about 20 hours to discover a new URL, 30 days to refresh a known URL, and 1.5 hours for end-to-end indexing once the page is in that stage. It also reported hours to one or two weeks for structured-data updates and one to two days for titles or snippets to update in results. The stages are linked, so delays add together. [1]
The important word is linked. A page cannot be indexed until Google has found and crawled it. A new price in page markup cannot be reflected until the relevant page has been fetched and processed. A changed title still has to make it through the serving side before the result shown to the shopper changes.
These are not promises from Google or a clock a merchant can set by. Illyes later described the slides as an internal exercise to see whether the audience could relate to the numbers. The slow end for several processes was weeks, months, or “never,” often because of quality. [1]
Google’s own documentation makes the broader point without putting a number on every stage: a requested recrawl may take a few days to a few weeks, asking repeatedly will not make it faster, and a sitemap helps Google discover URLs but does not make an update instantaneous. [2] Google also notes that changes to an existing site can take a few weeks to be noticed. [3]
In other words, the indexed version of a catalog is useful, but it is always a representation that passed through queues and systems outside the merchant’s direct control.
A citation is not a live offer
It is tempting to treat a citation as confirmation that an AI system has checked the product. Sometimes the cited page will be current. Sometimes the cited material will be a buying guide, a category page, a Merchant Center-backed product result, or an older indexed product page. The citation tells the shopper where information came from. It does not establish that a selected SKU is still available in the shopper’s size, at the displayed price, and with the required delivery window.
That is why a citation can be correct and still be a poor shopping result.
Imagine the request: “Find waterproof hiking boots for Iceland in October, under $250, in size 9.” A useful AI answer may cite a merchant’s guide to waterproof footwear or point to a category that deserves consideration. That is a good start. But a purchase decision still needs answers the guide cannot safely supply:
- Which products match the use case and budget?
- Which size-9 variants are available now?
- Is the displayed price the current price for that variant?
- Does the merchant’s shipping policy meet the trip date?
- Where should the shopper go to buy the qualifying item?
Those are catalog questions. They need a result object with a product ID, selected variant, price and currency, stock state, relevant attributes or policies, and a valid storefront URL. They should come from the same synchronized catalog or search system that the merchant relies on for its storefront—not from a cached search result alone.
This is the division we drew in AEO Citations vs. Storefront Product Discovery: AEO can help a merchant appear in an answer. Product discovery has to retrieve the right item and help the shopper reach checkout.
The price-change problem: a citation can lag the store
Consider an existing product page. At 9:00 a.m., a merchant raises the price from $189 to $229 and sells through the last size-9 variant.
The storefront should reflect that change as soon as its commerce data does. The discovery layer should return the same status as soon as its connected catalog or search index has synchronized. If the product no longer qualifies for the request, the assistant should exclude it or explain the limitation.
Google has a different job. It may not recrawl the known URL for some time. After it does, structured data and visible search-result elements have their own processing paths. The figures above are a useful reminder that “indexed in about 1.5 hours” does not mean “the shopper sees every changed field in 1.5 hours.” The crawl, indexing, structured-data, and serving stages can each matter. [1]
A Merchant Center feed and accurate product structured data remain worth maintaining. Google says that supplying both can maximize eligibility for shopping experiences and help it understand and verify product information; some experiences may combine page and feed data. [4] That is good ecommerce hygiene and good search strategy.
It is still not a substitute for a query made at the moment an assistant is about to recommend a product. A feed improves what Google can show. A live catalog query verifies what the merchant can sell now.
The new-SKU problem: Google has to find it first
A new product cannot be cited from the public index before Google has a chance to discover and process its page. The reported typical discovery time for a new URL was around 20 hours, while sitemap processing was around 24 hours; both had much longer slow ends. [1]
The merchant should do the normal work: create an accessible product page, use sound internal links, include it in the sitemap where appropriate, publish accurate product information, and maintain its feeds. Those steps make the SKU easier for Google to discover and understand over time.
But an assistant connected to the merchant’s queryable catalog is solving a different problem. If the new SKU and its variants are already present in the search backend that powers the store, the assistant can retrieve it when a shopper asks. It does not need to wait for a public crawler to discover the URL before it can return the product to a buyer who is already in the merchant’s discovery flow.
That is not a reason to abandon search visibility. Public indexing introduces a merchant to people who do not yet know the store exists. Direct catalog discovery helps an interested person or agent decide what to buy once the merchant is in consideration. Both are useful. They just run on different clocks.
The migration problem: visibility can recover slowly while commerce keeps moving
Site moves make the contrast even clearer. The reported typical time for processing a site move was one to three months, with a slow end of six months to a year or more. Core-update recovery was reported at three to six months typically. [1]
During that time, a merchant should still keep redirects, canonicals, product pages, feeds, and tracking in good order. Google specifically calls out sitemaps as helpful for newly launched sites and site moves. [2]
But organic visibility being in transition does not give a store permission to make its own product data vague. Existing customers, email recipients, paid-media visitors, affiliates, and assistants that already have an authorized route into the merchant’s catalog still need current results. If a shopper asks for an in-stock replacement part during a migration, a live search path should not depend on whether Google has finished reconciling the new URL structure.
The live path also needs its own discipline. If inventory is stale in the connected search backend, an agent will repeat stale inventory with more confidence and speed. “Live” means that the price, variants, availability, and policies are sourced from data the merchant keeps synchronized—not simply that an AI response arrived quickly.
What a live AI shopping citation should mean
There is no need to choose between a public citation and a structured product response. The strongest shopping experience can use both.
First, the citation can establish why the merchant or category belongs in the answer. It gives the shopper context, provenance, and a path to learn more.
Then, when the request turns into a purchase task, the assistant should call a merchant-controlled discovery layer for the current matching offers. The response should carry the shopper’s constraints forward: budget, use case, preferred size, compatibility requirement, location, and timing. It should return products that satisfy those constraints, explain meaningful trade-offs, and send the shopper to a working merchant-owned product page or cart path.
That is the role of SuggestAPI. It sits in front of the search backend or catalog a merchant already uses, so people and AI agents can submit a natural-language request and receive structured product matches without replacing the merchant’s search stack or checkout. The merchant keeps control of the catalog, storefront, policies, and payment flow. [5]
A live shopping citation, then, should not be treated as a fancier blue link. It should be a grounded recommendation: a source or explanation when useful, plus current product data that can survive the next click.
Treat the index as discovery, not stock control
The practical decision is not whether to “do SEO” or “do AI.” It is whether each system has the job it is suited to perform.
Google Search and Merchant Center can help a merchant be found, understood, and displayed across public search experiences. That work earns attention over time. It deserves accurate pages, structured data, feeds, internal links, and careful technical maintenance.
A live discovery layer should handle the moment when a shopper asks a precise question and needs a present-tense answer. It should understand the request, retrieve against current catalog data, respect variant-level facts and policies, and hand the shopper to a page that completes the journey.
The quick test is simple: change the price or stock status of ten representative variants, then compare three views of each product—the storefront, the result returned to an assistant, and the public search result. If the assistant cannot consistently agree with the storefront, it is not ready to make purchase recommendations. If the search result takes longer to change, that is a reason to manage shopper expectations, not a reason to make the live path depend on it.
A citation can open the door. A current catalog query is what lets an assistant walk a shopper through it.
Want to test whether an assistant can retrieve current, purchase-ready products from your catalog? Talk to SuggestAPI.
Frequently asked questions
Does a Google result always show stale product information?
No. Google can surface useful, current product information, and it recommends accurate structured data and Merchant Center feeds. The point is that Google’s public search representation is processed through discovery, crawling, indexing, and serving systems. A merchant should not treat it as the sole real-time authority for a purchase decision. [1] [4]
Is a citation in an AI answer a product recommendation?
Not by itself. A citation can support an answer or send a shopper to a useful page. A purchase-ready recommendation also needs a current product match, variant-level availability, price, relevant constraints, and a dependable storefront handoff.
Does a live AI shopping experience replace SEO or Merchant Center?
No. SEO, structured data, and feeds help a merchant earn public visibility and eligibility across search experiences. A live discovery layer handles a separate step: retrieving current catalog facts when someone is ready to compare or buy.