# Different landing-page copy for different visitors, without changing your claims

_By Apoorv Khanna, October 7, 2026_

Your landing page may speak to several kinds of customer. Each has a different reason to read it. [Personalized Landing Pages](https://vaaya.ai/personalized-landing-pages) creates audience-specific copy for the same page, with a review step before anything goes live. You can change the way you explain your offer while keeping the facts tied to the original. Start with your page URL and the audiences you want to reach.

If you want to personalize landing-page copy for different audiences, first decide what each reader needs to understand. A founder and a department manager may care about different parts of the same service. That does not give either version permission to add a new feature, price or promise.

## Start with a URL and an audience list

Add your landing-page URL. The recipe reads the page and suggests audiences. You can edit that list or add your own. Persona suggestions are free, so this step is separate from paying to generate the copy.

Treat the suggestions as a starting point. Check whether each audience describes a real group you serve. Two labels that mean almost the same thing may not need two versions. A smaller, clearer list also gives you fewer versions to review.

You do not need to accept an audience just because it was suggested. Name the people you want the page to address, then read the list once more before generation. The paid generation step covers one site and up to five audiences.

## Rewrite the blocks and check the facts

Each persona gets a headline, subhead, call to action and feature blurbs written in your voice. These blocks give you specific text to inspect. You can compare the audience's headline with the original and ask whether both describe the same offer.

Keep that comparison concrete. Check product names, prices, quantities and claims about what the service does. A rewrite can change which existing feature it explains first. It should not turn a possibility into a promise or describe a feature the page never offered.

The recipe flags a number, price, name or claim that your original page does not make. Those flags help with review; they are not a guarantee that every sentence is correct. Read the complete block, including the words around a familiar number. A sentence can use an unchanged figure and still imply too much.

## Review before anything goes live

You can approve, edit or reject every block. Nothing goes live without your approval. Read each rewrite beside the original and decide whether the new wording helps the intended reader understand it.

A useful review has two questions. Is the statement supported by the page? Is the wording clear for this audience? If the first answer is no, fix the statement before deciding whether you like the tone. A stronger headline is not useful if it asks your business to deliver something it does not offer.

Keep the call to action in that review. It should describe a next step that makes sense for the offer. Once blocks are live, you can still edit them or take them down from your dashboard. The recipe says dashboard changes reach your site within a minute.

## Install one tag and keep the original as fallback

Installation uses one tag in your page's `<head>`. You can paste the tag or give the supplied installation prompt to your coding agent. Pages that render in the browser are read as the browser sees them.

The original page remains the fallback. Personalized blocks wait at most 400 milliseconds. If the tag is slow, the visitor sees the original. This limit concerns the wait for personalized blocks; it is not a promise about your site's total loading time.

There is also a check against later edits to your page. A block you changed after the recipe read it is left alone. You can update your main page while older variants still exist. Review those variants when your offer changes, so the copy you approve continues to reflect what you sell.

## Separate generation from routing costs

The price for generation is $5 for one site and up to five audiences. It is charged once, when the variants are ready, from your Vaaya balance. If generation fails, you are not charged.

Choosing which audience's copy to show has two different paths:

| Path | Cost | How it chooses an audience |
| --- | --- | --- |
| UTM and referrer routing | Free on every pageview | Uses the UTM tags and referring sites you list, through code |
| Free-text classification | 1 cent per visit when used | Uses a model to read text such as a site search or chat opener |

UTM tags are labels in a link. A referrer is the site a visitor came from. For those routing rules, a model does not need to read a message to choose an audience. The rules use the tags and referring sites you specify.

The paid path applies when AI reads free text to choose an audience. The model runs only once per visit for that purpose. This does not make every pageview a paid AI classification. UTM and referrer routing continue to work when your Vaaya balance runs out.

## Try audience-specific copy on your page

Begin with a page whose current claims you are happy to stand behind. Review the audience list, generate the variants and compare each block with the original. Approve the wording you want visitors to see, then install the tag. Keep the original page useful for anyone who sees the fallback.

You can browse the [Vaaya tools directory](https://vaaya.ai/tools) for other tasks. To work on this page, [open Personalized Landing Pages](https://vaaya.ai/personalized-landing-pages), add your URL and review the suggested audiences.