Question 1

Can AI crawlers like GPTBot and Claude-User see content inside Shadow DOM?

Accepted Answer

Mostly no. As of May 2026, the dominant AI crawlers fetch raw HTML and do not execute JavaScript or attach Shadow DOM trees the way a browser does. GPTBot, Claude-User, PerplexityBot, and Google-Extended all default to a non-rendering fetch on the first pass, which means any content that lives inside a closed or attached Shadow DOM root is invisible to them unless you also serve it as Declarative Shadow DOM in the initial HTML response. Tests across Salesforce LWC sites, Shoelace-based marketing pages, and Lit-powered design system docs show citation rates 60 to 80 percent lower for shadow-encapsulated content than for equivalent Light DOM content on the same domain. The fix is either to render content into the Light DOM via slots, or to ship Declarative Shadow DOM so the encapsulated content is present in the HTML payload the crawler sees on first fetch.

Question 2

What is Declarative Shadow DOM and does it solve the AEO problem?

Accepted Answer

Declarative Shadow DOM (DSD) is a server-rendered template syntax that lets you write Shadow DOM directly in HTML using a template tag with the shadowrootmode attribute. It was shipped in Chrome 90, Safari 16.4, and Firefox 123, and as of 2026 it is the only practical way to get encapsulated component content into the initial HTML response. For AEO purposes, DSD largely solves the discoverability problem: AI crawlers that fetch HTML see the slotted and shadow content in the response, and citation testing across the May 2026 audit cohort shows DSD-rendered components are extracted at roughly the same rate as Light DOM content. It does not solve every problem — closed shadow roots and aria-references that span shadow boundaries still trip up some crawlers — but it is the single highest-leverage fix for any site shipping native Web Components or Lit-based design systems.

Question 3

Does Salesforce Lightning Web Components content show up in ChatGPT and Perplexity?

Accepted Answer

Patchily, and only when the page is server-rendered through LWR or Experience Cloud's SSR path. Standard client-rendered LWC pages — including most Lightning Communities and many Salesforce help portals — render their main content into Shadow DOM via the lwc:render-mode template, and that content is not visible to AI crawlers by default. Citation audits of Salesforce.com help articles, Trailhead modules, and partner-built LWC portals show that articles served via the legacy Aura framework or via fully SSR'd LWR pages get cited in ChatGPT and Perplexity at expected rates, while client-only LWC pages get cited at less than a quarter of the rate for equivalent content. Salesforce shipped Declarative Shadow DOM support in the Spring '25 release, but adoption across customer Experience Cloud sites remains low, and most LWC-based public surfaces are still functionally invisible to AI search.

Question 4

Should I rewrite my Web Components to use Light DOM instead of Shadow DOM?

Accepted Answer

Not wholesale, but yes for any component that holds primary content. Shadow DOM was designed to encapsulate styles and isolate widget internals — chrome, form controls, navigation, modals — where the content inside the component is incidental to the page's meaning. For those uses, Shadow DOM is still correct. But for components that wrap your actual content — article bodies, product descriptions, feature lists, pricing tables, FAQ blocks — pushing content into Shadow DOM hides it from crawlers and search assistants for no real encapsulation benefit. The pattern that works in 2026 is to render content components as Light DOM (Lit's createRenderRoot returning this, Stencil's shadow: false, native customElements with no attachShadow call), and reserve Shadow DOM for widget-style components. If you cannot move to Light DOM, ship Declarative Shadow DOM as a fallback so the content is present in the initial HTML response.

Question 5

How do I audit my site for Web Components content hidden from AI crawlers?

Accepted Answer

Run a four-step audit. First, fetch your key URLs with curl using a user agent string of GPTBot or PerplexityBot and grep the response for your primary content — if your headlines, body text, or product descriptions are not in the raw HTML, they are invisible to AI crawlers. Second, view source on the rendered page in a browser and search for the custom element tag prefixes used by your design system (lwc-, sl-, my-component-) — anywhere those tags appear without inline content or a template with shadowrootmode is a candidate Shadow DOM blind spot. Third, run Google's URL Inspection tool and Bing's URL submission tool on the same pages and compare the rendered HTML to your raw fetch — the gap is a proxy for what AI crawlers cannot see. Fourth, query ChatGPT and Perplexity with citation-shaped queries for the page content and check whether your page is cited or whether competitors with simpler markup take the citation slot.