Date your prices so every quote carries its age
A price with no date could be from any month. Show when your rates last changed, in text and in markup, and change that date only when a price moves.
Why a date belongs next to every price
Put a visible line above your price table saying when the rates last changed, carry the same date in the page markup, and move it only when a price moves. GPU rates change often enough that an undated figure could be from any month, and a reader, or a program writing for one, has no way to tell whether it still holds. A dated price can be quoted with its age; an undated one is a guess.
We treat the date as part of the figure. Every rate we show carries the day it was read, and a rate older than 21 days is hidden rather than shown stale. That rule is the same instinct this post recommends to vendors, applied from the other side.
Two dates, not one
There are two honest dates a pricing page can show, and they mean different things. "Prices checked" says somebody confirmed the table is current. "Prices changed" says when a number last moved. A page that has not changed its rates in a quarter but checks them weekly should be able to say both.
Many pages show neither, and some show a date generated at build time, which moves every time the marketing site is deployed. That date tracks the build, not the prices. A buyer who notices it advancing while the table sits still learns to ignore every date on the site.
If you can show only one, show the change date. It is the one a buyer comparing your rate with an older quote needs, and it cannot be faked by a build pipeline unless somebody wires it up that way on purpose.
What staleness costs on a comparison table
We read each provider page on a schedule and hold 464 current rate observations. When a provider changes its page and our next read has not happened yet, the old figure is the one a buyer sees beside the source link. A dated page lets a buyer clicking through see at once which of the two is newer.
The cost of an old figure compounds with time. At the lowest listed H100 SXM rate, a month of 730 hours comes to $1,226.40, and a small change in the hourly rate is a noticeable change on that monthly total. A buyer budgeting from a stale rate finds the difference on the first invoice.
Staleness runs in both directions. A provider that raised a rate and left the old one on a docs page is quoted low; one that cut a rate and left the old one on a launch post is quoted high. Either way the buyer meets a number that is not on the invoice.
Where the date goes
In the visible text, directly above the table, in words a person reads: "Prices last changed 3 March". Not in a footer, and not in a tooltip, because both are easy to miss and the tooltip may never be read by a crawler at all.
In the markup, as a dateModified on the page and validFrom on each offer, set to the same day. If the two disagree, a program comparing them has a reason to trust neither. The post on structured data for a GPU pricing page covers the rest of that markup.
In a changelog, if you can. A short dated list of price changes is the strongest freshness evidence a page can offer, because it shows the history rather than asserting the present.
Keeping the date honest without effort
Generate the date from the price data, never from the build. If prices live in a file, the date is the last commit that touched a price in that file. If they live in a database, it is the newest change to a rate row. Either way, a deploy that only fixes a typo leaves the date alone.
Then assign somebody to look at the page once a month and confirm it. That check is what earns the "prices checked" line. Our own log of changes works on the same idea: what moved and when, recorded rather than implied.
If a price is temporary, say so with both dates. A launch rate that ends on a stated day is a fact a buyer can plan around. A launch rate with no end date that quietly disappears leaves the buyer who budgeted on it with a wrong figure.
What a buyer does with the date
A buyer comparing providers holds several tabs open and a spreadsheet. When two figures disagree, the dated one can at least be placed in time. An undated figure gets a question mark in the spreadsheet, and a question mark is a reason to ask sales.
Some procurement teams attach the source and the date to every figure in a recommendation, so the people who sign can check it. A page that gives them both in one line saves them a screenshot and an email. That is the same reason we put the source URL and the read date beside every rate on the GPU price table.
Dates also help the buyer who arrives late, from an old link or a quoted answer. If the figure they were given has a date, they can tell at once whether to check for a newer one.
What we could not answer
- ⚑We cannot show that dating a page changes how often it is cited, only that an undated price leaves its age unknown.
- ⚑We do not track how often each provider changes its rates, so nothing here says how often a page should be checked.
What this rests on
infratoapp, “Date your prices so every quote carries its age”, read 27 October 2026. current GPU rates, none older than 21 days: 464. https://www.infratoapp.com/blog/date-your-prices-freshness-is-a-citation-signal
Questions people ask about this
Should a pricing page show a last updated date?
Yes. A visible date above the price table tells every reader how far to trust the figures. It should reflect when a price last changed, not when the site was last deployed, and the same date should appear in the page markup so the text and the markup agree.
Does a fresh date help a page get cited by assistants?
Nobody outside the labs knows how assistants weigh freshness, so no one can promise it. What can be reasoned is that an undated price is harder to quote responsibly, because its age is unknown. A true date removes that obstacle and helps human buyers in any case.
Why does infratoapp hide prices older than 21 days?
A stale price shown as current misleads a buyer more than a gap does. Rates older than 21 days are hidden, and the gap reads as no current figure on record rather than a claim the card is unavailable. Every price that is shown carries the date it was read.
These render as FAQPage structured data · answers are filled from the same live figures
Read next
Mark up each rate as a Product with an Offer that states price, currency, unit and a date, and never claim more in markup than the visible page shows.
A rate on the pricing page that differs from the one in the docs gives a buyer no way to tell which is right. Keep one source for prices and build from it.
Nobody outside the labs knows how assistants weigh sources. A price is easier to quote when it is readable as text, tied to its page and dated.