Create an identity record

Define the business before counting it. Record the official name, domain, product names, former names, and common misspellings. Add disambiguating facts such as category, location, parent company, and target customer. Short names and ordinary words require particular care. A word like Atlas could refer to software, a book, a geographic concept, or another business. A text match should therefore be a candidate observation until context confirms identity. Store this identity record separately from any individual prompt so the same rules apply consistently across collection periods and different search surfaces.

Match using context

Classify names using surrounding text and linked domains. Strong evidence includes the correct domain or an unmistakable product description. Weak evidence includes a bare name in a list. Keep an uncertain category instead of forcing every case into present or absent. Write rules reviewers can follow. For renamed products, separate references that describe the current business from references to discontinued offerings. Historical identity is not automatically current availability. Keep an audit note when reviewers disagree, and resolve recurring patterns in the guide rather than repeatedly making undocumented exceptions to the count.

Separate diagnostic questions

Use broad discovery questions alongside explicitly disambiguated diagnostics. Discovery shows what a buyer may encounter; diagnostics help investigate recognition of a specific business. Mixing them can inflate apparent recognition. Hypothetical example: fictional Harbor sells analytics software. One answer uses harbor in a shipping discussion. Another links to harbor.example and describes dashboards. Count only the second as a confirmed business mention. If a diagnostic names Harbor's domain, mark that prompt as branded and assisted. It should not raise a score intended to represent unprompted discovery among buyers.

Correct the public identity trail

Review the homepage, About page, documentation, social profiles, and important directory listings. Align the name, category, and domain wherever you control the information. Explain name changes clearly when older references remain useful. Structured data can describe an organization, but it should agree with visible facts. Treat it as another expression of the same identity rather than a substitute for readable information. A concise description of what the business does and who it serves also helps people distinguish it from similarly named companies, regardless of any later visibility change.

Audit inclusion and exclusion

Sample both included and rejected matches. False positives inflate visibility, while overly strict rules miss genuine references. Preserve reasons for uncertain or manually corrected cases. In exports, disclose how aliases and ambiguous names are handled. When a business changes its name, backfill only when historical meaning is clear and label the methodology update. Identity accuracy comes before sentiment scoring or competitor shares because those depend on knowing who an answer described. Review related products individually when they have distinct buyers, capabilities, or websites, rather than automatically attributing every parent-company mention to them. Include parent-company relationships only when they are verified and relevant to the classification being made.

PUT IT TO WORK

Prevent common names, renamed products, and unrelated domains from corrupting AI visibility reports.

Sources & further reading

Official documentation informs this guide. Examples are illustrative, and product interfaces or limits can change.

THE WORKSPACE WE'RE BUILDING

From search signals to a useful first draft.

SERP.so is in development. Join the waitlist for a workspace that connects research, content review, and publishing.

Join early access ↗