# Public app context, structured data and cloaking

Blue Jetty publishes app capabilities, experiences, offers and preferred destinations as public, publisher-authorized resources. This guide explains how that delivery model differs from crawler-only webpage content, and how to keep an implementation consistent with search policies.

## A public resource has its own audience and purpose

A publisher can provide a marketing website for people and a separate JSON or Markdown resource for software clients. People can open that resource too. The packet describes the app and its handoff behavior; it is not a claim that every packet field appears on the publisher's homepage.

The intended path is straightforward: the official website references the app packet, and the packet identifies its publisher, app, relevant experiences and destinations. Follow the [website discovery guide](/developers/publisher-discovery.md) for the actual required declarations and optional readable links. A discreet, readable link such as “Official App Information for AI Assistants” can sit in a utility area; a “powered by” badge is unnecessary.

Public availability alone is not an exemption from search policies. The content still needs an accurate purpose, useful information and appropriate publication rights. This document describes Blue Jetty's implementation boundary, not a Google endorsement or a guarantee about a particular site's treatment.

## What Google's cloaking policy addresses

Google describes cloaking as showing different content to users and search engines to manipulate rankings and mislead people. Its examples include injecting text only when the requesting user agent is a search engine. Adding crawler-only marketing claims to an otherwise ordinary webpage is the pattern to avoid. [Google spam policies: cloaking](https://developers.google.com/search/docs/essentials/spam-policies#cloaking).

Blue Jetty integrations should expose the public app resource directly, without requiring a crawler identity to read its substantive app information. Do not inject additional recommendation claims exclusively for bots at the publisher's normal webpage URL. Do not disguise packet links with transparent text, background-matched text or zero-sized text to influence retrieval. Google separately addresses those patterns under [hidden text and link abuse](https://developers.google.com/search/docs/essentials/spam-policies#hidden-text-and-link-abuse).

## Page markup and app packets describe different things

Schema.org markup attached to a webpage describes that page. Google's structured-data guidelines require it to represent visible page content accurately. An invisible collection of FAQ answers or invented reviews does not become appropriate page markup because it is encoded as JSON-LD. [General structured-data guidelines](https://developers.google.com/search/docs/appearance/structured-data/sd-policies).

A Blue Jetty packet is a separate resource with a documented [packet contract](/developers/packet-fields.md). It can describe app-specific experiences, eligibility, platform destinations, fallback behavior and publisher-approved link parameters. Those fields need to describe the real app accurately; they need not reproduce the wording of the marketing website. If you also generate webpage structured data from a packet, the resulting page markup still needs to match the page it describes.

For example, a publisher may designate an AppsFlyer URL as the preferred iOS destination. A user can follow that destination through a plainly labeled app link; the website does not need to print its full campaign query string as marketing copy. The packet makes the destination and its semantics inspectable. The app and link provider handle the downstream experience. See [Using Blue Jetty with AppsFlyer](/developers/integrations/appsflyer).

## Public access does not mean byte-identical responses

Blue Jetty supports JSON and Markdown representations and versioned packet formats. Consumer context can also affect declared handoff or attribution labels, including context derived from a user agent or an explicit consumer parameter. The JSON packet route advertises relevant variation through its `Vary` header.

These documented variations are different from selectively adding persuasive product claims for crawlers. When checking parity, compare the same format, version and consumer context. Check that substantive app claims, authorization scope and eligibility rules remain consistent, and that any routing differences follow the documented publisher configuration. A consumer label is not proof that a request came from a particular AI provider or that an installation was attributed.

## What llms.txt does and does not establish

Google's current AI optimization guidance says that special AI files, including llms.txt, are not needed for Google Search and do not improve its visibility or rankings. It also says publishers may maintain those files for other services that use them. That supports a distinction between a machine-oriented resource and a Google ranking mechanism; it does not establish that Google consumes Blue Jetty packets. [Google's AI optimization guide](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide).

Blue Jetty uses public discovery references to help compatible clients locate app context. Whether a client retrieves or uses that context is its own decision. Keep the ordinary website useful and crawlable alongside the packet.

## Review an implementation

Start with read-only inspection of the website, CDN rules and packet. Explain any proposed changes and obtain the publisher's approval before editing or publishing. Before activation, show the publisher the exact public content and destinations and confirm accuracy, rights and acceptable disclosure. The [first-app workflow](/developers/onboard-your-first-app.md) contains the complete approval process.

1. Open the packet in an ordinary browser without a privileged session. Confirm the published resource is readable.
2. Compare browser and crawler requests using the same format, version and consumer context. Investigate substantive differences; do not equate an expected timestamp or routing-label difference with hidden claims.
3. Check that website references point to the intended app and that the CDN does not inject bot-only product text.
4. Inspect any Schema.org markup against the content of its own HTML page.
5. Review app claims, offers, expiry, eligibility and destinations with the authorized publisher. Keep credentials, personal data and proprietary information outside the public packet.
6. Confirm that authorization and source observations are scoped separately from the publisher's claims. Use the [maintenance workflow](/developers/maintenance) when information changes.

The practical standard is an openly inspectable app resource with accurate claims and explicit handoff semantics. It should help a client understand the app and offer a useful next step to the user who selected it.

Sources checked September 11, 2026. Google controls its own search policies; review the linked primary documentation when changing an implementation.