How to evaluate the source pages cited alongside competitor recommendations

An answer that recommends a competitor usually arrives with links. Those links are the closest thing you get to a view of what the assistant relied on for that response. Reading them carefully is often more useful than reading the recommendation itself, because they show the kind of page that earned a citation: a vendor's own documentation, a comparison table, a third-party review, a news article, a forum thread.

This article gives you a method for reviewing those pages without over-interpreting them.

What a citation does and does not tell you

A citation shows that a page was linked or named in a response. That is all. It does not show that the assistant "preferred" the page, that the page's author did anything special, or that the page caused the competitor to be recommended. An answer can also mention a brand in its text while citing a different site entirely, so a domain appearing in a response is not evidence that the domain's owner is the source of a claim.

Keep that discipline throughout: you are collecting observations about what appears, not reverse-engineering a ranking algorithm.

Step 1: Collect the cited URLs

Gather the URLs cited in successful responses where a competitor appeared. Keep, for each one:

• the full URL, not only the domain,
• which question and provider produced it,
• how many times it appeared,
• when it was last seen.

Group by URL. A single page cited repeatedly across questions is a stronger signal than twenty pages cited once.

Step 2: Classify each page

Sort the pages into a short list of types. A useful starting set:

Classification matters because the response differs by type. You can publish documentation and a comparison page yourself. You cannot publish a third-party review, but you may be able to ensure your listing there is accurate.

Step 3: Read as a buyer

Open each page as a person would. Write down:

• the sub-question it answers in its first screen,
• whether it states anything concrete, such as a number, a limitation, a step list or a definition,
• whether it is current,
• whether it is readable without JavaScript or a login.

You are looking for answer shape, the way a page packages information, not for phrases to copy.

Step 4: Find your closest page

For each cited page, find your closest equivalent. Three outcomes are common:

1. You have no equivalent. That is a content gap, which may or may not be worth filling.
2. You have one, but it is hard to reach or read. That is an access or structure problem. Check whether crawlers can fetch it, whether it redirects, and whether the answer is in the page text.
3. You have one that answers the same question just as clearly. Then the difference is probably not the page, and your hypothesis should move on to other explanations, such as third-party coverage.

Step 5: Decide, and write it down

For each page, record one of four decisions: create, improve, fix access, or leave alone. "Leave alone" is a legitimate result, and it should be the default when a cited page is a third-party piece you cannot influence and your own coverage is sound.

A worked example (illustrative)

A team reviews six URLs cited with a competitor over a 30-day window. The data is invented to show the method.

Two of six call for new or improved content, one for a profile update, one for an access fix, and two for nothing. Notice that the access fix comes first: the cheapest correction is making an existing page reachable.

Cautions

• Do not copy. Mirroring a competitor's structure or wording creates thin duplicate content and still guarantees nothing.
• Do not generalize from one provider. Providers cite different sources for the same question; compare across them before concluding.
• Do not assume recency drives selection. A page being older or newer is an observation, not an explanation.
• Do not forget unmeasured cases. Pages cited only in responses you did not track are invisible to this method.

How Doclight helps

Doclight stores the URL for each citation it extracts, and the competitor deep dive lists the pages the competitor was cited for, with how many citations and responses each accounted for, each page's share of that competitor's citations, and when it was last seen. The note on that view states the same limit as above: a citation shows a page was linked or named, and is not attribution for every brand mentioned in the answer text. Recommended actions built from a competitor gap link to the cited competitor pages as evidence, and ask you to compare them with your own before editing.

Doclight does not classify the pages for you, and it does not know why a page was chosen. The classification and the decision are yours.

Checklist

• Cited URLs collected with question, provider, count and last-seen date.
• Each page classified by type.
• Each page read for the sub-question it answers.
• Closest page of yours identified, or its absence noted.
• One decision per page: create, improve, fix access, or leave alone.
• Access problems fixed before content is rewritten.

Sources and verification

Checked on 2026-10-12 against this repository: the competitor deep-dive implementation (compute_competitor_deep_dive, citation destinations and its limitation note) and the Citation model, which stores a domain and URL per citation. For the access checks mentioned, see our articles on robots.txt and HTTP status codes. No external research is cited; the URLs and counts in the table are invented examples on reserved example domains.