When Perplexity Doesn't Know Your Business Exists

Two businesses. Both invisible on Perplexity for their own brand queries. Both had assumed the fix was the same.

It wasn't.

In one case, Perplexity's query processing intercepted the brand name before it ever reached entity lookup. In the other, Perplexity recognized the name but mapped it to a completely different organization. The first business needed external indexed presence -- enough consistent external references to cross a disambiguation threshold. The second needed entity anchoring, because a competing organization with a similar name had a far larger web footprint.

Same symptom. Different cause. Different fix.

The Autocorrect Failure Mode

In our May 2, 2026 edge-case report on the Jupitrr audit (Scout session 10, `edge-cases/perplexity-brand-name-autocorrect-2026-05-02.md`), we documented something that hadn't appeared in any prior audit: Perplexity's A1 and A2 queries -- direct brand recognition queries for "Jupitrr" -- returned information about the planet Jupiter.

Not wrong information about Jupitrr. Information about Jupiter. The brand query never reached entity lookup.

Perplexity's retrieval pipeline includes a query normalization step that handles spelling variants and autocorrect. For strings that closely resemble a high-confidence known entity -- a planet, a major city, a famous person -- the normalization layer resolves the query before disambiguation runs. "Jupitrr" (intentional double-r) resembles "Jupiter" closely enough that Perplexity's spell-correction assigned it to the planet at high confidence. There is no wrong-company content to displace. The brand simply does not exist in Perplexity's entity vocabulary.

ChatGPT handled the same query differently. ChatGPT A1 said: "there is no widely recognized platform named Jupitrr." Entity lookup ran, returned null, and the model acknowledged the unknown. That's still a failure, but a different one: training-data absence, not query interception. The fix for ChatGPT is training data exposure -- getting mentioned in indexed content ChatGPT draws from. The fix for Perplexity's autocorrect wall is different: enough indexed external sources using "Jupitrr" consistently as a proper noun, with surrounding context that signals "this is a brand name, not a misspelling."

High-signal directories that Perplexity retrieves frequently -- Product Hunt, G2, Crunchbase, industry-specific registries -- are the right starting point. Each one adds a data point for Perplexity's resolver: the string "Jupitrr" appears alongside structured data indicating a company, a product, a software tool. Over time, that context shifts the spell-correction confidence below the threshold for a Jupiter redirect.

This failure mode is most common in brands with intentional alternate spellings, names that closely resemble common nouns, and businesses with near-zero external indexed presence. If your brand name has fewer than three edits from a well-known word or entity, it's worth explicitly testing whether Perplexity recognizes the name or normalizes it away.

The Entity Disambiguation Failure Mode

The second failure mode looks identical from the outside -- Perplexity returns irrelevant content for brand queries -- but the mechanism is different.

In our session 16 analysis (2026-05-13), we ran the first systematic source URL review from a Sourcepull audit: the May 11, 2026 audit, which captured 102 Perplexity source URLs across 12 queries. This is documented in `platform-citation-behaviors.md`.

For the A1 query -- "What is Sourcepull?" -- Perplexity cited 10 URLs. Every one pointed to Sourcewell, a Minnesota government cooperative purchasing agency. Not one URL from sourcepull.ca appeared.

Perplexity ran live web retrieval, retrieved real current results, and returned content about an entirely different organization. The mechanism was not autocorrect -- Perplexity recognized "Sourcepull" as a proper noun and ran retrieval. The problem was that Sourcewell had a much larger web footprint: more indexed pages, more external citations, more entity signal weight. When Perplexity retrieves results for "Sourcepull" and scores entity matches, Sourcewell's signal mass wins.

The session 16 finding framed it directly: "The disambiguation signal in sourcepull.ca's schema and llms.txt is not strong enough to override Sourcewell's much-larger web footprint."

What's notable is that the C-query results (service-level queries) showed what was actually working. Third-party sources like `peerpush.net/p/sourcepull` and `g2.com/products/sourcepull/pricing` appeared as Perplexity citations and resolved to the correct entity. The fix path was already visible in the data: more sources like those, pointing to Sourcepull specifically, and Perplexity's disambiguation tilts the right direction.

Why Wikidata Comes Second, Not First

For disambiguation failures specifically, the standard entity anchoring tool is Wikidata -- a Q-item that links your brand to a canonical entity ID, which AI platforms use when resolving ambiguous names.

That recommendation is right, with a caveat our April 25, 2026 methodology rec flagged early (`methodology-recs/2026-04-25-wikidata-smb-notability-risk.md`, Scout session 5): Wikidata entries without external citations get deleted by community editors.

Wikidata's standard for business entries is "clearly identifiable" with "reliable, public sources" -- meaning press articles, business registries, recognized public databases. A provincial corporate registry entry qualifies. A BBB profile qualifies. A Product Hunt listing qualifies. Your own website does not. "The entry is not the first step," the methodology rec noted. "It is a step that requires prior evidence to be valid."

The correct sequence: build external indexed presence first, then create the Wikidata entry using those external sources as citations. The April 25 rec also noted a distinction that matters for disambiguation cases specifically: "the disambiguation value of Wikidata is real even if citation-lift is uncertain." For businesses experiencing entity confusion, the goal is not getting cited more -- it's making sure Perplexity routes the brand name to the right entity at all.

Running the sequence backwards produces a Wikidata entry that gets flagged and deleted before it can do anything useful.

Both Failures Have the Same Upstream Cause

Two different failure modes, one upstream cause: thin external indexed presence.

A brand with a meaningful set of external citations -- real directories consistently using the brand name as a proper noun, with structured context around it -- is unlikely to fail either test. Perplexity's normalization layer gains enough signal to recognize the string as a proper noun. The entity disambiguation competition has more citations pointing to the right business.

The fix sequence in both cases follows the same order: external presence first, entity anchoring second. Schema refinements and llms.txt optimization come after the foundation is built, because they amplify the existing signal -- they don't generate it from nothing.

Perplexity's live retrieval architecture means it is the most responsive platform to these external changes. Once a new directory listing is indexed and consistently using the correct brand name, Perplexity can register the change in 2-7 days. That's faster than ChatGPT (7-21 days) and significantly faster than Claude or Google AI Overviews (14-45 days). The urgency of fixing it is matched by the speed at which the fix can take effect.

A Sourcepull Signal Check tests your brand queries on Perplexity directly. If your brand scores zero on Perplexity while scoring higher on other platforms, it may not be a visibility gap -- it may be a recognition gap. The source data tells them apart, and the fix is different enough that it matters which one you're dealing with.