ChatGPT SEO for product recommendations

Getting a product recommended by ChatGPT is not a matter of inserting a magic phrase on ten pages. A recommendation appears when the system can find the product, identify what it is, gather credible evidence about it, and decide that it fits the constraints in one particular conversation. Miss any one of those conditions and another product gets named.

Founders often treat this as a younger version of Google SEO. That framing leads to expensive busywork. Search rankings still matter because search engines and public pages supply much of the evidence, but ChatGPT usually synthesizes an answer rather than presenting a stable list of ten blue links. The unit of competition changes from a keyword to a decision: best accounting software for a two-person agency, safest travel stroller for cobblestones, or an observability tool that a small team can operate without a dedicated engineer.

The useful goal is not "rank number one in ChatGPT." There is no single ranking to own. The goal is to become an eligible, well-evidenced candidate across the buying situations that produce revenue, then measure whether the product is mentioned, accurately described, and supported by sources a buyer would trust.

ChatGPT recommendations come from several systems

ChatGPT can recommend a product through different paths, and each path uses a different supply of information. A plain model answer may draw on learned knowledge. A search-backed answer can retrieve current web pages and cite them. A shopping experience can use merchant feeds, catalog partners, product pages, reviews, and current commercial data. Treating those paths as one opaque model makes diagnosis impossible.

The distinction founders need is simple:

• Training presence means a model may have learned associations with the product before release. You cannot update that knowledge by publishing a page this afternoon.
• Search eligibility means OpenAI's search crawler can fetch a public page when a current answer needs it.
• Recommendation eligibility means the available evidence makes the product a plausible fit for the user's stated and implied constraints.
• Merchant eligibility means a purchasable item can enter shopping surfaces through supported product data or catalog channels.

These states overlap, but none guarantees the next one. A crawler can access a site that says almost nothing useful. A model can know a famous brand and still reject it on price or geography. A flawless product feed can establish availability while independent reviews expose a bad fit. OpenAI's ChatGPT Search documentation says ranking uses multiple factors intended to surface reliable, relevant information and explicitly says top placement cannot be guaranteed. That is a better operating assumption than any agency promising a fixed position.

Recommendations also change with context. Memory, custom instructions, location, earlier turns, budget, and the words used to describe the job can all alter the candidate set. OpenAI's shopping documentation says product selection considers the query and conversation context, with factors such as price, reviews, and ease of use. A founder who tests one broad prompt in one account has measured one conversation, not market visibility.

Google rank and model selection solve different jobs

Traditional search optimization tries to make a page the best result for a query. Recommendation optimization tries to make a product a defensible answer to a constrained decision. The work shares a foundation, but the output and the failure modes differ.

Google commonly gives the user a ranked set of pages. The user compares those pages and completes the reasoning. ChatGPT can perform much of that comparison itself. It may retrieve several sources, reconcile their claims, apply the user's constraints, and name a small set of products. Your category page can rank well while your product never survives that reasoning.

This changes what good content looks like. A page targeting "best CRM" is weak evidence that your CRM suits a five-seat consultancy that needs EU data residency and a month-to-month contract. A precise deployment page, current pricing page, security documentation, and credible third-party comparison can collectively answer that decision. One verbose article cannot substitute for missing product facts.

Google SEO metrics also stop too early. Impressions and positions tell you whether pages appeared in search. They do not tell you whether ChatGPT named the product, attached the correct category, repeated an obsolete price, cited a competitor, or omitted the product after applying a requirement. Keep Search Console data because discoverability still matters. Add recommendation-level observations because that is where the buying decision now happens.

There is another practical difference: the answer is sampled. Two clean conversations with the same prompt can produce different wording and candidates. Small changes in the prompt can change the shortlist for legitimate reasons. Measurement therefore needs repeated trials and a fixed prompt set, not a screenshot of the answer you liked.

Availability comes before persuasion

The first technical job is to make useful pages fetchable without opening private or low-quality areas of the site. If OAI-SearchBot cannot reach a canonical product, pricing, comparison, or documentation page, polishing its prose will not help a search-backed answer.

OpenAI separates OAI-SearchBot, which supports search discovery, from GPTBot, which relates to model training. A company may choose different policies for those crawlers. Do not copy a blanket bot block from a security checklist without knowing which outcome it disables. Review the current crawler documentation and published IP ranges when configuring a firewall or content delivery network, because a correct robots rule does not fix a network-level denial.

Start with two checks against representative public pages:

site_origin="${1:?pass site origin}"
curl -I -A "OAI-SearchBot" "${site_origin}/product"
curl -s -A "OAI-SearchBot" "${site_origin}/robots.txt"

A healthy first response normally has a 200 status, a stable canonical destination, and an HTML content type. Investigate 401, 403, 429, redirect loops, bot challenges, and a 200 response that contains only a JavaScript shell. The second response should not disallow the paths you expect search to use. Repeat the test from outside your office network if your edge rules depend on geography or reputation scoring.

Then inspect what a crawler actually receives. Put the product name, category, intended user, primary capabilities, limits, price or pricing method, and availability in rendered page text. Do not hide decisive facts behind a login, an interactive calculator, a PDF download, or client-side requests that fail without a browser session. Use canonical URLs consistently, remove accidental noindex directives, keep sitemaps current, and return honest status codes for deleted products.

IndexNow can notify participating search engines when a URL changes, which is useful for price, availability, and product updates. It accelerates discovery; it does not confer authority or force inclusion. The popular recommendation to "submit everything more often" confuses notification with selection. Notify on a real change, then make the changed page worth retrieving.

Evidence must match the decision

The strongest page answers the constraints that cause a buyer to include or exclude the product. Generic thought leadership may create awareness, but recommendation systems need claims they can apply to a decision.

Build a matrix with buying situations as rows and proof as columns. For each situation, record the user, job, hard constraints, acceptable tradeoffs, first-party fact page, independent evidence, and freshness owner. A B2B software row might describe a 20-person agency that needs SSO, a documented export, regional hosting, and a contract below a stated budget. A consumer row might describe a parent who needs a stroller under a given folded size, available in Canada, with replacement wheels.

The page set should follow those decisions. Product and feature pages establish what exists. Pricing, availability, security, compatibility, return, and support pages handle exclusions. Use-case pages explain fit for a real operating condition. Comparison pages should state where a competitor is better as well as where your product wins. A comparison that claims victory on every dimension reads like advertising and gives the system little reason to trust its judgments.

Write quotable facts in ordinary sentences. "Teams can export all projects as CSV without contacting support" is easier to verify than "Take control of your data." "The starter plan supports five editors and excludes SSO" is more useful than "Flexible plans for every team." Keep the marketing line if it earns its place, but put the testable sentence beside it.

Content breadth should not become a factory for near-duplicate pages. A hundred programmatic pages that swap an industry name while repeating the same unsupported claims create more crawl surface, not more evidence. Publish a page only when the situation changes the recommendation: different regulation, workflow, integration, economic constraint, or operational tradeoff. If the answer does not change, strengthen the existing page.

Product data turns claims into selectable facts

For products that can be bought, structured and feed-based data reduces ambiguity about identity, offers, and availability. It does not replace the visible product page or independent evidence.

Use stable identifiers wherever the category supports them: brand, SKU, GTIN, MPN, canonical URL, variant identifiers, currency, price, stock state, and condition. Keep those values consistent across the page, structured data, merchant feeds, and reseller listings. If one surface says the item is in stock at $79 and another says it is discontinued at $99, the system has to decide which source is stale.

A minimal product record shared by the page, structured-data renderer, and merchant export can look like this:

{
  "id": "TK-1L-STEEL",
  "name": "Trail Kettle 1L",
  "sku": "TK-1L-STEEL",
  "brand": "Example Works",
  "price": {"amount": "49.00", "currency": "USD"},
  "availability": "in_stock"
}

The publishing layer can map this record to standards such as Product and Offer JSON-LD, but the values must match what the shopper sees. Do not add review markup for reviews that are absent from the page, invent an aggregate rating, or label a lead-generation page as a purchasable offer. Google's merchant-listing documentation recommends Product and Offer data and warns that Google may verify listing data against the page. That guidance was written for Google surfaces, but the discipline transfers: machine-readable claims work when humans can verify them.

OpenAI's shopping documentation says product results can use merchant metadata from third parties or merchants directly. It also says Shopify Catalog data is integrated for Shopify merchants, while direct feed access is available through OpenAI's merchant process. Feed support and shopping behavior can change, so assign someone to check the current official merchant documentation rather than treating a launch announcement as permanent infrastructure.

For SaaS and services, do not force retail schema onto the business. Clear pricing units, plan limits, supported regions, procurement terms, implementation requirements, and update dates matter more than decorative markup. A recommendation cannot apply a budget constraint when the only published price is "contact sales."

Third-party corroboration beats self-description

Independent sources help a recommendation system distinguish a product's own claims from observed performance and market context. The goal is not raw mention volume. It is consistent evidence from sources that know the category and disclose enough detail to be checked.

Reviews matter when they describe who used the product, for what job, and with what tradeoff. A page full of anonymous five-star quotes gives little context. Detailed reviews on retailer, marketplace, editorial, professional, or community sites can reveal setup difficulty, durability, support quality, and fit for a particular user. OpenAI says shopping research reads public retail sites and uses reliable sources, while its product summaries may draw on third-party reviews. That makes honest review coverage useful, but it does not justify buying fabricated reviews.

Earn corroboration by giving reviewers facts they can test and by fixing the product failures they repeatedly report. Keep company profiles, category listings, partner pages, and reseller data accurate. Correct old names and discontinued plans where the publisher allows it. Do not demand that every negative view disappear. A credible source that names a limitation can improve selection for users who do not share that limitation.

Brand consistency has a technical edge. Use one product name, describe the category consistently, and connect renamed products to their former names on an official page. State the company and product relationship plainly. Models can merge two products with similar names or split one renamed product into separate entities when the web supplies conflicting identities.

Public relations can create useful source coverage, but a press release copied across syndication sites is still one self-authored claim wearing many URLs. Ten copies do not equal ten independent confirmations. Prefer a technical evaluation, a customer account with concrete operating details, or a comparison whose author explains the method.

Retail and B2B products need different proof

Retail recommendations depend heavily on item-level facts, while B2B recommendations depend on operational fit and procurement facts. Applying one playbook to both leaves decisive evidence unpublished.

A retailer should make each variant unambiguous. Color, size, material, stock, shipping destination, delivery estimate, return conditions, seller identity, and current price can all decide whether an item qualifies. Images and reviews help a buyer assess the product, but they cannot repair a feed that maps a blue medium shirt to the URL for a red large one. The catalog, page, checkout, and fulfillment system need the same identifiers.

A B2B buyer asks different exclusion questions. Can the vendor sign the required agreement? Which identity provider and provisioning methods work? Where does data reside? How does export work? What happens when usage crosses a limit? Does the quoted price require an annual contract, onboarding fee, or minimum seat count? A polished feature page that omits those answers may get the product mentioned early and eliminated later.

Services need evidence of scope and method rather than a pretend catalog. State who the service is for, what the engagement produces, how long it takes, what inputs the client must provide, how pricing works, and what lies outside scope. Case material should connect the starting condition, work performed, and observable result without exposing a client or inventing a percentage. A recommendation system needs enough detail to distinguish a fractional operator from an agency, recruiter, coach, or software subscription.

Market and language multiply these requirements. A product available in the United States is not automatically available in Germany. A translated landing page does not prove local shipping, tax handling, support hours, or contractual coverage. Give each market a canonical source of truth and localize the decision facts, not just the slogans. Then test prompts in that language with the actual currency, regulations, and buying vocabulary.

Do not publish an answer merely because competitors publish one. If the business does not support a region, integration, return window, or security control, say so. Clear exclusion data can lower the mention rate on bad-fit prompts while improving recommendation quality on good-fit prompts. That is progress, even though a dashboard built around total mentions will call it a loss.

The usual shortcut measures the wrong thing

The familiar failure starts when a founder asks a marketer to "get us into ChatGPT" without defining the buying situation. The marketer types the brand into ChatGPT, sees that the model recognizes it, publishes several broad articles, and repeats the branded query until a favorable answer appears. The final slide contains screenshots and a visibility score with no reproducible denominator.

Meanwhile, a prospect asks for a product under a specific budget with an export requirement. ChatGPT finds an old pricing directory, a current home page that says "flexible pricing," and a support thread about exports from a discontinued plan. It recommends two competitors with explicit plan tables. The founder's new articles never enter the reasoning because they do not resolve price or export eligibility.

The correct diagnosis begins with the failed prompt and its sources. Capture the exact claim ChatGPT made. Check whether the current plan page answers it in visible text, whether the crawler can fetch that page, whether structured or feed data conflicts, and whether independent sources repeat old terms. Fix the authoritative fact first, request corrections where you can, and rerun the same prompt. Do not change the prompt to one the product wins.

Another popular shortcut is counting how often a brand appears in a large set of synthetic questions. Volume makes the chart look scientific, but loosely generated prompts drift each month and overweight easy branded queries. A smaller fixed cohort tied to customer interviews, sales objections, site search, and support questions produces a comparable signal. Add new prompts in a separate cohort, with a recorded reason and start date.

Sentiment scoring creates a similar distraction. A positive paragraph can still contain a wrong price or recommend the product to an ineligible buyer. Score checked claims and selection outcomes first. Keep qualitative notes for tone only when tone changes buyer behavior, such as a warning that implies unusual risk. Accuracy errors deserve an owner; vague positivity does not.

A monthly test must control the prompt

A useful monthly measurement plan tracks decisions, not vanity mentions. Freeze a prompt set, run it under controlled conditions, save the full answers, and score the product against explicit fields.

Start with 24 to 40 prompts divided among four intent groups: category discovery, constrained recommendation, head-to-head comparison, and product verification. Use the language and markets that produce actual revenue. Each prompt should identify a user and a job, then add constraints a buyer would care about. Include several prompts where the product should not win. If your test assumes universal fitness, it cannot detect whether the system understands the product.

An example set for project-management software might include:

1. "Recommend project-management software for a 12-person design agency that bills clients by project and needs guest access."
2. "Which project-management tools support EU data hosting and SSO for fewer than 30 employees?"
3. "Compare Product A and Product B for an agency migrating from spreadsheets. Include pricing assumptions and export limits."
4. "Does Product A support a complete project export without an enterprise contract?"

Run every prompt in a new conversation with memory and custom instructions disabled. Fix the account tier, interface, model or mode, country, language, and test date in the log. If location matters, run a separate named cohort rather than mixing regions. Run each prompt three times when the interface and budget permit. Repetition will not remove variation, but it will stop one lucky answer from becoming the monthly result.

Save the prompt, complete answer, cited sources, product position if an ordered list exists, and whether search or shopping mode appeared. Record five scores: mentioned, recommended, factually accurate, supported by a first-party source, and supported by an independent source. Add a short exclusion reason when the product is absent or rejected. Use binary values for the first five fields so two reviewers can agree.

Calculate mention rate as runs mentioning the product divided by eligible runs. Calculate recommendation rate the same way but count only affirmative shortlist inclusion. Track factual accuracy as correct checked claims divided by all checked claims, not as a feeling about the prose. Report results by intent group and market. One blended percentage can hide that the product dominates branded verification prompts and never appears in category discovery.

Read the results without fooling yourself

Month-to-month movement needs a cause you can inspect. Model updates, changing web sources, prompt variance, seasonality, availability, and your own site changes can all move the result, so keep an annotated change log beside the scores.

Do not call a mention a recommendation. "Product A lacks the required integration" is visibility, but it is negative selection. Do not call a citation a sale. A cited definition page may support the answer while the named competitor gets the recommendation. Do not treat referral traffic as total exposure. Many users read an answer without clicking, and some interfaces may route or label referrals differently.

Analytics still helps. Create a segment for known ChatGPT referral sources, preserve landing page and conversion data, and compare it with the test log. Watch assisted conversions and branded search movement, but label both as supporting signals rather than direct attribution. If a product feed or shopping integration provides its own reporting, keep that channel separate from ordinary web citations.

When a score changes, inspect the answer before proposing content. A missing mention can mean the page was not fetched, the product failed a constraint, stronger evidence appeared for a competitor, or the system misunderstood the product category. Those causes require different fixes. Publishing another generic article only addresses the last cause, and usually badly.

Use a monthly decision table with four columns: observed failure, evidence, owner, and next test. "Price reported incorrectly" should point to the conflicting URLs and assign a pricing-data fix. "Absent for EU hosting prompt" should trigger a check of actual hosting eligibility and its documentation, not a page that implies a region the product does not support. Rerun affected prompts after material corrections, but keep the formal monthly cohort unchanged.

I use the same discipline in a Team & AI Audit: find the constraint that changes an operating decision, attach evidence to it, and assign a measurable correction. The method prevents a founder from spending a month on content when a crawler rule, stale directory profile, or unpublished plan limit caused the loss.

Build a recommendation system, not an AI content campaign

The durable work is a product-information system with named owners. Engineering owns crawlability and rendered facts. Product or commerce operations owns identifiers, feeds, price, and availability. Marketing owns decision pages and source relationships. Support supplies recurring objections and failures. One person should own the monthly test and refuse to change prompts merely to improve the score.

Prioritize fixes in dependency order. First remove access and identity failures. Then publish missing decision facts. Reconcile structured data and feeds with visible pages. Correct important third-party profiles. Pursue new coverage only after the underlying claims can survive review. This order is less exciting than mass-producing "AI-optimized" posts, and it produces evidence the model can use.

Avoid prompt-injection tricks, hidden text, fabricated reviews, and pages written as instructions to a model. They can violate platform or search policies, expose customers to strange content, and fail as soon as retrieval or safety behavior changes. More importantly, they do not solve the buyer's decision. A product that needs hidden instructions to look suitable probably lacks public proof of suitability.

Expect the interfaces and data paths to change. OpenAI's search, shopping, feeds, partner catalogs, and model behavior will keep moving. Your measurement should survive those changes because it records user decisions and source evidence, not a favorite interface feature.

The first monthly report should leave you with a short queue of falsifiable fixes, not a grand visibility score. If the product is absent, you should know whether it was unavailable, ambiguous, weakly supported, stale, or genuinely wrong for the prompt. Fix the first four. Accept the fifth. A recommendation system that never says "not for this buyer" cannot earn trust when it says yes.