How closed, fictional, and prank locations get indexed in the Google Places API, and how developers can filter them out
A critical field guide to POI hygiene in 2026, with supporting data tables per section and developer-side filtering strategies that hold up in production.
Every developer who has ever built a store locator, a food-delivery search box, a routing app, or a sales-territory dashboard against the Google Places API knows the moment. A user types in a query, the API returns a beautifully formatted response, and one of the results turns out to be a coffee shop that closed in 2019, a phantom locksmith whose real address is a suburban PO box, a joke listing named after a schoolyard nickname, or a “restaurant” that only exists in the imagination of a bored teenager with a Google account. The API delivers the ghost with the same confidence it delivers the real business. To the machine, all place records look equally real.
This is the phantom business problem, and in 2026 it is not going away. It has just become better documented. In this piece we look at the anatomy of the phantom, the scale of the problem, the mechanisms that let phantoms slip past Google’s moderation, the filtering tools the Places API does and does not give developers, and the design tradeoffs that keep the problem structural rather than solvable.
The Anatomy of a Phantom
Not every stale entry in a location database is the same. Cleaning them up requires knowing which kind you are dealing with. Six broad categories cover most of what shows up in the Places API in 2026.
| Category | What It Is | Typical Example |
|---|---|---|
| Closed Permanent | Business that has shut down but still appears in the index | Restaurant that closed during pandemic |
| Closed Temporary | Business closed for renovation, season, or emergency | Ski shop shut for summer |
| Moved but Duplicated | Business relocated; old address still listed | Dental practice with two Maps entries |
| Scam or Duress Vertical | Fake service targeting people in urgent need | Locksmith with VoIP number and no address |
| Prank or Vandal Listing | Real place edited or invented as a joke | High school renamed “Area 51 South” |
| Cartographic Ghost | Fictional place created as a copyright trap or an algorithm artifact | Argleton, Agloe, Beatosu and Goblu |
Table 1. Six categories of phantom entries typically found in the Google Places index.
Sources: Google Maps Platform blog; Wikipedia entries on Phantom settlement, Argleton, and Locksmith scam.
Each category has its own root cause and its own life cycle. Closed businesses accumulate because the world changes faster than Google’s moderation queue. Duress-vertical scams persist because they are profitable enough to justify continuously creating new listings. Prank listings survive because Google’s algorithms have no reliable way to distinguish an obvious joke from a legitimate niche category. Cartographic ghosts are the strangest of all: they exist because Google’s data providers themselves once used them to catch competitors copying their maps.
The Scale of the Problem
The most-cited figure, dating back to a 2019 Wall Street Journal investigation, is 11 million illegitimate business listings on Google Maps at any given time, with hundreds of thousands more created each month. Google has since spent seven years steadily reducing that surface, and by its own admission catches around 85 percent of fake listings before they ever go public.
| Metric | Value | Year and Source |
|---|---|---|
| Illegitimate Google Maps business listings | ~11 million | 2019 WSJ investigation via Search Engine Land |
| New illegitimate listings per month | Hundreds of thousands | 2019 WSJ investigation |
| Reduction in fake listings since 2015 | 70% | Google, via Foster Web Marketing |
| Fakes caught before public exposure | 85% | Google self-reported |
| Fake listings in one 2025 lawsuit | 10,000+ | CBS News, March 2025 |
| Duress verticals most targeted | Locksmiths, towing, contractors, movers, attorneys | Google general counsel testimony |
Table 2. Scale metrics of the fake and phantom listing problem in Google Maps and Google Places.
Sources: WSJ investigation; Search Engine Land (2022); CBS News (March 2025); Google company statements.
The 85 percent catch rate is the good news. The 15 percent miss rate is the developer’s problem. On a database that ingests millions of new entries per week, 15 percent of failures is still a lot of ghosts. And catch-before-public metrics do not address the far larger and more persistent problem of listings that were legitimate when created and have since become stale.
How Phantoms Enter the Index
Understanding how a bad entry gets into Google Places is the first step to filtering it out. There are four principal ingress paths, each with different implications for the confidence a developer can place in a record.
| Path | How the Entry Is Created | Detection Difficulty |
|---|---|---|
| Google Business Profile self-service | Owner or claimant submits a listing, verified by postcard, phone, or video | Low to medium |
| Third-party data feeds | Data brokers, yellow-page aggregators, franchise directories | Medium |
| User contributions | Local Guides, edit suggestions, photo uploads | Medium to high |
| Algorithmic inference | Google’s own crawlers detect a candidate place from web signals | High |
Table 3. The four principal paths a place record takes to enter the Google Places index.
Sources: Google Maps 101 blog post; Google Places API documentation.
The first two paths at least involve a claimant with legal accountability. The last two do not. Algorithmic inference in particular is the source of most cartographic ghosts. Argleton, a Lancashire town that never existed but sat on Google Maps for years, is believed to have been an artifact of a data-supplier’s algorithm that fictionalized a nearby settlement, either as a copyright trap or as a mis-transcribed record. Google itself did not create Argleton. It simply did not have the ground-truth signal to know Argleton was not there.
The business_status Field: What It Catches and What It Misses
The Places API does give developers one first-line defense against closed businesses. Since May 2020, business_status has been available on Place Search, Place Details, Find Place, Nearby Search, and Text Search responses. It replaced the deprecated permanently_closed boolean and takes three values.
| Value | Meaning | Developer Use |
|---|---|---|
OPERATIONAL | Google believes the business is currently trading | Include in results |
CLOSED_TEMPORARILY | Closed for renovation, season, emergency, or similar | Optionally exclude, or mark |
CLOSED_PERMANENTLY | Shut down for good | Exclude from user-facing results |
| (field absent) | Google has no confidence signal either way | Default to skepticism |
Table 4. Values of the business_status field in the Google Places API.
Source: Google Maps Platform Places API documentation; Google Maps Platform blog (2020).
The field is useful. It is also insufficient. Four failure modes cover most of what it misses.
First, business_status is only set when Google has enough signal to make a determination. On long-tail businesses, small-town listings, and any place where user contributions are sparse, the field is simply absent. A missing business_status is not the same as OPERATIONAL, but developers who treat it that way, and many do, quietly serve stale results.
Second, closure signals lag reality by weeks or months. A restaurant that shut on the first of the month will typically stay OPERATIONAL in the API for anywhere from thirty days to a full quarter, depending on how quickly Local Guides or the owner report the change.
Third, business_status cannot distinguish a scam listing from a legitimate one. A fake locksmith that verified itself two years ago and now diverts calls to a call center in another state will remain OPERATIONAL until someone flags it and Google acts on the flag.
Fourth, the field does nothing about vandalized names, joke edits, fictional entries, or duplicated records where the same physical business appears twice.
Trap Streets and Cartographic Ghosts
The most philosophically interesting category of phantom is the one Google did not create and cannot easily remove. Fictional places have been deliberately planted in maps for at least a century as copyright traps, also called Mountweazels. If a competitor copies your map, the fictional entry gives you legal evidence they did. Agloe, New York, was invented on a 1930s map as one of these. Beatosu and Goblu were added to a 1978 Michigan highway map by University of Michigan alumni as an inside joke about the Ohio State University rivalry.
| Phantom Place | Origin | Duration in Public Maps |
|---|---|---|
| Agloe, New York | Invented on a 1930s General Drafting map as a copyright trap | Appeared in Rand McNally through the 1990s |
| Argleton, Lancashire, UK | Appeared on Google Maps from ~2008, likely a data-supplier artifact | Roughly 2008 to 2010 |
| Beatosu and Goblu, Ohio | Added to 1978 Michigan highway map as an inside joke | Removed from later editions |
| Trap streets | Small cul-de-sacs or bends added to catch copyists | Persistent across map generations |
| Fictitious entry | Deliberate errors in dictionaries and encyclopedias | Standard practice in reference publishing |
Table 5. Notable cartographic ghosts and the practice of copyright trapping.
Sources: Wikipedia: Phantom settlement; Wikipedia: Argleton; coverage in the Sydney Morning Herald and Telegraph on Argleton.
The important developer implication is that some of the phantom entries in the Places index are not bugs. They are intentional, planted by upstream data suppliers to catch downstream copying. Filtering them requires ground-truth verification against imagery, addresses, or crowdsourced signals, not a boolean flag from the API.
Duress Verticals and the Locksmith Problem
Not every phantom is passive. Some are deliberately weaponized. In her March 2025 CBS Mornings interview announcing Google’s lawsuit against a fake-listings network, Google general counsel Halimah DeLaine Prado named the category directly: duress verticals, defined as service categories people search for in urgent or stressful situations. Locksmiths, towing companies, plumbers, electricians, and emergency contractors dominate the list, precisely because a stranded consumer is a consumer who does not shop around.
The mechanics have been documented for years. Fake service contractors flood Google Maps with listings that share a common pattern: VoIP phone numbers that look local but forward to a call center in another city or country, addresses that are either legitimate homes of unrelated residents or PO boxes and virtual offices, and multiple listings verified against the same address to game local pack rankings. When a stranded driver calls the “cheap locksmith” advertising a USD 15 unlock, a technician arrives, does shoddy work, and bills USD 400.
| Duress Vertical | Common Phantom Pattern | Consumer Harm |
|---|---|---|
| Locksmiths | Multiple listings, shared VoIP phone, virtual office | Overcharging, damage to locks |
| Towing services | Local-looking name, out-of-state operator | Predatory tow-truck lien enforcement |
| Electricians and plumbers | Unlicensed contractor impersonating a licensed one | Substandard work, safety risk |
| Movers | Bait pricing followed by inflated final invoice | Held goods until payment |
| Attorneys and immigration services | Impersonation of licensed practices | Financial and legal harm |
Table 6. Common duress-vertical scam patterns on Google Maps.
Sources: BizIQ analysis of scam patterns; CBS News reporting on the 2025 Google lawsuit; Wikipedia: Locksmith scam.
For developers, duress verticals are the highest-stakes filtering problem in the Places API. A store locator that returns a closed cafe is a minor inconvenience. A call-a-locksmith app that returns a scam operation is a lawsuit waiting to happen.
Developer Filters That Actually Work
Google gives developers exactly one clean field to filter with. Getting past that requires stacking heuristics on top of the raw API response. Here is a practical playbook that works in production in 2026.
| Filter Strategy | What It Catches | Implementation Cost |
|---|---|---|
Reject when business_status != OPERATIONAL | Explicitly closed businesses | Trivial |
Reject when business_status field is absent AND no user_ratings_total | Low-confidence long-tail entries | Low |
| Require minimum review count (5 to 20) | Prank listings, most cartographic ghosts | Low |
| Require review recency (last review within 6 to 12 months) | Zombie businesses that closed silently | Medium |
| Reject on shared VoIP phone patterns and multi-listing shared addresses | Duress-vertical scams (locksmiths, towing) | Medium |
| Cross-check business name against known category list | Vandalized names, gibberish edits | Medium |
| Verify address geocode against building footprint or satellite imagery | Cartographic ghosts, PO-box scams | High |
| Enrich with a second POI source and reconcile | Everything the above misses | High |
Table 7. Practical developer filter strategies for cleaning the Google Places API response.
Sources: BizIQ analysis of scam patterns; Search Engine Land coverage of fake listings; developer forum consolidation.
For most consumer applications, the first three filters remove most of the damage. For enterprise applications where a bad address can cost tens of thousands of dollars, like fleet routing, insurance underwriting, or last-mile logistics, filters four through eight become non-negotiable. That is where the developer conversation stops being about Google alone and starts being about whether Google is the right sole source.
The Reporting Pipeline: What Google Gives You Back
Google publishes a Business Redressal Complaint Form for reporting suspected fake or misleading listings, and users can suggest edits directly through Maps. In practice, both channels operate on a delay that limits their usefulness for real-time applications. Enterprise developers rarely rely on Google’s reporting pipeline as a primary defense; it functions instead as an eventual-consistency mechanism that improves the index over months rather than hours.
| Channel | Latency | Effectiveness |
|---|---|---|
| Business Redressal Complaint Form | Days to weeks | High for repeat scams, low for long tail |
| “Suggest an edit” in Maps | Days | Moderate; often requires multiple reports |
| Google Business Profile owner claim | Weeks | High once the real owner claims the listing |
| Machine-learning preemptive detection | Real time at ingestion | 85% catch rate per Google |
| Post-report human review | Weeks to months | Selective, prioritized by risk vertical |
Table 8. Google’s reporting pipeline for cleaning up phantom listings.
Sources: Foster Web Marketing on the Business Redressal Complaint Form; Google Maps 101 blog on preemptive detection.
The strong takeaway is that developer application logic cannot rely on Google to clean the index in time. Anything that matters at the transaction level, from dispatching a driver to authorizing a payment, has to be defended in the application layer.
The Design Tradeoff Behind the Problem
The problems above are structural. They come from Google’s decision to make Places open to self-service creation from anyone with a Gmail account. That decision drives coverage but taxes quality. It is easy to criticize the resulting phantom rate, but the tradeoff is genuine: a POI corpus that is hard to enter is a POI corpus with big gaps.
| Design Choice | Advantage | Cost |
|---|---|---|
| Open self-service creation | Fast long-tail coverage | Higher fake and prank rate |
| User-contributed edits | Freshness on operating hours, closures, name changes | Vandalism and joke edits |
| Algorithmic ingestion from web signals | Coverage of small businesses without web presence | Cartographic ghosts, misattribution |
| Third-party data feed integration | Broad geographic reach | Inherited errors from upstream suppliers |
| Ground-truth verification requirement | High confidence in every record | Slower creation, coverage gaps |
Table 9. Ingestion design choices and their consequences for POI quality.
Sources: consolidated from Google Maps 101; Search Engine Land; Google Places API documentation.
There is no free lunch. A corpus that is expensive to enter is a corpus that is cleaner. A corpus that is cheap to enter is a corpus that is bigger. Google has picked one point on that curve. Developers who need a different point on the curve have to build against it or move off it.
Recommendations for Developers
Anyone building on the Google Places API in 2026 can take five concrete steps to reduce phantom exposure without abandoning Google entirely. The order matters. Each step depends on the ones above it.
| Step | Action | Expected Impact |
|---|---|---|
| 1 | Filter every response on business_status == OPERATIONAL and treat absent as suspect | Removes most explicit closures |
| 2 | Apply a minimum review count and review-recency threshold appropriate to your vertical | Removes most pranks and ghosts |
| 3 | Cross-check high-stakes addresses against a second POI source | Catches structural phantoms and Google-only artifacts |
| 4 | Ingest ground-truth imagery for verification of critical delivery, service, and dispatch destinations | Catches the last mile of phantom failures |
| 5 | Instrument dispatch and delivery for phantom-address failure recovery, not just detection | Recovers cost when the first four fail |
Table 10. A five-step phantom-mitigation playbook for developers on the Google Places API.
Source: consolidated from Google documentation, industry reporting, and enterprise practice.
Outlook
The phantom business is not a bug in Google Places. It is a design consequence. An index built on self-service creation, crowdsourced contribution, and algorithmic inference will always contain a percentage of phantom entries proportional to how open the ingestion pipeline is. Google’s engineering has closed the gap from where it was in 2019 by a factor of several, but the gap is structurally impossible to close completely. Every developer using the Places API in 2026 needs a filter stack, and the more the application depends on the address, the deeper the filter stack has to go.
For consumer discovery, Google’s index remains hard to beat on coverage and freshness. For enterprise routing, dispatch, delivery, and any workflow where a phantom address triggers a real cost, single-source dependence on the Places API is a risk that operates silently until the day it does not. The digital graveyard will keep growing. The question is whether the tools that consume it are ready.
| Concern | 2026 Data Point | Source |
|---|---|---|
| Illegitimate Google Maps listings, 2019 baseline | ~11 million | WSJ / Search Engine Land |
| Fake listings caught before public exposure | 85% | |
| Reduction in fake listings since 2015 | 70% | |
| Fake listings in one 2025 lawsuit | 10,000+ | CBS News |
| Duress verticals most targeted | Locksmiths, towing, contractors | Google general counsel |
business_status field values | OPERATIONAL, CLOSED_TEMPORARILY, CLOSED_PERMANENTLY | Google Places API docs |
| Business Redressal Complaint Form latency | Days to weeks | Foster Web Marketing |
| Preemptive ML catch rate | 85% at ingestion | Google Maps 101 blog |
Table 11. The phantom business problem in 2026 at a glance.
Sources as cited in each table above.
Sources and Credits
- Google Maps Platform. Temporary closures now available in the Places API (2020). mapsplatform.google.com
- Google for Developers. Places Web Service FAQ. developers.google.com
- Google for Developers. Places Library Reference. developers.google.com
- Google Blog. Maps 101: How we tackle fake and fraudulent contributed content (2021). blog.google
- Search Engine Land. Millions of fake Google Maps listings hurt real business and consumers. searchengineland.com
- CBS News. Google finds 10,000 fake listings on Google Maps, sues alleged network of scammers, March 2025. cbsnews.com
- Foster Web Marketing. Google Rolls Out Complaint Form for Fake Listings in Maps. fosterwebmarketing.com
- BizIQ. How to Fight Spam and Fake Listings on Google Maps. biziq.com
- Wikipedia. Phantom settlement. en.wikipedia.org
- Wikipedia. Argleton. en.wikipedia.org
- Wikipedia. Locksmith scam. en.wikipedia.org
- Wikipedia. Ghost job. en.wikipedia.org
Disclosue: Data compiled from Google Maps Platform documentation, investigative journalism, and public records. Where estimates differ across sources, the most recently reported figure has been used. Terminology such as “duress vertical” is drawn directly from Google’s public statements.