Product Page SEO: Descriptions, Reviews and Structured Data That Earn the Click

A modern product page is not just a page that describes a product. It is a structured, verifiable representation of that product, built for people, search engines and AI systems alike, and most stores still treat it as a template with a photo and a button.

SHORT ANSWER

One Architecture, Four Directions

A product page ranks, sells and gets cited when it is a structured, verifiable representation of the product: clear about what the item is, complete in its data, honest in its claims and consistent everywhere it appears. Photos, a price and a button are the minimum. What separates a strong card is the information architecture behind it: an unambiguous product identity, specifications stored as data, a description written for real customers, reviews and questions from real buyers, related products built from real relationships, and markup that matches what the page actually says.

SEO, AEO, GEO and E-E-A-T are often treated as four separate sets of tags to add. Their requirements overlap almost entirely: quality of information, technical accessibility, structured data, the reputation of the brand and claims that can be checked. Our principle at Peretz Agency is simple: not four layers of optimization, but one information architecture that works in four directions. The task is not to add as many signals as possible; it is to build a reliable, understandable and consistent model of the product. Built that way, a product page becomes more than a place to show a name, a photo and a price: it is a source of information and a point of decision, a support channel with expert guidance, and a way to hear back from buyers.

This article is the third in our series, after e-commerce SEO built into the store and filters and faceted navigation.

THE ENTITY

The Product as a Digital Entity

At the core of every product page there should be an unambiguously described product. A system reading the page has to understand what the item is, who made it, which characteristics distinguish it from similar items and which category or collection it belongs to. In practice that means a defined set of facts for every product:

• the name and the type of item;
• the brand and the manufacturer;
• a unique identifier, such as an SKU, and a GTIN or MPN where one exists;
• materials and physical characteristics;
• dimensions, weight, color and available variants;
• links to its category, collection and related products;
• images of this exact item, not of a similar one.

Take a pearl necklace. "Pearl Necklace" is not enough for a customer, a search engine or an assistant. If the facts are known and confirmed, the page should state the type of pearl, the metal, the length, the clasp and anything else that matters to someone choosing it. And if a fact is not known, it should not be invented to make the card look complete. An unverified claim on a product page is a risk for the brand, not an optimization.

THE SEQUENCE

Order Is the Strategy

A product card is a sequence. The order in which information appears decides whether a customer understands the product, trusts it and buys it, and the same order decides how easily a search engine or an assistant understands it. In most categories the questions come in a predictable order: what is this, is it right for me, what exactly is it made of, how much and when will I get it, what do other buyers say, and what goes with it.

The first screen has to answer the first questions without a click: the name, the key attribute, the price, availability and delivery. A customer should never have to open three tabs to find the one fact that decides the purchase. Information hidden in collapsed tabs, sliders or images is harder for customers to find and harder for machines to read, and it is usually the information that matters most: material, size, compatibility, care.

The order also depends on the market. A mass-market card is built for speed and comparison. A luxury card can open with video and take its time, as long as the full text about the piece is part of the page. We described that difference in the main article of this series.

A product card is a sequence of answers, not a container for a photo.

DESCRIPTIONS

Writing What the Manufacturer Did Not

The fastest way to fill a catalogue is to copy the manufacturer's description, and the result is a page that says exactly what fifty other stores say. It tells Google nothing new about yours, and it tells the customer nothing about why to buy here. In the pet supply store we took over, almost every description had been copied, and that was one of the problems we had to work through.

A useful description is written for the store's own customers. It explains who the product is for, how it is used, how it differs from the nearest alternatives and what people usually ask before buying. It uses the words customers use, which site search queries and buyer questions reveal for free. That is one of the few things on a product page that competitors cannot copy overnight.

Large catalogues need a plan rather than a promise to rewrite everything. We start with the products that bring the most revenue or have the most search demand, write those by hand, and build careful templates for the long tail, filled from real specifications rather than generic phrases. AI can help draft descriptions at scale, but only when every draft is built from real product data and checked by someone who knows the product; otherwise it produces the same generic text as everyone else, a problem we wrote about in When Everyone Can Publish 500 Articles.

ONE DATA MODEL

One Data Model Instead of Four Optimizations

The key architectural idea is to store product information in a single model and use it in every representation: the customer-facing card, the structured data, the product feed and the store's internal systems. For a piece of jewelry, that model might hold a stable product ID or SKU, the brand and product type, and the confirmed material and pearl type. It would add the length and weight with units and the collection, then the current price and currency and actual availability, and finally care instructions, warranty terms and images of that exact piece.

This is a conceptual model, not a final database schema, and it has to be adapted to the real catalogue and the business processes behind it. What it does is separate two kinds of information. Standardized facts such as price, availability and dimensions can come from structured fields and update everywhere at once. The story of a collection, the explanation of design decisions and editorial recommendations need separate preparation and checking by people who understand the product. We keep the data that can be formalized apart from the content that needs human understanding and expertise.

That is also why the order of work matters, as we explained in the article on filters: the data model comes first, and the card, the filters and the feed are built on top of it.

FOUR DIRECTIONS

What SEO, AEO, GEO and E-E-A-T Each Need

The same architecture serves four directions, and it helps to be clear about what each one asks of the page:

• SEO is about discovery, crawling and understanding: a stable address and a unique title, internal links to the category and collection, a correct canonical address and clear rules for indexing variants. It does not come down to meta tags, and it does not guarantee rankings on its own.
• AEO, answer engine optimization, means organizing information so that specific questions about the product get precise answers. What is it made of? Which type of pearl is used? How long is the chain, and can it be adjusted? How do I care for it? How does it differ from the model next to it? What are the delivery, return and warranty terms? The answers have to be in accessible content on the page, not only in advertising language, and no special "AI tags" are needed for each question.
• GEO, generative engine optimization, is about making product information usable for generative search: unambiguous identification, explicit specifications, context for choosing based on real properties, a page that loads properly with its main content, and no contradictions between the page and other representations of the same product. There is no universal algorithm that guarantees a product will be mentioned in an AI answer.
• E-E-A-T, experience, expertise, authoritativeness and trust, moves a premium brand from claims to evidence: who stands behind the item, what exactly the buyer gets, where materials come from and how the piece is made when that is reliably known, the warranty, returns, delivery and service, genuine reviews, and certificates only for properties that documents actually confirm.

Badges do not create trust. Claims that can be checked do.

E-E-A-T should not turn into a decorative row of icons. A badge, the word "Certified" or a beautiful brand story does not build trust by itself; trust appears when the claims can be verified and the information matches reality.

REVIEWS AND QUESTIONS

Questions, Reviews and Expert Answers

Reviews and questions from real buyers are exactly what Google means by experience in E-E-A-T. They are also content the store cannot write itself: they use the customers' own words, answer doubts the description missed and keep the page changing over time.

The pet supply store is our clearest example. Before our work, customers could not ask a question on a product page at all, so we added that function. At first the store's sales managers answered, and one of them had previously worked as a veterinarian, so questions that needed real animal-care expertise got an expert answer right on the page. The product card stopped being a display and became a source of information and a support channel, with expert advice available at the moment of choice.

Reviews came in every kind, and negative ones were published too. With every unhappy customer, the team's first step was to get in touch, understand what had happened and try to resolve the problem. Only two kinds of reviews stayed unpublished: those whose authors could not be reached at all, so the complaint could not be checked, and openly abusive ones full of profanity. The cards also carried labels that helped people scan the catalogue, such as bestseller, new and sale, along with recommended, out of stock and extra discount markers. Alongside that, we consistently asked customers to leave reviews on the store's Google Business profile, and answering those reviews mattered as much as collecting them.

That approach is close to what US rules now expect. The FTC's rule on consumer reviews, in force since October 2024, prohibits suppressing negative reviews while presenting the rest as the full picture, so a store selling in the US should publish its moderation rules and apply them equally to positive and negative reviews: abuse, spam, content unrelated to the product, or reviews that cannot be linked to a real customer.

What we saw afterwards was organic growth that showed up first on product pages in Search Console and analytics, and later across the whole site, and people spending real time interacting with the cards; even writing a negative review takes time on the page. We cannot say that questions, reviews or labels alone caused that growth, and we would not claim a precise effect without a before-and-after analysis. What the sequence suggests is that pages which help people decide also tend to be the pages search engines show. The store is still one of the largest pet stores in Ukraine.

Every question on a product page shows a gap the description left.

Questions are often more valuable than reviews. Every question a customer asks on a product page shows what the description failed to explain, and every answer becomes text that the next customer, and the next search, can use. A store that answers questions on the page is writing its best content in public, one customer at a time.

RELATED PRODUCTS

Relationships, Not Recommendations

A block of "you may also like" filled at random helps no one. Related products work when they come from real relationships between products: the same collection, the same material, a matching accessory, a compatible part, an alternative at a different price. Those relationships become part of the store's information architecture, giving the customer a reason to stay and giving search engines a map of how the catalogue fits together.

We build these relationships through object-oriented UX: first we define what a product is in the system, which properties it has and what it is connected to, and only then decide how those connections appear on the page. We work this way on Schoeffel, Nicole, Nico Juliany, SHTAYER and other stores where relationships between products matter, by collection, material, purpose or compatibility depending on the business. The opposite mistake is linking everything to everything: a relationship has to make sense to the buyer, or it becomes noise.

STRUCTURED DATA

Markup That Search and AI Read

Structured data describes the product to machines in a standard vocabulary: what it is and who makes it, what it costs and whether it is available, and what buyers think of it. Google recommends correct Product and Offer markup for product pages, and uses it for two kinds of results, product snippets and merchant listings. Markup helps systems interpret the facts, but it does not guarantee rankings, a rich result or a place in an AI answer, and it must always match what the page visibly shows.

Several parts of that vocabulary changed recently and are worth checking on any store:

• Variants. Since February 2024 Google supports markup for product variants, so a product sold in several sizes or colors can be described as one product group with its variants instead of a set of unrelated items.
• Shipping and returns. Google supports structured data for return policies, including at the level of the whole organization, and shipping and return settings can also be configured in Search Console. Clear delivery and return terms are trust signals for customers and data for search.
• FAQ. Google stopped showing FAQ rich results in May 2026. Questions and answers on a product page are still useful to customers and to AI assistants, but they should be written for people, not for snippets.

The same data feeds Google Merchant Center, which makes the catalogue available for free product listings. Google says its Shopping Graph holds more than 50 billion product listings, and its AI Mode now answers shopping questions with prices, reviews and stock. The store's own data, clean and consistent across the page, the markup and the feed, is what every one of these systems reads.

VARIANTS

One Product, Many Versions

Colors and sizes raise a structural question: should each variant have its own page, or should one page let the customer choose? There is no single answer. A size rarely deserves its own page, because people rarely search for a size without a product. A color sometimes does, when customers search for it directly and the variants look different enough to be different products for them.

The decision follows the same logic as filters. If a variant matches its own search demand, it can have its own address, with a canonical tag that reflects that decision; if it does not, it stays a selection on the main product page. What a store should avoid is the accidental version: dozens of near-identical variant pages created by the platform, competing with each other and with the main product.

THE BASICS

The Basics, Checked on Every Template

The basics rarely make a card exceptional, but their absence makes it fail, and on a large catalogue one template mistake repeats thousands of times. On every product template we check:

• a page title of roughly 50 to 60 characters with the product name and its key attribute, and a meta description of up to about 155 characters written as a short advertisement;
• one clear heading and a clean, stable address;
• image descriptions that say what is in the picture, which many stores simply do not have;
• breadcrumbs that show where the product sits in the catalogue;
• loading speed on mobile, especially with large photo galleries;
• delivery, payment and return information visible near the price.

The clothing store we worked with after its drop in visibility had almost all of these problems at once. We rewrote the product cards, added the image descriptions it had never had, improved speed, and brought back breadcrumbs that the original design had removed for the sake of looks; session recordings later showed that customers use them. We also added payment in installments and a current shipping module, because a card that answers every question except "how do I pay and when will it arrive" still loses the sale.

BEFORE LAUNCH

Six Signal Groups and a Pre-Launch Checklist

To check product pages systematically, we group what we look at into six sets of signals. This is Peretz Agency's internal project model, not an official Google classification and not a claim about six separate ranking algorithms. The groups overlap, and their value is in making sure nothing is forgotten:

• identity signals: the name and brand, the product type, identifiers such as SKU or GTIN, and links to other entities;
• product data signals: materials and dimensions, color and weight, other characteristics, and the variants and images;
• commercial signals: price and availability, delivery and returns, and the warranty and terms of purchase;
• semantic signals: clear headings, a logical content structure, answers to questions and relationships between products;
• trust signals: confirmed information about the manufacturer, genuine reviews, transparent terms and verifiable claims;
• discovery signals: an indexable address, internal links, the sitemap, technical correctness and accessibility.

Before a store or a new product template goes live, we run through a checklist built on those groups:

• The product has a stable address.
• The name identifies the item unambiguously.
• The main characteristics are presented in a structured form.
• The images show this exact product.
• Price, currency and availability match the real data.
• Product and Offer markup is implemented correctly and matches the visible content.
• Variants are linked to each other correctly.
• Canonical and indexing rules are set correctly.
• The page is linked to its category and relevant collections.
• A customer can find answers to the main questions.
• Delivery, return and warranty terms are visible and clear.
• Claims about materials, origin and production are confirmed.
• The structured data passes validation.
• After launch, errors and inconsistencies can be tracked.

HOW WE WORK

How We Build Product Cards

We design the product card after the data model and before the screens. First we define the product as an object: its properties, its variants and its relationships. Then we decide the sequence in which a customer needs that information, and only then draw the page. That is why the same card can serve the customer, the filters, the feed and the markup without anyone retyping the same facts four times. A modern product page, in our view, is not a page that describes a product; it is a structured, verifiable representation of it, built for people, search engines and AI systems alike.

For stores that are already live, we start with an audit of the product templates and a sample of real cards, then work through descriptions, specifications, reviews and markup in order of impact. The work is part of our e-commerce SEO, and for new stores, part of e-commerce development from the first sketch.

FAQ

Sources

• Google Search Central: Product structured data
• Google Search Central: Merchant listing structured data
• Google Search Central: Creating helpful, reliable, people-first content
• Google Search Central: Adding structured data support for product variants (February 2024)
• Google Search Central: More ways to share your shipping and returns policies with Google
• Davis Wright Tremaine: FTC finalizes rule banning fake consumer reviews (August 2024)
• Search Engine Journal: Google drops FAQ rich results
• TechCrunch: Google expands AI shopping (November 2025)