Cold Brew and Ready to Drink Product Pages and Schema
Short answer: a cold brew or ready to drink product page needs to answer a different set of questions than a coffee bag page, how long it keeps, whether it needs refrigeration, the serving size, the ingredients, and any shipping limits, right in the first screen a customer sees. Then it needs a Product structured data block built from facts you actually know, not from a template copied off a bag page that was never built for this kind of product.
If you added cold brew cans, bottles, or concentrate to your shop and simply reused your coffee bag product page as a starting point, you likely have a page missing the exact information a first time buyer actually needs before they will click add to cart. A shopper deciding whether to buy a bag of whole beans thinks about roast level and tasting notes. A shopper deciding whether to buy a can of cold brew thinks about whether it needs to stay cold, how long they have before it goes bad, and how much caffeine is in it. Those are different questions, and a page built for the first kind of product usually does not answer the second kind well.
This post walks through what an RTD page needs on the page itself and how to mark it up with Product structured data so a search engine can read it accurately. No dataset tracks how many roasters currently do this well or poorly, so this is a how to grounded in Google's own product documentation and in general schema fundamentals, not a study with a published rate.
None of this requires a redesign of your entire site or a developer on retainer. It requires rewriting one page with a different customer question in mind, and adding a small, accurate block of structured data behind it. Both are things a single owner can do in an afternoon once the right questions are in front of them.
Why the Bag Page Template Falls Short
Most roaster websites are built, understandably, around the bag of beans as the primary product. Templates, category structures, and even the language a platform suggests by default are all shaped around that core product. When a cold brew or ready to drink item gets added later, the fastest path is often to duplicate an existing bag page and swap out the photo and price, which produces a page that looks complete but is quietly missing the specific information this different kind of product needs.
The problem is not laziness. It is that a bag of beans and a can of cold brew are genuinely different products with different buying decisions behind them, even though both are coffee. A bag sits on a shelf indefinitely and gets ground and brewed at the buyer's own pace. A can or bottle has a real shelf life, may need refrigeration, and is consumed as is, with no brewing step for the customer to control. Treating them as interchangeable in page structure means the page built for one silently fails the other, and the customer pays for that gap with confusion rather than confidence at the exact moment they are deciding whether to buy.
The Buying Questions an RTD Page Actually Needs to Answer
Put yourself in the position of someone who has never tried your cold brew before, browsing your site for the first time. Their first real question is almost never about flavor. It is about logistics: does this need to be refrigerated right now or is it shelf stable until opened, how long does it keep, and what size am I buying, a single serving can or a multi serving bottle meant to be poured into a glass over ice.
Answer those three questions plainly, near the top of the page, before anything else. Storage and shelf life information belongs in the first screen a visitor sees, not buried in a paragraph further down or left out entirely and assumed to be obvious. What is obvious to you, having made this product, is very often not obvious at all to a first time buyer deciding whether to trust an unfamiliar can with their money.
After storage and size, list the ingredients plainly, since this matters both for anyone with a dietary restriction and for anyone simply curious what is in the can beyond coffee and water. If the product ships, state any shipping limits clearly, particularly anything related to temperature sensitive shipping or regional restrictions, since a customer who orders a case expecting it to survive a hot delivery truck and finds otherwise is a customer who will not order again.
Caffeine content is another detail worth including plainly if you know it, since it is a genuine, practical question for anyone deciding when in the day to drink a ready to drink product, or whether it is a reasonable choice for someone sensitive to caffeine. Only state a specific number if you know it and can stand behind it, since an invented or guessed figure on a food or beverage product is exactly the kind of detail that should never be filled in casually.
What Belongs on the Page, in What Order
Structure the page with the logistics questions first, since those are the ones a genuinely new customer needs answered before anything else earns their attention. A clear product name that says what it is, cold brew concentrate or ready to drink cold brew, rather than a clever name alone with no clarifying descriptor, helps both the customer and a search engine understand the product correctly from the title alone.
Photos matter differently for an RTD product than for a bag of beans. Show the actual can or bottle clearly, ideally next to something that gives a sense of scale, and consider a photo showing the product poured into a glass, since many first time buyers do not know whether a concentrate needs to be diluted before drinking or a ready to drink can is meant to be consumed straight from the container. That single point of confusion, concentrate versus ready to drink, is common enough to be worth addressing directly and visually rather than assuming the product name alone makes it clear.
Keep the tasting notes and flavor description further down the page, after the practical questions are answered, rather than leading with them. A customer who does not yet know whether this needs to be refrigerated is not ready to care about tasting notes yet, and leading with flavor language before logistics risks losing a first time buyer who simply closes the tab still unsure how to store what they were about to buy.
A short frequently asked questions block near the bottom of the page is a reasonable place to catch the remaining smaller questions that do not fit neatly into the main copy: whether the product is available for local pickup, whether it can be purchased as a multi pack, or how it compares to your bagged coffee for someone trying to decide between the two. Keeping this block short and specific to your actual product, rather than a generic template block copied from elsewhere, keeps it useful rather than padding.
What Product Schema Actually Covers
Google's structured data documentation for products describes a set of properties that help a search engine understand what a product page is describing: a name, at least one image, a description, pricing and availability information grouped under an offer, and typically a brand. Applying these accurately to a cold brew or RTD listing means using the real product name, a real photo of the actual can or bottle, a plain description that matches what is written on the page, and accurate availability, in stock or out of stock, kept current.
It is worth being honest about what this markup does and does not do. Applying Product structured data correctly helps a search engine understand your page more precisely. It is not a promise of any particular visual treatment in search results, and this post makes no claim that adding this markup guarantees a specific outcome. Treat it as giving accurate information in a structured, machine readable format, the same information already on the page for a human visitor, not as a shortcut to a better looking search result.
Wix, Squarespace, and Shopify each offer some level of built in product markup for standard product pages, though the exact fields available and how much an owner can customize varies by platform and by template. Check your own platform's product page settings directly rather than assuming a specific field exists, since these settings and their defaults do change over time across all three platforms.
If your platform's default markup does not have a clean way to represent something specific to an RTD product, like a refrigeration requirement, do not force it into a field it was not built for. Put that information plainly in the visible page copy instead, where both a customer and, in time, a search engine reading the page's full text can still find it, even if it does not slot neatly into a specific structured data property.
A Simple JSON LD Example With Placeholder Values
A basic Product structured data block for a cold brew listing, using entirely invented placeholder values rather than any real product, looks roughly like this in structure: a name field stating the product plainly, an image field pointing to a real product photo, a description field matching the page's actual text, a brand field naming the roaster, and an offers block containing price, currency, and availability. Every value in an example like this needs to be replaced with your own accurate, current information before it goes live, never left as placeholder text on a real page.
Validate whatever you build using Google's Rich Results Test before publishing it, pasting in either the page URL once it is live or the code itself beforehand. This tool checks the markup for structural errors and flags anything missing or malformed, and running the test is a normal, expected step, not an advanced one reserved for a developer. Rerun the same check any time you significantly edit the page, since a small copy change can sometimes break a markup field without any obvious visible sign on the page itself.
One detail worth being careful about, since this is a beverage product: do not include any shelf life number, expiration claim, or health related statement in your markup or on the page unless you have verified it yourself and it is accurate for your specific product. Shelf life and storage claims for a food or beverage product are the kind of statement that should come from you, the person who knows the product, verified against your own packaging and any relevant food safety guidance, never invented to fill out a template field.
If you are unsure what your own labeling already states about storage or shelf life, start there before writing the page copy. Your existing can or bottle label is the most reliable source you have for this information, and matching your online product page to what is already printed on the physical product keeps the two consistent, which matters both for a customer comparing them and for avoiding any accidental mismatch between what is sold online and what arrives at their door.
Related Reading
More from Hillcane on this topic, plus the pages on the site that sit next to the work.
Frequently Asked Questions
What is the biggest difference between a coffee bag page and a cold brew product page?
A coffee bag page typically leads with roast level and tasting notes. A cold brew or ready to drink page needs to lead with logistics first: whether it needs refrigeration, how long it keeps, and the actual serving size. These are the questions a first time buyer needs answered before flavor description earns their attention.
Where should storage and shelf life information appear on the page?
Near the top, in the first screen a visitor sees, alongside refrigeration needs and serving size, whether a single serving can or a multi serving bottle poured over ice. Buried or missing storage details leave a first time buyer unsure how to handle an unfamiliar can. Start from your own can or bottle label, since the printed packaging is the most reliable source, and keep the page matched to it so what arrives never contradicts what the page promised.
Should tasting notes come before or after the practical details?
After. Lead with the logistics a new customer needs first: whether it must be refrigerated, how long it keeps, the serving size, ingredients, and any temperature sensitive shipping limits. A buyer who does not yet know how to store the product is not ready for flavor language and may close the tab still confused. Put tasting notes further down, and near the bottom add a short FAQ block covering local pickup, multi packs, or bagged coffee comparisons.
What does Product structured data require?
Google's product structured data documentation describes a name, at least one image, a description, and pricing and availability grouped under an offer, typically alongside a brand. For a cold brew listing, use the real product name, such as cold brew concentrate or ready to drink cold brew, a photo of the actual can or bottle, a description matching the page, and availability kept current. Validate the block in Google's Rich Results Test before publishing.
Does adding Product schema guarantee a better search result?
No. This post makes no claim that structured data guarantees any particular visual treatment or outcome in search results. Product schema helps a search engine understand the page more precisely; it is not a promise of any specific result, and it should be treated as accurate information in a machine readable format, not a shortcut.
Do Wix, Squarespace, and Shopify add Product schema automatically?
Wix, Squarespace, and Shopify each offer some built in product markup for standard product pages, but the available fields and how much you can customize them vary by platform and template, and defaults change over time. Check your own product page settings directly instead of assuming a field exists. If nothing fits a detail such as a refrigeration requirement, state it plainly in the visible copy rather than forcing it into a structured data field built for something else.
How do I check if my Product structured data is set up correctly?
Use Google's Rich Results Test, pasting in the live page URL or the code itself before publishing. It checks for structural errors and flags anything missing or malformed in fields such as name, image, description, brand, and the offer's price, currency, and availability. Running it is a normal step, not one that needs a developer. Rerun it after any significant edit, since a small copy change can break a markup field without any visible sign.
Should I include a specific shelf life number in my product schema or page copy?
Only if you have verified it yourself for your specific product. Shelf life, storage, and any health related claims should come from you as the maker, checked against your own printed can or bottle label and relevant food safety guidance, never from a template. Do not leave a placeholder in a JSON LD block or make up a figure to complete a page. The same rule applies to caffeine content: state a number only if you know it and can stand behind it.
How should photos differ for a cold brew page compared to a coffee bag page?
Show the actual can or bottle clearly, ideally with something giving a sense of scale, and consider a photo of the product poured into a glass. This helps address a common point of confusion, whether a concentrate needs to be diluted or a ready to drink can is meant to be consumed straight, directly and visually.
Can Hillcane help build product pages and schema for cold brew or RTD items?
Yes. Hillcane can help restructure your cold brew or RTD pages so storage, shelf life, serving size, ingredients, and shipping limits appear in the first screen, with tasting notes further down. It can also build Product structured data from your own verified label information, covering name, image, description, brand, and offer, then validate it in Google's Rich Results Test before it goes live. Reach out at hillcane.co/contact or call (256) 384-2449.
Work with Hillcane
You copied your coffee bag product page template for your new cold brew cans. The customer trying to decide whether they need to refrigerate it cannot find the answer anywhere on the page.
If your roastery needs cold brew or ready to drink product pages that actually answer the questions customers have, reach Hillcane at hillcane.co/contact or call (256) 384-2449.
Comments