Google Says Text Added With CSS Content May Not Be Indexed.

Google says text inserted with the CSS content property is outside the DOM and may not be indexed. Important copy should live in semantic HTML, even when generated CSS text is visible to a person in the browser.

Correction, September 24, 2026: An earlier version described this as a newly logged clarification. Google’s documentation changelog dates the CSS content entry to September 22, 2023, not September 2026. We are revisiting established guidance, not reporting a new Search change.

The current developer guide still says generated CSS text is outside the DOM and may not be indexed. This is not a ranking-system announcement or proof that every generated string disappears. The practical distinction remains: visible rendering and indexable document content are not the same thing.

The failure pattern is easy to ship

A designer places a label, instruction or offer in a pseudo-element because it is convenient:

.price::before {
  content: "Annual price";
}

The browser paints “Annual price,” so visual review passes. But the words were not supplied as a text node in the document. Google’s clarification says that text added this way is outside the DOM and is currently ignored or may not be indexed.

The durable version puts the meaning in HTML and leaves CSS responsible for presentation:

<span class="price-label">Annual price</span>

That also makes the text easier to expose to accessibility APIs, translation systems, copy-and-paste, reader modes and automated testing.

Classify each use before rewriting it

The audit question is not “Do we use ::before?” It is “Would the page lose a fact, condition or instruction if generated content vanished?”

Find generated text in code and rendered pages

Start with source search. Look for content: in first-party stylesheets, component styles and injected theme CSS. Exclude common decorative values such as empty strings, counters and icons, then review every remaining human-readable value.

Next, compare three representations of representative pages:

1. the visible page with normal styles;
2. the DOM text exposed by browser developer tools or a scripted extraction;
3. the page with styles disabled.

If a commercially or editorially important phrase appears only in the first view, it is a migration candidate. Add this check to the rendering stage of the technical SEO pre-publish process rather than waiting for an indexing discrepancy.

Move meaning, keep presentation

Do not duplicate the same visible words in CSS and HTML. That can create double speech in assistive technology and inconsistent updates. Move the authoritative phrase into HTML, then style that element. If the text is only a visual flourish, remove its semantic responsibility and keep the CSS output deliberately decorative.

For component libraries, define a rule the team can test: user-facing facts, instructions, labels that change decisions and status messages must be present in the DOM. Icons and ornaments can remain generated when an accessible name or nearby text already carries the meaning.

What the clarification does not prove

Google did not publish a ranking update, a new penalty or a measurement showing how often CSS-generated text affects search results. The wording describes current processing behavior. It should not be converted into a claim that one pseudo-element causes a traffic loss.

It also does not settle every rendering edge case. Browser rendering, accessibility trees and Google’s indexing systems are related but not identical. Treat the documentation as a reason to remove avoidable ambiguity, not as permission to predict a specific ranking change.

A controlled test would answer the remaining question

A useful experiment would publish three otherwise equivalent pages with unique nonsense phrases:

• one phrase in ordinary HTML;
• one inserted through a CSS pseudo-element;
• one added as a real DOM text node by JavaScript.

Submit all three through the same discovery path, record crawl and index dates, and query the unique phrases on a fixed schedule. Repeat across enough pages to avoid treating one crawl outcome as a rule. Until that test is completed, Google’s documentation is the primary evidence and the test remains a proposed protocol, not a result.

Use a five-minute release check

1. Search changed stylesheets for human-readable content: values.
2. List the pages and components that use each value.
3. Mark whether the words affect a decision, instruction, fact or disclosure.
4. Move meaningful text into semantic HTML and preserve only its styling in CSS.
5. Verify visible text, DOM text, keyboard flow and the no-CSS view before release.

This is a small technical fix with a broader publishing lesson: if words carry meaning, they belong in the document. Visual presence alone is not a reliable indexing or accessibility contract.