# Annotated Page Content: the structured tree Chrome hands Gemini instead of your HTML

> Chrome builds a structured, typed node tree from a page's render tree and hands that to Gemini when a tab is shared, per Dejan AI's teardown.

Canonical: https://brandonlazovic.dev/articles/annotated-page-content-gemini/  
Author: Brandon Lazovic  
Published: 2026-07-28

## The short version

- Sharing a browser tab with Gemini sends Chrome's Annotated Page Content (APC): a typed node tree built from the page's render tree, the state after CSS, layout, and JavaScript have executed, according to a teardown published by Dejan AI.
- Dejan's analysis documents 21 typed node categories inside APC, spanning structural elements like headings and tables to interactive containers like dialogs and iframes, each carrying geometry, styling, and interaction state.
- APC's structured-Markdown output tags interactive elements with stable node IDs such as {#14}; that reference is what Dejan's teardown says lets Gemini click buttons, fill forms, and follow links inside a shared tab.
- Privacy filters run during extraction: password values are redacted, cross-origin iframe content becomes origin-only metadata, and paywalled sections are flagged through schema.org detection, per Dejan's analysis.

When a person shares a Chrome tab with Gemini, Chrome builds Annotated Page Content (APC): a structured, machine-readable tree assembled from its internal render tree, the version of the page that reflects what is actually visible after CSS, layout, and JavaScript have run, according to a teardown published by SEO firm Dejan AI. [1] Every visible element, text, links, images, forms, and tables, becomes a typed content node with its own geometry, styling, and interaction data. Raw HTML never enters that pipeline: what reaches Gemini is whatever the render tree already resolved. For a page to reach Gemini through a shared tab, it first has to survive that extraction, and that changes what markup decisions are for.

> Dejan's teardown documents 21 typed node categories inside Annotated Page Content, Chrome's render-tree export to Gemini for every shared tab. [1]

## What is Annotated Page Content (APC)?

Annotated Page Content, or APC, is the structured, machine-readable tree Chrome builds from a page's render tree the moment a user shares a browser tab with Gemini, according to a teardown published by SEO firm Dejan AI. [1] Instead of forwarding raw HTML, Chrome walks the render tree, the internal representation of what is actually visible after CSS, layout, and JavaScript have executed, and outputs a tree of typed content nodes.

Dejan's teardown describes the tree capturing every visible element, meaning text, links, images, forms, and tables, as individual nodes. [1] That is a meaningfully different object than a text summary or a stripped accessibility label set. APC reads more like a typed serialization of the rendered page, annotated with the geometry, styling, and interaction properties an agent needs to reason about layout and action alongside content.

The same Dejan page cross-references a companion analysis describing Chrome's Page Content Agent, framed there as the subsystem supplying Gemini with grounded context for reading and interacting with a page. [1] I did not independently fetch that companion piece; the framing above comes from its teaser text on the APC concept page itself, so I am citing it at that remove rather than as a directly reviewed source.

This description comes from a third-party teardown of Chrome-internal behavior. I have not found a Google-published technical specification that names or documents Annotated Page Content directly, so the mechanism should be read as one analyst's detailed analysis of observed behavior, not confirmed first-party engineering documentation.

Practitioners who already reason about what Googlebot sees now have a second, structurally distinct question to answer: what a shared tab exposes to Gemini. Search indexing and APC extraction are separate pipelines built for separate products, and how a page indexes says nothing about how it renders into APC.

## How is APC different from the HTML a crawler downloads?

APC and the HTML a crawler downloads come from different pipelines entirely. A crawler like Googlebot downloads the HTML document a server returns, plus whatever a rendering queue later executes, and treats content as characters, tags, and attributes. Dejan's analysis describes APC skipping that document model altogether: Chrome exports the render tree, the post-layout, post-JavaScript state of the page, as typed nodes carrying geometry, styling, and interaction data rather than markup. [1]

The practical difference shows up in three places. First, APC is generated inside the browser session a user is already looking at, not fetched independently the way a crawler requests a URL. Second, every node in the tree carries a bounding box in viewport coordinates, so APC records where an element sits on screen and how large it renders, a property raw HTML does not encode at all. [1] Third, APC nodes carry interaction metadata, meaning whether an element is clickable, focusable, or disabled, and Dejan's analysis notes the tree records why an element is disabled, beyond simply flagging that it is. [1]

Dejan's concept page names 21 distinct node types, covering structural elements such as Heading, Paragraph, and Anchor, form elements such as Form and FormControl, tabular elements such as Table and TableCell, and interactive containers such as DialogModal and Iframe. [1] An HTML parser sees a generic container element regardless of what it holds. APC's type system assigns a table, a dialog, and a form control their own distinct categories before any further processing happens, a richer starting point than tag-name parsing alone.

## How does APC let Gemini act on a page, not just read it?

Gemini reads a page through APC's structured Markdown output, where every interactive element carries a stable node ID formatted like {#14}, and Dejan's teardown states that this ID reference is what lets the model click buttons, fill form fields, and follow links, going beyond summarizing visible text. [1] The interaction metadata on each node, specifically whether it is clickable, focusable, or disabled and why, is what makes that possible.

APC exports in more than one format. Dejan's analysis lists five: JSON, plain text, cleaned HTML, passage-sized chunks sized for an LLM's context window, and the structured Markdown carrying node-ID tags. [1] The first four are read-only representations, useful for summarization or question answering. The node-ID Markdown format is the one that turns APC from a reading surface into an acting surface, because a node ID is an address Gemini can reference in a later action, the same way a developer references a DOM element by selector.

The chunked, passage-sized output matters beyond convenience. Dejan's site frames the broader mechanism as supplying Gemini with grounded context, meaning the model's answers about a page are meant to trace back to specific passages instead of a general sense of the page. [1] A page whose content survives extraction as clean, well-bounded passages, complete paragraphs under real headings, is more likely to produce a grounded answer that cites it correctly.

My read: this is the detail that separates APC from earlier read-the-page-for-the-model approaches built on plain text extraction. A summarizer only needs content. An agent that clicks and fills forms needs a stable reference to act against, and the sequential node ID is that reference. Whether Gemini's action success rate holds up on cluttered or dynamically-renumbered pages is a separate, open question that Dejan's concept page does not address, and I have not tested it myself.

## What does APC do with passwords, paywalls, and cross-origin frames?

APC applies three documented privacy filters before the node tree reaches the model. Dejan's analysis reports that password field values are redacted, cross-origin iframe content is replaced with origin-only metadata, and paywalled sections are flagged through schema.org markup detection. [1] Each filter runs during extraction, as part of building the tree, not as a separate pass afterward.

The cross-origin handling is worth sitting with. An iframe from a different origin, an embedded payment widget, a third-party comment system, a syndicated ad unit, does not get its content pulled into the tree under Dejan's description. APC substitutes origin-only metadata, presumably domain and frame purpose, for the frame's actual rendered content. For a page that leans on cross-origin iframes for core functionality, such as embedded checkout or a reviews widget, that content may be structurally invisible to whatever Gemini receives from a shared tab, regardless of how well the iframe itself is built.

The paywall handling depends on schema.org markup detection specifically, so the signal is structural, a recognized schema.org paywall pattern in the markup, rather than visual, such as a paywall overlay a human would notice on screen. [1] A page relying on a purely visual or script-triggered paywall, without a corresponding schema.org signal, has no confirmed guarantee from this material that APC treats that content the same way. I am flagging this gap rather than resolving it: Dejan's page states the detection method but does not enumerate which schema.org properties trigger it.

## What does APC change about how you should structure a page?

APC sets a concrete bar for markup decisions: whatever survives Chrome's render-tree-to-APC extraction is the only version of a page Gemini can act on through a shared tab. Call that surviving set the render-tree contract, meaning server-rendered visible content, semantically typed elements, accessible interaction states, and schema.org signals reach the model; everything else does not. [1]

The render-tree contract has three practical terms, each traceable to a mechanic documented above. Content injected only after user interaction, content that never enters the render tree Chrome walks, cannot appear in APC no matter how visible it eventually becomes to a human. Elements built from generic containers instead of the typed categories APC recognizes, for instance a styled `<div>` standing in for a `<table>` element, lose the semantic type that would let Gemini reason about them as tabular data. Cross-origin embeds and non-schema.org paywalls sit in the blind spots already named above.

In concrete terms, the render-tree contract rewards a short list of choices: serving primary content in the initial server response rather than injecting it after load, using real semantic elements (`<table>`, `<form>`, `<dialog>`) instead of generically styled containers, keeping interactive elements keyboard- and focus-accessible so their state is legible, and maintaining accurate schema.org markup for anything gated behind a paywall. [1]

My read is that this reinforces advice practitioners already have reason to follow: server-render the content that has to be there, use real semantic HTML elements in place of styled generic ones, and keep schema.org markup current. What APC adds is a second, concrete reason those choices matter beyond Search rankings, since they now determine what an AI assistant physically receives the moment a user shares a tab with it.

I have not captured a live APC payload myself: sharing a tab with Gemini and inspecting what comes back. Everything above synthesizes Dejan's published teardown of the mechanism, not a first-hand test of it. That first-hand capture is the natural next check, and it is the one that would confirm or complicate the reading above.

## Sources

1. Dejan AI: Annotated Page Content (APC) concept page — https://dejan.ai/concepts/annotated-page-content-apc/