Structure a pricing page for search and assistants

The short version

A pricing page that search engines and assistants can read puts every rate in a plain HTML table that arrives with the first response from the server, quotes every row in the same unit, gives each section an anchor that does not change, and carries a visible date. A price that appears only after a click, a hover or a calculator input is a price a crawler may never see.

None of that is exotic. It is roughly what a careful buyer wants too, which is the useful part: the page you build for a program is the page a procurement lead can paste into a spreadsheet without retyping anything. We read 48 provider pages on a schedule, and a plain table is the hardest kind of page to misread.

One table, in the HTML, before any script runs

Some GPU pricing pages are built as single-page apps that fetch prices after load and paint them into a styled grid. Some crawlers run scripts and some do not, and even those that do may not wait, scroll or click. The safe assumption is that whatever is missing from the server response is missing for some readers.

Use a real table element with a header row: card, memory, unit, commitment, region, rate. Styled divs that look like a table read as a stream of loose numbers. Put the card name in full in its own cell, H100 SXM 80GB rather than H100, because the short name covers two different purchases.

If the price list is long, keep it on one page and let the browser scroll. Pagination and infinite scroll split the list across URLs or behind events, and the rows past the first page are the ones a reader is most likely to miss.

One unit for every row

A table that mixes price per GPU, price per node and price per instance forces the reader to divide, and many readers will not. A program summarising your page will either skip the arithmetic or do it wrongly. Pick price per GPU per hour, state it in the header, and if you sell eight-GPU nodes, show the node price in a second column beside the per-card figure rather than instead of it.

This is the unit buyers compare in. The lowest listed H200 rate we hold is $2.09 per GPU-hour, and a node price set next to it on another tab will look either absurdly dear or suspiciously cheap until somebody does the division. The H200 page quotes every seller per GPU for that reason.

Anchors and headings a link can land on

Give each block of the page an id that will survive a redesign: #h100, #h200, #storage, #egress. A link to a fragment points a reader, or a citation, at the exact rows that support a claim. When the id changes on every deploy because a framework generated it, every old link lands at the top of the page.

Keep one URL for one price list. A pricing page that exists at several addresses, one per campaign or one per region with the same rows, splits whatever attention it gets between copies and leaves readers unsure which is current. Pick the canonical address, point the others at it, and put the regional differences in a column rather than on separate pages.

Headings should name what is under them. "Hopper GPUs, on demand" is a heading a reader can scan and a program can attach to the rows below it. "Simple, transparent pricing" tells nobody anything and makes the page look like every other page.

Tabs, toggles and calculators

The monthly and hourly toggle, the region dropdown and the reserved-term tab all hide prices behind an event. The default state is what gets read, and the other states may as well not exist for a crawler. If reserved prices are worth showing, show them in their own table below the on-demand one, labelled as reserved, with the term.

A calculator is a fine extra and a poor primary source. It answers one buyer one question at a time, and it holds no rate a program can read until somebody types into it. Our own rental cost calculator works from rates that already sit in a public table; it never replaces that table.

Accordions on an FAQ are a milder case. Text collapsed in the HTML is usually still in the source, so it can be read. Text that is fetched only on expand is not.

A date, and what to leave off

Put a line above the table saying when the prices last changed, and change it only when they do. It tells every reader how far to trust what follows. The first post in this series covers why a date matters so much to a figure that may be quoted elsewhere.

Leave off what cannot be checked. "Lowest prices in the market" is a claim a reader cannot verify and a careful program has no reason to repeat. A plain rate with a unit and a date makes the case better than an adjective does.

Leave off "contact us" in place of a rate where a rate exists. A row for a card with no price in it reads, to a buyer and to any table built from your page, as no figure on record. If a card is only sold on a quote, say that in words in the cell, so the gap is a statement rather than a blank.