Offer Schema for a Dropshipping Store
Check Offer markup against supplier price, stock, shipping, and returns so the structured data matches the storefront.
Offer schema is schema.org markup that states the terms on which you sell one product. It covers the price, currency, availability, and page where a shopper can buy it. On a dropshipping store, some of those values begin with the supplier. The markup therefore stays true only while your store sync stays current.
I ran a niche-products Shopify store, where I set product prices and availability by hand. Shopify's documented Offer example has four selling fields. A supplier-fed store also has to settle shipping and returns. If it runs a sale, the store must maintain the sale dates too.
Key takeaways
What is Offer schema?
Offer schema describes the terms on which a seller offers one item. It sits inside product schema through the offers property. Google's merchant-listing documentation treats price and priceCurrency as its core fields. Schema.org defines Offer more broadly as an offer to transfer rights to an item or provide a service.
The Product names the item. The Offer tells a shopper what they'll pay, whether they can buy it, and which URL completes the purchase. When the buying terms differ, one product can carry more than one Offer.
Put Offer markup on a page where a shopper can act on those terms. A review-only page uses product-snippet markup. A page with many unrelated products also falls outside one Offer's scope.
Why supplier-fed Offers go stale
A supplier-fed Offer is only as accurate as your last successful sync. The supplier can change cost, stock, and processing time before your store updates. The import app moves those values into your product record, so SEO for dropshipping needs checks that ordinary ecommerce advice skips.
The Offer reports whatever the product record holds. If the store price is stale, the markup can be valid and still show the wrong value. In that case, fix the sync instead of the JSON-LD.
When a supplier changes its cost after an app scan, the page and Offer keep the earlier value until the next update. Your margin then uses the current supplier cost while the store still shows the old selling price. Markup has no freshness field for that gap.
The same delay can split the product page, its markup, and the submitted product data. Our Product schema guide explains that wider mismatch.
A supplier-fed store should correct the import app's price and stock updates before editing markup. Clean code will still publish stale values. A store that sets both values itself avoids this particular sync gap.
A higher supplier cost can leave your selling price too low, while a stock change can leave an unavailable item for sale. Both failures begin before the Offer is generated, so markup edits leave the cause untouched.
The Supplier-Fed Offer Check
Use the Supplier-Fed Offer Check to find what your theme prints and compare it with the page and supplier listing. Run its five dependent stages in this order:
- Read the theme: Record the Offer fields your page already prints.
- Sort the fields: Assign each value to the supplier, app, store, or theme.
- Sync changing values: Set monitoring and sale dates after the price rule is stable.
- State store policies: Publish shipping and returns once, then add real exceptions.
- Compare and validate: Match three surfaces before checking the code.
The order matters because each stage gives you the information needed for the next one.
1. Read what your theme already writes
Read the rendered page source and record every field in its offers object. Shopify's documented output example shows availability, price, currency, and a variant URL. Themes and apps can print a different set, so treat other fields as absent until your source shows them. Record these values:
- Note the price and priceCurrency values.
- Check the stock state in availability on the page.
- Confirm the url selects the right variant.
- Look for shipping, return, and sale-date properties.
A theme, app, or custom snippet may write the object. The source shows which fields reached the page. Search the theme and app code for a matching value to learn which component printed it. Read that output before installing another schema app because duplicate markup makes ownership harder to trace.
Shopify's example covers one product with one variant. A product with several options needs a separate Offer for each variant, while its parent ProductGroup connects them.
2. Sort each field by who controls it
Assign each Offer field to the person or system that can change it. Google requires a positive price and a three-letter priceCurrency for merchant listings, while it recommends the other fields below. Use this table to assign the maintenance job:
The table groups each field by who can change it. Google publishes the field status, while the controller split is this article's classification. If you price products by hand, you control price, although a supplier cost change can still make that price unprofitable.
3. Sync price, stock, and sale dates
Activate price and stock monitoring for existing products before trusting the Offer. DSers says updates start after activation. The AutoDS documentation says monitoring is off by default, so enable products one by one or in bulk. Before sale markup, check:
- Enable DSers updates for supplier price changes.
- Set the DSers price-change threshold.
- Activate AutoDS monitoring in bulk or per product.
- After the next scan, match the store value to the supplier listing.
AutoDS uses scheduled scans, while DSers can sync its compared-at price setting. I'd confirm that the price rule preserves your required margin before adding sale dates. Shopify's compare-at price is the original price beside a lower sale price.
The page source shows if your theme uses StrikethroughPrice. Google puts the sale price in price and the original price in priceSpecification. Set validFrom and priceValidUntil with a date, time, and time zone. A past end date can stop the listing from displaying. Use this illustrative JSON-LD sale shape:
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "Example product",
"offers": {
"@type": "Offer",
"url": "https://example.com/products/example?variant=123",
"price": 24.99,
"priceCurrency": "USD",
"validFrom": "2026-12-01T00:00:00-05:00",
"priceValidUntil": "2026-12-15T23:59:59-05:00",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"priceType": "https://schema.org/StrikethroughPrice",
"price": 34.99,
"priceCurrency": "USD"
},
"availability": "https://schema.org/InStock"
}
}
Replace the sample values inside the Product and Offer objects your page already prints. Adding another object can create duplicate markup. When a supplier removes or sells out a variant, apply the variant stock states from our variant guide.
4. State shipping and returns once
Use a store-wide policy for normal terms and Offer-level properties only for product exceptions. Google supports Search Console or Organization markup for store-wide policies. Its return-policy documentation puts product exceptions under Offer. Set policies in this order:
- Use Search Console or site-wide Organization markup.
- Set handling time from supplier processing.
- Set transit time from the shipping method's delivery window.
- Publish the return window and add only real product exceptions.
Before dispatch, handling time covers supplier processing. Transit time begins after dispatch, and Google can use both for its delivery estimate.
AutoDS can hold a product when the estimate exceeds your Maximum Shipping Days setting. Use that limit to catch a method that falls outside your published window.
In Baymard's cart-abandonment distribution, slow delivery made up 20% of non-browsing abandonments by US shoppers, while a poor return policy made up 13%. Those results show the buyer risk of weak terms. Schema performance falls outside their scope.
A long but honest delivery estimate can cut sales. When the real window is too weak, choose a faster supplier or shipping method. If your store promises more than the supplier accepts on returns, you carry the cost and own the RMA path between the customer and supplier.
5. Compare, then validate
Compare the source Offer, visible page, and supplier listing for your three best sellers before running a validator. Google recommends the Rich Results Test during development and URL Inspection after deployment. Run the comparison like this:
- Read the Offer's price, availability, and delivery window in the source.
- Read the same values on the visible page and supplier listing.
- Fix the app setting or markup source until they agree, then validate.
The three-way comparison catches a stale price. A validator checks only whether the markup is well formed and complete. I use validation last because a green result is easy to mistake for a factual check.
Google says recrawling takes time. Treat both tools as code checks rather than proof that your values are current.
After Google processes the page, diagnose its Offer errors in the Search Console reports covered by our merchant listings guide.
What Offer markup can't fix
Supplier updates and store settings determine whether Offer values are accurate. Offer markup reports the values your store holds. A missed import-app update can therefore produce accurate JSON-LD for the wrong price.
The upkeep is the real cost of this work. I'd maintain the three products checked above first, then expand after you can repeat the routine without leaving a field unchecked. Changing values deserve attention before broad catalog coverage because they can make a valid Offer untrue.
The Offer is done only when its price and stock match the page, its delivery window has supplier support, and its policies match what shoppers receive.
The source shows the rendered fields. Search the theme and app code for the matching value to find the component that needs correction.
Route each mismatch through the table's controller column:
- Fix supplier price and stock changes in the import app.
- Fix shipping and return promises in store policy settings.
- Fix missing output in the theme or schema app.
Following that path is faster than editing several systems and waiting for another crawl.
Keep the goal narrow. Publish terms that agree across the supplier, page, and Offer. The available sources don't quantify a traffic or sales lift from accurate Offer markup.
FAQ
Schema.org defines StrikethroughPrice for a prior price shown with the offer. Don't add it when shoppers can't see the comparison.
It defines AggregateOffer for a set of offers rather than one seller's terms. A single storefront offer normally needs the narrower type.
Google documents the current sale-price requirements. Use them only when the visible offer supports the value and period.
Offer or AggregateOffer for my store?
Use Offer for your store's selling terms and AggregateOffer for several offers on one product. AggregateOffer states a low price, high price, and offer count.
Which price does Google use if I add two?
Google uses the active price in the Offer's price property and ignores an active price repeated in priceSpecification. Keep priceSpecification for a different price role, such as the original strikethrough price.
Can one Offer list several shipping options?
Yes. Add multiple shippingDetails properties, with each one pairing its shipping rate and delivery time.
