When You Change Your Pricing, What Changes on the Website?

When You Change Your Pricing, What Changes on the Website?

Far more than the pricing page. Price appears in comparison tables, FAQs, calculators, screenshots, meta descriptions, structured data, PDFs, and the CDN cache. A pricing change is a site wide find and replace exercise, and treating it as a one page edit is how customers find the old number.

The number itself is a commercial decision somebody else makes. What happens on the site afterwards is ours, and it is consistently underestimated. A pricing change we are told about on Tuesday for a Thursday launch is a much bigger job than it sounds.

Here is the checklist we work through, roughly in the order things get missed.

Where Does Price Actually Appear on a B2B Site?

In at least eight places on a typical site, and only one of them is the pricing page. The comparison table, the plan selector, the FAQ answers, a pricing calculator, the annual versus monthly toggle copy, feature pages that mention what tier something is on, the meta description, and any PDF or one pager linked from the site.

Screenshots are the reliably forgotten one. Product screenshots on feature pages often show a billing screen, an upgrade prompt, or a plan name, and those images are invisible to any text search you run. So are images of pricing tables that somebody exported from a design file.

The fix is to grep before you edit. Search the site for the currency symbol, for each old number, and for each plan name, and write the list down. It takes fifteen minutes and it is the difference between a clean change and three weeks of stragglers.

What About Structured Data?

Update it in the same commit, because a stale price in markup is worse than no markup. Google's Product snippet documentation defines price as "the offer price of a product" and priceCurrency as "the currency used to describe the product price, in three-letter ISO 4217 format."

There is a specific trap in the expiry field. Google documents priceValidUntil as "the date (in ISO 8601 date format) after which the price will no longer be available, if applicable", and warns that "your product snippet may not display if the priceValidUntil property indicates a past date." A date that quietly passes takes your rich result with it.

If your pricing is genuinely dynamic or quote based, the honest answer is not to publish a price in structured data at all. Markup that disagrees with the page is a liability, and it is the sort of thing a careful buyer notices.

Why Do Some Visitors Still See the Old Price?

Because caches do not know you changed anything. MDN's caching guidance explains that a response is fresh while its age is less than its max-age and stale after, and that a stale response must be revalidated before reuse. If your pricing page carries a long max-age, visitors keep the old page until it expires.

MDN also names the trap for pages specifically. Versioned filenames solve this for assets, since "for resources that do change, it is a common best practice to change the URL each time the content changes", but "unlike subresources, main resources cannot be cache busted because their URLs can't be decorated in the same way."

The practical consequences are simple. Keep a short max-age on pages whose content is commercially sensitive, purge the CDN explicitly at launch, and check the page from a device that has never visited the site. Your own browser is the least reliable place to verify a pricing change.

How Long Until Search Results Catch Up?

Days to weeks, and you cannot buy your way past it. Google states that "crawling can take anywhere from a few days to a few weeks" and that "requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all."

You can nudge it. Google's guidance is to "request a crawl of individual URLs" with the URL Inspection tool, while warning that "there's a quota for submitting individual URLs and requesting a recrawl multiple times for the same URL won't get it crawled any faster." Submitting the same URL five times achieves nothing except using your quota.

This has a content consequence most teams miss. If your meta description contains a price, the old one will keep appearing in results after the page has changed. Prices in meta descriptions are a maintenance liability, and we would take them out permanently rather than update them.

What Should Happen to the Old Pricing Page?

Nothing, if the URL stays the same, which it should. Changing the pricing page URL during a pricing change is two risky changes at once, and it throws away the ranking history of one of the highest intent pages on the site.

The exception is plan pages. If you are retiring a tier that had its own page, redirect it to the nearest equivalent rather than leaving a page describing a plan nobody can buy. A live page for a dead plan generates sales conversations that start with a correction.

If the retired plan page had genuine traffic, consider keeping a short honest page that says the plan is no longer offered and points to what replaced it. That is better than a redirect that silently lands somebody somewhere confusing.

What Do Existing Customers See?

Whatever you forget to gate. Existing customers on legacy pricing will visit your pricing page, and if it shows only the new numbers with no acknowledgement that grandfathering exists, your support queue fills with people who think their bill is about to change.

One line handles most of it. A sentence saying that existing customers keep their current plan until they choose to change, with a link to the details, removes the ambiguity that generates the tickets. It costs nothing and it is nearly always omitted.

Coordinate the timing with whoever is emailing customers. A pricing page that changes before the email goes out means customers learn about their own pricing from your marketing site, which is a bad way to find out.

Who Signs Off, and On What?

Somebody who can confirm the numbers are correct, and it is not the person who built the page. Transposed digits and a currency left as dollars on a page meant to show euros are the two errors we see most, and both survive a design review because a design review looks at the layout.

Have the sign off happen on staging with the real content in place, not on a design file. A number in a mockup gets approved as a placeholder and shipped as a fact more often than anyone would like to admit.

Write the old and new numbers side by side in the approval request. Asking somebody to confirm a page is right is a weaker check than asking them to confirm that 49 became 59.

What Should You Check the Morning After?

The three things that break quietly. Any calculator, because they usually hold their rates in a script that is separate from the visible copy. Any form or checkout that passes a plan or price as a parameter. And the site search, because it can serve an old cached snippet of a page you updated.

Then look at the pricing page in a search result rather than directly. That is where the stale meta description shows up, and it is the version a new visitor sees first.

Finally, check one PDF. There is always a PDF, it always has the old pricing in it, and it is always linked from somewhere nobody remembers. We covered the general problem of drifting site content in our piece on auditing a website.

How Do You Make the Next One Easier?

Store the numbers once. If price lives in CMS fields or site variables rather than being typed into twelve rich text blocks, the next change is one edit and a publish. Our piece on building a pricing page on the Webflow CMS covers that structure.

Keep a written list of every location price appears, updated whenever somebody finds a new one. That document is worth more than any process, because the whole problem is that price hides in places nobody thinks to look.

If a pricing change is coming and you want help making sure the site keeps up with it, we are happy to work through the list with you. Find us at phoenix.studio.