Your HTML Aside Tags Are Invisible to AI Models

👁 113 reads

The conclusion of my article sat in an elegant box built with an aside tag. When I asked a language model about the thesis of that text, I got an answer composed of middle paragraphs - as if the box didn’t exist. I ran the page through a content extraction library and saw why: aside was removed before analysis, along with nav and footer.

Why This Happens: The Pipeline Reads Clean Text, Not Your Page

Language models don’t get your HTML. Between your page and the model sits a content extraction layer whose job is to throw out menus, footers, banners, and sidebars while keeping the article. This layer works on rules about document structure, not on the meaning of content.

The rule is brutally simple: aside semantically means “related content, but not main content.” Since the HTML spec author defined it that way and you used that tag, the library takes it as a declaration of intent. It cuts and moves on. It doesn’t check whether what’s inside is an ad or the most important paragraph in your entire text.

This is a trap for people who do things properly. You learn semantic HTML as best practice, and aside looks like the obvious choice for a frame, callout box, or “good to know” box. In the context of AI optimization, the same decision works exactly opposite to your intention.

What Exactly Disappears

I tested three types of blocks that most often sat in frames in my texts. The result was the same every time - and every time the fix was swapping one tag.

Notice the second row. A comparison table is usually the most information-dense fragment of an article - exactly the kind of material models eagerly cite because it has clear structure and concrete values. If your template wraps tables in aside to display them next to text, you’re throwing the best part of your text in the trash.

The third row is less painful content-wise, but worth noting. A call-to-action in aside disappears, so the model describing your material has no idea what you’re proposing the reader do. This is my opinion, but I think it’s one reason why AI responses about products often skip the specific offer and stay at the level of generalities.

Why Nav and Footer Are in the Same Bucket

nav and footer disappear along with aside, and here the logic is more understandable - they’re usually menus and contact information. The problem appears when someone uses these tags non-standardly.

I’ve seen footer used as a container for author information and update date. I’ve seen nav used for a table of contents with section descriptions. Both things are valuable for AI visibility: author and date are credibility signals, and a table of contents is a ready-made map of the article. Both get cut along with the main menu.

If you want a table of contents visible to extraction, make it a plain div with a list inside. Navigation through the document works identically because they’re still internal links, and the content stays in the extracted text.

How to Write for AI Without Breaking Accessibility

The first reaction I hear is: but semantic HTML exists so screen readers understand structure. That’s true, and you don’t have to give that up.

The solution is cheap. Use div as a container and describe the role and meaning of the block with visible text inside - a heading that says plainly what the block is. A heading like “The Bottom Line” does more for a language model than any structural tag, because it reaches the extracted text and unambiguously labels the fragment.

My working rule goes like this: I reserve aside for things that really can disappear without loss - related links, newsletter box, banners. Everything I want to see in the model’s response lands in a div. This reverses typical thinking about writing for AI: instead of adding tags, I remove those that signal “this is secondary.”

Most Common Places Where Aside Enters Without Asking

You rarely decide this consciously. The tag comes with the template or component.

• Callout blocks in CMS systems - default markup often relies on aside because that looked “proper” when designing the component.
• Pull quote frames and highlighted quotes - a classic case where aside is textbook correct but practically harmful.
• Summary boxes at the top of articles - the worst possible choice because it’s usually the best-written fragment of the entire text.
• Columns with technical tables displayed next to content on wide screens.

Checking takes a minute per template and works once for all future texts. Worth doing before the next round of writing, not after.

How to Check This on Your Site

1. Choose one of your articles that has a conclusion frame, callout box, or table in a side column.
2. Open the page source and search for aside. Note how many blocks and what content sits in this tag. While you’re at it, look for nav and footer used for something other than menus and footers.
3. Run the URL through a content extraction library like readability - locally or through any clean text article preview.
4. Compare the result with the original. Check whether content from frames is present in the extracted text. If it’s not there either in whole or in fragment - you have confirmation.
5. Change the container from aside to div, keeping the same CSS classes. The appearance won’t change because class-based styling works identically.
6. Add a heading inside the block that names its function, so the model gets a clear content label.
7. Repeat extraction and check whether the block is now in the result.
8. Ask a language model about the thesis or data from the table in this article and compare the answer with what you got before the change.

// read moreSEO Audit with AI: A Step-by-Step GuideGuidesWill AI Replace SEO? The Real Future of Search and ContentState of AIAnthropic’s Invisible Watermarks on Claude Outputs Spark User BacklashNews

Kinetyra