Спор о том, засчитывает ли поисковик текст, спрятанный в табах и аккордеонах, тянется больше десяти лет. Одни оптимизаторы до сих пор вываливают всю информацию сплошной простынёй, потому что побаиваются невидимых блоков. Другие спокойно сворачивают половину страницы и не замечают просадок. Ответ Google давно сформулирован, и всё же в нём хватает нюансов, из-за которых сайты продолжают терять охват запросов. Дальше разберём, что робот видит под свёрнутым блоком, когда скрытый текст действительно не попадает в индекс и почему мобильная вёрстка способна обесценить даже аккуратно подготовленный контент.
Что происходит с текстом в табах на этапе рендеринга страницы
Поисковая машина работает со страницей в два прохода. Сначала краулер забирает исходный HTML, ровно то, что отдал сервер. Затем ссылка попадает в очередь рендеринга, где страница открывается в движке на базе актуального Chromium: скрипты исполняются, стили применяются, компоненты дорисовываются. Для индексирования Google берёт итоговое дерево DOM, а не скриншот и не картинку, а именно структуру узлов вместе с их текстом.
Отсюда первый практический вывод. Табы и аккордеоны почти всегда устроены одинаково: все панели уже лежат в разметке, а переключение видимости выполняет CSS. Панель со свойством display none никуда не исчезает из DOM, она лишь не показывается на экране. Робот читает дерево целиком, поэтому текст из свёрнутой панели для него существует и попадает в индекс наравне с видимым. По той же причине индексируются значения, подставленные JavaScript после загрузки, если скрипт отработал до завершения рендеринга.
Скорость здесь решает многое. Исторически разрыв между первым проходом и рендерингом доходил до нескольких дней, а то и недель: страница попадала в индекс в урезанном виде, а полный вариант появлялся позже. К 2026 году отставание у большинства сайтов сократилось до минут и часов, но ресурсы с тяжёлым JavaScript по-прежнему задерживаются в очереди, а на исполнение скриптов отводится ограниченный лимит времени. Если за отведённое время табы не успели отрисоваться, робот зафиксирует страницу без спрятанных панелей, и до следующего визита она останется в индексе урезанной.
Официальная позиция Google по скрытому контенту и её история с 2014 года
Ещё в 2014 году представители поиска в публичных ответах вебмастерам объясняли, что текст в табах и аккордеонах индексируется и учитывается при ранжировании. Когда в 2018 году началось развёртывание mobile-first индексации, позиция прозвучала ещё определённее: контент в свёрнутых блоках получает полный вес, поэтому прятать его не запрещено и не страшно. С тех пор подход не менялся, и в 2026 году логика осталась прежней. Скрытие ради удобства интерфейса, отзывчивой вёрстки и экономии места считается нормальным приёмом, а не попыткой обойти правила.
Граница проходит по намерению. Аккордеон, который экономит место на экране и упрощает навигацию, поисковик воспринимает спокойно. А вот блоки, набитые ключами и убранные за пределы экрана или залитые цветом фона, попадают под определение скрытого текста, направленного на манипуляцию выдачей. Разница видна в коде почти мгновенно: у безобидной панели есть смысловая роль, заголовок и управляющая кнопка, у спамной обычно только нагромождение повторов и сомнительные стили со сдвигом в минус две тысячи пикселей.
Отдельный штрих к портрету 2026 года касается микроразметки. Структурированные данные для часто задаваемых вопросов, которые нередко вешают на свёрнутые блоки, с августа 2023 года приносят расширенный сниппет в основном государственным и медицинским сайтам. Для остальных ресурсов такая разметка остаётся просто способом описать структуру, но красивый сниппет уже не гарантирует. На индексацию самого текста это изменение никак не повлияло.
Когда аккордеон действительно прячет текст от индексации
Проблемы начинаются там, где контента в исходном HTML нет вообще. Типовой сценарий выглядит так. Панель таба пустая, её заполняет скрипт только после клика, отправляя запрос к внутреннему API. Пока человек не нажал кнопку, текста в DOM не существует. Робот кликов не делает, он не взаимодействует со страницей как пользователь, поэтому второй, третий и пятый табы остаются для него пустыми.
Показательный фрагмент:
btn.addEventListener('click', async () => {
const res = await fetch('/api/reviews?product=42');
panel.innerHTML = await res.text();
});Пока клика не было, внутри панели пусто. Похожие ловушки расставлены и в других местах. Отзывы, подгружаемые только при прокрутке внутри свёрнутого блока, требуют от робота действий, которых он не выполняет. Контент за авторизацией невидим в принципе. Если путь к внутреннему API закрыт в robots.txt или отдаёт ошибку для чужих агентов, рендерер не получит данные, даже когда сам скрипт корректный. Тяжёлые одностраничные приложения добавляют свой риск: у рендеринга есть свои лимиты времени, и сложная страница иногда не успевает собрать всё содержимое до их истечения.
Посчитаем на типовой карточке товара с пятью табами по 800 знаков в каждом. Если все пять панелей лежат в HTML, робот видит 4000 знаков. Если же четыре панели подтягиваются запросами по клику, в разметке остаётся около 800 знаков. Потенциальные запросы из отзывов, характеристик и условий доставки превращаются в слова, которых в индексе нет, и охват запросов урезается не на проценты, а в разы. Именно поэтому страницы с ленивой подгрузкой контента внезапно выпадают из выдачи по низкочастотным формулировкам, хотя для людей всё выглядит безупречно.
Разметка, которая оставляет контент видимым для поискового робота
Самый простой рабочий вариант свёрнутого блока без единой строки скриптов даёт нативный элемент details. Содержимое уже находится в HTML, браузер лишь прячет его до клика по строке заголовка.
<details>
<summary>Характеристики модели</summary>
<p>Мощность 1200 Вт, вес 2,4 кг, длина шнура 5 м, гарантия 24 месяца.</p>
</details>Робот видит полный текст сразу, потому что он присутствует в разметке независимо от состояния блока. Такой каркас отлично подходит для характеристик, условий доставки и ответов на вопросы.
Классические табы собираются похожим образом. Ключевое правило звучит коротко: все панели в HTML, клик лишь переключает классы.
<div class="tabs">
<button class="tab active" data-panel="p1">Описание</button>
<button class="tab" data-panel="p2">Характеристики</button>
<div class="panel active" id="p1">Подробное описание товара на 800 знаков.</div>
<div class="panel" id="p2">Таблица параметров и комплектация.</div>
</div>CSS при этом минимальный:
.panel { display: none; }
.panel.active { display: block; }Для робота безразлично, какой класс активен, потому что оба текста присутствуют в DOM до любых нажатий. Надёжный фундамент поверх такой схемы – серверный рендеринг или статическая генерация, когда сервер отдаёт готовый HTML со всеми панелями ещё до первого скрипта. Клиентский фреймворк дальше может анимировать переключения сколько угодно, база уже собрана.
Вес скрытого текста в ранжировании и числовые ориентиры охвата
Официально спрятанные панели получают полный вес, однако практика вносит коррективы. Оптимизаторы описывают обе картины. Часть тестов не находит разницы между текстом на виду и тем же текстом в табах. Часть фиксирует небольшой отрыв в пользу видимого варианта, особенно на конкурентных запросах. Разумная рабочая гипотеза звучит осторожно: индексируемость полная, а сила сигнала у спрятанного абзаца может быть скромнее, чем у текста на виду.
Оценить масштаб помогает условный расчёт. Пусть на странице сразу видно 1500 знаков, а ещё 3500 спрятано в аккордеонах. Если спрятанная часть работает хотя бы с половинной силой, она всё равно приносит пользу по редким запросам, где конкуренция ниже и хватает минимального совпадения. Слабое место проявляется на среднечастотных формулировках, где между соседними позициями лежит тонкая грань и половинная сила уже не спасает. Отсюда практическое правило. Главный смысловой блок, отвечающий на основной запрос страницы, оставляют на виду, а вспомогательные материалы, характеристики, отзывы и ответы на вопросы спокойно укладывают в табы и аккордеоны. Такой баланс сохраняет и охват, и вес ключевых формулировок.
Подводные камни мобильных версий при mobile-first индексации
К началу 2020-х Google перевёл поиск на mobile-first индексацию: базой для ранжирования служит мобильная версия, а краулинг идёт агентом smartphone Googlebot. Именно здесь живут самые дорогие ошибки, и почти все они связаны с расхождением версий.
Первая и самая частая ловушка. Десктоп отдаёт полный текст, а мобильный шаблон прячет его за аккордеоном и заодно отрезает часть абзацев ради скорости загрузки. Если отрезание происходит на уровне CSS, беды нет, в DOM текст остаётся. Если же мобильный шаблон вообще не выводит блок, индекс получает усечённую страницу. Расхождения между версиями в несколько раз по объёму текста на аудитах встречаются сплошь и рядом.
Вторая ловушка связана с фреймворками. Компонент проверяет ширину экрана и возвращает пустой узел на мобильных устройствах.
if (window.matchMedia('(max-width: 768px)').matches) {
return null; // блока нет даже в мобильном DOM
}На широком экране панель существует, на смартфоне её нет даже в коде. Разработчик любуется аккуратным дизайном, а робот индексирует пустоту и честно переносит её в поиск.
Третья ловушка касается самих аккордеонов на десктопе при mobile-first подходе. Привычка сворачивать всё подряд перекочевала с телефонов на широкие экраны: десяток свёрнутых секций, сотни отзывов, таблицы в каждом табе. Само по себе это не приговор, но мобильный шаблон, повторяющий такую структуру, несёт тяжёлые скрипты и рискует не уложиться в лимит рендеринга. Медленный код, который не успевает развернуть данные за отведённое время, оставляет робота с пустыми панелями уже на мобильной версии, то есть ровно там, откуда собирается индекс.
Четвёртая ловушка прямолинейна. Владельцы убирают с телефонного экрана таблицы сравнения, развёрнутые описания и блоки с ценами, оставляя их только на широких экранах. Формально правила не нарушены, фактически эти темы вычеркнуты из мобильной страницы, а значит и из индекса, по которому строится ранжирование для всех устройств.
Проверка страницы глазами поискового робота перед публикацией
Теория проверяется за несколько минут прямо в браузере и в панели для вебмастеров. Порядок действий простой:
- Открыть исходный код страницы через Ctrl+U и найти в нём текст из свёрнутой панели, чтобы убедиться, что контент отдан сервером;
- Запустить инструменты разработчика клавишей F12, дождаться полной отрисовки и сверить дерево DOM с исходным кодом, особое внимание уделяя пустым панелям;
- Отключить JavaScript в настройках DevTools и перезагрузить страницу, чтобы увидеть, сколько контента выживает без скриптов;
- В Search Console ввести адрес и изучить отрендеренный HTML из блока просмотра просканированной страницы, это самый близкий взгляд на то, что получает Google;
- Повторить ту же проверку на мобильном разрешении и сравнить объём текста в DOM с десктопным вариантом.
Отдельного внимания заслуживают расхождения между исходным кодом и отрендеренным. Если Ctrl+U показывает панель, а отрендеренный HTML её теряет, виноват скрипт, который падает или не успевает отработать. Если наоборот, исходный код пуст, а рендер всё собирает, страница зависит от исполнения JavaScript, и тогда любая ошибка в коде или блокировка запроса превращается в потерянный контент. Обе ситуации лечатся на стороне разметки: контент переезжает в исходный HTML, а скриптам остаётся только управление видимостью.
Итоговый расклад в 2026 году получается прозрачным. Текст, который лежит в HTML, пусть даже под display none, попадает в индекс и работает на охват запросов. Текст, который появляется только после клика и запроса к серверу, для поисковика не существует. Мобильная версия задаёт то, что увидит робот, поэтому паритет контента между версиями проверяют до релиза, а не после падения трафика. Табы и аккордеоны остаются легальным и удобным приёмом, если помнить одну вещь: спрятать можно показ, но не сам контент.