The Anti-Patterns: 7 Content Shapes AI Overviews Refuse to Cite

There is a category of AEO failure that has nothing to do with content quality. The information is correct, the page is crawlable, the schema is valid, and the page still never appears in an AI Overview. The cause is the shape of the content. AI Overviews need to lift a clean, self-contained passage and attribute it. When the content's structure prevents clean extraction, the engine moves on to a competitor whose information is worse but whose shape is better. Watching enough of these in retrieval forensics, the same seven shapes come up again and again.

None of these are exotic. They are common, popular design patterns that look fine to a human and are invisible or unusable to an extraction layer. Here they are, in roughly the order I see them cause damage.

1. Testimonial walls

A page that is mostly customer quotes has almost nothing an AI Overview can use. Testimonials are subjective, unattributable to a factual claim, and structurally repetitive. The engine reads a wall of "this product changed my life" and finds no extractable fact to anchor a citation. The deeper issue is that an AI Overview needs to make a verifiable statement and point to a source for it. A testimonial supports a feeling, not a fact, so even when the engine retrieves the page it has nothing it can responsibly quote in an answer. The fix is not to remove testimonials but to lead with a factual claim the testimonials support: a concrete outcome, a number, a specific capability, stated in plain text before the social proof. Give the engine the fact, then let the testimonials corroborate it. A line like "teams cut onboarding time by roughly half" is quotable; "our customers love us" is not.

2. Comparison sliders and interactive tables

Comparison data locked behind a slider, toggle, or JavaScript-driven table is data the extraction layer often cannot reach. The information that would make a perfect AI Overview answer, the side-by-side comparison, is exactly the information hidden behind interaction. The fix is to render the comparison as a plain HTML table in the initial response, then layer the interactive version on top for humans. How you structure the underlying HTML of a table determines whether it survives retrieval chunking, so the markup matters as much as the visibility.

3. Accordion-only content

Content that exists only inside collapsed accordions is technically in the HTML but carries reduced retrieval weight, because the engine treats hidden-by-default content as lower priority than visible content. If your entire FAQ or your key explanation only exists inside collapsed sections, you are signaling to the engine that this content is secondary. The fix is the semantic approach: use the proper disclosure element so the content is in the DOM at full weight, and consider exposing the most important answer outside the accordion entirely. The details and summary pattern handles this correctly for Q&A content, keeping the collapse behavior without burying the answer.

4. Image-encoded text

Text baked into an image, an infographic, a screenshot of a pricing table, a quote rendered as a graphic, is invisible to text extraction. The engine sees an image with alt text at best, and alt text is rarely the full content. This is one of the most common own-goals: a beautifully designed infographic containing your best facts, none of which the engine can read. The fix is to mirror every fact from the image in adjacent plain text. The image stays for humans; the text feeds the engine.

5. Infinite-scroll and lazy-loaded feeds

If your content loads as the user scrolls, it is not in the initial HTML response, which means a non-rendering crawler never sees it. This is the empty-shell problem applied to feeds: the first response is a near-empty container, and the content arrives only through scroll-triggered JavaScript the crawler does not execute. The fix is to ensure the substantive content exists in the first server response, with lazy-loading reserved for genuinely secondary material like images far down the page.

6. Interstitial-gated content

Newsletter walls, cookie interstitials that block content, age gates, and "continue reading" overlays often serve the gate to the crawler instead of the content behind it. The engine fetches the page, hits the interstitial, and indexes the gate. Whatever brilliant answer sits behind it never enters the candidate pool. The fix is to serve the actual content in the initial HTML and apply the gate as a presentation-layer overlay that does not replace the underlying content in the response.

7. The answer buried at the bottom

This is the most fixable and the most common. The page opens with three paragraphs of context, history, and preamble, and the actual answer appears in paragraph eight. AI Overviews strongly favor content that answers the question early, because the first extractable passage that cleanly answers the query is the one most likely to get lifted. If your answer is buried under a runway of setup, a competitor who leads with the answer wins the citation. This pattern is endemic to long-form SEO writing, where the old playbook rewarded word count and slow build-up to keep readers on the page. That playbook actively hurts you in AI Overviews, because the engine is not reading to the end. It scans the opening for a clean answer and, finding preamble instead, looks elsewhere. The fix is the inverse pyramid: put the answer in the first 100 tokens, then expand with the context, history, and nuance below it. The DIRECT ANSWER block at the top of this article is that principle in practice: the complete answer is stated before any of the supporting explanation.

The common thread, and why it matters

Every one of these fails for the same root reason: there is no clean, standalone passage the engine can lift and attribute. This connects directly to the attribution layer of how an LLM picks sources, where the engine has to select a quotable passage from the ranked candidates. A page can win retrieval and scoring, then lose at attribution purely because its shape offers nothing quotable.

The fix is always the same move, which is why this is worth internalizing as one principle rather than seven rules: expose a plain-text, self-contained answer in the initial HTML, alongside the interactive or designed presentation, never instead of it. You keep the slider, the accordion, the infographic, the testimonial wall. You add an extractable layer underneath. The contrarian takeaway is that the prettiest pages are often the worst-performing in AI Overviews, not despite their design but because of it, since rich interactive design tends to encode content in exactly the ways extraction cannot reach. If your site is showing the broader signs of AI invisibility, run your top pages against these seven shapes first, because content-shape failures are faster to fix than most people expect and they are usually the difference between a page that ranks and a page that gets cited. Your overall AI readiness score moves fast when you fix shape, because you are not creating new content, you are unlocking content you already have.

Sources

• Google, AI Overviews and how content is selected: guidance on what surfaces in AI Overviews. developers.google.com
• W3C, HTML disclosure and semantic structure: the standards behind details/summary and accessible content exposure. html.spec.whatwg.org
• Website AI Score, the Citation Stack: why shape failures hit the attribution layer specifically. View article
• Website AI Score, the 100-Token Rule: leading with the answer for maximum retrieval. View article
• Website AI Score, signs of AI invisibility: the broader symptom set that shape failures contribute to. View article