Блог был виден людям, но почти не существовал для краулера

Как стандартный поток Tilda, кнопка «Загрузить ещё» и доверие к sitemap спрятали около 80 статей от нормальной внутренней навигации

На экране всё выглядело исправно. Страница блога открывалась, карточки загружались, по ним можно было перейти в статьи. У каждой публикации был отдельный адрес, заголовок и SEO-настройки. Со стороны это выглядело как обычный работающий раздел сайта.

Проблема обнаружилась только тогда, когда мы решили проверить не то, что видит человек, а содержимое, доступное внешнему краулеру. Вместо названий публикаций и ссылок он получил служебные переменные шаблона: {{title}}, {{text}}, {{published}} и команду %%translate:load_more%%.

Так мы выяснили, что создали блог, удобный для посетителя, но ненадёжный с точки зрения поисковой навигации.

Всё работало. В этом и была проблема

Блог нашего агентства Salvare сделан на Tilda через «Потоки». В разделе было около 80 материалов. Пользователь заходил на страницу, видел карточки статей, нажимал «Загрузить ещё» и продолжал листать публикации.

Никаких явных признаков поломки не было:

- статьи открывались по прямым адресам; - страницы присутствовали в sitemap; - часть материалов уже находилась через поиск; - кнопки и карточки нормально работали в браузере; - в настройках постов были заполнены заголовки и описания.

Обычно на этом проверка заканчивается. Страница открывается, ссылки нажимаются, sitemap сформирован - значит, технически всё в порядке.

Мы тоже сначала так решили.

Проверка, которую мы едва не пропустили

Сомнение появилось, когда мы попытались пройти сайт так, как это сделал бы простой краулер: открыть главную, перейти в блог, найти в списке конкретную публикацию и открыть её без заранее известного URL.

Для теста выбрали статью «Что такое семантическое ядро и зачем оно нужно». По прямой ссылке она открывалась. В поиске её тоже можно было обнаружить. Но на странице блога внешний парсер не находил ни заголовок, ни обычную HTML-ссылку на материал.

Вместо наполненной ленты в разобранном содержимом страницы оставались переменные шаблона:

{{title}}
{{seo-description}}
{{feedtitle}}
{{text}}
{{published}}
%%translate:load_more%%

Браузер после выполнения скриптов показывал человеку готовую ленту, а инструмент, анализирующий доступную структуру страницы, получал почти пустой шаблон.

Это не означает, что любой JavaScript-контент автоматически закрыт от поиска. Google умеет обрабатывать JavaScript и может находить динамически добавленные ссылки, если после рендеринга они представлены обычным элементом <a> с атрибутом href.

Однако поисковая система рекомендует проверять именно отрендеренный HTML. Нельзя исходить только из того, что элемент отображается в браузере и работает при взаимодействии с ним.

Кнопка не является ссылкой

Главной ловушкой стала кнопка «Загрузить ещё».

Для человека это понятное действие: после нажатия появляется следующая часть списка. Для поискового робота механика работает иначе. Краулеры в первую очередь находят URL в атрибутах href у обычных HTML-ссылок. Они не обязаны нажимать кнопки и запускать JavaScript-функции, которым требуется действие пользователя.

В результате первые карточки могут быть доступны после рендеринга, а остальные публикации появляются только после нажатия на кнопку. Человек видит полноценный архив, а краулер - ограниченную часть списка или шаблон без названий материалов.

Работающие карточки статей ещё не доказывают доступность всего раздела для поискового робота. Важнее понять, может ли он самостоятельно найти каждую публикацию, двигаясь по обычным ссылкам от уже известных страниц сайта.

Но у нас же был sitemap

Sitemap действительно был. Более того, Tilda автоматически формирует отдельный sitemap для опубликованных потоков. Поэтому статьи не были полностью изолированы: поисковая система могла узнать об их адресах из XML-файла.

Однако sitemap и внутренняя перелинковка решают разные задачи.

Sitemap передаёт поисковой системе список существующих URL. При этом отправка sitemap считается рекомендацией, а не гарантией обхода и индексирования.

Обычные ссылки не только помогают обнаружить страницу, но и показывают её место в структуре сайта. Дополнительный контекст передаётся через окружающий текст и анкор ссылки.

Проще говоря, sitemap представляет собой перечень адресов, а внутренняя навигация формирует карту связей между документами.

Если статья находится в sitemap и открывается по прямому URL, она не обязательно выпадет из индекса. Но для поискового робота такая страница может выглядеть слабо связанной с остальным сайтом. Особенно когда на неё почти не ведут другие внутренние ссылки.

Почему мы не заметили проблему раньше

Большинство проверок оценивает конечную страницу, а не путь до неё.

Мы проверяли:

- открывается ли URL; - заполнены ли Title и Description; - есть ли статья в sitemap; - не установлена ли директива noindex; - возвращает ли страница код 200; - отображается ли текст после загрузки.

Все эти проверки были полезны, но отвечали только на один вопрос: сможет ли робот обработать конкретную страницу, если её адрес ему уже известен.

При этом мы не проверили, каким способом краулер должен самостоятельно обнаружить этот адрес внутри сайта.

Это важное различие. Техническая возможность проиндексировать страницу ещё не означает, что архитектура сайта выстроена правильно.

Что мы изменили

Мы не стали переписывать блог или отказываться от «Потоков». Проблема была не в самом конструкторе, а в том, что обнаружение публикаций полностью зависело от динамической ленты и sitemap.

На страницу блога добавили обычные HTML-ссылки на материалы:
<a href="/blog/chto-takoe-semanticheskoe-yadro">
Что такое семантическое ядро
</a>

После этого повторили ту же проверку. В разобранном содержимом страницы по-прежнему могли появляться служебные переменные Tilda, но ниже краулер уже видел реальные названия публикаций и их адреса. На момент повторной проверки инструмент смог извлечь 76 ссылок на статьи.

Для пользователя внешний вид раздела практически не изменился. Для робота появилась понятная дорога от страницы блога к каждому материалу.

Дополнительно мы проверили весь маршрут:

главная → блог → конкретная статья.

До исправления путь обрывался на странице блога. После добавления обычных ссылок маршрут стал воспроизводимым без прямого ввода адреса статьи.

Что на самом деле мог потерять сайт

Мы не будем утверждать, что эта ошибка обнулила весь блог или гарантированно лишила нас определённого количества трафика. Такие выводы без чистого эксперимента были бы спекуляцией.

Но архитектура создавала несколько рисков.

Первый - замедленное обнаружение новых публикаций. Если робот не извлекает URL из раздела, ему остаётся ждать обновления sitemap или находить страницу из другого источника.

Второй - слабая внутренняя связность. Статья существует, но страница-хаб не подтверждает её место в блоге обычной ссылкой.

Третий - неравномерный обход архива. Материалы, скрытые за кнопкой «Загрузить ещё», могут получать меньше внимания, чем публикации из первой порции карточек.

Четвёртый - ложное чувство безопасности. Владелец сайта видит работающий интерфейс и не подозревает, что технический потребитель страницы получает другую картину.

Проблема касается не только блогов. Аналогичные ситуации встречаются в каталогах, портфолио, лентах проектов, разделах с отзывами, карточках услуг и товарных категориях с бесконечной прокруткой.

Как проверить свой блог за 20 минут

Не стоит ограничиваться визуальным просмотром страницы. Для проверки можно выбрать статью, расположенную глубоко в архиве, и попытаться обнаружить её без прямого перехода по известному URL.

Сначала нужно открыть главную страницу и найти ссылку на блог. Затем проверить, присутствует ли нужная публикация в исходном или отрендеренном HTML раздела. После этого стоит убедиться, что переход оформлен обычной ссылкой <a href>, а не только обработчиком клика.

Отдельно нужно проверить, доступны ли материалы после первой порции карточек без нажатия на кнопку «Загрузить ещё».

Полезно сравнить четыре источника:

- то, что видит человек в браузере; - исходный HTML; - отрендеренный HTML в инструментах поисковой системы; - список URL, который способен извлечь внешний краулер.

Для проверки отрендеренного содержимого можно использовать инструмент проверки URL в Google Search Console. У Яндекса также есть инструменты, позволяющие оценить страницу после выполнения JavaScript, поскольку итоговое содержимое может отличаться от первоначального ответа сервера.

Различия между результатами ещё не всегда говорят об ошибке. Но это повод разобраться, каким именно способом поисковый робот узнаёт о внутренних страницах.

Главный вывод

Мы привыкли делить сайты на работающие и сломанные. Однако существует и третье состояние: сайт исправно работает для человека, но передаёт поисковому роботу неполную версию своей структуры.

Такая ситуация опаснее явной поломки. Неработающую кнопку замечают сразу. Динамическую ленту, которая красиво отображается, но плохо раскрывает ссылки, можно не замечать месяцами.

После этой истории мы добавили в технические проверки простой пункт: проходить сайт не только как посетитель или владелец, но и как робот, которому заранее неизвестны адреса внутренних страниц.

Страницу можно успешно открыть по прямому URL, но это ещё не значит, что поисковая система сможет самостоятельно её найти.

Автор: команда маркетингового агентства Salvare