Structured data for a GPU pricing page

Which types fit a GPU price list

For a GPU pricing page, the schema.org types that fit are a Product for each card you rent, with an Offer that states the price, the currency, the unit the price is for and the dates it is valid, plus a BreadcrumbList if the page sits under a parent. The markup must state only what the visible page states; Google's structured data guidelines ask for markup that matches the visible content.

Structured data does not make a page rank or get cited. It removes guessing for any program that does read it: which number is the price, in which currency, for how much of what. That is worth having on a page whose whole job is numbers.

Saying what the price is for

The hard part of GPU pricing in markup is the unit. A bare price of $1.66 on an Offer says nothing about whether it is per hour, per GPU or per node. Schema.org has a UnitPriceSpecification for this, with a reference quantity and a unit, so an offer can say plainly that its price covers one GPU for one hour.

Name the product the way the visible table names it. If the row says H100 PCIe 80GB, the Product name says H100 PCIe 80GB, not H100, and the memory size can go in a property of its own. A program reading the markup should arrive at the same card a buyer reading the table does. The H100 PCIe page is a separate page from the SXM one for exactly this reason.

State the commitment in the offer name or description when it is anything other than on demand. A reserved rate marked up exactly like an on-demand rate will be read as one.

Dates in markup

An Offer can carry a validFrom date and a priceValidUntil date. Use them only when they are true. If your prices hold until you change them, validFrom set to the day they last changed is honest, and an invented expiry date a month out is not.

The page itself can carry a dateModified. Tie it to the day the prices changed, not to the build time of the site. A date that moves on every deploy tells readers nothing, and it teaches any program comparing the markup with the visible text that your dates mean little.

Make the visible date and the markup date the same day, written from the same field. A page that says one date in text and another in markup gives a careful reader two claims and no way to choose between them.

FAQ markup, and what to skip

FAQ markup no longer produces rich results in Google search, so adding it in the hope of a larger listing is wasted effort. HowTo markup is in the same position and is not worth adding to a pricing page. Keep FAQPage markup only if the questions on the page are real ones buyers ask and the answers are visible on the page, word for word. Some programs other than Google may still read it, and an honest FAQ is useful to a buyer either way.

Skip anything you cannot back with visible text. Aggregate ratings with no reviews on the page, a lowest price that appears nowhere in the table and an availability flag that nothing updates are the usual offenders. Each one is a statement your page makes on your behalf, and a buyer who checks it and finds it false stops reading.

Generate it from the same data as the table

The safe way to keep markup and page in agreement is to build both from one source. If the table is rendered from a price file, render the JSON-LD from the same file in the same build. Hand-written markup drifts from the page as prices change, and that drift is the mismatch the markup was meant to remove.

Then test it. Paste the page into a structured data validator and compare what it reports with what the table shows, row for row. A validator confirms the syntax; only a person checks that the price in the markup is the price on the page.

Add the comparison to the build if you can. A test that renders the page, reads every price from the table and every price from the JSON-LD, and fails when they differ, turns a quarterly chore into a check that runs on every deploy. Break it on purpose once, by changing a price in one place only, and confirm it fails before you trust it.

One row, written out in words

Take a single row: the H100 PCIe 80GB, on demand, per GPU per hour, in US dollars, in one region, unchanged since the first of the month. In markup that becomes a Product named H100 PCIe 80GB, with an Offer whose price specification gives the amount, the currency, and a reference quantity of one GPU-hour. The offer names the region in its area served and carries validFrom set to the first of the month.

Now a reserved rate for the same card. It is a second Offer on the same Product, named so that the commitment is plain, for example reserved for one year, with its own price and its own date. The two offers sit side by side in the markup the way the two rows sit side by side on the page, and nothing in either claims to be the lowest or the default.

A page with many cards repeats the pattern per card. It gets long, which is fine: it is generated, nobody edits it by hand, and the length matches the table. Across the market we hold on-demand rates for 51 cards, and the page on how figures are gathered explains why each carries a source and a date.