Can buyers tell what your integration actually does? A page review checklist

To find out whether buyers can tell what your integration does, read each integration page as a sceptical evaluator would: can they see what you must already have, which actions the integration supports, what it cannot do, and how someone would verify the setup? A page that only says "connects with X" leaves all four questions open, and it leaves an AI engine summarising the page for a buyer with nothing precise to repeat. This post gives you a twelve-point checklist, a copyable page brief, and a worked example.

In short

• Integration pages usually fail on specifics rather than tone. Missing prerequisites, vague verbs and unstated limits are common gaps.
• Review each page against four areas: prerequisites, supported actions, limitations and setup evidence.
• Write limits on the page yourself. A buyer or an engine that cannot find them may ask elsewhere, or assume.
• Treat every suggested edit as a hypothesis. No edit is proven to earn a citation or a mention.
• Use the page brief below to hand the fixes to a writer, with a named owner for each fact only your team can supply.

Why do integration pages deserve their own review?

Integration pages get their own review because they answer a different question from a feature page: not "what does this product do?" but "will it work with what we already run?" A buyer's decision can turn on that answer, and a vague page cannot give it.

Three things make them easy to get wrong. They are often written once, at launch, by whoever built the connector. They describe a moving target, because the other product changes too. And marketing wording ("seamless", "powerful") can easily replace facts on them.

For this post, an integration page is a page on your own site that describes how your product connects to one other product or platform. A supported action is something the integration does that a user can point at, such as "creates a matter in the other product when a review is approved". A prerequisite is anything a buyer needs before the integration works: a plan, a permission level, a version, an account role, a credential.

Why is this a content-and-citation problem, not only a support problem?

It is a content-and-citation problem because buyers put compatibility questions to AI engines, and an engine that answers from web pages has more to work with when the pages are specific. That is a reasonable inference, not a measured effect, so hold it as a working assumption.

Take a prompt such as "does document review software X work with our storage tool?" An engine that searches the web answers from what it finds. If your page says "connects with popular tools", the answer may be vague, or may draw on someone else's page about you. If a competitor's page lists actions and limits, an engine has something precise to quote from theirs and not from yours.

DiscoveredBy gives you two ways to see whether this matters for you. The Objections study (available depending on your plan; see plans and limits) asks the same fixed question about your brand and each active tracked competitor: what are the main objections or reasons a buyer might have for not choosing it? It puts the question to the chat engines on your plan and to ChatGPT (app), and each objection opens to the quotes behind it. If "limited integrations" or "unclear compatibility" shows up there, that is a lead for this review. The question is designed to produce downsides, so almost every brand gets some; the useful signal is which ones engines raise first and how they compare with your competitors and earlier studies. Read how to review an objection backlog for that process.

Enlarge image

The second is your own prompt list: prompts phrased as compatibility questions show whether your brand is mentioned and which pages are cited in the answers you collect.

The four areas: what should an integration page settle?

An integration page should settle four things, in this order: what you need first, what it does, what it does not do, and how to check it is working. Each area has a different failure mode.

Enlarge image

Prerequisites

Prerequisites are the conditions on the buyer's side and on yours. List the plan or edition needed on each product (without quoting prices), the account role who can authorise the connection, the versions supported, and any credentials or admin steps. Say who does the setup: the buyer's admin, your support team, or a partner.

Supported actions

Supported actions should be written as verb, object and direction. "Syncs documents" is a topic. "Sends approved documents from Quillstone to Vaultbox folders, one way" is a fact a reader can check. State what triggers each action (manual, scheduled, on event) and what data moves.

Limitations

Limitations are the part teams skip and buyers hunt for. List what is not supported, what is capped, what needs a workaround, and what is on a roadmap only if you can commit to a date (otherwise leave it out). Overstating a limit is as much a defect as hiding one, so state it at its true size.

Setup evidence

Setup evidence lets a reader trust the rest: the steps, what a successful connection looks like, where to get help, and when the page was last checked against the other product. A dated line such as "Checked against Vaultbox 4.2 on 12 March" is worth more than an unqualified "always up to date".

Enlarge image

The twelve-point integration page checklist

Use this table for each page. Score each row as pass, partial or fail, and write the evidence you saw. It works on a page you own, so it needs no tools beyond the page itself.

Row 12 deserves a note. Whether important text reaches a crawler depends on how the page is built. In DiscoveredBy, page diagnostics (available depending on your plan) compare a page's delivered HTML with a browser load that runs JavaScript, and mark content that only appears after rendering as needing review. Each check is one lab request from DiscoveredByBot on one page of your own domain, so treat it as a review prompt, not a statement about how every engine's crawler behaves.

The integration page brief (copy this)

Fill in one brief per page. The last block, "Facts only we can supply", is the one that stops a writer from inventing specifics.

INTEGRATION PAGE BRIEF

Page URL:
Partner product and category:
Owner (person who can confirm facts):
Date facts last verified:

BUYER QUESTIONS THE PAGE MUST ANSWER
1.
2.
3.
(Source of each question: sales call, support ticket, tracked prompt, objection study)

PREREQUISITES
Our plan/edition needed:
Partner plan/edition needed:
Roles and permissions:
Supported versions:
Who sets it up:

SUPPORTED ACTIONS (verb + object + direction + trigger)
1.
2.
3.

DATA SCOPE
Moves:
Does not move:

LIMITATIONS
Not supported:
Caps and delays (with units):
Known workarounds:

SETUP EVIDENCE
Steps (or link to public help article):
What success looks like:
Where to get help:
Last checked against partner version/date:

FACTS ONLY WE CAN SUPPLY (do not let the writer guess)
-
-

CLAIMS TO AVOID
(superlatives, "seamless", "real-time" without a measured interval)

REVIEW: pass / partial / fail on the 12-point checklist, before and after

DiscoveredBy's Articles screen handles a similar problem. On plans that ground drafts in source pages, and only when the brief calls for a brand new page, generation can pause with the status "Needs your input" and, when the brief named it, list "Proof only you have". The brief above applies that principle to any writer, human or otherwise. The Articles docs also say the tool never publishes for you, and that it awards "verified by source" to a claim only when the quoted evidence, at least four words long, appears in the scraped text of the source page it names. That is a standard you can borrow for integration claims: each line on the page should trace to something a named person confirmed.

Worked example: Quillstone and Vaultbox

Quillstone sells document-review software to legal and compliance teams. Its Vaultbox integration page currently reads, in full: "Quillstone integrates seamlessly with Vaultbox, so your team can work with your documents wherever they live. Get started today."

An objection study surfaces "Unclear which storage tools Quillstone works with" for Quillstone, while a competitor, Brieflane, has an objection about pricing instead. The Quillstone team pulls the Vaultbox page and scores it against the checklist.

That is 1 pass, 1 partial and 10 fails across 12 checks. The brief, once the integration engineer confirms the facts, produces this rewrite of the core section:

• Prerequisites: Vaultbox admin role required to authorise; Quillstone workspace admin to enable. Vaultbox 4.x supported; checked on 12 March.
• Actions: Sends approved documents from Quillstone to a chosen Vaultbox folder (one way, on approval). Imports documents from a Vaultbox folder into a Quillstone review (one way, manual, per folder).
• Data scope: Moves the document file and its approval status. Does not move comments or version history.
• Limitations: Files over 100 MB are not imported. Sync of approved documents runs within 15 minutes of approval. No two-way sync of edits.
• Setup evidence: Five numbered steps; after step 5 the folder shows a "Connected" label in Quillstone.

Every number here is invented for the example. Note the effect of the rewrite: each line is now a claim someone can verify or dispute, which is the point. It is also now possible for a buyer, and for an engine summarising for them, to say "yes, but it does not sync comments", which is a better outcome than a vague answer that later disappoints.

After publishing, the team would run page diagnostics on the exact URL to confirm the new facts sit in the delivered HTML, and at a later weekly objection study look at whether "unclear which storage tools" changes in prominence. It might not move in one study, and a comparison of two studies cannot show that the page edit caused any change.

What can this checklist not tell you?

It cannot tell you that an engine will cite the page, or that completing it will change your visibility. A stated objection is an observation of what an engine said about your brand in one study, not proof of why it said it. The checklist tells you whether the page is precise and checkable; whether that helps depends on the prompts your buyers use, the sources engines choose and factors outside your control.

Common mistakes to avoid:

• Listing logos instead of pages. A grid of partner logos with no detail per partner tells a reader nothing about actions or limits.
• Writing limits as marketing. "Advanced sync" hides the cap. State the cap.
• Publishing roadmap items as capabilities. If it is not shipped, keep it off the supported list.
• Letting facts drift. Partner products change. Put a last-checked date on the page and an owner in the brief.
• Hiding facts in a PDF or an image. Key facts belong in page text.
• Forgetting the pricing dimension. If access depends on a plan, say so; see the pricing page audit for how to review that page separately.

Frequently asked questions

How detailed should an integration page be?

Detailed enough that a buyer can decide whether to proceed without contacting anyone, and no more. Put the four areas on the page and link out to a public help article for the full setup steps. Very deep configuration material belongs in support documentation.

Should I list what the integration cannot do?

Yes, for the cases buyers actually ask about. A short, honest limits section makes the supported list more credible. Do not invent limits you cannot confirm, and do not list unshipped features as if they were coming.

Do I need a separate page for every integration?

Only if the integration has facts different enough to fill the four areas. A single page that lists ten partners with one line each usually fails the checklist for all ten. If two integrations share identical actions and limits, one combined page can be reasonable.

Will fixing integration pages get my brand cited by AI engines?

There is no guarantee, and we do not claim a citation lift. The change makes the page more precise and easier to verify, which helps human buyers regardless. Whether engines cite it is something to observe over time with the same prompts, not assume.

How often should I recheck an integration page?

Whenever the partner product releases a major version, when your connector changes, and on a regular schedule you set, for example each quarter. Put the date of the last check in visible text so readers and reviewers can see it.

Who should own the facts on the page?

The engineer or product manager who knows the connector. A writer can shape the page, but the brief's "facts only we can supply" block should have a named person who confirms each line and its date.

Next step

Pick your three most-visited integration pages, score them against the checklist, and fill in one brief. To see whether buyers' questions about compatibility surface in AI answers, run an objection study and track compatibility prompts in DiscoveredBy. If a prompt shows a citation gap, accepting it creates a topic on the Articles screen. For the wider set of tools, see optimisation features. For turning a gap into a writer's brief, read citation gap to content brief.