What Google's spam policies actually prohibit
Google's spam policies for Google Search name cloaking and keyword stuffing as two separate, specific violations. Cloaking is presenting different content to search engines than to human visitors — Google's own examples include redirecting crawlers to one page while sending visitors somewhere else entirely, or serving extra text only when the request looks like it came from a crawler, not a browser. Keyword stuffing is filling a page with keywords or numbers to manipulate rankings, whether that text is fully visible or hidden from the reader.
The two often show up together: a block of repeated keywords is stuffed onto the page, then hidden so it does not look spammy to a visitor while still (in theory) reaching the search engine's index. That combination — hidden keyword stuffing — is common enough that it is a named manual action inside Google Search Console, separate from ordinary visible keyword stuffing.
How pages hide text: CSS tricks and invisible Unicode
Every hiding technique Google's guidance and Search Console help describe comes down to making text present in the page's markup but absent from what a sighted visitor sees:
Color-on-color text
White text on a white background, or any text colored to match its container — invisible to the eye, present in the DOM. Google's own manual-action guidance suggests selecting all page text (Ctrl/Cmd+A) as the fastest way to reveal it.
Zero-size or off-screen text
font-size: 0, display: none, visibility: hidden, or a large negative text-indent that pushes text off the visible canvas while leaving it in the rendered page.
Behind an image or element
Text positioned underneath an image or another element via CSS layering, so it renders but is never seen unless the covering element is removed.
Invisible Unicode inside keywords
A zero-width space (U+200B) or word joiner (U+2060) inserted inside a repeated keyword or between duplicate phrases, aiming to defeat an exact-text spam filter while the phrase still looks normal to a reader.
The last row is where this distinguishes itself from ordinary CSS cloaking: it depends on the same invisible-character family this site normally helps people remove by accident — see the full list of invisible Unicode characters this tool detects. Splitting a keyword with a zero-width character does not, in practice, hide it from Google — modern crawling and spam systems process rendered, reader-facing text, not raw markup a naive filter would exact-match against — but it reliably breaks the page for actual visitors: copy-search, screen readers, and browser find-in-page all stumble on the same characters.
The 2006 BMW.de cloaking case
The best-documented real-world cloaking penalty involves a household name. In February 2006, Google removed bmw.de, BMW's German site, from its index. Several pages used doorway pages — text-heavy pages built purely to rank for search terms — that immediately redirected any human visitor to BMW's ordinary, polished marketing site, showing Googlebot one page and every real visitor another. Google's Matt Cutts announced the removal on his blog, pointing to the guideline that a site must not show search engines and users different content (reported at the time by Search Engine Journal). BMW removed the doorway pages, and Google restored the site to its index within about a week.
The case is still cited two decades later for a reason: it shows that cloaking enforcement applies regardless of a site's size or reputation, and that the fix Google wants is simple — stop showing two versions of the page — not a more sophisticated way to hide the discrepancy.
How Google detects hidden text today
Modern detection starts with rendering, not raw HTML parsing. Google's crawler executes CSS and JavaScript and builds a rendered version of the page much like a browser would, which is why content hidden purely through display tricks is visible to Google's systems in the first place — hiding text no longer means hiding it from the crawler, only from the reader. Site owners can see exactly what Google rendered for a given URL through Search Console's URL Inspection tool.
On top of rendering, Google runs algorithmic spam-detection systems — publicly named SpamBrain since 2021 — alongside manual review. When a human reviewer confirms a violation, Search Console records a named manual action, "Hidden text and keyword stuffing," which can suppress rankings for the affected pages or the whole site until the issue is fixed and a reconsideration request is filed.
When hidden text is legitimate
Not every element that is invisible by default is a violation. Google's spam policies explicitly carve out ordinary interface patterns: text inside a closed accordion or tab a visitor can expand, tooltip content, and text that exists specifically to serve screen-reader users are all standard, allowed uses of "hidden until interacted with" content. The distinguishing question Google's guidance asks is intent — was the text hidden to improve the experience for some users (or all users, before they interact), or hidden specifically to show search engines something sighted visitors never see?
That second category — text meant only for assistive technology — deserves its own care, since a careless implementation can make a page confusing for screen-reader users even with good intentions. That overlap between accessibility markup and "hidden" content is covered in detail on how hidden characters affect screen-reader accessibility.
How to check your own pages
- Select all visible text on the rendered page (Ctrl/Cmd+A) — color-matched or zero-size text usually appears as an unexpected highlighted block.
- Check the rendered HTML for the URL in Search Console's URL Inspection tool to see the page the way Google's crawler processed it, including anything CSS is hiding from a visitor.
- Scan pasted or CMS-imported copy for invisible Unicode. Neither check above catches a zero-width space or word joiner sitting quietly inside body text copied from Word, Google Docs, or a chatbot. Paste the text into the cleaner on this page — it names every hidden character it finds, by code point, without changing a visible word — or read the dedicated guide to removing zero-width spaces specifically.
This tool only removes characters with no visible glyph — it does not detect CSS-based hiding (color-matching, display: none, off-screen positioning), which needs the rendered-HTML check above, not a text cleaner.