Code + Page Copy Experiment

Technical SEO in the era of AEO is less about "ranking blue links" and more about proving that your content is renderable, extractable, and trustworthy when an answer engine is deciding what to cite. This test page exists to isolate one variable: the difference between content that is present in the raw HTML (and therefore directly parsable) versus content that is present only as application state in a hydration payload. In our earlier setup, we embedded a large JSON "state blob" with rich fields (titles, timestamps, IDs, full descriptions) and rendered only a short excerpt into visible HTML. That pattern mirrors how many JS-heavy UIs behave: the app ships a dataset, then selectively paints small pieces of it into the DOM for performance and UX. Here we're running the opposite experiment. The full narrative is shipped as plain HTML text inside the DOM, but CSS line-clamp restricts what a user can see without expanding the component. Visually, this behaves like a preview card. Technically, the page source contains the entire copy, which means bots that parse HTML (including many SEO crawlers and some AI systems) can access it without executing JavaScript. If an AI bot can summarize the hidden portion accurately, that suggests it is reading beyond what's visible, either by parsing the full DOM or by extracting raw HTML rather than "what's painted" in the viewport. Why does this matter for Answer Engine Optimization? Because AEO often rewards content that is easy to extract into concise, reliable answers. If your content is only available after client-side rendering, some bots may miss it, misquote it, or rely on secondary sources. Conversely, if you include everything in HTML but hide most of it behind UI constraints, you may gain crawlability—yet you also risk creating content that looks thin to humans while being dense to machines. That's exactly the tradeoff we want to measure. We're also tying this to compare rendering and hydration approaches. In SSR + hydration, the server emits full HTML, and the client "hydrates" it by attaching event handlers and reactivity. In payload-first approaches, the server emits state (JSON or JS) and the client builds the DOM from that state. Both can produce identical user experiences, but they behave differently for crawlers, performance budgets, and debugging. Expected outcome: humans see only a teaser; machines that read raw HTML should be able to access the full text. If a bot only reports the visible snippet, it's likely using rendered viewport extraction. If it reports the full argument (including the SSR/hydration discussion), it's likely parsing the DOM source. Either way, we'll learn how different "answer engines" treat content that is in the HTML but not visible.