What product information should be public? A decision sheet for the login wall

Product information belongs outside the login wall when a buyer needs it to decide whether to sign up, when it is the same for every visitor, and when publishing it creates no confidentiality, legal or accuracy risk you cannot manage. That usually means what the product is, who it is for, what it integrates with, how it is priced in general terms, and its policies. Account data, unreleased plans and customer-specific terms stay behind login. The method below scores each fact on those tests and produces a publication decision sheet. It cannot promise that any engine will cite a page you publish.

In short

• A login wall hides content from anything that cannot sign in, which includes a first-time buyer comparing options and an AI engine assembling an answer.
• Decide fact by fact, not page by page. One gated page usually mixes public-safe facts with private ones.
• Publish a summary, not the gated page itself, when the original mixes both. The summary is a new page with its own owner.
• Keep confidential and account-specific material private. Public visibility is never a reason to expose it.
• Treat every published summary as a hypothesis: check whether answers change, and expect that they may not.

Why does the login wall matter for AI answers?

If a fact lives only behind a login, no page that can be read without signing in states it. That does not mean an engine will get the fact wrong; it means the engine may have to answer from whatever else it finds, such as review sites, old blog posts or a competitor's comparison page.

A login wall here means any page that requires an account, a session or a form submission before it shows its content. A request that carries no credentials receives a login form or an error instead of the content. We are not claiming how any particular engine's crawler handles such a page; the safe working assumption is that content you want quoted should be readable without signing in.

In DiscoveredBy terms, this can show up as a citation gap. The product docs define a citation gap as the difference between what the pages engines cite for a prompt contain and what your own page offers, and they note that when no page of yours exists to compare, the opportunity is to create one. The docs do not describe DiscoveredBy detecting a login wall, so deciding that a missing fact sits behind one is your judgement, not something the tool reports.

A citation is your domain linked as a source for an AI answer. A mention is your brand named in the answer. You can be mentioned without being cited, and cited without being mentioned; the key terms page draws the same line. A public page gives an engine something it can link to. Whether that changes your citations or your mentions is something you observe, not something you can assume.

Enlarge image

How do you inventory the facts buyers need before signing up?

Start from buyer questions, not from your site map. List the questions a prospect asks before they would create an account, then write the fact that answers each one and note where that fact lives today.

Good sources for the list are your sales call notes, your support pre-sales inbox and the prompts you already track. A tracked prompt in DiscoveredBy is a question you chose to monitor because it is the kind of thing your buyers ask, so your prompt list is a ready-made list of buyer questions. Work through it and, for each prompt, ask what fact a good answer would need.

Then sort the facts into families:

• Identity: what the product does, who it is for, what category it sits in.
• Capability: features, supported file types, integrations, deployment options.
• Commercial: pricing model, plan structure in general terms, trial terms, refund policy.
• Trust: security summary, compliance status you can support with evidence, data residency, uptime policy.
• Operations: supported regions and languages, support hours, onboarding steps.
• Account-specific: anything that differs per customer, such as negotiated prices, usage, invoices, configuration.

Only the last family is private by definition. The others need a decision.

What tests decide whether a fact goes public?

Apply five tests to each fact. A fact goes public only when it passes all five, or when you can rewrite it into a version that does.

Enlarge image

The fourth test is the one teams skip. A public claim that nobody maintains becomes a wrong fact in an AI answer later, and correcting that is harder than not publishing. If you have already had a wrong price or feature quoted, see what to do when AI gets your pricing or product facts wrong.

The fifth test matters most for trust facts. State only what you can support, and say how current it is. A public security summary that overstates the position is a liability, not a visibility asset.

Should you publish the gated page or write a public summary?

Write a public summary when the gated page mixes public-safe and private material, and publish the page itself only when everything on it passes the tests. A summary is a separate page that states the shareable facts in plain text, links to the gated page for signed-in users, and has its own owner and review date.

Three rules help keep summaries safe:

• Summarise, never mirror. Copying a gated page onto a public URL exposes whatever you forgot to remove. Write the summary from the inventory, not from the page.
• Leave out the specifics that vary. Say "pricing is per seat with volume tiers" if that is true and stable, rather than a table of negotiated discounts.
• Give it one canonical home. Two public pages stating the same fact slightly differently create the next problem; see your own pages disagree about your product.

Choose the format for the reader. A short section of plain sentences and a small table depends on little beyond the HTML itself, unlike a PDF or an interactive widget. If the summary depends on JavaScript to show its text, check what a crawler receives; can a crawler see the content on your JavaScript-heavy page covers that check.

The deliverable: a publication decision sheet

Copy this sheet once per product, fill one row per fact, and review it with legal, security and the product owner before anything goes live.

PUBLICATION DECISION SHEET
Product: ____________   Prepared by: ________   Date: ________

Row fields, one row per fact:
  #            Running number
  Buyer question   The question a prospect asks before signing up
  Fact         The one-sentence statement (exact wording to publish)
  Family       Identity / Capability / Commercial / Trust / Operations / Account-specific
  Lives today  Where it is now (gated URL, PDF, sales deck, nowhere)
  T1 Buyer need            Y / N
  T2 Same for everyone     Y / N
  T3 Safe to disclose      Y / N   (reviewer: ________)
  T4 Accuracy owner        Name, or NONE
  T5 Evidence on file      Y / N   (link or reference)
  Decision     PUBLISH / SUMMARISE / KEEP PRIVATE / HOLD
  Public URL   Where the public statement will live
  Review date  When the owner re-checks it
  Signals to watch  Prompt(s) and engine(s) you will re-read after publishing

Decision rules:
  All five tests pass                          -> PUBLISH
  Passes after removing specifics or wording   -> SUMMARISE (write the reduced version)
  T3 fails, or fact is Account-specific        -> KEEP PRIVATE (do not revisit for visibility)
  T1 fails, T3 passes                          -> KEEP PRIVATE (no buyer reason to publish; leave it in gated docs)
  T4 or T5 fails but T1 to T3 pass             -> HOLD until an owner or evidence exists

Apply the rules from the top; the first that matches decides. Two notes on using it. First, KEEP PRIVATE is a legitimate final answer; the sheet exists to protect confidential material as much as to expose public facts. Second, HOLD is not a soft yes. A fact on hold stays off the public site until the missing owner or evidence exists.

Worked example: Quillstone

Quillstone sells document-review software to mid-sized legal and compliance teams. Its tracked prompts include "which document-review tools support Microsoft 365 and a case-management system?" and "how is document-review software usually priced?". A competitor, Brieflane, is cited on both. Quillstone's integration list and pricing model both sit inside a gated customer portal, and the public site has only a marketing page with general claims.

The team writes ten facts from its prompt list and runs the sheet:

Counting the decisions: 4 PUBLISH, 2 SUMMARISE, 1 HOLD, 3 KEEP PRIVATE, which is 10 in all. Six of the ten facts (60%) can appear on public pages, in full or reduced.

Fact 5 becomes "tiers start at a stated minimum seat count and discounts apply with volume", with no price bands. Fact 6 becomes "customers choose EU or US storage at signup", because which region a given customer has is account-specific. Fact 7 is held: the audit is not complete, nobody owns the statement, and no evidence is on file, so the sheet forbids a public line. Quillstone then puts the six publishable statements on one public product-facts page and leaves the portal as it was.

After publishing, the team re-reads the two prompts in its monitoring tool at the next weekly review. If Quillstone is cited on one and still not on the other, that is a finding, not a failure. The result does not prove the page caused the change, and no change would not prove the page was wrong.

What does DiscoveredBy help with here?

DiscoveredBy can help you find the prompts worth this work, brief a page, and watch what engines say afterwards. It does not decide what is confidential, and it never publishes a page for you. Which of these features you have depends on your plan; see plans and limits.

• Citation gaps turn prompts where your visibility is low and other domains are cited into a ranked list of specific changes, with the evidence found for each. Where DiscoveredBy finds no matching page of yours, it recommends creating one.
• Articles starts from an accepted gap or a topic you type and decides which asset should exist. When the brief calls for a brand new page on a plan that grounds drafts in evidence, generation can pause and ask for proof only you can supply, such as pricing. You put any page live yourself.
• Fact check lets you keep a list of approved statements about your own brand, such as what a plan costs or which countries you serve, and shows whether AI engines state them correctly. Your approved facts are a sensible starting point for the wording on the sheet.
• Page diagnostics checks an exact URL on your project's domain, without credentials or cookies, and records the HTTP status DiscoveredByBot receives and whether the delivered HTML has extractable text. The docs are explicit that this does not simulate another crawler or establish access for it.

Enlarge image

Common mistakes and limits

• Publishing the whole gated page. You expose what you meant to keep, and you may create a second, conflicting version of the fact.
• Treating public as citable. A public page can be crawled and still not be cited. Whether an engine uses it is outside your control.
• Leaving nobody accountable. An unowned page goes stale, and stale public facts are how wrong answers persist.
• Confusing a clean check with a verdict. A passed page diagnostic is not a complete page-health verdict and does not establish indexing or citation eligibility, per the docs.
• Reading one result as proof. Answers vary between runs. Compare consistent prompts, engines and windows before concluding anything.
• Skipping the security review. Anything in the Trust family needs a named reviewer who can defend the wording.

The public site is also not the only place engines look. Third-party pages describing you matter as well, and this sheet does not cover them.

Frequently asked questions

Will putting product information outside the login wall get me cited by ChatGPT or Gemini?

Not by itself, and nobody can promise it. Publishing gives an engine something readable to draw on; whether it does so depends on the prompt, the engine and the other sources available. Measure it against tracked prompts instead of assuming.

Can I keep my documentation behind login and still show up in AI answers?

You can, but the answers to buyer questions may then have to come from other pages. If documentation holds the answer to a pre-sales question, put a summary of that answer on a public page and leave the detailed documentation gated.

Is it safe to publish pricing?

That is a business decision, not a technical one. Describing a pricing model in general terms, without negotiated figures, often passes the five tests; publishing exact prices needs sales and finance sign-off and an owner for keeping them current.

How do I check that the public page is actually readable?

Open it in a private browser window with no session, then run a check on the URL in your monitoring or audit tool. In DiscoveredBy, page diagnostics records the status DiscoveredByBot receives and whether the delivered HTML has extractable text, and the page issue queue brings saved findings for known pages into one list. A clean result is not a guarantee for other crawlers.

What if a competitor's public page is cited and mine is gated?

Treat it as a citation gap: compare what their page states with what a public version of yours could safely state, then use the sheet to decide what to publish. Do not copy their wording.

Does robots.txt affect this?

Yes, separately. A public page can still be disallowed for a crawler by a robots.txt rule. The robots diagnostics page explains how DiscoveredBy reads the declared policy for five AI crawlers; it reports the policy, not whether any crawler actually visits.

Next step

Take the ten buyer questions your prospects ask most, fill the decision sheet, and publish only what passes. Then track the matching prompts so you can compare answers before and after. To see which of your tracked prompts have a citation gap, sign in to DiscoveredBy and open Citation gaps. If you want the wider workflow, see how to optimize. To decide which gaps to work first, read find the citation gaps that deserve your next content update.