If your content only becomes visible after somebody scrolls, then the fastest growing category of reader on the web sees an empty page. Not a degraded page. An empty one.
We found this on a client site during a rebuild. The page looked excellent in a browser. Sections eased into view as you moved down it, the way most well made marketing sites have behaved for a decade. Then we fetched the same page the way a retrieval pipeline does, with no viewport and no scrolling, and got a navigation bar, a footer, and almost none of the argument in between.
Why the pattern breaks
The mechanism is ordinary. A scroll reveal sets an element to invisible by default, watches it with an IntersectionObserver, and adds a class when it enters the viewport. It is a good effect. It is also a conditional, and the condition is a human being with a window, moving a mouse.
It is worth being precise about who breaks, because the reader most people worry about is not the one at risk. A modern search crawler does execute JavaScript, and it renders with a viewport tall enough that observer based reveals usually fire. Search is largely fine. The systems that fail are the ones that never execute anything: a retrieval pipeline taking the raw HTML, an ingestion job behind a knowledge base, an agent doing a plain HTTP GET and reading what comes back. They arrive, take what the document gives them, and leave.
So this is not really a search problem. It is a retrieval problem, and it arrived recently enough that most sites were designed before it existed.
Two failure modes hide under the same visual symptom, and they are worth separating, because one is survivable and one is not.
The first is content that exists in the HTML but is styled invisible. Most text extractors still read it, because they parse the document rather than render it. Anything that judges visibility, and a growing number of tools do, will drop it. That is a coin flip decided by a consumer you do not control.
The second is content injected by JavaScript once the observer fires. That text is genuinely absent from the fetched document. There is nothing to extract, no heuristic that recovers it, and no amount of semantic markup that helps. It is not indexed because it was never there.
The test takes thirty seconds
Fetch your own page with curl and read what comes back. Not the status code, the body. If your central argument is not in that text, it is not there for any reader that does not execute your JavaScript.
One caveat, so the test is not trusted further than it deserves. Some stacks vary their response by user agent, so a default request can be served something different from what a named crawler or agent receives. If your site does that, run the test with the user agent strings that matter to you as well. An acknowledged limit is worth more than a clean result you cannot rely on.
Most teams have never done this. The site is checked in browsers, across breakpoints, sometimes with a screen reader. The rendering path that now handles a large share of first contact is the one nobody opens.
The fix is a default, not a feature
Content is visible in the raw HTML. Motion enhances a baseline that is already readable. The animation improves the experience of a reader who has a viewport, and its absence costs a reader who does not exactly nothing.
Concretely, that means three things. Never let the observer be the thing that makes text exist. Never let the default state of a content element be hidden. And add a timer that reveals everything anyway if the observer has not fired, because headless browsers, background tabs and reduced motion settings all produce a session where it never does.
The site you are reading is built that way, and the rule is written into the source as a comment so it survives the next person to touch the file. Content is visible by default and the observer only enhances. If it never fires, a fallback reveals the lot after two and a half seconds. Reduced motion skips the whole mechanism and shows everything immediately.
Why this is about more than one animation
A great many organisations are now deploying agents and retrieval systems over web content, their own included. Those systems are bounded by what the fetcher can actually see. An organisation can buy the best retrieval stack available and still get thin, confident, wrong answers, because the source it was pointed at returns a shell.
This is the same shape as most governance failures we are called into. The system reports success. The page returns HTTP 200. The pipeline ingests without error. Every indicator is green and the substance is missing, because nothing in the chain was ever asked to check for substance rather than for absence of failure.
Presentation decisions are now data decisions. A design choice made in 2019 for how a page should feel is, in 2026, deciding whether your organisation is legible to the machines your customers use to find you.
How we help
We audit what your content actually looks like to a non human reader, and we fix the defaults that make it disappear. That work usually arrives inside a wider question, which is whether the knowledge your organisation depends on is retrievable, attributable and provable. The website is where the problem is easiest to see. It is rarely where it stops.