Get your brand ready

Getting your brand ready for AI answers means deciding, before you measure anything, what a correct answer about you would contain, and making sure your own public pages say it consistently. Write down the facts a buyer could check, the qualities you want to be known for, and the competitors you expect to be compared with. Reconcile the pages that disagree, publish what buyers need outside your login wall, and gather the Search Console and analytics data you already hold. None of this guarantees what an engine will say. It gives you a fixed yardstick for every later reading, and it removes the inconsistencies on your own site, which are the part you control.

In short

• Write your approved facts and target attributes before you read any answer, so the answers cannot reshape your intent.
• Answers can draw on your website, your docs and help centre, third-party articles and lists, review sites, and social and video. Only your website and your docs are yours to change.
• Reconcile your own pages fact by fact: copy what each page says, choose one value confirmed by a named owner, and fix the pages that disagree.
• Put a fact outside the login wall when a buyer needs it before signing up and it passes the tests for sameness, confidentiality, ownership and evidence. Keep account-specific material private.
• Search Console queries and GA4 referrals are evidence for choosing and phrasing prompts. They are not a measure of what people ask AI engines.

What should AI be able to say about you?

A correct answer about your brand would state your facts accurately, link you to the qualities you want to own, and place you among the competitors buyers actually weigh. Write those three things down first, in your own words, because they are the yardstick every later reading is measured against.

Order matters. If you read answers first, the answers shape the facts. What to do when AI gets your pricing or product facts wrong makes this the first step of its correction workflow: write each approved fact once, check it against your own records, and only then look at what engines say. The same rule applies to the qualities you want to own.

Separate three kinds of statement, because each is checked in a different way:

• Facts. A fact is a single statement about your organisation that a buyer could verify and that has one correct value at a given time: how pricing is structured, the seats on a plan, the regions where data is stored, a refund window, the integrations you support.
• Attributes. An attribute is a short, neutral quality phrase, such as "Ease of use" or "Audit trail", that an answer associates with a brand. Attributes can be unwelcome as well: "Expensive" is an attribute in the same way.
• Competitors. The brands you expect answers to name beside you, and the ones you want to be compared with.

Positioning lines such as "we care about compliance teams" are none of these, because there is nothing a buyer could check. A useful test from the company facts audit: if you cannot imagine a buyer checking a sentence, leave it off the fact list.

Where do answers read about you?

An answer that describes your brand can draw on much more than your website. Figure 2.1 groups the places into five: your website, your docs and help centre, third-party articles and lists, review sites, and social and video.

Any of these can carry a fact about you. A wrong price in one answer can be tied to your own old blog post, and in another to an undated software roundup on someone else's site. When a fact exists only behind a login, an engine may answer from review sites, old blog posts or a competitor's comparison page. Engines also cite social, community, video and review accounts; DiscoveredBy's Social sources screen lists those cited accounts and marks each as yours, a tracked competitor's or unlabelled. Your own help centre and FAQ articles count as well, and they are among the places an out-of-date figure survives.

You control two of those five groups: your website and your docs. The other three belong to someone else, so you cannot edit them; when one of them states something wrong, you can ask its publisher for a correction, which chapter 5 covers. That is why this chapter starts with your own pages. Keep the reading honest, though: a cited source shows where an engine placed its citation, not why the model wrote what it wrote, and engines may also draw on older copies or their own training. A consistent website is a precondition for accurate answers, not a guarantee. Chapter 1 explains how mentions, citations and recommendations differ.

Illustrative example: Quillstone and its competitors are fictional, and the numbers are made up to show the method. Quillstone sells document-review software to mid-sized legal and compliance teams and competes with Brieflane and Clausewise. Its content lead starts a one-page list of facts, qualities and competitors, and each section below adds to it.

Which attributes do you want to own?

Choose three to five qualities you want buyers to link with your brand, phrase them without brand names, and set a market wording you would be happy to be judged in. Then check each quality with two separate questions, because being described a certain way and being named for it are different results.

Keep sentiment out of it. Positive sentiment means an answer spoke well of your brand; positioning means it tied your brand to a specific quality. An engine can recommend you warmly for reasons you never chose. Is your brand known for the attributes you want to own? sets out the method, and AI brand sentiment: read the evidence behind a positive score covers the sentiment side.

The two questions are:

1. What is this brand best known for? The answer lists qualities from most to least prominent. How prominently your description lists a quality is its association.
2. Which brands are best known for this quality, in this market? This question does not name your brand, so the engine is not steered toward it. How prominently you are named is your market prominence, and the brand named most prominently is the leader, which can be a brand you do not track.

Read the two as a pair, one attribute at a time, and never subtract one from the other. They come from different questions, so they are not on a shared scale. High association with low prominence means engines describe you this way but name other brands first. Low association with high prominence means engines name you for the quality but do not reach for it when describing you. The disagreement is usually the most useful finding.

The market wording changes what every reading means. A broad market such as "software" puts you among every well-known software brand, where a small company is rarely named. Decide it early and change it rarely, because a reading is only comparable with earlier readings that asked about the same market in the same language.

Before you look at any result, write next to each attribute why it matters to buyers and what evidence you could back it with. If a quality is missing from the descriptions engines give, the first check is whether your own pages state it plainly, with something concrete behind it.

In the Quillstone example, the market is "document review software for legal and compliance teams" and the three attributes are Ease of use, Audit trail and Security certifications. Scores run from 100 for a quality listed first, minus 10 for each later position, to 0 for an engine that answered without it, averaged over the engines that answered. Three engines answered every question:

The arithmetic: (100 + 90 + 0) ÷ 3 = 63.3; (80 + 70 + 0) ÷ 3 = 50.0; (80 + 0 + 0) ÷ 3 = 26.7; (100 + 100 + 90) ÷ 3 = 96.7.

Audit trail is the interesting row: Quillstone leads the market ranking, yet engines seldom list it when describing Quillstone, so the team reads the quotes to see which qualities the descriptions lead with instead. Ease of use is the reverse, and the team reads Brieflane's supporting quotes and sources before writing anything. Security certifications is zero in both. That does not mean Quillstone lacks certifications, only that the engines that answered did not connect it to them (if no engine had answered, there would be no number at all). Its evidence column turns out to be the problem, as the login wall section shows.

Nothing in either score explains why an engine said what it said, so every gap is a hypothesis to test. What engines say your product is bad at is a separate reading; see what AI says your product is bad at.

Do your own pages agree with each other?

Often they do not. Pages written at different times, by different people, for different jobs drift apart, so check them fact by fact: copy what every public page says about one fact, choose a value someone can confirm, and fix the pages that disagree.

A pricing page is updated at a plan change, a feature page at a release, a help article when a support agent notices, and a launch announcement never. Each may have been right when last edited, and together they can still describe three different products.

A reader, human or machine, who finds two values for one fact has to choose, and you no longer control which one it picks. We cannot say how any engine weighs conflicting pages. The narrower point still holds: while your pages disagree, you cannot point at one and say "this is our position", and buyers who read them directly notice.

Which pages should you compare?

Compare every public page a buyer or a crawler could plausibly land on: pricing and plans, feature and integration pages, security and compliance pages, help centre and FAQ articles, terms and refund pages, about, contact and careers pages, and the announcements, press releases and blog posts that state specifics. Add the places stale values hide: footers, PDF press kits, author bios, and partner listings or directory profiles you control. Search your site for an old product name or an old figure and treat every hit as a row to review. Leave out pages behind a login; this review is about what is public.

How do you run the review?

Work fact by fact, not page by page, or each page looks fine on its own and the conflict never shows. Your own pages disagree about your product gives the full register; the core steps are:

1. Freeze the scope and date. A reconciliation is a snapshot. Without a date, nobody can tell later whether a mismatch is new.
2. Copy exact wording. Paste each page's sentence, not your paraphrase. "Since 2018" and "founded in 2018" are the same fact; "about 40 people" and "50+ people" are not.
3. Group by fact. Give each fact one row label and collect every page's statement under it. Two statements share a row when a buyer would treat them as answers to the same question.
4. Compare values, units and dates. Check monthly against annual, per seat against per workspace, currency and effective dates. Mark each row as matching, conflicting, or different in scope.
5. Choose the source of truth. Name the authoritative value and the person who confirmed it, usually in product, finance, legal or security. If nobody can confirm a value, mark the row unverified and do not publish one.
6. Fix pages, then record. Edit the pages that disagree, note the date and re-read them.

Not every difference is a defect. A sales email and a press email should differ, and an enterprise page can quote a longer contract term than a page for small teams if it says so. Write down the reason for each difference by design, so nobody "fixes" it later. And do not let the newest page win by default: the latest edit might be the wrong one, so the value comes from the fact's owner, not the page's editor.

Product names deserve their own rows, because marketing shortens them, engineers abbreviate them and retired names linger. Pick one canonical name for your pages, and keep the variants you find: in DiscoveredBy, an alias is another name for a brand that mention extraction accepts as it (see Brands and sub-brands).

Quillstone's seat count on five pages

Quillstone's fact row is "seats on the base plan". Figure 2.2 shows what the five public pages that state it say: the pricing, feature and comparison pages and the press release give 5 seats, and the help article gives 10.

The team does not settle it by majority, because agreement is not accuracy: four pages can agree and all be wrong. Finance confirms 5, so the help article is the page to change. Seats are something a buyer would choose or refuse on, so the row is high impact and goes to the front of the queue. Rank the rest of the register by buyer impact and reach. Even an old public post that states a specific still needs a decision: correct it, add a dated note, or retire it.

Once the values agree, they can become your approved facts. DiscoveredBy's Fact check keeps approved facts about your own brand, in six categories (pricing, company, product, availability, policy and other), and shows whether AI engines state them correctly. It checks answers against your facts; it does not compare your pages with each other, and its Suggest from my site drafts each come from a single page, so if your pages still disagree it may draft both versions. Reconcile first, then approve only the confirmed wording.

What belongs outside the login wall?

A fact belongs on a public page when a buyer needs it to decide whether to sign up, it is the same for every visitor, publishing it breaches nothing, a named person will keep it correct, and you can back it with evidence. Account data, unreleased plans and customer-specific terms stay behind login.

A login wall here means any page that needs an account, a session or a form submission before it shows its content. This guide makes no claim about how any particular engine's crawler handles such pages; the safe working assumption is that content you want quoted should be readable without signing in. A fact that lives only behind the wall will not necessarily be stated wrongly, but you have left the answer to other pages.

Start from buyer questions, not your site map. Sales call notes, the pre-sales inbox and the prompts you track all hold questions prospects ask before they would create an account. Write the fact that answers each one and where it lives today (a gated page, a PDF, a sales deck, or nowhere), then apply five tests:

The tests lead to four decisions. Publish when all five pass. Summarise when a reduced version passes, for example a pricing model described in general terms instead of negotiated figures. Keep private when confidentiality fails, when the fact is account-specific, or when no buyer needs it. Hold when the owner or the evidence is missing but the first three tests pass; a held fact stays off the public site until both exist. What product information should be public? has the full decision sheet and its rules.

The fourth test is the one teams skip: a public claim nobody maintains becomes a wrong fact in an answer later. The fifth matters most for security and compliance claims, where overstating your position is a liability, not a visibility asset.

When a gated page mixes public-safe and private material, write a summary instead of publishing the page. Summarise, never mirror: copying a gated page onto a public URL exposes whatever you forgot to remove. Give the summary one canonical home, or you recreate the reconciliation problem from the previous section. If its text needs JavaScript to appear, check what a crawler receives; see can a crawler see the content on your JavaScript-heavy page?

Quillstone's integration list and the detail of its pricing model (per reviewer seat, with volume tiers) sat only inside a gated customer portal. The team wrote ten facts from its prompt list and ran the tests: four to publish (what the product does, the Microsoft 365 integration, two named case-management integrations, pricing per reviewer seat with volume tiers), two to summarise (exact tier price bands became a sentence about volume discounts, and data storage became "customers choose EU or US storage at signup"), one to hold, and three to keep private (one customer's negotiated discount, usage and invoice history, an unreleased mobile app). Four plus two plus one plus three is ten.

The held fact is the SOC 2 audit, which is still in progress, with no owner for the statement and no evidence on file. That leaves the Security certifications attribute from earlier with an empty evidence column: there is nothing public the team can point to yet, so it plans no content for that quality until the evidence exists.

A public page can be crawled and still not be cited. Treat each published summary as a hypothesis: re-read the matching prompts afterwards, and expect that answers may not change. Chapter 4 covers checking whether crawlers can reach the pages that matter.

Which competitors do you compare against?

Compare against the brands buyers actually weigh you against, starting from your own list and correcting it with evidence. Names that keep appearing in answers, names in your Search Console queries, and the leaders of your attribute rankings all show who belongs on it.

Write your own list first, then check it against three kinds of evidence.

Brands that appear in answers. In DiscoveredBy, names in collected answers that match none of your tracked brands are listed on the Competitors screen under "Brands appearing in your answers", with how many answers named each and when it was first seen. Until you track a brand, its mentions are left out of every metric that counts brand mentions, so an untracked rival is invisible in your shares.

Competitor names in your search data. A query such as "clausewise alternative" is usually a comparison-stage question with real commercial weight, and it often makes a good tracking prompt, rewritten so the question stays neutral. A competitor that keeps turning up in queries like this belongs on your list.

Leaders you do not track. The leader of an attribute's market ranking can be a brand you do not track. If one keeps leading the qualities you want to own, consider adding it.

Some names that turn up this way are not competitors at all. A product name, abbreviation or misspelling of a brand you already track is another name for it; record it as an alias so one brand is not counted as two.

Keep the list deliberate and fairly stable, because changing it changes the numbers. Pausing a competitor takes it out of the share-of-voice chart and out of the total those shares divide by, and a competitor that an earlier attribute study did not ask about reads "No comparison" for market prominence against that study, not "New". Write down when you add or pause one, and read shares before and after that date as different populations; why share of voice can rise while your brand mentions stay flat explains the denominator. How many competitors you can track depends on your plan (plans and limits).

Quillstone tracks Brieflane and Clausewise. A third name, Docket North, keeps appearing in answers, so the team adds it. A fourth, "QReview", turns out to be Quillstone's own internal shorthand, used in a help article; the team records it as an alias of its own brand and uses the canonical product name on the page.

What data do you already have?

Most teams already hold three useful sources: Search Console shows which Google searches surfaced your pages, GA4 shows which sessions arrived from AI engines' own referrers, and sales and support notes hold buyer questions neither tool sees. Use all three as evidence for choosing and phrasing what to track, not as a measure of AI demand.

Search Console: queries are fragments

A Search Console query is a search string typed into Google. A tracking prompt is a full question you choose to monitor because it resembles what your buyers ask. A query carries little context: it does not say who is buying, what they are comparing, or what happens next. A prompt has to, because an engine answers the question as written.

From Search Console query to AI tracking prompt sets out five steps: collect candidate queries with impressions, position and the ranking page; classify each one; keep, merge or drop it with a written reason; rewrite each keeper as a buyer question; and log the evidence. Branded, navigational and single-word queries usually make poor prompts; "quillstone pricing" is a fact to check, not a discovery question.

Figure 2.3 shows one query becoming a prompt.

The query "contract review software for legal teams" drew 1,900 impressions at an average position of 6.1 in Quillstone's 28-day window. As a buyer question, it needs a buyer, a situation and a decision: a legal team of about 20 people choosing contract review software. The tracking prompt fixes that as "What should a 20-person legal team look for when choosing contract review software?" A test for any rewrite: could a colleague in the buyer's role plausibly type it into an AI assistant? If it still sounds like a search box, it has not been rewritten.

Do not slip your own brand into an unbranded question, because a question that names you measures something different. And keep the wording stable once tracking begins, or results before and after the edit are no longer like for like.

Search Console only contains queries that already surfaced your pages, so silence is not zero demand. Impressions count appearances in Google results, and nothing in DiscoveredBy measures how often a question is put to ChatGPT or Gemini. With Search Console connected, DiscoveredBy shows a Google demand figure on each tracked prompt, best used to rank your own prompts against each other.

GA4: a floor, not a total

AI referral traffic is the set of sessions whose source is an AI engine's own referrer, such as chatgpt.com or perplexity.ai. A visit with no referrer is recorded as direct and cannot be counted, so the figure is a floor. Visits from Google AI Overviews and Google AI Mode arrive as ordinary Google traffic. Nothing in a session connects it to a specific prompt, answer or citation.

Decide which GA4 events count as conversions before you read a conversion figure anywhere, and write the list down. How to measure AI referral traffic and conversions with GA4 has the full worksheet, and the AI traffic page explains how DiscoveredBy classifies referrers.

Sales and support notes

Neither tool shows the buying questions you do not yet rank for: Search Console lists only queries that already surfaced your pages, and GA4 records visits, not questions. Sales calls, support tickets, the pre-sales inbox and buyer interviews fill that gap. Chapter 3 turns all of these sources into a prompt list you can defend.

Brand fact sheet

The fact sheet collects this chapter's decisions on one page: the facts with their approved wording and owners, the attributes you want to own, and the competitors you compare against. Fill it before you read any answers, keep a date on it, and re-check it after any pricing change, launch, rebrand or new market. The example row is Quillstone's seat count from this chapter, and is illustrative.

BRAND FACT SHEET
Brand:                  Prepared by:            Date:
Market wording (one line, no brand names):
Next full review date:

A. FACTS (one row per fact; one checkable sentence each)
ID | Category (pricing / company / product / availability / policy / other) |
Fact | Approved wording (exact, with unit, scope and effective date) |
Source page (the one public URL that is the source of truth) |
Other pages that state it (URL + their wording) | Match? (yes / conflict / scope) |
Public? (publish / summarise / keep private / hold) | Confirmed by (name) |
Last checked (date) | Owner (who keeps it correct) | Pages to change | Status (open / fixed / unverified)

Example (illustrative):
F1 | pricing | Seats on the base plan | "The base plan includes 5 seats." |
quillstone.example/pricing | feature page: 5; comparison page: 5;
help article: 10; press release: 5 | conflict | publish | Finance lead |
(date) | Pricing owner | help article | open

B. ATTRIBUTES WE WANT TO OWN (fill before reading any results)
Attribute (no brand names) | Why it matters to buyers |
Evidence we can back it with (fact ID or public URL) | Owner | Last checked

C. COMPETITORS WE COMPARE AGAINST
Brand | Domain | Why it is on the list (our judgement / appears in answers /
search queries / leads an attribute) | Date added or paused | Known aliases

D. OUR OWN NAMES
Canonical brand and product names | Variants found (abbreviations,
old names, misspellings) | Where each variant appears | Record as alias? Y/N

E. DATA WE ALREADY HAVE
Search Console property mapped? Y/N | GA4 property mapped? Y/N |
Conversion events counted (list) | Sources of buyer questions
(sales calls, support tickets, pre-sales inbox, interviews)

RULES
- Every approved value has a named person who confirmed it.
- Every difference by design has a written reason.
- An unverified fact is not published and not monitored.
- A held fact stays off public pages until its owner and evidence exist.
- When a value changes, every page in its row changes too.

In DiscoveredBy

Four screens support this step. Attributes and Fact check, and how many competitors you can track, depend on your plan (plans and limits); Integrations does not. Attributes holds your market wording and up to 10 attributes of your own. A weekly study asks engines what your brand and each active tracked competitor are known for and, once a market is set, which brands are best known for each of your attributes and a few others, showing association and market prominence side by side with the quotes behind them. Fact check keeps your approved facts and shows whether engines state them correctly, though it does not compare your own pages with each other. Competitors lists the brands appearing in your answers that you do not track yet, with "Add as competitor" on each row and, for owners and editors, "Add as alias of…". Integrations connects a Google account with read-only access and maps Search Console and Analytics properties to your project.