# What Product Information Should You Publish? AI Search for UAE E-commerce By Maria Marnovora We think a UAE online store's product page should carry twenty-eight pieces of product information. This is our list, in five groups. Identity and description: what the thing is and who made it. Price and availability: what it costs and whether you have it. Variants: what it varies by and which option this one is. Getting it to the customer: how it reaches them and what happens if it comes back. Proof and freshness: what backs it up and whether it is still current. If you have come here because you heard that AI assistants now recommend products, none of the twenty-eight makes that happen. What they do is keep your own product pages accurate, which is the part you control. They are not a new file or a new tool. They are the ordinary product information your pages already carry, stated where an assistant or a search engine can read them rather than left behind a dropdown, a link or a checkout step. Google's documentation labels a few of them required and most of them recommended, and four it does not name at all. The answers we logged used three of those four. Your product pages probably hold most of the twenty-eight somewhere. Whether they state them on the page is a different question, and it is the one that decides which version of your product facts is available to be repeated. This article works through all twenty-eight. The spreadsheet published with it lets you score the seven that matter most in about ten minutes, or one full product page with its variant list in about an hour. The short version: the twenty-eight are our own recommendation for describing a product clearly. They are not a statement of anyone's obligations, and nothing in this article describes what any UAE rule requires a seller to publish. Product information is a separate job from company information. Every product fact on your site exists twice, once in the words a customer reads and once in a machine-readable copy inside the page. Where that second copy already claims something the page does not say, fix that before anything else, because it breaks a rule in Google's own published guidelines. Then get the name, image, price and currency right, because those are the ones the documentation calls required. Then get your variants properly linked, because that is where most shops lose. Then write delivery, returns and assembly on the product page rather than behind a link. None of it gets a product shown, named, priced or linked anywhere, and nobody can promise that it will. What it does do is make the correct version of your product facts available to be quoted, which is the part you control. AI Visibility is owned by Lunasol. Why product information is a different job from company information Product information is a different job from company information because the two answer different questions and go out of date at different speeds. Company information answers who you are. Eighteen facts are worth stating, they change about once a year, and our article on the company information your website should include works through them. Product information answers what this thing is, what it costs today, whether you have it, which version the customer is looking at, and how it reaches them. It changes weekly, it is different on every page, and it is usually maintained by a different system from the one that holds your about page. A service page is a different job again, and our article on writing a service page covers it. That difference matters for a practical reason. Company facts go stale slowly and quietly. Product facts go stale fast and loudly: a price that moved, a variant that sold out, a delivery promise from before the last carrier change. Anything reading your site reads the version that is there, not the version you meant. There is also a second copy of every product fact, and most shops forget it. What your page says in words is one copy. What your page publishes as structured data is another. Structured data is a block of machine-readable code inside the page that repeats your product facts in a fixed format, so a machine does not have to work them out from your wording. Where the rest of this article says markup, it means that same block. You cannot see it by looking at the page, and on most shop platforms it is generated for you from the product record rather than typed by hand. Google's guidelines are explicit that the second copy has to match the first: "Your structured data must be a true representation of the page content", and "Don't mark up content that is not visible to readers of the page" (Google Search Central (https://developers.google.com/search/docs/appearance/structured-data/sd-policies)). Its guidance for AI features says the same thing from the other side: "Making sure your structured data matches the visible text on the page" (Google Search Central (https://developers.google.com/search/docs/appearance/ai-features)). Product schema required properties: what Google requires and what it only recommends For a product snippet, Google's documentation requires only the product name plus one of review, aggregateRating or offers. For a merchant listing it requires name, image and offers, plus a price, a currency and a price specification. Everything else on those pages is labelled recommended. Those are two different markup types with two different requirement lists, and a single list of mandatory fields does not match the documentation. A product snippet is the extra detail Google can show beneath an ordinary search result. A merchant listing is the richer shopping treatment, the one with a price, a picture and a stock status. Almost every shop wants the second, so work to the merchant listing list and treat the snippet list as the floor. An offer is the part that carries what a customer would pay and on what terms: the price, the currency and the stock status. A price specification is the structured way of stating the price rather than leaving it as a bare number. For a product snippet, the required properties are the product "name", plus one of "review", "aggregateRating" or "offers". The documentation is explicit: "You only need to provide one of review, aggregateRating, and offers" (Google Search Central (https://developers.google.com/search/docs/appearance/structured-data/product-snippet)). For a merchant listing, the list is longer. Required on the product: "name", "image", "offers". Required on the offer: "price" or "priceSpecification.price", "priceCurrency" or "priceSpecification.priceCurrency", and a "priceSpecification". Where a product is sold by weight, length or volume rather than by the item, the unit price specification carries the per kilo or per metre figure, and it requires its own "price" and "priceCurrency" (Google Search Central (https://developers.google.com/search/docs/appearance/structured-data/merchant-listing)). The recommended list is long enough to be worth seeing in one place, and most of it is set by your platform rather than by you. Skip it on a first read. It is here so that you can hand it to whoever maintains your site, and so that you can check any short list of mandatory fields you are given against what the documentation labels recommended. The twenty-eight fields later in this article are the version written for you to work through. Properties Google's documentation labels recommended for a merchant listing Recommended property Where the documentation lists it aggregateRating On the product audience On the product brand.name On the product category On the product color On the product description On the product gtin, and the gtin8, gtin12, gtin13 and gtin14 family On the product hasAdultConsideration On the product hasCertification On the product inProductGroupWithID On the product isbn On the product isVariantOf On the product material On the product mpn On the product pattern On the product review On the product size On the product sku On the product subjectOf On the product availability On the offer hasMerchantReturnPolicy On the offer itemCondition On the offer priceValidUntil On the offer shippingDetails On the offer url On the offer validFrom On the offer validThrough On the offer Every property in that table is labelled recommended rather than required (Google Search Central (https://developers.google.com/search/docs/appearance/structured-data/merchant-listing)). None of these labels is a statement about what any UAE rule requires you to publish. Two lines on that page are worth pinning up. "Images must represent the marked up content", which rules out using one photograph for eight colours. And Google "may attempt to verify merchant listing product data before showing the information in search results", which is the documentation's own way of saying the data you publish may be checked. One more, from the snippet page, because it catches shops with old sale pages: "Your product snippet may not display if the priceValidUntil property indicates a past date." And if somebody proposes a separate AI layer to you: Google's guidance for its AI features says "There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary", and "You don't need to create new machine readable files, AI text files, or markup to appear in these features". Ordinary product markup, matching the page, is all the documentation asks for. What product information did an AI answer use? Two shopping questions, one e-commerce category In September 2026 we put two questions about one product category to Google's AI Mode, one run each: where to buy the thing online in the UAE, and what to check before buying it online in the UAE. One tool, one day, one category. It is an illustration of what gets used, not a study, and we name no retailer, brand, product or domain. The same category, two questions, two different data sets. The where-to-buy answer ran on trade attributes: delivery coverage by emirate, installation options, breadth of range, shipping terms, authorised stockist status, a variant count, named product series, free assembly, manufacturing location and customisation. The what-to-check answer ran on specification attributes: motor count, leg stages, weight capacity, height range, anti-collision behaviour, memory presets, desktop material, board grade, levelling feet, and whether the parts are bought together or separately. Whatever you sell, you have your own version of that list, and it is often sitting in a specification image rather than in text. A shop that has written only one of those two sets has written for only one of those two questions. Price moved between the two. In the where-to-buy answer, no price appeared in the prose at all. One price appeared on that page, and only inside a source card. In the what-to-check answer, price appeared four times, as bands in dirhams attached to specification tiers, each attributed to a source, and again inside the questions the assistant put back to the buyer. The source card carried what the prose did not. One retailer's card on the first page carried, in a single line, a price in dirhams, a star rating, a review count, an availability status, a "More options" label and a named variant option. None of that was in the answer's text. We did not establish where the card's contents came from, and nothing in this observation shows that any product information causes a card, a price or a rating to be shown. It is still the clearest argument in this article for getting both halves of your own product data right. Variants were a headline number. The answer described one retailer by its variant count and by two variant axes, the things its options vary by. The count ran to dozens, across more than one desk configuration. The range was what it said about that retailer. And three things barely appeared at all. Neither returns nor warranty was mentioned in the what-to-check answer, which is the one that set out what a buyer should check. Availability appeared only as a status inside a card. Returns and warranty are the fields shops most often leave to a linked policy page rather than stating on the product page itself, and availability is the one most easily left out of date. What should a product page include? The twenty-eight fields, grouped The twenty-eight fields we think a product page should include fall into five groups: identity and description, price and availability, variants, getting it to the customer, and proof and freshness. Four of them have no named property at all. Read the first two columns on your first pass. The third is the name Google's documentation uses for a field, which is the word to use when you ask your platform's support desk or whoever maintains your site about it. The fourth repeats how that documentation labels it. This list is Lunasol's, built for this article. Lunasol owns AI Visibility, and the kind of consistency the brand row asks for is one of the things it works on: its published page lists "Entity and brand signal building" among its deliverables (Lunasol (https://lunasol.ae/geo-aeo)). Group one, identity and description: eight fields Field What good looks like What Google's documentation calls it How Google's documentation labels it Product name The name a customer would use, not an internal code name Required for both Description, as text What it is, what it is for, who it suits, in sentences on the page description Recommended Brand As the manufacturer writes it, spelled the same way everywhere brand.name Recommended Category The category a customer would browse category Recommended Main image The exact item on this page, not a different variant image Required for a merchant listing SKU, your own stock code Your own code, stable, different for every variant sku Recommended GTIN, the barcode number printed on the product, or MPN, the manufacturer's part number, where there is no barcode Copied exactly, including leading zeros gtin family, mpn Recommended Condition Stated plainly where it is anything other than new itemCondition Recommended Group two, price and availability: five fields Field What good looks like What Google's documentation calls it How Google's documentation labels it Price What a customer pays today, as text, matching the markup price Required for a merchant listing Currency Three letters, the currency the page displays priceCurrency Required for a merchant listing Price valid until A future date, or none at all priceValidUntil Recommended Availability One status, kept current availability Recommended Unit price, where the product is sold by weight, length or volume The price per kilo, per metre or per litre, with its currency UnitPriceSpecification Required where a unit price is given Group three, variants: seven fields Field What good looks like What Google's documentation calls it How Google's documentation labels it What the product varies by The named things that change between one option and another, such as size, colour or configuration. These are the variant axes, and they belong in the text on the page rather than only in a dropdown variesBy Recommended Parent group identifier One identifier for the family, shared by every option productGroupID Recommended Each option linked to its group Every variant points at the parent, or the parent lists them all inProductGroupWithID, hasVariant Recommended Size As a customer reads it, with the unit size Recommended Colour The name you use in the listing, not a supplier code color Recommended Material What it is made of, in a buyer's words material Recommended Pattern Where the product comes in patterns rather than plain colours pattern Recommended Group four, getting it to the customer: four fields Field What good looks like What Google's documentation calls it How Google's documentation labels it Delivery cost and time On the product page, not only at checkout shippingDetails Recommended Returns terms Your own terms, on the page rather than only linked hasMerchantReturnPolicy Recommended Assembly or installation Assembled, flat packed or installed, and what it costs Not named Not named Who fulfils the order Who ships it and who handles a problem with it Not named Not named Group five, proof and freshness: four fields Field What good looks like What Google's documentation calls it How Google's documentation labels it Ratings and review count Real ratings with a real count, or nothing at all aggregateRating, review Recommended, and one of the three that can satisfy a product snippet Certification or conformity mark Any the product actually holds, named as the scheme names it hasCertification Recommended Specifications as text Dimensions, weight, capacity, power, materials, written out Not named Not named Date last checked The date you last confirmed the row Not named Not named The four unnamed fields are not decoration. Three of them, assembly, fulfilment and specifications, were used by the answers we logged. The fourth, the date, is there because product facts go stale. The review row in group five is easy to misread. A product snippet needs one of a review, a rating or an offer, and an offer satisfies that on its own, so nothing here is a requirement to go and get reviews. Product variants schema: how to group options, and where most shops lose Product variants are handled by grouping them: one parent identifier for the family, named axes the options vary by, and every option carrying its own identifier, price, availability and image, and pointing back at the parent. Google describes the problem in its own words: "Many types of products such as apparel, shoes, furniture, electronic devices, and luggage are sold in different variations (for example various sizes, colors, materials, or patterns)" (Google Search Central (https://developers.google.com/search/docs/appearance/structured-data/product-variants)). Its instruction is to group them rather than to scatter them: "To help Google better understand which products are variations of the same parent product, use the ProductGroup class". A ProductGroup is the parent record that holds the whole family. On most hosted platforms it maps to the thing you already call the product, with each size or colour sitting under it as an option. This is a question about how your variants are set up rather than a new thing to build. Three properties do the work. "variesBy" names the axes: "Aspects by which the variants in the ProductGroup vary, (for example, size or color)". "productGroupID" is described as "The identifier of the product group (also known as the parent sku)". And each variant either sits inside the group through "hasVariant", or points back at it through "inProductGroupWithID". In practice, four things go wrong, and you can check all four in one sitting. Two options share a SKU. Usually because the platform generated one code for the product and the variant dropdown is cosmetic. If two options cannot be told apart by an identifier, there is nothing on the page that distinguishes one from the other. An option has no price of its own. A colour that costs more than the default, with the higher price appearing only after selection, has a price that exists nowhere a machine can read. An option has no availability of its own. The page says in stock because the parent is, while the size the customer wants has not been in stock for a month. Every option shares one image. That contradicts the line quoted above: images must represent the marked up content. The Variants tab in the spreadsheet published with this article is built to find exactly those four. List your options, one per row. It holds twenty rows, which covers most products; where a family runs to dozens of options, list the ten you sell most and treat what you find as a likely pattern in the rest rather than as a finding about all of them. In the SKU, price and availability columns, write the value itself. Where an option has none, leave the cell empty rather than typing the word No, because the counts work by counting filled cells. An empty cell and a value repeated on two rows are both problems. The counts under the list flag each of the four, and a SKU check column marks any code used twice. Which product information goes out of date fastest? Price, availability, delivery and returns Price, availability, delivery and returns are where product information decays, and each has its own failure. Price. Google's guidelines ask for structured data to be a true representation of the page, so the number on the page and the number in the markup should be the same number. Where a sale is over, move the price valid until date forward or take it off, because the documentation says a past date can stop the snippet showing. And state the currency in three letters. The documentation requires priceCurrency for a merchant listing and recommends it for a product snippet, and a dirham amount without a currency code is ambiguous to everything except a person who already knows which country your shop is in. Availability. One status, kept current. The documentation asks for "the single most appropriate product availability option". The common failure is not a wrong status, it is a status that was correct in March. Delivery. State the cost and the time on the product page rather than only at checkout. The answers we logged used delivery coverage and terms to tell one retailer from another, and assembly came up repeatedly, including whether it was included or charged extra. Returns. Write your own terms, on the page. Returns did not appear in the what-to-check answer we logged, which may be because it is one of the fields most often left to a linked policy page. Whether that is worth changing is a commercial decision for you, and what your terms are is a matter for your own advisers rather than for us. Freshness. Every one of those four can be right today and wrong in a fortnight. That is why the last field in the checklist is a date. A product checklist without a date on each row is a photograph of something that moves. How to check your own product page in ten minutes You can check your own product page in about ten minutes, in two passes that need no developer: read the page as a stranger, then compare what it says with what its structured data claims. Before either of them, one thing to know. On a hosted platform you almost never edit the structured data directly. Your platform builds it from the product record, so the fix for most of these fields is the product record itself: the variant table, the price field, the stock field, the image assigned to each option. The fields that do need whoever maintains the site are the variant links and anything your theme or an app is adding on top. Read the page as a stranger. Open your best-selling product on a phone. Without clicking anything, find the price, the currency, the availability, which variant you are looking at, what delivery costs, how long it takes, and what happens if the customer sends it back. Anything you cannot find in ten seconds is a field that is either missing or behind a link. Compare the two copies. Paste the product page address into Google's Rich Results Test (https://search.google.com/test/rich-results) and read the product data it reports back. Ignore everything in the report except the product properties and their values. Put the two lists side by side: what the page says in words, and what the structured data claims. You are looking for three things, in this order: anything the markup claims that the page does not say, anything the two disagree about, and anything the page says that the markup has not caught up with. The first is the one that breaks a published rule, so fix it first. On a hosted platform that one is rarely yours to edit directly: markup claiming what the page does not say is often added by a theme or by an app rather than written by you. The fix is usually to correct the product record it draws from, to check what else the app is doing before you switch it off, or to send whoever maintains the site the page address and the one line from the test that does not match. That last one is a short, specific request rather than a project. If you want that in a form you can keep, the spreadsheet does both passes as a scored sheet and counts the gaps for you. Budget an hour to take one product all the way through the twenty-eight and its variant list. Whether anything reading your site can reach the product page in the first place is a different problem, covered in our article on whether AI search can access your website. The prompts side of this is a separate job, and our article on how to check what AI says about your company sets out how to run and record that on a schedule rather than once. The free product information checklist published with this article The Product Information Checklist comes with this article as a free download, as 16-product-information-checklist.xlsx. It opens in Excel, Numbers or Google Sheets. In Google Sheets, open it through File, Import and pick Replace spreadsheet, which brings the dropdowns through with it. Lunasol's product information checklist Lunasol built this checklist for AI Visibility and released it with this article. It is free to use and free to pass on. Five tabs: how to use it, the twenty-eight product fields, a variants tab, a gap summary that counts your results, and the documentation the required and recommended labels come from. Fill the yellow cells only. Write the fact itself in Your value, then answer three questions: is it stated as text on the page, is it in the structured data, and do the two agree. Row 5 is a grey example row, so leave it alone; your twenty-eight rows are 6 to 33. The verdict column and the counts fill themselves. It is built to be worked through one product at a time, and to be done again in a quarter. Where to start in the sheet. Open the Product fields tab and take your best-selling product. Keep the Rich Results Test open on that same page in another window, because the second of the three questions asks what the structured data says. Where you tried a row and could not get an answer, the dropdown offers Not checked, which the sheet counts as a real answer rather than as a blank. Rows you have not reached yet are better left empty, so the tab can tell the two apart. Fill rows 6 to 10 first: name, description, brand, category and image. Write the fact itself in Your value, then answer the three questions above. Five rows take about five minutes, and the Verdict column will already name the failures you have. Then do rows 14 and 15, price and currency. Those two, with the name in row 6 and the image in row 10, are the four fields on this sheet that the merchant listing documentation requires. That is seven rows, about ten minutes once the two passes above are done. The Gap summary tab then counts how many rows are still unanswered, how the ones you did answer came out, and how consistent they were, so you can stop there and come back to the rest. If the structured data half is the one you could not answer, the consistency figures will read zero on a first pass, because a row cannot count as consistent until both halves are answered. Read Stated as text on the page instead. That half is the one you can fix on your own. Lunasol, which owns AI Visibility, lists "Schema and structured data implementation" among its published deliverables, alongside "Schema markup, FAQ, HowTo, and more", inside a four-step process of audit, signals, content and quarterly tracking (Lunasol (https://lunasol.ae/geo-aeo)). Where to start with your own catalogue Pick one product, the one you most want to sell, and score it. Then pick a second one a week later. If the two score the same way, the problem is your template rather than either product, and fixing the template fixes every page at once. If you would rather have somebody run it with you, Lunasol offers a free AI visibility check as a starting point. Its published process and its contact routes, WhatsApp and email, are at Lunasol (https://lunasol.ae/geo-aeo): there is no form, and the stated reply time is within the hour. Common questions Nine questions about the twenty-eight fields. What product information should an online store publish? Name, description, brand, category, image, an identifier, condition, price, currency, availability, variant axes and options, delivery, returns, assembly, specifications and a review record. Twenty-eight fields in all, and the five grouped tables above say which of them Google's documentation labels required and which it labels recommended. That is our recommendation for describing a product clearly, not a legal requirement. Nothing here states what any UAE rule requires you to publish about price, delivery, returns, warranties or conformity. Do I need product schema markup for AI search? You do not need anything new for it. Google states that "There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary" and that "You don't need to create new machine readable files, AI text files, or markup to appear in these features". Ordinary product markup, matching the page, is the whole of what the documentation asks for. What are the required properties for product schema? For a product snippet: the name, plus one of a review, a rating or an offer. For a merchant listing: name, image, offers, and on the offer a price, a currency and a price specification. Everything else on those pages is labelled recommended. Those are Google's labels for structured data in its own search features. They are not a statement about what any UAE rule requires you to publish. What is the difference between a product snippet and a merchant listing? A product snippet is the extra detail Google can show beneath an ordinary search result, and it needs the product name plus one of a review, a rating or an offer. A merchant listing is the richer shopping treatment, the one with a price, a picture and a stock status, and it needs name, image and offers, plus a price, a currency and a price specification on the offer. The same property can be required for one and recommended for the other, which is why a proposal that hands you a single list of mandatory fields is worth a question. Do I need a GTIN for every product? No, Google's documentation does not require a GTIN for every product: it lists the gtin family and mpn among the properties it recommends for a merchant listing, not among the ones it requires. That is Google's label for its own search features, and it is not a statement about what any UAE rule requires you to publish or to hold. Where the product already carries a manufacturer's barcode, publish that number exactly as printed, leading zeros included. Where it does not, because you make it yourself or it is a bundle, use the manufacturer part number if there is one, and your own SKU either way. Nothing here is guidance on registering, licensing or obtaining an identifier. A wrong identifier is worse than an absent one, because it describes a different product. How do I mark up product variants? Group your variants into one product group: give the family one identifier, name the axes the options vary by, give every option its own identifier, price, availability and image, and link every option to the parent. Does my shop platform add the product markup for me? Many hosted platforms generate it from the product record rather than anyone typing it into the page. Platforms differ, though, and we make no claim about any particular one, so check yours rather than assuming. Google's Rich Results Test will show you what your page publishes today. Where it is generated that way, the fix for most of these fields is the product record, not the markup: the variant table, the price field, the stock field, the image assigned to each option. The variant links, and anything a theme or an app adds on top, are the part that usually needs whoever maintains the site. Does any of this get my products shown in AI answers? No, and nobody can promise that it does. OpenAI's help pages state that "Placement is not guaranteed" and that "Search results and citations can be incomplete, outdated, or incorrect" (OpenAI Help Center (https://help.openai.com/en/articles/9237897-chatgpt-search)). What this work does is make the correct version of your product facts available in a form that can be read and quoted, which is the only part of it you control. How often should I check my product pages? Once a quarter for the template, and whenever a price, a variant or a delivery term changes for the individual product. The last field in the checklist is the date for that reason. What this checklist cannot do A product information checklist cannot make a product appear anywhere. It cannot make a price competitive, a delivery time shorter or a photograph better. It cannot tell you what your returns terms should be, and it does not try to: that is a commercial and legal question for your own advisers. What it can do is stop you losing on the mechanical things. A variant with no identifier, a price the markup disagrees with, a stock status from last quarter, an assembly cost that only appears at checkout. None of those are strategy. They are the kind of thing that is invisible until somebody quotes the wrong one back at your customer. Method, sources and notes This article and the checklist published with it are general guidance on describing products on your own website, current at September 2026. They are not legal, tax, consumer-protection, e-commerce, customs, warranty or returns advice, and nothing in them describes what any UAE authority requires or permits you to publish about prices, delivery, returns, warranties, conformity or product claims. Nothing in this article or in the spreadsheet describes what any conformity, certification or safety scheme requires of any product sold in the UAE. One assistant answer we logged told a buyer to check compliance with a conformity scheme; we do not repeat the scheme's name, we do not report it as a requirement, and we make no statement of our own about it. Check your own obligations with somebody qualified before changing what you publish. Nothing here gets a product shown, named, priced, linked or recommended in any AI product, and nobody can promise that it will. The required and recommended labels in this article and in the spreadsheet repeat how Google's published documentation labels each property, as fetched on 21 September 2026. That documentation changes without notice, so check the current version before relying on it, and note that the two markup types have two different requirement lists, which is why the same property is required in one and recommended in the other. The live check was one tool, one day, one connection, one product category, two questions and one run each. It is an illustration of what an answer used, not a study, and nothing in it is a finding about any retailer, brand or product. We name none of them, and we name no domain. We did not attempt a second assistant: this environment produced no usable answer from it across three earlier articles in this series, and that decision was taken before these runs rather than after them. We report attribute types, counts and structure. The logged runs are available on request. Assistant answers vary by account, location and time. Product and company names are used here for identification only. Neither this publication nor its owner is affiliated with, endorsed by or sponsored by any of them, nothing here is an endorsement by us of any of them, and none of them has reviewed, approved or contributed to this article. ChatGPT is a product of OpenAI, and the OpenAI Help Center is a publication of OpenAI. Google Search, Google Search Central, Merchant Center, the Rich Results Test, AI Mode and AI Overviews are products or publications of Google. schema.org is an independent collaborative vocabulary. Excel is a product of Microsoft, Numbers of Apple, and Google Sheets of Google. WhatsApp is a product of Meta. All are trademarks of their respective owners. AI Visibility is owned by Lunasol.