Written by Ramón Saquete
Table of contents
Before we get down to business, let’s remember what web components are: they encompass various technologies, among which is also shadow DOM.
Shadow DOM is one of the technologies we talked about some years ago, which is used by web components. Since then, they have evolved from web components v0 (which were only compatible with Chrome and required polyfills or frameworks for other Internet browsers) to web components v1, which are compatible with all browsers.
We must not confuse this type of components with the components of a framework like Vue, Angular JS or React, because these directly replace the component by HTML code in light DOM, and they can do it server-side using the universal version, which is why they don’t pose as many indexability issues as real web components do.
Difference between light DOM, shadow DOM and composed DOM
Composed DOM is a combination of the two, because inside the shadow DOM we can define slots, to which we can assign chunks of the light DOM.
<my-component> <span slot="title">Title inside the light DOM but with the H3 inside the shadow DOM</span> <p>Text inside the light DOM</p> </my-component>
Moreover, we assume that the component has a template declared in the following way, where there is a slot with the name “title”, and another one, initially without a name, which will take the content of the component that doesn’t have any slot name assigned:
<slot></slot> <h3><slot name="title"></slot></h3> <p>Text inside the shadow DOM</p>
<p>Text inside the light DOM</p> <h3>Title inside the light DOM but with the H3 inside the shadow DOM</h3> <p>Text inside the shadow DOM</p>
How can we know which part of a web component is inside the shadow DOM?
In this Google Chrome screenshot, where we can see the component of the previous example with the “Inspect element” tool, we can see that the shadow DOM appears inside the #shadow-root tag, indicating that it’s the shadow DOM’s root. Moreover, if we click inside a slot, it will highlight the HTML linked to it in the light DOM.
How can we make shadow DOM indexable?
Another option is, as Google suggests, to move all the content susceptible of affecting rankings to the light DOM. But this can only be done in specific cases. For example: if the component is a button carrying out an action, such as sharing a page on a social media platform, you don’t even need it to have light DOM. If, on the other hand, it’s a component providing format to a Q&A block, then it can be more problematic, especially if we want to keep inside the light DOM the semantic tagging of the headers and other semantic tags of the HTML, and to prevent the page styles from affecting these tags.
Web components are very useful for custom development, and if their use extends to CMS, we can better isolate the code of the various plug-ins to prevent incompatibilities. However, to ensure the indexability of these pages, we should either not use web components, or keep all the important code inside the light DOM of the component, or force developers to use the complex solution of rehydrating DOM.
None of these approaches is good, because we lose our ability to encapsulate code, which is the primary reason for the use of web components. We expect this specification to evolve in the future, and allow us to declare shadow DOM inside the HTML in an explicit and indexable way.