How do you do e-commerce SEO?

Why does e-commerce SEO not start with writing copy?

On an e-commerce site the content is product data, not blog posts. A search engine and a generative engine ask the same questions when recommending a product: what is it called, who makes it, what does it cost, in which currency, is it in stock, what is the returns position. If the answers are not on the page in structured form, the product stays unrecommendable no matter how well it is written about.

So the order is settled: product data first, page copy second, category content last. Projects that start from the other end typically end up with a beautifully written catalogue whose prices are invisible to machines — and a product whose price cannot be read falls out of scope on every question that asks for a comparison.

Which data is required on a product page?

The set of fields Google requires for merchant listing experiences is smaller than people expect; the real difference is made by the recommended ones. Without the required fields a product is not listed at all; without the recommended ones it is listed, but incompletely.

Google's rule is explicit: only pages where a shopper can purchase the product are eligible for merchant listing experiences, not pages linking to other sites that sell it. Comparison pages and affiliate listings fall outside for exactly this reason.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Ergo 300 office chair",
  "image": ["https://example.com/img/ergo-300.jpg"],
  "description": "Office chair with adjustable lumbar support and 4D armrests.",
  "sku": "ERG-300-BLK",
  "gtin13": "8691234567895",
  "brand": { "@type": "Brand", "name": "Kuzey" },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/product/ergo-300",
    "price": "8450.00",
    "priceCurrency": "TRY",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "TR",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 14,
      "returnMethod": "https://schema.org/ReturnByMail",
      "returnFees": "https://schema.org/FreeReturn"
    }
  }
}

How do you mark up product variants?

In a shop with colour and size options this is the most expensive markup mistake there is. Mark the same chair's four colours as four separate Products and an engine sees four different products, each a near-duplicate of the others; done properly it sees one parent product with four variants attached.

• The parent node is of type ProductGroup, and the only field it requires is name.
• productGroupID is the parent's code (the parent sku) and is written identically on the ProductGroup and on every variant.
• Variants are either listed under hasVariant or attached upward from their own pages with isVariantOf.
• Every variant needs its own sku or gtin; that is what distinguishes them.
• The variesBy field names the distinguishing properties by their full schema.org URL: https://schema.org/color, https://schema.org/size. The supported values are colour, size, suggested age, suggested gender, material and pattern.

{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "name": "Ergo 300 office chair",
  "productGroupID": "ERG-300",
  "variesBy": ["https://schema.org/color"],
  "hasVariant": [
    {
      "@type": "Product",
      "sku": "ERG-300-BLK",
      "color": "Black",
      "gtin13": "8691234567895",
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/product/ergo-300?color=black",
        "price": "8450.00",
        "priceCurrency": "TRY",
        "availability": "https://schema.org/InStock"
      }
    },
    {
      "@type": "Product",
      "sku": "ERG-300-GRY",
      "color": "Grey",
      "gtin13": "8691234567901",
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/product/ergo-300?color=grey",
        "price": "8450.00",
        "priceCurrency": "TRY",
        "availability": "https://schema.org/OutOfStock"
      }
    }
  ]
}

When variants sit on separate pages the rule changes: each page must carry full, self-contained markup. The ProductGroup definition is repeated on every variant page, with the other variants listed as stub entries carrying only a url. In the single-page structure there must instead be exactly one canonical URL for the ProductGroup, and selecting a variant does not change it.

Why must the feed and the page say the same thing?

The product feed and the markup on the page describe the same product through two channels, and when they disagree neither side wins — the product loses credibility in both. The most common disagreement is price: the feed updates nightly while the page changes instantly, so at the start of a promotion the two records do not match.

• Price and currency must update in the feed and the page markup at the same moment; generating both from one source solves this structurally.
• Availability follows the same rule: the page saying "sold out" while the markup still says InStock is among the most common causes of a listing being dropped.
• The GTIN must be identical and numerical in both channels, and the most specific GTIN that applies to the product is the one to use.
• If the brand reads "Kuzey" in the feed and "Kuzey Mobilya" on the page, two different manufacturers appear; pick one spelling and hold it everywhere.
• A description copied from the manufacturer shares the same text with hundreds of retailers in both channels; the only thing that makes the product distinguishable is the usage and dimension detail you write yourself.

Category page or product page?

The distinction is intent. Someone searching "office chair" has not decided yet and wants to see options; a category page answers that. Someone searching "Ergo 300 price" has decided and is verifying; a product page answers that. Chasing both on one page means half-serving both intents.

In generative engines the distinction sharpens further, because a question like "which office chair should I buy" sends the engine looking for a page it can compare from. Putting a table on the category page that compares dimensions, materials and use cases is the shortest route to making that page quotable.

Should an out-of-stock product page be deleted?

No. Deleting the page throws away the link equity and the search history that accumulated at that address, and when the product returns you start from zero. The right move is to update availability in the Offer markup to OutOfStock, state the situation plainly on the page, and show alternatives.

If the product is gone for good the decision changes: redirect the page to its nearest equivalent with a 301. Redirect to the equivalent product, not the category — bulk-redirecting to a category drops the user on a list that does not contain what they were looking for, and on the search side it gets treated as a soft 404.

How do you write a product description that gets quoted?

A description copied from the manufacturer shares its text with hundreds of retailers, so no engine has a reason to prefer it. What distinguishes a page is the information the manufacturer did not write: who the product suits, which size matches which use, what it is used alongside, and where it falls short.

• Put a 40–75 word answer passage at the top of the page: what the product is, who it suits and what distinguishes it, in one paragraph.
• Write the specifications as a table rather than prose; engines lift a table whole and reformat it at answer time.
• Give dimensions with units and in one system; the adjective "wide" enters no comparison, "64 cm" does.
• Write the three most frequent questions into the product page — delivery time, return terms, compatibility. These are the last questions before a decision.
• Show customer reviews on the page; a rating that appears in the markup must be visible on the page, and a rating you generated yourself cannot be published.