Your landing page may speak to several kinds of customer. Each has a different reason to read it. Personalized Landing Pages creates audience-specific copy for the same page, with a review step before anything goes live. You change the way you explain your offer while the facts stay tied to the original. Start with your page URL and the audiences you want to reach. The recipe page lists the steps, prices and limits in one place.
Before you personalize copy for different audiences, 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 shorter, clearer list also gives you fewer versions to review.
You do not need to accept an audience because it was suggested. Name the people you want the page to address, then read the list once more before generating. 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. 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.
A number, price, name or claim that your original page never makes is flagged before you approve. 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.
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. Changes reach your site within a minute.
Install one tag and keep the original as fallback
Installation is one tag in your page's <head>. Paste it as the first tag, or hand the supplied prompt to your coding agent. It works with Lovable, Cursor and Next.js sites as well as plain HTML. Pages that render in the browser are read the way a 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
Generation costs $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 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, in plain code |
| Free-text classification | 1 cent per visit when used | A model reads text such as a site search or a chat opener |
UTM tags are labels in a link. A referrer is the site a visitor came from. For those routing rules, no model needs 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 keep working when your balance runs out.
Run it yourself
The code is MIT licensed on GitHub. Self-hosting needs your own Vaaya API key with balance. Every model call is billed to it, persona suggestions included.
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.
To work on your page, add your URL at vaaya.ai and review the suggested audiences.