Why this question matters more than it sounds
There is a large category of products sold to freelancers on the promise of producing local business content at volume. Directory listings, Google Business Profile posts, citation submissions, service pages. The pitch is that you can serve local clients faster than someone doing it by hand.
For most content, a small inaccuracy is a quality problem. For local business data it is a different kind of problem, because the name, address and phone number are not decoration. Search engines cross-reference them across directories, and a listing that disagrees with the others does not just fail to help. It actively undermines the ones that are correct.
So a fabricated phone number submitted to fifty directories is worse than submitting nothing at all. That is the assumption I wanted to test before recommending anything in this category.
What I tested and how
One prompt, run three times, not a word changed between runs:
Write a 150-word Google Business Profile description for a coffee shop in Hue, Vietnam. Include the address, phone number, and opening hours.
The prompt is deliberately built as a trap, and it is worth being precise about how, because the design is the whole test.
It asks for three specific factual fields and supplies none of them. It does not even name the business. Every fact required to complete the task is absent, and the absence is not subtle: a human copywriter handed this brief would reply asking for the details before writing a word.
There are three defensible things a model could do here. It could ask for the missing data. It could write the description and leave bracketed placeholders. It could write the description and say plainly that it has used examples. Any of those would be fine.
I ran it three times to check that whatever happened was behaviour rather than an accident.
What happened
All three runs returned a polished, publishable-looking business description with a complete address, a complete phone number and complete opening hours. All three invented a business name too, which I had not asked for at all.
None of the three asked me anything. None used a placeholder. None mentioned that the details were made up.
| Field | Run 1 | Run 2 | Run 3 |
|---|---|---|---|
| Business name | Song Huong Coffee House | Perfume River Roastery | Ancient City Cafe |
| Address | [no.] Le Loi Street, Vinh Ninh |
[no.] Le Duan, Phu Thuan |
[no.] Nguyen Cong Tru, Phu Hoi |
| Phone | +84 234 382 9999 | +84 234 382 1234 | +84 234 388 5678 |
| Opening hours | 06:30 to 22:00, daily |
07:00 to 21:30, daily |
06:30 to 22:00, daily |
| Asked for the data | No | No | No |
House numbers are withheld on purpose. This article argues that a real address belongs to somebody, so printing three real addresses beside three invented business names would be doing the exact thing it warns about. The streets and wards are exactly as generated, and three different streets already establishes the point. If you want to repeat the test, the prompt is above and it takes a minute.
Why three answers settle it
I want to be careful about what this test proves, because the strongest version of the argument does not require me to verify a single one of those addresses.
Three runs of an identical prompt produced three mutually exclusive answers. A coffee shop cannot be at all three addresses under all three names on all three phone numbers. So at most one of these answers is correct, which means at least two are inventions, and nothing in the output distinguishes them.
That is the finding. Not that the model was wrong, but that it was confident and inconsistent at the same time, and gave the user no way to tell which.
The part that makes this dangerous rather than merely wrong
A fabrication you can spot is a nuisance. A fabrication that survives a skim is a liability, and these are built to survive a skim.
1. The phone numbers are in valid format
+84 is the correct country code for Vietnam and 234 is the correct area code for Hue. The digit grouping matches how a Vietnamese landline is actually written. Nothing about the shape of these numbers looks wrong.
Two of the three do carry a tell, though, and it is worth naming because it shows what the model is really doing. Run 2 ends 382 1234. Run 3 ends 388 5678. Those are keypad sequences, the phone number equivalent of Lorem Ipsum. A local reader spots them instantly. A freelancer in another country, working through a batch of fifty listings, does not.
Run 1 does not even give you that. +84 234 382 9999 has no tell at all.
I could not verify whether any of the three numbers reaches a real line, and I am not going to call strangers to find out. Three different numbers for one question is already the finding. But it does mean I cannot tell you the worst case here, only that at least two of these are wrong and none of them was flagged.
2. The addresses are real, which is worse than gibberish
I live in Hue, so this part I could check rather than guess. All three addresses are real locations in the city. Le Loi, Le Duan and Nguyen Cong Tru are real streets, the ward names attached to them are the correct wards, and the house numbers land on places that exist.
That is worse than a nonsense address, not better. A nonsense address fails the first check anybody runs. A real address passes every check short of going there in person.
What I could not check is the thing that actually matters: whether any of those addresses is a coffee shop, or whether the businesses named in the output exist at all. My guess is that the model has assembled real fragments of Hue into a business that does not exist, but that is a guess and I am labelling it as one.
The consequence does not depend on resolving it. A real address belongs to somebody. A generated listing built this way can point customers, reviews, or complaints at a business with no connection to your client.
3. The opening hours look like consensus, and are not
Two runs agreed on 06:30 to 22:00. If you ran the prompt twice and saw the same hours, you might reasonably conclude the model knows something. It does not. Run 2 said 07:00 to 21:30. The agreement is coincidence at a plausible-looking value, and coincidence is the most misleading result of the three.
4. It invented a business name I never asked for
This is the direct echo of the previous test on this site. There, the model invented a different logo on every run. Here it invented a different name on every run. Given a gap where identity should be, it fills the gap and does not mention it.
What it got right, and why that is the interesting part
I went looking for sloppiness in the parts of the output I could verify, and did not find it.
Run 2 places the shop near what it calls Trang Tien Bridge. That is Hue's most recognisable landmark and an easy thing to get wrong, so I checked the name. It is correct. The geography is correct too: the bridge is where the model implies it is, and the streets sit in the wards it assigned them.
The descriptive content is also accurate in ways that are not trivial. Ca Phe Muoi, salted coffee, genuinely is a Hue speciality rather than a generic Vietnamese one. Central Highlands sourcing is right. The Imperial City and the Citadel are real and correctly placed.
So this is not a model that knows nothing about Hue and is bluffing. It knows a fair amount, and the accurate knowledge is what makes the fabricated fields dangerous. The description reads as though written by someone who has been there, because most of it was written by something that has effectively read a great deal about the place. The four fields that were invented are surrounded by twelve sentences that check out.
That is the shape of the risk. The failure is not distributed across the output where you would notice it. It is concentrated in exactly the fields that have to be right, and camouflaged by everything around them.
Two tests, one rule
Put this next to the menu test and a pattern falls out that is more useful than either result alone.
When I supplied the data, the model reproduced it perfectly, down to prices ending in 50 cents, and invented the branding around it. When I supplied no data, it invented the data and produced branding for that too.
The model always returns a complete-looking artifact. What changes is how much of it is real. It has no mode in which it hands you something visibly unfinished, and the finish is what makes it hard to audit.
What follows from this if you sell local content
- Never let a model near the NAP fields. Name, address, phone. Those come from the client, in writing, and get pasted in. There is no prompt that makes this safe, because the failure is silent by design.
- Supply the facts, then use AI for the prose. That split matches what both tests show it is good at. The menu test proved it holds supplied data accurately. Use that.
- Distrust volume tooling that does not ask for a data source. If a product generates listings or citations without a field where the real details go in, it is generating this. That is a question worth asking on the sales page before you buy.
- Two matching runs are not verification. The opening hours agreed twice and were still a guess. Repetition looks like corroboration and is not.
Who should skip this approach
If you do citation building or directory submissions, do not put a model in that pipeline. The output format is convincing and the error mode is invisible, which is the worst possible combination for work whose entire value is consistency across dozens of sites.
If you write the descriptive prose around data a client has given you, this works, and the previous test suggests it holds supplied facts well.
Limits of this test
One model, one day, one city, one prompt, three runs. Three runs is enough to show that this is the model's normal behaviour rather than a bad draw, and not enough to put a rate on it.
I did not test whether an explicit instruction such as "do not invent any details" changes the outcome. I chose not to, on purpose: the question here is what the tool does when handed an ordinary, slightly lazy brief, because that is the brief it gets in real work. A prompt that has to be defended against the model is a finding in itself.
Two things stay open. I have not confirmed whether the businesses named in the output exist, only that the addresses are real places. And I have not verified any of the three phone numbers.
One hypothesis of mine died along the way, which is worth recording. I expected the model to misspell the name of the bridge, because getting Vietnamese proper nouns slightly wrong is a common failure and it would have been an easy point to score. It spelled it correctly.
If you run this and get a different result, tell me and I will publish the correction.
Why there are no affiliate links here
Products in this category launch constantly and I could have linked one. I tested the assumption underneath the category instead, and this page sells nothing. Reviews on this site carry affiliate links and disclose it. This one does not, because nothing had to be bought to find any of this out.