Two pages about the same thing. The first is a wall of text, 5,000 characters long, with rare paragraphs and no headings. The second is the same 5,000 characters, broken into tables, lists, with clear headings and short paragraphs. The model will quote the second page with 80% probability. The first—with 5% probability. Not because the second page is “better” in meaning. But because the model can extract structured fragments from it for an answer.

In this article—why neural networks “love” tables and lists, “hate” plain text, and how to turn your pages into a convenient source for citation.

How the Model Sees Plain Text

When the model sees a page with plain text—long paragraphs, no headings, rare line breaks—it perceives it as a “mass.” There are no clear boundaries between thoughts. The model doesn’t know where one explanation ends and another begins. As a result, it simply skips the page.

The model has a limited attention budget. It processes only a certain number of semantic units. If the text isn’t broken into these units, the model can’t decide what’s important and what isn’t. It won’t “fish out” useful thoughts from long paragraphs. It’s easier to find another source where thoughts are already packed into a convenient form.

Example. A page about choosing a laptop. Plain text: “When choosing a laptop for programming, it’s important to pay attention to the processor. Intel Core i7 or i9 is best. Also important is RAM—at least 16 GB. If you work with large projects, 32 GB is better. The drive must be SSD, from 512 GB...” And so on for 5,000 characters.

The model can’t extract clear criteria from this text. It sees a stream of thoughts. The alternative is a list: “Key laptop parameters for programming. Processor: Intel Core i7 or i9. RAM: from 16 GB, better 32 GB. Drive: SSD from 512 GB.” The model instantly extracts three criteria and can use them as a ready answer.

The Power of Structured Data: What Tables Give Models

A table is an ideal source for the model. Why? Each row is one semantic block. Each column is one data type. The model can take a separate row as an answer to a specific query. It doesn’t need to analyze the structure—it’s already set.

Tables allow the model to quickly compare objects by multiple parameters. For queries like “what’s the difference,” “what’s better,” “compare”—this is the most convenient format. The model can use the entire table or its individual parts. An important condition—the table must be real, with table tags, not a “table” drawn with spaces.

Example. Comparison of SEO and generative optimization. Text: “SEO is classic promotion aimed at positions in search results. Generative optimization is adjusting content for neural networks so the site is cited in answers. SEO prices usually start from 50,000 rubles, and generative optimization from 30,000...” The model gets confused.

Table: row “Goal”: column “SEO”—“positions in search results,” column “GEO”—“citation in neural network answers.” Row “Price from”: column “SEO”—“50,000 ₽,” column “GEO”—“30,000 ₽.” The model instantly extracts differences and can use any row as a separate answer. Effective geo-optimization of a website often uses tables for comparison.

Why Lists Work, but Enumerations Don’t

Lists come in two types. Numbered lists (1, 2, 3)—for sequential actions, stages, steps. Bulleted lists (circles, dashes)—for criteria, characteristics, reasons. The model recognizes both types but uses them differently. Numbered—for instructions and processes, bulleted—for lists and classifications.

What the model doesn’t like. Pseudo-lists—when an enumeration is formatted in a line with commas, without line breaks. “For choosing a CRM, the business scale, budget, number of employees, integrations, mobile support, interface convenience are important.” The model sees this as one long sentence, not as 6 criteria. Each list item is a separate paragraph or line with a marker.

Too long lists—more than 10 items. The model may perceive them as redundant and shorten them “in its mind” or ignore them. The optimal list length is 3–7 items. If you need more, break them into subgroups with subheadings. Each item should be short—1–2 sentences, without complex constructions. Professional creation of text content should take these rules into account.

What to Do If Coherent Text Is Unavoidable

You can’t turn the entire site into a set of tables and lists. Coherent text is needed for explaining complex concepts, building arguments, telling case studies. But you can make it convenient for the model.

Rule 1. Break into short paragraphs—2–4 sentences, 300–500 characters. One paragraph—one thought. If a thought doesn’t fit into 4 sentences, split it into two paragraphs. The model extracts paragraphs as semantic units. A long paragraph is perceived as a “mass” and may be skipped.

Rule 2. Add interim conclusions after each semantic block. Even in coherent text. “Thus...”, “This means that...”, “Therefore...”. The model can take an interim conclusion as a ready answer, even if it skips the rest of the text. An interim conclusion is a micro-answer inside your explanation.

Rule 3. Highlight key phrases in bold. The model pays attention to highlighted fragments. If a key thought inside a paragraph is highlighted, the model is more likely to notice and use it. But don’t highlight everything—only the main points.

Rule 4. Use subheadings to break coherent text into chapters. A second-level heading “Why This Matters,” a second-level heading “How It Works,” a second-level heading “Practical Example.” The model perceives each section as a separate semantic block. Coherent text without subheadings is read worse.

How to Check If Your Text Is Convenient for the Model

After writing a page, run a quick diagnostic. The more points from the list below you violate, the lower the chances of citation. Professional website audit for search engines will help identify such problems.

Test 1. Average paragraph length. Count the number of sentences in paragraphs. If most paragraphs contain more than 5–6 sentences, the text is overloaded. Break long paragraphs. Ideal length—2–4 sentences.

Test 2. Frequency of subheadings. Count how many characters of text are between subheadings. If more than 800–1000 characters without a subheading, the model may lose structure. Add a subheading or break the section.

Test 3. Presence of tables and lists. See if you can replace part of the enumerations in the text with tables or lists. “For choosing, A, B, C, D are important”—this is a candidate for a list. “Comparison of characteristics X and Y”—a candidate for a table.

Test 4. Presence of interim conclusions. Find phrases “thus,” “this means,” “therefore” at the end of sections. If they’re absent, add them. The model uses them as ready answers.

Test 5. Density of key fragments. Count how many “quotable fragments” (definitions, criteria, steps, conclusions) there are per 1000 characters of text. If fewer than 2–3, the text is inconvenient for the model. Add missing fragments.

Read about new search trends in the article new search trends.

Conclusion

Artificial intelligence doesn’t “love” tables and lists and doesn’t “hate” plain text in an emotional sense. It’s just that tables and lists are ready-made structured fragments that the model can use without refinement. Plain text requires additional effort from the model to extract semantic blocks. The model doesn’t have time for that. It chooses what’s more convenient.

Rules for text that gets cited. Break into short paragraphs (2–4 sentences, 300–500 characters). Add interim conclusions after each semantic block (“thus,” “this means”). Use subheadings for model navigation. Highlight key phrases in bold. Replace enumerations with bulleted lists. Replace comparisons with tables.

Tables and lists aren’t “magic” or a “secret trick.” They’re a way to package information so the model can quickly extract and use it. The less effort the model requires to analyze your page, the higher the chance it will choose your fragments for the user’s answer.

Frequently Asked Questions

Can there be too many tables on one page?
Yes. If a page turns into a set of tables without coherent text, the model may not understand the context. Optimal—one table per page, maximum two, if they’re about different aspects. Before each table, there should be text explaining what’s being compared and why it matters. Without context, a table can be meaningless.

What’s better for the model: a bulleted list or a numbered list?
The choice depends on the content. Numbered—when sequence matters: process stages, instruction steps, chronology. Bulleted—when classification matters: criteria, reasons, characteristics, examples. Don’t use numbering if order doesn’t matter—it misleads the model.

What if the table doesn’t fit on a phone screen?
The model analyzes content, not layout. But users who visit the site should see a convenient table. Use horizontal scrolling for wide tables or break one table into several small ones by topic. The model sees the table markup regardless of how it’s displayed on screen. The main thing is that the table is marked up as a table.

Do I need to replace all text with lists everywhere?
No. Lists are good for enumerations but useless for explaining cause-and-effect relationships or building arguments. Mix formats: the beginning of a section—coherent text for context, then a list—for key criteria, then a table—for comparison, then an interim conclusion. This is the ideal structure for the model. Additional information can be obtained on the page geo-analysis of a website.