Put every currency in the document: the counts our own pricing page now serves a crawler

The fix for a crawler reading the wrong currency is not better detection. It is printing every region's prices into the document on every request, whether or not anything about the visitor is known. Measured as GPTBot with no cookies and no language header, the visible text of our own pricing page now carries 15 dollar figures, 5 pound, 5 euro and 31 rupee. The same fetch before the change returned rupee figures and no dollar, pound or euro figure at all, because the conversion ran in the browser. Nothing about the detection logic was altered. The page gained a chapter that the server writes every time.

Those four counts are the measurement that proves the change shipped, and they are the form this claim has to take. A sentence saying prices are now server rendered is unfalsifiable. Four counts taken under a named agent with stated conditions can be reproduced against the url this afternoon, and if the numbers have moved since, that movement is information rather than a problem.

Why smarter detection cannot be the answer

Our region logic reads five signals before it concludes anything, among them a network country header, a time zone cookie and the language preference a browser announces. A plain fetcher sends none of them. So every branch of that logic has to work from nothing, which means the fallback is not an edge case for automated readers, it is the only case.

You can make a fallback cleverer and it will still produce one answer. A document containing one price ladder tells an automated reader that one ladder exists. The upgrade that actually changes the outcome is at the document level, not the logic level, and that distinction is the whole of this page.

Same fetch, as GPTBot, no cookies, no language header	Before	After
Dollar figures in the visible text	0	15
Pound figures	0	5
Euro figures	0	5
Rupee figures	Present	31

What to put in the document, and what can still wait

The rule is per fact rather than per page, and the test is to ask what somebody reading the raw response would be unable to learn about your business.

• Belongs in the server response. Every plan name, every price in every currency you sell in, what each tier includes, the billing period, and any minimum or commitment. Also coverage areas, cities served and anything with a number in it that a buyer would ask about.
• Can arrive afterwards. The toggle that chooses which ladder a person sees, the currency conversion for a visitor's own locale, comparison sliders, calculators and anything that reacts to a click.
• The shape that satisfies both. A person keeps the view appropriate to them. The complete set lives in the document underneath it, so a reader with no scripts and no locale still finds the whole price list rather than one region's slice.

That last point answers the obvious objection. Nobody has to look at four currencies at once. The region specific presentation is still what a visitor gets; what changed is that the alternatives now exist in the bytes rather than only in the browser's memory after a script runs. The broader argument about which facts belong in the first response, with the measurements behind it, is in our page on what a crawler receives in the first response.

The acceptance test, which is a count and not an opinion

Once the change is written, the way to keep it is to assert the counts rather than to eyeball the page. Fetch your own pricing url with no cookies and no language header, strip the markup, and count the currency symbols in the visible text. Then require that at least three distinct currencies appear and that each of your named markets shows its own. That assertion needs one request and it fails loudly the day a build configuration quietly moves the table back behind a script.

Put it in the same place as your other release checks. A price that was in the document last month and is not this month is a regression nobody will notice from a browser, because a browser will keep showing the right thing to the person looking at it.

Why this one page earns the effort

Across 102 conversations in which we asked engines what a page in this category would need to be worth citing, every single one of them asked for pricing in the reader's own currency. Not most. All 102. It is the one requirement that came back unanimously, and it is the requirement a client side currency toggle quietly fails while looking perfectly correct to everybody in the building.

A pricing page is also one of the few pages whose job is to answer a question a buyer asks out loud, in those words, which is why it is worth more attention than its word count suggests. Which page types actually earn citations, measured at url level, is covered in our page on which website pages earn AI citations.

Questions about getting prices into the html for crawlers

Does this mean abandoning localised pricing?

No. Keep the localised view for people. Add the complete set to the document so that a reader with no locale finds everything rather than one region's slice. The two coexist and the second one costs you a block of markup.

Is printing all currencies going to confuse buyers?

It has not, because the presentation layer still chooses what a visitor is shown first. The complete table sits below as reference, which is a pattern plenty of software companies already use for their own reasons.

What exactly do I fetch to check mine?

Your pricing url, with a plain client, no cookies and no language header, under a named agent string you care about. Strip the tags, then search the text for each currency symbol and count the hits. Four numbers and you know where you stand.

Our prices come from a feed. Does that change anything?

Only where the feed is read. If the request for it happens in the browser, the figures are not in the document. Fetch the feed server side and render the result, and the same four counts become reproducible.

Does a currency in the document guarantee an assistant will quote it?

It makes the figure available to be quoted, which is the part you control. Whether it gets used depends on whether your page is the source being read, and our own citation figures are 3 of 597 readings of ChatGPT and Gemini on 15 October 2026 and 6 of 1,260 readings of those two engines the next day.

Four numbers anybody can reproduce

Fifteen, five, five and thirty one, taken under a named agent with the conditions printed beside them. That is a small claim and a checkable one, and the reason to make it in this form is that the version we published before the fix, rupees and nothing else, was equally checkable and equally ours. Both readings are on the record with their dates, as are the two Google Search Console exports and the dated blind scan behind everything else we assert, on our proof page. Finding this specific gap on other companies' pricing pages and getting the figures into the document is a job we are paid to do, which is why our own before and after is printed rather than described.