How Do I Add Warranty Data to Google Merchant Center?

Add warranty data to Google Merchant Center through the product data source you already use. For a text feed, add a warranty(duration:duration_unit) column and enter a value such as 3:year for a verified three-year warranty. XML and Merchant API submissions use different structures, but should describe the same coverage.

The important part is checking the product after Google processes the update. A field in your spreadsheet or a successful API response does not prove that the final product contains the intended value.

The examples below cover standard products and reflect Google's documentation checked on October 18, 2026. They are illustrative data fragments, not results from a live merchant-account test.

When should you submit warranty information?

Google now documents the warranty attribute for general products, alongside its separate vehicle-ad implementation. Search Engine Land reported the expansion on October 16, 2026. That is the reporting date, rather than a precise rollout date supplied in Google's help page.

The official warranty specification describes an optional attribute for communicating coverage in ads or free listings, including situations involving local disclosure requirements. It does not say every merchant must populate every product.

For standard products, distinguish the overall attribute from the information inside it: when submitting warranty data, provide both the duration and its unit. Do not send an unexplained number and expect Google to infer years.

Google specifically calls for a year-based period in its Quebec Bill 29 example. That formatting instruction does not determine which goods, warranties or advertising obligations apply to your business. Establish the applicable coverage and disclosure obligations before choosing the feed value.

Vehicle ads in Japan have additional rules, including mileage-related data. Those are outside this guide; do not copy a vehicle warranty example into an ordinary electronics, appliance or furniture feed.

Prepare a warranty record for each product

Start with the coverage the buyer actually receives for that offer. A manufacturer's document, your product-specific terms and the selected variant should agree before you automate the export.

Create a small internal worksheet like this. These are suggested working columns, not extra attributes Google requires:

Keep the source document or its reference with the record. If a supplier changes the warranty, you need to identify affected products without guessing from a category label.

Do not replace missing coverage with 0, a convenient default or an invented number for a lifetime promise. Route unknown records for clarification before generating the attribute. A return window, an optional protection plan sold separately and an included warranty are different customer promises; map the one your product's warranty field is intended to describe.

Also check variants and product condition. A blanket rule such as "all appliances have three years" is only appropriate if you can substantiate it for every included offer. The same accuracy principle applies to the product-page trust information covered in Screpy's ecommerce SEO guide.

Add warranty data to CSV, TSV or XML

Choose the syntax for the source that actually sends your products. The examples here add a warranty to an existing offer; they do not replace the rest of a valid product feed.

Spreadsheet and text feeds

For a spreadsheet exported into a compatible text feed, use this exact column header:

warranty(duration:duration_unit)

The subattribute order in the header determines the order of the values. Keep the duration first and unit second:

id,warranty(duration:duration_unit)
KETTLE-100-BLACK,3:year
LAMP-200-WHITE,18:month

This is an illustrative two-column extract from a larger file. Keep your existing title, link, image, price and other applicable attributes. If you intend to submit only an ID and an extra field, use a properly configured supplemental source rather than treating this extract as a complete primary feed.

In a TSV file, use tabs between columns. The colon inside 3:year remains the separator between the warranty subvalues; it is not a replacement for the file's column delimiter.

Use singular technical tokens, such as month and year, rather than translated words or a phrase like three years. Do not add quotation marks as part of the warranty cell's content. This does not override ordinary CSV escaping rules for other fields that contain commas or line breaks. Google's attribute submission guidance explains technical names and subattribute formatting.

XML feeds

Inside the existing product's <item>, add:

<g:warranty>
  <g:duration>3</g:duration>
  <g:duration_unit>year</g:duration_unit>
</g:warranty>

The surrounding feed must already declare Google's namespace, normally on its root element:

xmlns:g="http://base.google.com/ns/1.0"

The snippet is not a standalone XML document. Keep the existing item identifiers and all other required offer fields. A namespace declaration gives g: its meaning; typing the prefix alone is insufficient.

Whichever format you use, inspect the generated export itself. Seeing two populated warranty fields in your store's administration screen does not prove the export includes the correct column or XML elements.

Use the Merchant API warranty object

For an API-managed catalog, use the structure documented for your API version rather than translating XML element names directly into JSON. The current ProductInput resource places typed product fields under productAttributes.

An illustrative fragment for the same three-year coverage is:

{
  "productAttributes": {
    "warranty": {
      "duration": "3",
      "durationUnit": "YEAR"
    }
  }
}

The current ProductAttributes warranty reference defines duration as an int64 represented by a JSON string. Its unit field is durationUnit, with MONTH and YEAR enum values. Those uppercase API values differ from the lowercase text-feed tokens. Do not send the CSV string 3:year as the entire API warranty object.

This is a field fragment, not a complete insert request. Keep the required product identity and other offer attributes in your existing integration. API-based product writes require an API data source, as explained in Google's Products sub-API overview.

There is a documentation detail to watch: the general-product help page links to Merchant API resources, while parts of the API warranty reference still use vehicle wording. Verify the fields exposed by your actual client library and API version, then check the processed product after submission. The existence of the documented object does not prove that every ecommerce connector already exports it.

If your integration rejects the field, preserve the validation response for investigation. Check its schema and client version before changing field names or inventing a custom encoding. We have not submitted this example to a live merchant account.

Submit the update and verify the processed product

Make the change in the system that owns your product source. For a store connector, that may mean updating its mapping and regenerating the export. For a file, it means updating the uploaded or fetched file. For an API integration, update the data your application sends.

Avoid a second, competing source unless you deliberately configure how its values should supplement the existing products. An edit that looks correct today can disappear when the next scheduled export sends the old data again.

Use a small, representative pilot before applying a broad mapping:

1. Record the existing identity. Keep the offer ID, language, feed label or relevant source context, and product URL. You are updating the same offer, rather than creating a duplicate to test one attribute.
2. Check the outgoing data. Save the generated row, XML item or API payload with a timestamp. Confirm that it describes the chosen product's actual coverage.
3. Run the normal submission. Upload, fetch or synchronize through the existing source's supported workflow. Inspect its processing result for formatting or field errors.
4. Inspect the final product. Check the effective attributes and current product issues in Merchant Center. For API workflows, retrieve the processed Product, not just the submitted ProductInput or write response.
5. Check destination status separately. A correctly populated warranty is one piece of the offer. Other data or policy issues can still prevent the product from appearing.

Google's processed-product and issue guide explains that processing is delayed and that final products reflect source merging and rules. Do not immediately treat an unchanged readback as a failed write; check whether the latest update has finished processing first.

Keep a simple reconciliation log for the pilot:

These checkpoints answer different questions: was the field sent, was it retained after processing, and is the product eligible for the intended destination? None proves a particular warranty presentation will appear in an ad.

If you are also preparing for Google Universal Cart, keep that onboarding work separate. A warranty update improves a specific part of your catalog data; it does not replace the requirements for another shopping experience.

Fix common warranty feed problems

Start with the actual processing message and the outgoing record. The table below offers diagnostic checks, not a list of official Google error names.

Two documentation details deserve extra care. First, Google labels the unit required for products while also describing a default of months when unspecified. Providing the unit avoids relying on that ambiguity. Second, the duration must be a whole number. For a documented 18-month term, use 18:month rather than a fractional year. Where Google's Quebec-specific instruction applies, preserve its year-based formatting requirement and resolve any mismatch with the actual applicable term before submitting.

Some promises cannot be reduced safely to this numeric pair. The documented format does not provide a special lifetime token. Do not convert that wording into an arbitrary number of years. Likewise, do not add a number of months to represent unknown coverage.

Google also marks warranty as a non-repeated field. If a product has different periods for different components, do not concatenate several competing pairs or select the longest term merely because it looks attractive. Clarify which coverage the submitted value represents, keep the detailed conditions accessible to buyers, and seek specification guidance if no single accurate value can be established.

A useful troubleshooting record includes the exact offer, submitted value, source, processing result and expected coverage. That is more actionable than a screenshot showing only that a product is not appearing.

Can product-page schema replace the warranty field?

Google's warranty specification lists no corresponding Schema.org property for this Merchant Center attribute. That statement concerns Google's mapping for the feed field; it does not mean Schema.org has no vocabulary about warranties.

Do not assume a warranty sentence on a product page, or a warranty-related property in structured data, automatically fills the Merchant Center record. Verify the actual outgoing source and processed product. If your store platform offers a mapping, inspect what it sends rather than relying on the field's label.

Keep the buyer-facing terms accurate as well. The numeric feed value cannot explain every exclusion, registration condition or component-specific limitation. A shopper still needs the relevant detail before buying. Warranty also does not replace the other required and applicable attributes in Google's product data specification.

Treat implementation success as an accurate value that survives processing and the next source update. Do not promise higher organic rankings, better click-through rates or a guaranteed warranty badge from adding this attribute. Maintain one dependable coverage record, export it in the required format, and recheck it whenever the product's terms or your integration changes.