Decide what to fix first

Fix first the gaps where three things line up: the prompt is a real buying question, you have read the cited pages and can name what yours lack, and the fix sits somewhere you can act. Then let the location of the missing evidence choose the job. If a page of yours should answer the prompt and has a nameable shortfall, update it. If no page of yours answers it, write one. If third-party pages carry the answer, earn a mention, or request a correction when they state something false. Check that crawlers can receive the fix, hand it over with evidence and an acceptance check, and treat it as a hypothesis to test, not a promised citation.

In short

• A citation gap is an observed difference in evidence, not a task. Rank gaps by buyer value, evidence, reach and effort; a tool's score knows nothing about which questions decide your sales.
• Where the missing evidence lives picks the job: a page you own (update it), no page at all (write one), or someone else's page (earn a mention or ask for a correction). "Hold off" is a legitimate outcome.
• Each page type answers one buyer question, and a common failure recurs across them: a dropped unit, limit, exception or date.
• A fix only counts if it can be received. Compare the raw HTML with the rendered page, and check that your CDN or firewall serves the crawlers you want.
• Hand over one change per task, with the finding, the evidence, the change and the check, and log every decision so it can be judged later.

Which gaps deserve the next piece of work?

The gaps worth working first sit on prompts that decide a shortlist, rest on evidence you have read yourself, show up across more than one prompt or engine, and are cheap enough to finish and review. Everything else waits in the log with a reason.

A citation is a link in an AI answer pointing at a specific URL as a source. A citation gap is the difference between what the pages an engine cites for a prompt contain and what your own page offers for the same question: a comparison table, an answer to the follow-up question, a figure your page never states. It is a specific missing piece, not a feeling that a competitor "ranks better" (see the glossary entry).

Candidates come from the audit in chapter 4, from a queue of gaps in your monitoring tool, and from citation data filtered to sources that are not yours. In DiscoveredBy, a prompt becomes a gap candidate only when, over the trailing window, your brand appears in under 30% of that prompt's runs and at least one citation points at a domain that is not yours (Citation gaps). A prompt you already win most of the time never becomes a gap, and because a run works through a bounded number of eligible prompts, a gap missing from the queue is not proof that none exists.

Then do the part no queue can do: read the cited page. Start from a buyer question written the way a buyer would ask it (chapter 3 covers choosing those). Open the top cited URLs and write down, in one plain sentence, what they contain that your page does not. "Has a feature table comparing three products" is useful; "is better" is not. Note who owns each cited page: a competitor, a third party such as a publisher or review site, or occasionally you.

Now score each gap. The method in finding the citation gaps to fix first uses four factors, each scored 1 to 3:

• Buyer value: 1 for a side question, 3 for a question that decides the shortlist.
• Evidence: 1 for one thin observation, 3 for something repeated across runs where you read the source and named the gap.
• Reach: 1 for one prompt on one engine, 3 for several prompts across engines.
• Effort: 1 for a small edit, 3 for a new page needing subject review, or for outreach.

Priority is buyer value plus evidence plus reach, minus effort. This structures your team's judgement; it is not a product feature. A tool's impact score is a relative order inside one project's evidence and cannot know which questions win deals.

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. Its team reviews three gaps over a 28-day window.

The arithmetic: 3 + 3 + 2 − 1 = 7 for A, 2 + 2 + 1 − 3 = 2 for B, and 3 + 2 + 3 − 3 = 5 for C. Gap C's 5 of 24 is 20.8%, so all three sit under the 30% line. The order of work is A, then C, then B, open to revision: if gap B turned out to decide more deals, its buyer value would rise.

Take as few gaps at a time as you can finish and review. With five changes made together, you cannot tell which one mattered.

Update a page, write a new one, or earn a mention?

Ask where the missing evidence lives. If a page you own should answer the prompt and you can name its shortfall, update it. If no page of yours answers the question, write a new one. If third-party pages carry the answer, the work is an earned mention.

The three jobs change different things:

• Update a page: edit a page you own so it contains what the cited pages have, such as a table, an FAQ, a figure, a clearer heading or a fresher date. It is usually the smallest change, and the easiest to compare before and after because the address stays the same.
• Write a new page: answer a question nothing you own answers yet. It is more work, and there is no earlier version to compare against.
• Earn a mention: get your brand into a third-party page that engines already cite. You do not control that page, so the work is outreach and evidence, not editing.

There is a fourth outcome: hold off. Weak evidence, a prompt that is not a real buying question, or a page already being reworked can all justify waiting. DiscoveredBy's Articles brief can recommend holding off too, alongside updating a page you own or publishing something new.

The decision matrix in update a page, write a new article, or earn a mention asks five questions. Answer in order and stop at the first that settles it:

1. Is the prompt a real buying question, with gap evidence you can show? If not, hold off and revisit the prompt list.
2. Do third-party pages (not yours, not a tracked competitor's) carry most of the cited answer? If so, the job is an earned mention; still go on to question 3 for any share that belongs on your site.
3. Do you have a page that should answer this prompt? If not, write a new page, after checking that no weaker page on the topic exists.
4. Can you name a specific shortfall against the cited pages? If so, update that page. If not, hold off, or re-check retrieval and crawler access first.
5. Will the change be judged on a before-and-after basis you have already defined? If not, define the measure first.

Figure 5.1 draws the first four; the fifth is a gate before any work starts.

To answer question 2, sort the cited URLs by whose site they sit on. Competitor product, pricing, feature and guide pages put the evidence on your site. A publisher's "best tools" roundup puts it on the publisher's site. Review sites, directories and forums put it on the third party's site, where the job is an earned mention or a profile you can legitimately maintain. A mix means two tasks. This sorting says where you can act, not what engines prefer.

Three cautions apply. A page of yours that engines seem to read but do not credit may have a delivery problem, not a content problem; your page was retrieved but not cited covers what to check. A new page can duplicate one you already have, so search your own site first. And do not bundle an update, an article and a pitch into one week.

For Quillstone, gap A is an update: the cited pages are competitor feature pages, Quillstone has a features page that should answer the prompt, and the shortfall has a name (the competitors show a clause-comparison table; Quillstone describes the feature in prose only). Gap B is a new page: the team searches its own site, confirms nothing weaker exists, and names someone who holds a real sample checklist as the owner of the proof. Gap C is an earned mention: nothing on Quillstone's own site can alter the roundup. The competitor pages cited beside it go into the log as a separate, later task.

What does each page type need to answer?

Each type of owned page answers one buyer question, and a common shortfall is a missing qualifier: the unit, the limit, the exception or the date. Figure 5.2 lists the question each type must settle.

Pricing: "What will this cost us, for what, and on what terms?" A price without its unit, billing period and conditions is an incomplete fact. The pricing page audit checks currency, what each price is per, billing period, minimums, tax, what each plan includes and what happens at a limit, add-ons and fees, terms, regions, and an effective date. Any figure shown only through a toggle or slider needs a written equivalent, and the pricing page, FAQ and checkout must agree.

Integrations: "Will it work with what we already run?" The integration page checklist asks for prerequisites (editions on both sides, roles, versions, who sets it up), supported actions written as verb, object, direction and trigger, limitations with units, and setup evidence with a last-checked date. Overstating a limit is as much a defect as hiding one.

Comparisons: "How do these options really differ, as of when?" A cell reading "Yes", "Unlimited" or "Included" cannot be checked. The comparison table QA sheet rewrites each cell as one sentence with a unit, an exception, a date, an owner and a source, adds a plain-text equivalent on the page, and allows a competitor cell only when it comes from that competitor's public documentation, dated. A cell nobody can source needs evidence, narrower wording or removal.

FAQ: "What is the straight answer to the question I asked?" Build the list from questions people actually asked: sales calls, support tickets, Search Console. Tracked prompts and fan-out searches can add candidates, but prompts are your own selection and fan-out searches are an engine's queries, not a buyer's words. The FAQ method merges duplicates, sorts questions into product fact, advice or "route elsewhere", and gives every answer a named source. Markup describes the page; it does not guarantee a citation.

Feature: "Does this fit the decision I am making, and what must be true first?" The decision-first rewrite picks one buying decision from evidence (stated reasons in answers, a citation gap, objections, sales questions) and builds the page around use, limits, prerequisites and proof that a reader can open.

Use case: "Is this right for someone in my situation?" A use-case page earns its place only when its audience asks different questions, needs different evidence or has different requirements. Otherwise it is a thin variant with a job title swapped in. The rubric in when a use-case page deserves to exist often ends in "add a section", and a rival's page is not a mandate.

Migration: "What will switching cost us, and can we go back?" A migration guide covers preparation, data portability (including what does not move), effort by task and role, and rollback. It names no other vendor and gives no timeline the team has not measured.

Help articles can answer capability questions too, but decide by risk first: customer-only material, then accuracy, then whether a buyer can follow them (support docs for pre-purchase questions). On every type, each claim needs a named owner and source, the date moves only when someone rechecks, and no format is a proven citation factor.

When is a third-party page worth approaching?

When it covers your category, does not already name you accurately, and has an editor who could reasonably add or correct something you can offer. How often engines cite it breaks ties among those pages; it should not choose the list.

Start from the pages AI answers already cite, not from a media list, and filter in the order set out in finding third-party pages worth approaching:

1. Relevance. Does the page treat the problem your product solves?
2. Brand match. Does its saved text already name you? DiscoveredBy's Mentions view checks literal, word-bounded matches of your names and aliases in saved text of third-party cited pages, and reports missing, failed, blocked or oversized scrapes as unknown. Unknown is not absent, and a common-word alias can match unrelated text.
3. Editorial fit. Is there a real reason for the author to change something, such as an outdated section or a missing use case? "Please mention us" is not a reason.
4. Freshness. Check when the saved text was fetched, then open the live page.
5. Count. Among the survivors, prefer pages cited in more completed answers and prompts.

Skip a page that is off-topic or already names you accurately. Hold one whose brand match is unknown until you have opened it, or where you have nothing concrete to offer. Approach a page that is on-topic, omits you, and has a specific addition or correction you can write down; if the angle is blank, the decision is not "approach". Review listings and forum threads usually have no editor who can revise them, so decide whether a legitimate route exists.

Lead the outreach with the specific gap, give the editor something verifiable, never buy placements you would have to hide, and log every contact, refusals included. DiscoveredBy's Earned sources lists third-party pages cited in completed answers, excluding your own domain and active tracked competitors, and lets you save one as an opportunity with an assignee, notes, a follow-up date and a status. Its counts find observed sources; they are not an authority score or a likelihood of placement. It does not send messages, find contacts, buy placements or publish anything.

For Quillstone's gap C, the roundup is on-topic, names Brieflane and Clausewise but not Quillstone, and its section on workflow features predates Quillstone's current approval routing. The angle is a factual update with a link to the documentation. If the publisher later reports the page updated, a before-and-after citation comparison is an observation, not proof that the outreach caused it; chapter 6 covers how to read one.

How do you ask a publisher for a correction?

Ask only when the publisher's own page states something false about you, then send one short message with an evidence packet: the disputed statement, the current fact, dated proof, and the exact wording you want instead.

If the page is right but an AI answer garbled it, the publisher has nothing to fix: make the official fact easy to find on your own pages and keep watching the answer. If the page states an opinion, there is no factual error to correct. And a cited page is not proof it caused the wrong claim, so confirm it contains the statement in its own words. The wrong claim starts in an AI answer, such as one you read in the audit from chapter 4, and the approved wording should already be on your fact sheet from chapter 2.

Capture first, because pages change: save the disputed page with the date and time, copy the sentence exactly, save your own official page the same way, and record the AI answer that started this (engine, date, prompt, quoted sentence). The packet in the correction request post has four parts:

1. The disputed statement: page address, the sentence quoted word for word, and the capture date.
2. The current official fact: one sentence, linked to the page on your site that states it.
3. Dated evidence: a release note, filing, press release or policy page the publisher can check, plus when the fact changed, if it did.
4. The requested amendment: the replacement sentence, the fastest thing for an editor to approve.

Keep the tone factual and the ask small. Some errors are just out of date: a roundup saying Quillstone is English only may have been accurate before later release notes added languages. Ask for an update, not an apology, and say a correction note would also resolve it. Send from a company address to a named editor or corrections contact, and do not bundle it with a request for a link.

The publisher may refuse or not reply. The page may not be where the wrong claim came from, and a corrected page may not change the answer. If your own fact turns out to be stale, fix that first; legal disputes need qualified advice, not a template. Report the page change as done and the answers as still being observed. If you track the request in Earned sources, keep it at Outreach in progress. Placement reported asks for a placement date and adds a before-and-after citation comparison, which measures something else.

Can crawlers actually see the fix?

Only if the content arrives in the HTML the crawler receives, and only if your CDN or firewall lets the crawler's request through. Check both before the change ships and again after.

Raw HTML is the response your server sends before any script runs; rendered HTML is the page after a browser has run its scripts. Crawlers that do not run JavaScript only see the raw response, so content, links, a title or a heading that appear only after scripts run are invisible to them (Site audit). Whether a given crawler runs scripts is for its operator to document: look it up, record the date, and write "not documented" rather than guessing. The safe rule is cheap: put the main text, key facts, important links, title and main heading in the initial HTML. The check in can a crawler see the content on your JavaScript-heavy page? compares raw and rendered versions of one exact URL on body text, links, title and heading, and indexing directives, and repeats after any delivery change.

Quillstone runs it on the features page it plans to update for gap A. The raw HTML holds 310 characters of text; the rendered page holds 2,450, because the feature details are inserted by a script. DiscoveredBy's page diagnostics mark "Content that needs JavaScript" for review when rendering adds at least 200 characters and at least doubles the raw text. Rendering adds 2,140 characters, and 2,450 is more than double 310 (620), so it needs review, and a new table built the same way would share the problem. Those checks come from one lab request and one browser load as DiscoveredByBot; they do not simulate any engine's crawler.

Next, the edge. Robots.txt is a request that well-behaved crawlers choose to honour; a CDN, web application firewall or bot-management layer decides separately whether each request is served. Is your CDN or firewall blocking requests you intended to allow? reads the status served to each bot: 403 and challenge pages are refusals, 429 a rate limit, 5xx capacity or a protection failing closed.

A user agent is only a claim, so split refusals by whether the request came from the bot's operator. DiscoveredBy's AI crawlers page labels logged requests verified (from the operator's published address ranges), spoofed (ranges are held and the address is outside them) or unverified (the address could not be checked). Then act on the combination:

• Verified bot refused on a page you want public: find the rule in your vendor's event log and add a narrow exception for that bot's verified identity and that path.
• Spoofed request refused: leave it; the protection is working.
• Unverified request refused: verify through the operator's own documentation before changing anything.
• Verified bot getting 5xx errors: look at origin capacity before touching security rules.

Change one rule at a time, write the rollback first, and never switch a protection off to test. Access is a precondition, not a guarantee: a page a crawler can fetch may still go uncited.

How do you hand the work to an editor or a developer?

Give one person one change on one exact page, in four parts: the page, the evidence, the change and its scope, and the check that says it is done. Figure 5.3 lists them.

The page is one exact URL, with its path, trailing slash and query string as saved. One page per task.

The evidence lets the recipient see the finding for themselves without a meeting. A developer needs the check name and its state, steps to reproduce (view-source, not the browser inspector, for a raw HTML finding) and the documented rule the audit applied. An editor needs the prompt, the engines, a one-sentence diagnosis written as an observation ("the cited pages include a comparison table and ours does not", never "AI ranks us lower because"), and the source URL and passage behind the change; saved quotes are not a fresh check, so ask them to open the source.

The change and its scope is one change: what may change, what must not, and who owns any content decision. A developer can remove one of two conflicting canonical tags but cannot decide which URL is preferred. State expected behaviour as a property of the page ("the feature details are in the delivered HTML"), never as an outcome in answers.

The check is written before work starts and answered yes or no. For a developer, it is a recheck of the same exact URL after release that moves the finding to "Check passed", plus a look at the delivered source; an Unknown result never closes the ticket. For an editor, it is a short list of statements about the page, such as "the table sits under the named heading and every cell names a source".

Keep three finish lines apart, as the page-fix task post does: the edit is done (the editor confirms it is live and accurate), the fix is recorded (whoever runs monitoring marks it applied after checking the published page), and the outcome is known (an analyst compares visibility at least a month later). The third belongs to chapter 6.

Turning an audit finding into a developer-ready ticket adds a "what this does not prove" block, so a ticket never claims more than the audit measured. A new page needs a brief instead: turning a citation gap into a content brief lists the gap, decision, audience, questions, the evidence only you can supply (each item with an owner), existing pages, constraints, and an acceptance checklist written before the draft.

If a tool drafts the change, know what was verified. In DiscoveredBy's Optimizations, a proposed change survives only if at least one evidence quote appears in the scraped text of the source page it names; the draft text itself is never compared against a source. Treat it as a starting point: the editor owns the wording.

Quillstone splits gap A into two tasks. The editor gets the features page, the passages from the two cited competitor pages, one change (a factual table of Quillstone's own clause-comparison features, sourced from its documentation), a scope line and four yes-or-no criteria. The developer gets a ticket for "Content that needs JavaScript" on the same exact URL, with both character counts, reproduction steps, the expected behaviour and an acceptance check: a passing recheck after release, and the table text visible in view-source. Neither task promises a citation.

Fix decision log

Copy this into a spreadsheet or ticket. Fill in one entry per gap before work starts, and a second entry when one gap calls for two actions.

FIX DECISION LOG

Entry ID:
Date of decision:
Decided by:

1. GAP
Prompt (exact wording):
Engines, channel and window examined:
Completed answers in window:
Answers naming my brand:               (count and share)
Cited pages, grouped by owner:         (mine / competitor / publisher / review site / other)
What the cited pages have that mine lack (one plain sentence):
Page of mine that should answer this:  (URL, or "none found after searching my site")

2. EVIDENCE
Cited pages I opened and read (URL, date read):
Passage or rule that supports the gap (quote, source URL):
Scores, 1 to 3:  Buyer value __  Evidence __  Reach __  Effort __
Priority (value + evidence + reach - effort):
Crawler check on the target page:      (raw vs rendered, date; bot access status, date)

3. CHOSEN ACTION (one per entry)
[ ] Update a page        URL:                 The one change:
[ ] Write a new page     Working title:       Owner of proof only we have:
[ ] Earn a mention       Target page:         Editorial angle:
[ ] Request a correction Disputed sentence:   Requested wording:
[ ] Developer ticket     Exact URL:           Expected behaviour:
[ ] Hold off             Reason:              Re-check date:
Where the missing evidence lives:      (my site / other site / both)
What I am NOT claiming:                (e.g. "this will not guarantee a citation")
Related entry, if one gap needs two actions:

4. OWNER
Owner of the work:
Reviewer or verifier:
Owner of any content or fact decision:
Due date:

5. HOW IT WILL BE CHECKED
Done when (yes/no acceptance criteria):
  -
  -
Baseline before the change:            (visibility and citation rate for this prompt, date range)
Check dates:                           (e.g. day 7, 14, 30)
Comparison basis:                      (same prompts, same engines, same window length)
Other changes in the same period:

6. DATES AND RESULT
Date the change went live:
Date recorded as applied or implemented:
Result and date:                       (improved / no change / insufficient evidence)
Next step:

In DiscoveredBy

Citation gaps takes prompts where your brand appears in under 30% of runs and another domain is cited, compares the most-cited competing URLs with your best matching page, records what yours lacks as evidence, and recommends creating a page when none matches. Actions, To do gathers open citation gaps, optimizations, earned sources and other open work into one list, with a priority band from one rule per kind rather than a combined score, and tabs that separate work on your site from work on other sites. Optimizations drafts a change for a page of yours behind a gap, each backed by a quote found in a cited source, and exports a task packet you can hand to the person doing the work. Nothing reaches your site unless you put it there. Earned sources lists cited third-party pages and tracks assignees, notes, follow-up dates and statuses, while the outreach itself happens outside the product. Citation gaps, Optimizations and task-packet downloads depend on your plan.