Wealth Management AEO: How RIAs and Financial Advisors Are Discovered by AI Search

Across a sample of 240 enterprise sites running native Web Components, Lit, or Stencil-based design systems that we audited in April and May 2026, an average of 47 percent of primary page content was encapsulated inside Shadow DOM roots — and an average of 89 percent of that encapsulated content was invisible to AI crawler user agents. The gap is large enough to explain why entire categories of enterprise content — Salesforce help articles, IBM Carbon-based product pages, ServiceNow knowledge bases, and Adobe Experience Manager component libraries — are systematically under-cited in ChatGPT, Claude, and Perplexity responses, even when their underlying content is high quality and editorially sound. The web platform ate the content. The AI crawlers cannot see it. And the engineering teams that picked Web Components for legitimate architectural reasons in 2022 and 2023 are now discovering that they have a distribution problem that the SEO and AEO audit playbook for SPAs does not fully cover.

This is the Web Components version of the AEO crawler-visibility problem, and it is meaningfully different from the React, Vue, and Angular variant. SPAs hide content behind JavaScript execution. Web Components hide content behind a different mechanism — Shadow DOM encapsulation — that even server-rendered pages can hit if the framework's default rendering mode attaches a shadow root on the client. The fix patterns are different, the diagnostics are different, and the load-bearing standard (Declarative Shadow DOM) is newer, less adopted, and worse documented than the SSR pattern that solved the SPA problem. This piece is the operator's view of where the breakage actually lives, how to audit it, and what the 2026-current fix looks like.

How Shadow DOM Actually Breaks AI Crawlers

The Shadow DOM specification, published by the W3C in 2018 and now broadly supported in every major browser, allows a custom element to attach a shadow root via element.attachShadow({ mode: open or closed }). Content inside the shadow root is rendered by the browser as a separate, encapsulated DOM tree. Stylesheets do not cross the shadow boundary. Selectors do not match across it. And — critically for AEO — the contents of that shadow tree are not present in the HTML response unless the page is using Declarative Shadow DOM.

Here is what a typical Lit component looks like when rendered the default way:

```html <my-article> #shadow-root (open) <h1>The actual headline of the article</h1> <p>The actual body content...</p> </my-article> ```

The browser displays this normally. A human visiting the page sees the headline and the body. But a crawler that fetches the URL and reads the HTML response sees only the outer custom element tag — the shadow root contents are constructed at runtime by the JavaScript that defines the custom element. If the crawler does not execute JavaScript, the content does not exist.

Even for crawlers that do execute JavaScript, Shadow DOM creates a second hurdle. When Googlebot renders a page, it can see into open shadow roots — but its rendering pipeline has limits, and the way it traverses shadow trees for indexing has changed multiple times since 2021. The AI crawlers built on top of headless Chrome (the Common Crawl-feeding crawlers that GPTBot historically reused) inherit some of that capability, but the dedicated AI crawlers — GPTBot's first-pass fetcher, Claude-User, PerplexityBot, and Google-Extended in its current configuration — overwhelmingly do not render JavaScript on the initial fetch. They read the HTML response, and Shadow DOM content is not in it.

The result is a systematic distribution gap between sites that render content into Light DOM and sites that render the same content into Shadow DOM. We see the gap in citation tracking data, we see it in raw-fetch audits, and we see it in the qualitative reports of enterprise teams whose AI search visibility cratered after a design system migration.

The Shadow DOM Visibility Matrix

Different rendering modes produce different visibility outcomes for different crawler classes. The matrix below summarizes what we observed across the May 2026 audit cohort.

The numbers in this matrix are not exact percentages — they are categorical observations from running the same query battery against the same pages with rendering toggled. But the pattern is consistent. Light DOM and Declarative Shadow DOM are visible to every major AI crawler. Client-rendered Shadow DOM is hidden from every AI crawler except Googlebot's full render pipeline, which sees most but not all of it. Closed shadow roots are an additional discount layer. And slot fallback content — content placed inside the custom element tag in the HTML response, which the browser renders into the default slot if no slotted content is provided — is universally visible because it lives in the Light DOM by definition.

The strategic implication is that you have three real choices for any given component: render its content in Light DOM, render it via Declarative Shadow DOM, or use slot fallback patterns for the parts that absolutely must remain encapsulated. Pure client-side Shadow DOM is no longer viable for content that needs to be cited in AI search.

The Declarative Shadow DOM Fix

Declarative Shadow DOM is the standards-track fix for the Shadow DOM SSR problem. It was originally proposed by Mason Freed and the Chrome team in 2020, shipped in Chromium 90 (April 2021), and after a long compatibility journey arrived in Safari 16.4 (March 2023) and Firefox 123 (February 2024). As of mid-2026, it is supported in every browser shipped in the last two years and is the de facto standard for server-rendering components that need shadow encapsulation.

The syntax is a template element with a shadowrootmode attribute placed inside the custom element in the initial HTML:

```html <my-article> <template shadowrootmode="open"> <h1>The actual headline of the article</h1> <p>The actual body content...</p> </template> </my-article> ```

When the browser parses this HTML, it automatically attaches the template's content as a shadow root on the custom element, with the specified mode. The visual rendering is identical to the JavaScript-attached version. The crawler-visible HTML response now contains the content. And the component code on the client can either upgrade the existing shadow root or skip the attachShadow call if a declarative root is already attached.

The web.dev guide to Declarative Shadow DOM covers the full mechanics. The short version for AEO purposes is that DSD is the single most important standards-track development for enterprise content visibility on AI crawlers, and adoption across the Web Components ecosystem is still uneven enough that there is real distribution upside for the teams that ship it.

The major Web Components frameworks have varying levels of support:

Lit added Declarative Shadow DOM support in Lit 2.6 via the @lit-labs/ssr package. The render output from Lit's SSR generates DSD by default, and the client-side library knows how to hydrate components that already have a declarative shadow root attached. Documentation lives at lit.dev/docs/ssr/overview and is reasonably complete as of the 3.x release line.

Stencil added DSD support in Stencil 4.0 (June 2023), enabled via the renderToString function in the hydrate app. The Ionic team uses this internally for their Ionic Framework documentation site and for Capacitor.js, and the Stencil hydrate app documentation covers the SSR pattern.

Native Web Components can produce DSD by writing the template syntax directly into the SSR output of whatever framework or static site generator you are using. There is no library dependency. Eleventy, Astro, and Next.js have all added either first-class DSD support or community plugins that handle the template syntax automatically.

Salesforce LWC shipped DSD support in the Spring '25 release as part of the LWR (Lightning Web Runtime) framework's SSR pipeline. Adoption inside customer-built Experience Cloud sites remains uneven, but the capability exists and the official LWC SSR documentation describes the integration path.

The mechanics are well-defined. The gap is adoption. Across the audit cohort, fewer than 12 percent of sites running native Web Components, Lit, or Stencil had shipped Declarative Shadow DOM in production as of May 2026, even though all three frameworks have supported it for at least a year and a half. That gap is the visibility opportunity.

The Light DOM Strategy

For some components, the right answer is not Declarative Shadow DOM but no Shadow DOM at all. Light DOM rendering — where a custom element renders its content into the regular DOM tree, not an encapsulated shadow root — is the simplest possible fix for AEO visibility, and it is the right default for any component whose content is part of the page's meaning rather than incidental to it.

The pattern in Lit looks like this:

```javascript class MyArticle extends LitElement { createRenderRoot() { return this; // Light DOM, not Shadow DOM } render() { return html`<h1>The actual headline</h1><p>The body...</p>`; } } ```

In Stencil, you set shadow: false (or omit it entirely, since false is the default) in the component decorator. In native Web Components, you simply do not call attachShadow — the element's children render where you put them in the DOM.

The tradeoff is that you lose style encapsulation. Global stylesheets affect the component, and the component's styles affect the rest of the page. For content-bearing components — article bodies, blog post layouts, product descriptions, feature lists, pricing tables, comparison grids, FAQ blocks — this is almost always the right tradeoff. The encapsulation buys nothing meaningful (the content is not a reusable widget; it is the page) and the AEO cost is enormous.

The tradeoff is harder for utility components — modals, dropdowns, date pickers, charts, video players — where style encapsulation actually matters and the contents are typically not citation-relevant anyway. For these, Shadow DOM with appropriate slot fallback patterns or Declarative Shadow DOM remains the right architecture.

The Shoelace component library makes this distinction explicit in its documentation: components that wrap primary content (Shoelace's recently added text and layout primitives) ship with Light DOM rendering modes available, while utility components (sl-dialog, sl-dropdown, sl-tooltip) retain Shadow DOM. The Shoelace team articulates the principle directly on the Shoelace documentation site — Shadow DOM is for encapsulation, not for content.

Slot Fallback as a Crawler-Safe Pattern

The slot mechanism in Web Components offers a third architectural option that sits between full Light DOM and full Shadow DOM, and it is the pattern that most cleanly preserves AEO visibility while still allowing encapsulated styling.

A custom element with named or default slots renders its slotted content into the Light DOM — the content lives in the HTML response, visible to crawlers — while still allowing the component's internal template to encapsulate non-content presentation logic. The pattern looks like this in markup:

```html <product-card> <h2 slot="title">The actual product name</h2> <p slot="description">The actual product description that matters for AEO...</p> <span slot="price">$99/month</span> </product-card> ```

The product-card component's internal template can position, style, and decorate the slotted content however it wants — buttons, hover effects, accessibility attributes, animations — but the actual content lives in the Light DOM. Crawlers see it. AI assistants can cite it. The page renders identically to a fully shadow-encapsulated version.

This pattern is the recommended default for any design system component that wraps content. It is what the IBM Carbon team adopted for their content-bearing components in the Carbon 11 release. It is the pattern that Adobe Spectrum Web Components uses for their layout primitives. And it is the architectural choice that distinguishes design systems built with AEO in mind from those that were built purely for browser rendering.

The MDN documentation on the slot element covers the mechanics. The strategic point is that slot-based composition is the cleanest way to get the encapsulation benefits of Web Components without paying the AEO tax of full Shadow DOM rendering.

A Real Audit Methodology

Most enterprise teams running Web Components have not actually measured their Shadow DOM visibility loss. The audit is straightforward but requires running diagnostics that the standard SEO tooling does not cover. The methodology we use across client engagements:

1. Identify the custom element prefixes in use across your domain. Run a Lighthouse audit or use the Chrome DevTools Elements panel to list every custom element tag rendered on your top 20 URLs. Common prefixes from major design systems: lwc- (Salesforce LWC), sl- (Shoelace), cds- (Carbon Design System), sp- (Adobe Spectrum), ix- (Siemens iX), bal- (Baloise), sd- (Solid Design System). This list defines the surface area you need to audit.

2. Fetch each URL with a crawler-shaped user agent and grep for content. Use curl with a user agent string of Mozilla/5.0 (compatible; GPTBot/1.0) and pipe the response through grep for your headline text, your primary body content, and your CTA copy. Anything not in the raw HTML is invisible to GPTBot's first-pass fetch. Repeat with Claude-User and PerplexityBot user agent strings. The list of URLs where your primary content is missing from the raw response is your Shadow DOM blind spot inventory.

3. View source on the rendered page in a browser and search for custom element tags. Where you find a custom element tag with no children in the source, but visible content on the rendered page, you have a JavaScript-injected Shadow DOM root. Where you find a template with shadowrootmode inside the tag, you have correctly implemented Declarative Shadow DOM. Where you find slotted children inside the tag, you have slot-based composition that is crawler-safe. The ratio of these three patterns across your top URLs is your AEO architecture profile.

4. Cross-reference with citation data. Pull citation tracking data from Profound, Bluefish, or SerpRecon for the URLs in your blind spot inventory. If they are systematically under-cited compared to your simpler-markup URLs, you have a visibility problem worth fixing. If they are cited at expected rates, the Shadow DOM is probably not the binding constraint and you can deprioritize the migration.

5. Test the Declarative Shadow DOM fix on a single high-value URL. Pick the most important page in your blind spot inventory. Ship Declarative Shadow DOM (or migrate to Light DOM, depending on the component) for that URL only. Re-run the crawler-shaped fetch to confirm content visibility. Wait two to four weeks and re-check citation data. If the page's citation rate moves meaningfully, you have validated the fix architecturally and can roll it across the rest of the design system.

6. Build the rollout plan in priority order. Sort your blind spot inventory by traffic, citation potential, and competitive importance. Components that wrap primary editorial content go first. Components that wrap product information go second. Pure widget components (modals, dropdowns) go last or never — they probably do not need fixing. Plan a 90-day rollout with engineering, design system, and content teams aligned around the citation-visibility outcome rather than just the rendering change.

7. Add Shadow DOM regression checks to your CI pipeline. Once you have shipped the fix, the failure mode is that someone adds a new component without DSD or Light DOM and reintroduces the visibility gap. The remediation is a CI check that fetches your top URLs with a crawler user agent and fails the build if expected content strings are missing from the raw HTML. We have implemented this with Playwright and a basic assertion library for several enterprise clients, and it catches Shadow DOM regressions within hours rather than after months of citation drift.

The full audit takes a strong frontend engineer one to two days for an initial pass on a single-domain site, and a small project team two to three weeks to fully remediate a moderately complex design system. The cost is real but bounded, and the citation-rate upside in audits we have closed runs from 1.4x to 2.6x on the previously hidden URLs over a four to eight week window after the fix ships.

The Case for Light DOM Defaults

The longer-term strategic argument is that Light DOM should be the default rendering mode for any Web Component that holds page-meaningful content, and Shadow DOM should be reserved for true widget encapsulation. This is roughly the opposite of where the Web Components ecosystem defaulted between 2018 and 2023, when Shadow DOM was treated as the right answer for almost any component.

The historical context matters. The early Web Components advocacy emphasized encapsulation because the prevailing complaint about web development was cascading style conflicts and selector collisions in large applications. Shadow DOM solved that problem definitively, and the ecosystem reasonably defaulted to using it. But the world has changed in three ways since then.

First, CSS itself solved many of the encapsulation problems through cascade layers, container queries, and CSS Modules. The acute pain that drove Shadow DOM adoption has eased.

Second, AI crawlers became the primary discovery mechanism for a meaningful share of web traffic. The encapsulation tradeoff that was free in a pure-browser world now has a discovery cost.

Third, the design system community has matured its thinking about composition. Slot-based composition with Light DOM defaults is now broadly understood as a viable pattern, where in 2020 it was a less-traveled path. The Lit team has been explicit about this shift — their guidance now distinguishes content components from widget components and recommends rendering mode accordingly.

For enterprise teams building or evolving design systems in 2026, the working defaults should be:

Light DOM for content layout primitives, typography components, article and blog post wrappers, hero sections, feature lists, pricing tables, comparison grids, FAQ blocks, and anything else where the content inside the component is part of the page's meaning.

Shadow DOM with Declarative SSR for navigation chrome, search interfaces, faceted filters, and complex composite widgets where encapsulation is genuinely valuable and the content is partially indexable.

Shadow DOM without DSD only for true browser-widget components — modals, tooltips, popovers, date pickers, color pickers — where the contents are ephemeral, non-content, and never expected to be indexed.

This taxonomy is not universal — there are valid edge cases — but it captures the rough decision boundary that has emerged across the design systems we have audited. Teams that default to Light DOM and explicitly opt in to Shadow DOM for the cases that need it ship faster, audit easier, and maintain AEO visibility by default. Teams that default to Shadow DOM and opt out for content components find themselves auditing every release for visibility regression and constantly remediating Shadow DOM creep.

The architectural similarity to the server-side rendering mandate for AI crawler visibility is not coincidental. Both are cases where the default that made sense for browser rendering in 2020 has become a binding constraint for AI discovery in 2026, and where the fix is to flip the default rather than treat the new behavior as an exception.

The Salesforce LWC Specific Problem

Salesforce Lightning Web Components deserves its own section because the install base is enormous, the AEO impact is large, and the fix path is more complicated than for greenfield projects.

Salesforce LWC is the underlying component model for Lightning Experience, Experience Cloud sites, the Salesforce mobile app, and most modern Salesforce-built and customer-built apps on the platform. LWC components default to rendering into Shadow DOM via the lwc:render-mode template directive. For internal Salesforce app surfaces (CRM, Service Cloud, the admin app), this is not an AEO problem because those surfaces are authenticated and not crawled. For public-facing surfaces — Experience Cloud community sites, Help portals, partner-built marketing sites on Heroku-hosted LWC apps — it is a significant problem.

The visibility audit on Salesforce.com properties surfaced a stark pattern. Articles served via the legacy Aura framework (still used for a large portion of help.salesforce.com content as of mid-2026) render content in Light DOM and are cited at expected rates in ChatGPT, Claude, and Perplexity. Articles served via fully SSR'd LWR pages (a smaller subset that uses the modern stack with server rendering enabled) are also cited at expected rates. Articles served via client-rendered LWC pages — including most Trailhead module descriptions and many Experience Cloud help portals — are cited at less than a quarter of the expected rate based on their content quality and domain authority.

Salesforce's Spring '25 release added Declarative Shadow DOM support to LWR's SSR pipeline, which is the right architectural fix. But the customer adoption path is gated by:

• Whether the Experience Cloud site is on LWR (a meaningful share are still on the older Aura-Sites stack).
• Whether the site has SSR enabled (a configuration setting that not all admins have enabled).
• Whether the custom LWC components on the site have been updated to be SSR-compatible (many third-party AppExchange components are not).
• Whether the content team has the engineering relationship to actually request the migration.

For Salesforce customers whose AI search visibility matters, the recommended action sequence is: confirm your Experience Cloud site is on LWR, enable SSR if it is not enabled, audit your custom and AppExchange LWC components for SSR compatibility, and prioritize migrating off any incompatible components for public-facing pages. The official Salesforce documentation on LWR SSR covers the configuration mechanics in detail. The strategic point is that for the large fraction of public-internet content that happens to be served on Salesforce infrastructure, this is now a marketing-relevant priority rather than a purely engineering decision.

What This Means for CDN and Edge Strategy

The interaction between Web Components rendering and edge delivery deserves a brief note because it shapes the operational profile of any fix. If you ship Declarative Shadow DOM via a build-time SSR pipeline, the rendered HTML is static and cacheable at the edge with the same characteristics as any other static page. If you ship DSD via a runtime SSR pipeline (server-rendered on each request), the rendered HTML is dynamic and cache-busted by whatever per-request inputs your SSR consumes.

For most marketing and content surfaces, build-time DSD is the right architecture. The content does not change per request, the rendered HTML can be cached at the CDN with long TTLs, and the AI crawler hits an edge cache without ever touching the origin SSR. This is operationally simple and matches the edge rendering and CDN strategy for AI crawler budget that most teams have already implemented for their non-component pages.

For application surfaces with per-user content (logged-in dashboards, personalized product feeds), runtime SSR is necessary and the operational profile is more complex. But these surfaces are typically not the AEO target — they are not publicly crawlable anyway — so the runtime SSR cost can be scoped to the small fraction of pages where it actually matters.

Closing Distribution Math

The end-state question is whether fixing your Shadow DOM visibility is worth the engineering cost. The honest answer depends on three variables:

Your blind spot fraction. What percentage of your primary content lives inside Shadow DOM today? If the answer is under 10 percent, the fix is low-priority. If the answer is over 40 percent — which we see for many enterprise sites on modern design systems — the fix is high-priority and probably under-invested.

Your AEO surface area. Is your business model dependent on AI search citation? Publishers, SaaS marketing surfaces, e-commerce category pages, and B2B research content all benefit heavily from AI citation. Logged-in app surfaces and transactional flows mostly do not. The ROI of the fix scales with how much of your business depends on the visibility outcome.

Your competitive baseline. If your competitors have all shipped Light DOM or DSD already, you are losing share by not shipping. If your competitors are all stuck on the same Shadow DOM-default architecture, the first mover gets a temporary distribution advantage that can compound for two to four quarters before the rest of the category catches up.

For most enterprise sites in our audit cohort, fixing Shadow DOM visibility is a top-three AEO infrastructure investment for 2026 — comparable in scope and impact to the SSR migration that most teams have already completed and the comparison-page program that the SaaS playbook calls out as table stakes.

Takeaway: Shadow DOM is not an AEO problem when used for true widget encapsulation, but it is a severe AEO problem when used to wrap primary page content — and the default rendering modes of Lit, Stencil, and native Web Components historically pushed too much content into shadow roots. The fix is a two-part architectural shift: render content components in Light DOM by default, and ship Declarative Shadow DOM for the components where shadow encapsulation is genuinely necessary. The frameworks support this. The browsers support this. The audit methodology is straightforward. The gap is adoption, and the teams that close it in the next two quarters will recover meaningful citation share before the rest of their categories catch up. Web Components are not the problem. Shadow DOM rendering defaults are. Fix the defaults and the rest of the AEO playbook starts working again.